Jestem rootem. Zrozumienie eskalacji uprawnień systemu operacyjnego Linux

Pierwszy kwartał 2020 roku spędziłam przygotowując się do egzaminu OSCP. Wyszukiwanie informacji w Google i wiele "ślepych" prób pochłaniało cały mój wolny czas. Szczególnie trudne okazało się zrozumienie mechanizmów eskalacji uprawnień. Kurs PWK przywiązuje dużą wagę do tego tematu, ale materiałów metodycznych to zawsze za mało. W internecie jest sporo poradników z przydatnymi komendami, ale nie jestem zwolennikiem ślepego stosowania się do zaleceń bez zrozumienia do czego to doprowadzi.

Chciałbym podzielić się z Wami tym, czego udało mi się nauczyć podczas przygotowań i pomyślnego zdania egzaminu (w tym okresowych nalotów na Hack The Box). Poczułem głęboką wdzięczność za każdą informację, która pomogła mi bardziej świadomie kroczyć ścieżką Próbuj mocniej. Teraz nadszedł czas, aby coś odwdzięczyć się społeczności.

Chcę dać ci przewodnik po eskalacji uprawnień w OS Linux, który zawiera analizę najczęstszych wektorów i powiązanych funkcji, których na pewno będziesz potrzebować. Często same mechanizmy eskalacji uprawnień są dość proste, pojawiają się trudności podczas strukturyzacji i analizy informacji. Dlatego postanowiłem zacząć od „wycieczki krajoznawczej”, a następnie rozważyć każdy wektor w osobnym artykule. Mam nadzieję, że oszczędzę Ci czasu na zapoznanie się z tematem.

Jestem rootem. Zrozumienie eskalacji uprawnień systemu operacyjnego Linux

Dlaczego więc eskalacja uprawnień jest w ogóle możliwa w 2020 r., skoro metody są dobrze znane od bardzo dawna? Tak naprawdę, jeśli użytkownik poprawnie obsłuży system, to naprawdę nie będzie w nim możliwości podwyższenia uprawnień. Głównym globalnym problemem, który stwarza takie możliwości, jest niepewna konfiguracja. Szczególnym przypadkiem niebezpiecznej konfiguracji jest również obecność w systemie nieaktualnych wersji oprogramowania zawierających luki.

Eskalacja uprawnień przez niezabezpieczoną konfigurację

Przede wszystkim zajmijmy się niepewną konfiguracją. zacznijmy od Specjaliści IT często korzystają z podręczników i zasobów, takich jak stackoverflow, z których wiele zawiera niebezpieczne polecenia i konfiguracje. Uderzającym przykładem jest wiadomości że kod najczęściej kopiowany z stackoverflow zawierał błąd. Doświadczony administrator zobaczy ościeżnicę, ale jest to idealny świat. Nawet kompetentni fachowcy zwiększone obciążenie pracą zdolny do popełniania błędów. Wyobraź sobie, że administrator przygotowuje i zatwierdza dokumentację do kolejnego przetargu, jednocześnie zagłębiając się w nową technologię, która zostanie wprowadzona w kolejnym kwartale, okresowo rozwiązując zadania wsparcia użytkowników. Następnie otrzymuje zadanie szybkiego stworzenia kilku maszyn wirtualnych i wdrożenia na nich usług. Jak myślisz, jakie jest prawdopodobieństwo, że administrator po prostu nie zauważy ościeża? Potem zmieniają się specjaliści, ale kule pozostają, a firmy zawsze dążą do minimalizacji kosztów, także tych dla informatyków.

Pseudo powłoka i jailbreak

Powłoka systemu uzyskana podczas fazy produkcyjnej jest często ograniczona, zwłaszcza jeśli uzyskałeś ją poprzez zhakowanie użytkownika serwera WWW. Na przykład ograniczenia powłoki mogą uniemożliwić użycie polecenia sudo z błędem:

sudo: no tty present and no askpass program specified

Po zdobyciu powłoki polecam stworzenie pełnoprawnego terminala, na przykład z Pythonem.

python -c 'import pty;pty.spawn("/bin/bash")'

Pytasz: „Po co mi tysiąc poleceń, skoro jednego mogę użyć na przykład do przesyłania plików?” Faktem jest, że systemy są różnie konfigurowane, na następnym hoście może nie być zainstalowany Python, ale dostępny jest Perl. Umiejętność polega na wykonywaniu znanych rzeczy w systemie bez znanych narzędzi. Pełną listę funkcji można znaleźć tutaj.

Powłokę o niskich uprawnieniach można uzyskać za pomocą zespoły 1 и zespoły 2 (o dziwo nawet GIMP).

