Prezentacja luk w systemie Ubuntu 9.04

15

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?

Andreas Unterweger
źródło
Przynajmniej powinieneś sprawdzić dzienniki maszyny wirtualnej.
Klaatu von Schlacker
@KlaatuvonSchlacker: Czego dokładnie szukam? Właśnie uruchomiłem ponownie exploita i do dziennika żadnej maszyny wirtualnej nie dodano żadnych nowych wpisów.
Andreas Unterweger

Odpowiedzi:

16

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 .

terdon
źródło
Wydaje się, że nie ma modułu Metasploit dla CVE-2013-2094. Czy są jakieś inne exploity z modułami Metasploit, które mogą działać? exploit / linux / local / pkexec z 2011 roku wydawał się obiecujący, ale daje takie same wyniki jak exploit / linux / local / sock_sendpage .
Andreas Unterweger
@AndreasUnterweger och, przepraszam, nie wiedziałem, że nie ma modułu. Właśnie to znalazłem losowo, wyszukując „eskalację uprawnień”. Jeśli chodzi o pkexecexploit, czy sprawdziłeś wersję libpolkit-backend-1? Strona, do której prowadzi link, stwierdza, że ​​podatność wymaga wersji starszej niż 0.94-1ubuntu1.1.
terdon
Zgodnie z dpkg -s libpolkit2zainstalowaną wersją jest 0.9-2ubuntu1.
Andreas Unterweger
@AndreasUnterweger w takim przypadku nie mam pojęcia. Przepraszam. Lepiej opublikuj pytanie na temat bezpieczeństwa informacji , prosząc o konkretną kombinację wykorzystania i dystrybucji eskalacji uprawnień, o której wiadomo, że działa.
terdon
@AndreasUnterweger i ThorbjørnRavnAndersen prosimy o rozmowę na czacie . Przeniosłem już tam twoje poprzednie komentarze.
terdon
1

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

Richard Braganza
źródło
btw możesz także wypróbować oryginalny kod Spendera dla modułu metasploit na wypadek, gdyby moduł metasploit nie był całkiem poprawny: grsecurity.net/~spender/exploits
Richard Braganza
Bardzo dziękuję za wystawienie tych przedmiotów. Obawiam się jednak, że obie grupy przedmiotów będą wymagały od uczniów zbyt wielu informacji i kontekstu - na tym etapie ledwo znają Linuksa. Chcę im pokazać, że eskalacja uprawnień jest prawdziwą rzeczą i że zawsze powinni łatać systemy, za które są / będą odpowiedzialni. Jak na ironię, jak dotąd nie udało mi się wykazać faktycznej eskalacji uprawnień, jak opisano powyżej. EDYCJA: Rzucę okiem na kod Spendera, ale obecnie brakuje mi niestety czasu. Dziękuję bardzo za link.
Andreas Unterweger