Prezentacja luk w systemie Ubuntu 9.04

Na zajęciach z bezpieczeństwa IT chcę pokazać uczniom eskalację uprawnień. Aby to zrobić, przejrzałem exploit/linux/locallistę w Metasploit Framework, znajdując (między innymi) exploit/linux/local/sock_sendpageod sierpnia 2009 roku.

Skonfigurowałem maszynę wirtualną z 32-bitowym Ubuntu Server 9.04 ( http://old-releases.ubuntu.com/releases/9.04/ubuntu-9.04-server-amd64.iso ) od kwietnia 2009. uname -rDaje mi 2.6.28-11-generic. Zgodnie z opisem exploita

Uważa się, że dotyczy to wszystkich wersji systemu Linux 2.4 / 2.6 od maja 2001 r .: 2.4.4 do wersji 2.4.37.4 włącznie; 2.6.0 do 2.6.30.4 włącznie

Wydaje się więc, że skonfigurowany przeze mnie serwer Ubuntu powinien nadawać się do demonstracji. Nie udało mi się jednak uruchomić go.

Dodałem (zwykłego) użytkownika na serwerze i działa dostęp do SSH. Z poziomu Metasploit Framework mogę utworzyć sesję SSH przy użyciu auxiliary/scanner/ssh/ssh_login. Jednak kiedy uruchamiam exploita, otrzymuję

[*] Writing exploit executable to /tmp/mlcpzP6t (4069 bytes)

[*] Exploit completed, but no session was created.

Nie otrzymuję żadnych dalszych informacji, nawet jeśli ustawię wartość DEBUG_EXPLOITtrue. /tmpjest zapisywalny, również z sesji SSH Metasploit:

$ sessions -c "touch /tmp/test.txt"
[*] Running 'touch /tmp/test.txt' on shell session 1 ([redacted])

$ sessions -c "ls -l /tmp"
[*] Running 'ls -l /tmp' on shell session 1 ([redacted])

total 0

-rw-r--r-- 1 [redacted] [redacted] 0 2016-03-28 09:44 test.txt

Próbowałem też ustawić WriteableDirkatalog domowy użytkownika na serwerze, ale bez żadnych zmian. Czego tu brakuje? Czy ta wersja serwera Ubuntu (której celowo nie zaktualizowałem!) Nie jest zagrożona?

Wydanie 9.04 było obsługiwane do 23 października 2010 r. Znaleziona luka została zgłoszona w sierpniu 2009 r. Wydaje się uzasadnione, że ponieważ wydanie było wciąż aktualne i obsługiwane w tym czasie, ISO zostało załatane, a pobrana wersja była wersją, która jest nie jest już wrażliwy.

Co więcej, wydajesz się całkiem ładnie wykazać, że nie jest wrażliwy. W końcu próbowałeś wykorzystać exploita i wygląda na to, że się nie udało.

Dlaczego nie spróbujesz nowszego exploita? Coś takiego jak CVE-2013-2094, który powinien również wpłynąć na przykład na Ubuntu .

To nie odpowiada na konkretne zapytanie, a raczej daje więcej możliwości prywatnego wyboru, aby pokazać uczniom ...

Możesz także rozważyć dwie następujące konfiguracje administratora, które mogą prowadzić do esc esc na 'nix (istnieje wiele innych sposobów na pominięcie konfiguracji skrzynki' nix, która może zezwalać na esc esc, więc rozważ to zaostrzenie apetytu) …

1. pliki binarne suid i guid będące własnością root / root group ( find / -uid 0 -perm -4000 -type f 2>/dev/nulli find / -uid 0 -perm -2000 -type f 2>/dev/null) i sprawdź, czy można je zapisywać na całym świecie, aby umożliwić użytkownikom o niskich uprawnieniach ich zmianę; folder, w którym się znajdują, jest zapisywalny przez użytkownika o niskich uprawnieniach - w celu ewentualnego wstrzyknięcia ścieżki biblioteki. Co z bibliotekami, których używają - czy można je zmienić: sprawdź wartości dowolnych DT_RPATHi DT_RUNPATHnagłówków ELF w plikach binarnych za pomocą jednego z następujących poleceń:

   • objdump -x ...
   • readelf -a ...
   • scanelf (z PaX)
   • elfdump (od Słońca)
   • readelf -a binary | grep PATH

2. sudoers wady

   • NOPASSWD - Lokalny atakujący może użyć tego dostępu do zwiększenia swoich uprawnień w systemie operacyjnym, gdy użytkownik zapomni zablokować ekran

   • Brak plików wykonywalnych w Sudoers - Niektóre pliki wykonywalne w /etc/sudoerspliku nie istnieją. Jeśli pliki wykonywalne są tworzone, można je uruchamiać za pomocą sudo jako root, co pozwoliłoby na zwiększenie uprawnień.

   • Osierocone wpisy sudoers - /etc/sudoersplik może zawierać wiele osieroconych wpisów, dla których nie ma w nim odpowiedniego konta /etc/passwd. Jeśli użytkownik został utworzony z jedną z osieroconych nazw, zapewniłby mu to możliwość zwiększenia uprawnień do pełnego dostępu do konta root.

   • Niektóre programy nie powinny być w stylu sudo vi, używać :elub Ctrl o używać :wdo uzyskiwania dostępu /etc/shadow.

   • Niepoprawnie przemyślane / złe polecenie użyte w pliku sudoers - często widuję httpdw sudoers - więc spróbuj jako użytkownik o niskim poziomie uprawnień z dostępem sudo, aby uruchomić tylko to polecenie ( sudo -llub sudo -llpokaże, co użytkownik może zrobić): sudo /usr/bin/httpd -t /etc/shadowi spójrz na błąd.

   • perms plików poleceń i plików wymienionych w sudoers są słabe - zobacz mój wcześniejszy akapit na temat plików binarnych suid i guid będących własnością root