Wyświetl historię poleceń

Linux gromadzi historię wszystkich wykonanych poleceń w pliku ~ / .bash_historia. Jeśli serwer jest aktywnie używany, a jego historia nie jest wyczyszczona, istnieje duża szansa, że ​​dane uwierzytelniające zostaną znalezione w tym pliku. Czyszczenie historii jest banalnie niewygodne. Jeżeli administrator jest zmuszony wybierać komendy dziesięciopoziomowe przez , oczywiście wygodniej będzie mu wywołać tę komendę z historii niż wpisywać ją ponownie. Ponadto wielu nie wie o tym „hacku”. Jeśli w systemie istnieją alternatywne muszle, takie jak Zsh lub Fish, mają one swoją własną historię. Aby wyświetlić historię poleceń w dowolnej powłoce, wystarczy wpisać historię poleceń.

cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_history

Istnieje hosting współdzielony, w którym serwer służy do hostowania kilku witryn. Zazwyczaj w tej konfiguracji każdy zasób ma własnego użytkownika z oddzielnym katalogiem domowym i hostem wirtualnym. Tak więc, jeśli skonfigurowano niepoprawnie, możesz znaleźć plik .bash_history w katalogu głównym zasobu internetowego.

Wyszukiwanie haseł w systemie plików i ataki na sąsiednie systemy

Pliki konfiguracyjne różnych usług mogą być czytelne dla bieżącego użytkownika. Można w nich znaleźć poświadczenia w postaci zwykłego tekstu - hasła dostępu do bazy danych lub usług powiązanych. To samo hasło może służyć zarówno do dostępu do bazy danych, jak i do autoryzacji użytkownika root (zarządzanie poświadczeniami).
Zdarza się, że znalezione poświadczenia należą do usług na innych hostach. Rozwój ataku na infrastrukturę za pośrednictwem skompromitowanego hosta nie jest gorszy niż wykorzystanie innych hostów. Sąsiednie systemy można również znaleźć, wyszukując adresy IP w systemie plików.

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Find string password (no cs) in those directories
grep -a -R -o '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' /var/log/ 2>/dev/null | sort -u | uniq #IPs inside logs

Jeśli zainfekowany host ma aplikację internetową dostępną z Internetu, lepiej wykluczyć jej logi z wyszukiwania adresów IP. Sądząc po logi, mogą być interesujące.

Sudo

Polecenie sudo umożliwia użytkownikowi wykonanie polecenia w kontekście roota przy użyciu własnego hasła lub bez użycia go w ogóle. Wiele operacji w Linuksie wymaga uprawnień roota, ale uruchamianie jako root jest uważane za bardzo złą praktykę. Zamiast tego lepiej zastosować selektywne uprawnienia do wykonywania poleceń w kontekście roota. Jednak wiele narzędzi Linuksa, w tym standardowe, takie jak vi, może służyć do eskalacji uprawnień w legalny sposób. Aby znaleźć właściwą drogę, polecam szukać tutaj.

Pierwszą rzeczą do zrobienia po uzyskaniu dostępu do systemu jest uruchomienie komendy sudo -l. Wyświetli pozwolenie na użycie polecenia sudo. Jeśli zostanie uzyskany użytkownik bez hasła (taki jak Apache lub www-data), wektor eskalacji uprawnień sudo jest mało prawdopodobny. Podczas korzystania z sudo system poprosi o hasło. Użycie polecenia passwd do ustawienia hasła również nie zadziała, poprosi o podanie bieżącego hasła użytkownika. Ale jeśli sudo jest nadal dostępne, w rzeczywistości musisz poszukać:

  • dowolni tłumacze, każdy może spawnować powłokę (PHP, Python, Perl);
  • dowolne edytory tekstu (vim, vi, nano);
  • dowolni widzowie (mniej, więcej);
  • wszelkie możliwości pracy z systemem plików (cp, mv);
  • narzędzia, które mają wyjście w bash, interaktywnie lub jako polecenie wykonywalne (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

W Internecie jest wiele podręczników, które zalecają budowanie wszystkich poleceń suid / sgid, ale rzadki artykuł zawiera szczegółowe informacje na temat tego, co należy zrobić z tymi programami. Można znaleźć opcje eskalacji uprawnień, które nie uwzględniają wykorzystania exploitów tutaj. Ponadto wiele plików wykonywalnych ma określone luki w zabezpieczeniach wersji systemu operacyjnego, Przykładowo.

W idealnym świecie powinieneś uruchamiać wszystkie zainstalowane pakiety przynajmniej przez searchsploit. W praktyce należy to zrobić za pomocą najpopularniejszych programów, takich jak sudo. Zawsze istnieje również opcja wykorzystania i wspierania rozwoju zautomatyzowanych narzędzi, które wyróżnią interesujące, z punktu widzenia eskalacji uprawnień, pliki wykonywalne z ustawionymi bitami suid/sgid. Podam listę takich narzędzi w odpowiedniej części artykułu.

Zapisywalne skrypty uruchamiane przez Cron lub Init w kontekście rootowania

Zadania Cron mogą działać w kontekście różnych użytkowników, w tym root. Jeśli w cronie znajduje się zadanie z linkiem do pliku wykonywalnego i jest ono dostępne do napisania, możesz łatwo zastąpić je złośliwym i wykonać eskalację uprawnień. Jednocześnie domyślnie pliki z zadaniami cron są dostępne do odczytu dla każdego użytkownika.

ls -la /etc/cron.d  # show cron jobs 

Podobnie jest z init. Różnica polega na tym, że zadania w cron są wykonywane okresowo, aw init - podczas uruchamiania systemu. Do działania konieczne będzie ponowne uruchomienie systemu, podczas gdy niektóre usługi mogą się nie podnieść (jeśli nie zostały zarejestrowane w automatycznym ładowaniu).

ls -la /etc/init.d/  # show init scripts 

Możesz także wyszukiwać pliki, które każdy użytkownik może zapisać.

find / -perm -2 -type f 2>/dev/null # find world writable files

Metoda jest dość dobrze znana, doświadczeni administratorzy systemu ostrożnie używają polecenia chmod. Jednak w Internecie zdecydowana większość instrukcji opisuje ustawienie maksymalnych praw. Podejście „po prostu spraw, żeby to działało” niedoświadczonych administratorów systemu zasadniczo stwarza możliwości eskalacji uprawnień. Jeśli to możliwe, najlepiej poszukać w historii poleceń niebezpiecznych zastosowań chmod.

chmod +w /path 
chmod 777 /path

Uzyskanie dostępu do powłoki dla innych użytkowników

Patrzymy na listę użytkowników w /etc/passwd. Zwracamy uwagę na tych, którzy mają muszlę. Możesz zbrutować tych użytkowników - możliwe, że poprzez wynikowego użytkownika będziesz mógł ostatecznie zwiększyć uprawnienia.

Aby poprawić bezpieczeństwo, zalecam, aby zawsze przestrzegać zasady najmniejszych uprawnień. Warto również poświęcić czas na sprawdzenie niezabezpieczonych konfiguracji, które mogą pozostać po rozwiązaniu problemu - jest to „techniczny obowiązek” administratora systemu.

Kod napisany samodzielnie

Warto dokładnie przyjrzeć się plikom wykonywalnym w katalogu domowym użytkownika i serwera WWW (/var/www/, chyba że zaznaczono inaczej). Pliki te mogą okazać się całkowicie niepewnym rozwiązaniem i zawierać niesamowite kule. Oczywiście, jeśli masz jakiś framework w katalogu serwera WWW, nie ma sensu szukać w nim dnia zerowego w ramach pentestu, ale zaleca się znalezienie i przestudiowanie niestandardowych modyfikacji, wtyczek i komponentów.

Aby zwiększyć bezpieczeństwo, lepiej unikać używania poświadczeń w samodzielnie napisanych skryptach, a także potencjalnie niebezpiecznych funkcji, takich jak czytanie /etc/shadow lub manipulowanie id_rsa, jeśli to możliwe.

Podniesienie uprawnień poprzez wykorzystanie luk w zabezpieczeniach

Przed podjęciem próby podniesienia uprawnień poprzez eksploatację ważne jest, aby zrozumieć przesyłanie plików do hosta docelowego. Oprócz zwykłych narzędzi, takich jak ssh, ftp, http (wget, curl), istnieje całość „zoo” możliwości.

Aby poprawić bezpieczeństwo swojego systemu, aktualizuj go regularnie do najnowszej wersji stabilny wersje, a także spróbuj użyć dystrybucji zaprojektowanych dla Enterprise. W przeciwnym razie rzadko, ale zdarzają się sytuacje, gdy apt upgrade powoduje, że system jest bezużyteczny.

Eksploatacja usług uruchomionych w kontekście użytkownika root

Niektóre usługi systemu Linux działają jako uprzywilejowany użytkownik root. Można je znaleźć za pomocą polecenia ps aux | korzeń grepa. W takim przypadku usługa może nie być ogłoszona w sieci i być dostępna lokalnie. Jeśli ma publiczne exploity, można ich bezpiecznie używać: awaria usługi w przypadku awarii jest znacznie mniej krytyczna niż awaria systemu operacyjnego.

ps -aux | grep root # Linux

Za najbardziej udany przypadek można uznać działanie zhakowanej usługi w kontekście użytkownika root. Obsługa usługi SMB daje SYSTEMowi uprzywilejowany dostęp w systemach Windows (np. przez ms17-010). Jednak nie jest to powszechne w systemach Linux, więc możesz poświęcić dużo czasu na eskalację uprawnień.

Wykorzystanie luk w jądrze Linuksa

To jest ostatnia droga do obrania. Nieudana operacja może doprowadzić do awarii systemu, aw przypadku ponownego uruchomienia niektóre usługi (w tym te, przez które można było uzyskać oryginalną powłokę) mogą się nie podnieść. Zdarza się, że administrator po prostu zapomniał użyć polecenia systemctl enable. Ponadto spowoduje to wiele niezadowolenia z twojej pracy, jeśli nie uzgodniono eksploatacji.
Jeśli zdecydujesz się na wykorzystanie źródeł z exploitdb, koniecznie przeczytaj komentarze na początku skryptu. Między innymi zwykle mówi, jak poprawnie skompilować tego exploita. Jeśli byłeś zbyt leniwy lub potrzebowałeś „na wczoraj” ze względu na terminy, możesz poszukać repozytoriów z już skompilowanymi exploitami, Przykładowo. Należy jednak rozumieć, że w tym przypadku dostaniesz świnię w szturchnięcie. Z drugiej strony, gdyby programista rozumiał co do bajtu, jak działa komputer i jakiego oprogramowania używa, w całym swoim życiu nie napisałby ani linijki kodu.

cat /proc/version
uname -a
searchsploit "Linux Kernel" 

Metasploit

Aby przechwycić i obsłużyć połączenie, zawsze lepiej jest użyć modułu exploit/multi/handler. Najważniejsze jest ustawienie poprawnego ładunku, na przykład generic/shell/reverce_tcp lub generic/shell/bind_tcp. Powłokę uzyskaną w Metasploit można zaktualizować do Meterpretera za pomocą modułu post/multi/manage/shell_to_meterpreter. Dzięki Meterpreter możesz zautomatyzować proces poeksploatacyjny. Na przykład moduł post/multi/recon/local_exploit_suggester sprawdza platformę, architekturę i elementy możliwe do wykorzystania oraz sugeruje moduły Metasploit do eskalacji uprawnień w systemie docelowym. Dzięki Meterpreterowi eskalacja uprawnień czasami sprowadza się do uruchomienia odpowiedniego modułu, ale hakowanie bez zrozumienia tego, co dzieje się pod maską, nie jest prawdą (i tak trzeba napisać raport).

Tools

Narzędzia do automatyzacji lokalnego zbierania informacji zaoszczędzą Ci wiele wysiłku i czasu, ale same w sobie nie są w stanie w pełni zidentyfikować ścieżki eskalacji uprawnień, szczególnie w przypadku wykorzystania luk w jądrze. Narzędzia automatyzacji wykonają za Ciebie wszystkie niezbędne polecenia do zebrania informacji o systemie, ale ważna jest też umiejętność analizować otrzymane dane. Mam nadzieję, że mój artykuł będzie Ci w tym przydatny. Oczywiście jest o wiele więcej narzędzi, niż wymienię poniżej, ale wszystkie robią to samo - to bardziej kwestia gustu.

Linpeas

Dość świeże narzędzie, pierwsze zatwierdzenie jest datowane na styczeń 2019 r. Obecnie mój ulubiony instrument. Najważniejsze jest to, że podkreśla najciekawsze wektory eskalacji uprawnień. Zgadzam się, wygodniej jest uzyskać ocenę eksperta na tym poziomie niż analizować monolityczne surowe dane.

LinEnum

Moje drugie ulubione narzędzie, które również zbiera i porządkuje dane otrzymane w wyniku lokalnego wyliczania.

linux-exploit-sugester(1,2)

Ten exploit przeanalizuje system pod kątem odpowiednich warunków dla exploitów. W rzeczywistości wykona zadanie identyczne z modułem Metasploit local_exploit_suggester, ale będzie oferować linki do kodów źródłowych exploit-db zamiast modułów Metasploit.

Narzędzie sprawdzania prywatności Linuksa

Ten skrypt zbierze i zorganizuje według sekcji dużą ilość informacji, które mogą być przydatne do tworzenia wektora eskalacji uprawnień.

Innym razem doprecyzuję Eskalacja uprawnień Linuksa przez suid/sgid.

Źródło: www.habr.com

Dodaj komentarz