🥇Jestem root. Zajmujemy się podnoszeniem uprawnień w OS Linux

Pierwszy kwartał 2020 roku spędziłem na przygotowaniach do egzaminu OSCP. Szukanie informacji w Google i mnóstwo „ślepych” prób zajmowały mi cały wolny czas. Szczególnie trudne okazało się zrozumienie mechanizmów podwyższania uprawnień. Kurs PWK poświęca tej tematyce dużą uwagę, jednak materiałów metodycznych zawsze brakuje. W Internecie jest mnóstwo podręczników z przydatnymi poleceniami, ale nie jestem zwolennikiem ślepego podążania za zaleceniami bez zrozumienia, dokąd to prowadzi.

Chcę podzielić się z Wami tym, czego dowiedziałem się podczas przygotowań i udanej sesji egzaminacyjnej (w tym okresowych wizyt na Hack The Box). Doświadczałem potężnego uczucia wdzięczności za każdą drobinę informacji, która pomogła mi przejść drogę Try Harder z większą świadomością, teraz nadszedł czas, aby oddać hołd społeczności.

Chcę dać Wam przewodnik po podwyższaniu uprawnień w systemie OS Linux, obejmujący omówienie najczęstszych wektorów i pokrewnych sztuczek, które na pewno Wam się przydadzą. Często same mechanizmy podwyższania uprawnień są dość proste, trudności pojawiają się przy strukturyzacji i analizie informacji. Dlatego postanowiłem rozpocząć od „przeglądowej wycieczki” i dalej omawiać każdy wektor w osobnym artykule. Mam nadzieję, że zaoszczędzę Wam czas na poznawanie tematu.

Dlaczego zatem podwyższanie uprawnień jest w ogóle możliwe w 2020 roku, skoro metody te są dobrze znane od bardzo dawna? W rzeczywistości, przy odpowiednim korzystaniu użytkownika z systemu, podwyższenie uprawnień w nim naprawdę nie będzie możliwe. Główna globalna problem, który wywołuje takie możliwości, polega na niebezpiecznej konfiguracji. Obecność w systemie przestarzałych wersji oprogramowania, które zawierają luki, jest również szczególnym przypadkiem niebezpiecznej konfiguracji.

Podwyższanie uprawnień przez niebezpieczną konfigurację

Na początek zajmijmy się niebezpieczną konfiguracją. Zacznijmy od tego, że specjaliści IT często korzystają z podręczników i zasobów takich jak stackoverflow, wiele z nich zawiera niebezpieczne polecenia i konfiguracje. Jaskrawy przykład — wiadomość. mówi, że najczęściej kopiowany kod ze stackoverflow zawierał błąd. Doświadczony administrator zauważy problem, ale to — w idealnym świecie. Nawet wykwalifikowani specjaliści przy zwiększonym obciążeniu roboczym mogą popełniać błędy. Wyobraźcie sobie, że admin zajmuje się przygotowaniem i uzgadnianiem dokumentacji na kolejny przetarg, jednocześnie zagłębia się w nową technologię, którą będzie wdrażać w następnym kwartale, przy tym okresowo rozwiązując problemy wsparcia użytkowników. I nagle dostaje zadanie, aby szybko uruchomić kilka wirtualek i skonfigurować na nich usługi. Jak myślicie, jakie jest prawdopodobieństwo, że admin po prostu nie zauważy błędu? Potem specjaliści się zmieniają, a prowizje pozostają, przy tym firmy zawsze dążą do minimalizacji kosztów, w tym kosztów związanych z IT.

Pseudopowłoka i jailbreak

Powłoka systemowa, uzyskana na etapie eksploatacji, często bywa ograniczona, szczególnie jeśli zdobyliście ją poprzez złamanie dostępu do serwera WWW. Na przykład ograniczenia powłoki mogą uniemożliwić zastosowanie polecenia sudo, co skutkuje błędem:

sudo: brak tty i brak określonego programu askpass

Po uzyskaniu powłoki zalecam stworzenie pełnoprawnego terminala, na przykład za pomocą Pythona.

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

Zapytacie: „Po co mi tysiąc poleceń, skoro mogę użyć jednego, na przykład do przesyłania plików?” Rzecz w tym, że systemy mogą być skonfigurowane w różny sposób, na nowym hoście może brakować Pythona, ale może być obecny Perl. Mistrzostwo polega na umiejętności wykonywania w systemie znanych rzeczy bez znanych narzędzi. Pełny wykaz możliwości można znaleźć tutaj.

Niskoprawna powłokę można uzyskać, używając poleceń 1 i poleceń 2 (dziwne, że nawet GIMP).

Przeglądanie historii poleceń

Linux zbiera historię wszystkich wykonanych poleceń w pliku ~/.bash_history. Jeśli serwer jest aktywnie używany, a jego historia nie jest czyszczona, istnieje duże prawdopodobieństwo, że w tym pliku znajdą się dane logowania. Czyszczenie historii jest po prostu niewygodne. Jeśli administrator musi wybierać dziesięcioetapowe polecenia przez , oczywiście będzie mu łatwiej wywołać to polecenie z historii, niż wpisywać je ponownie. Ponadto wiele osób nie zna tego „hacku”. Jeśli w systemie są alternatywne powłoki, takie jak Zsh lub Fish, prowadzą one swoją historię. Aby wyświetlić historię poleceń w dowolnej powłokę, wystarczy wpisać polecenie history.

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

Istnieje hosting współdzielony, gdzie serwer jest używany do hostingu kilku stron internetowych. Zwykle w takiej konfiguracji dla każdego zasobu tworzy się oddzielnego użytkownika z osobnym katalogiem domowym i wirtualnym hostem. W przypadku niewłaściwej konfiguracji w głównym katalogu zasobu internetowego można znaleźć plik .bash_history.

Poszukiwanie haseł w systemie plików i ataki na systemy powiązane

Pliki konfiguracyjne różnych usług mogą być dostępne do odczytu dla twojego aktualnego użytkownika. Można w nich znaleźć dane logowania w otwartym formacie — hasła do baz danych lub powiązanych serwisów. To samo hasło może być używane zarówno do dostępu do bazy danych, jak i do autoryzacji użytkownika root (credential staffing).
Czasami znalezione dane logowania należą do serwisów na innych hostach. Rozwój ataku na infrastrukturę poprzez skompromitowany host jest równie skuteczny jak eksploatacja innych hostów. Systemy powiązane można również znaleźć poprzez wyszukiwanie adresów IP w systemie plików.

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Znajdź ciąg password (bez cs) w tych katalogach
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 w logach

W przypadku, gdy na skompromitowanym hoscie znajduje się aplikacja internetowa dostępna z Internetu, lepiej wykluczyć jej logi z poszukiwania adresów IP. Adresy użytkowników zasobu z Internetu raczej nie będą nam przydatne, natomiast adresy wewnętrznej sieci (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) oraz to, gdzie się logują, mogą być interesujące.

Sudo

Polecenie sudo daje użytkownikowi możliwość wykonania polecenia w kontekście root za pomocą własnego hasła lub całkowicie bez jego użycia. Wiele operacji w systemie Linux wymaga uprawnień root, jednak praca z poziomu root jest uważana za bardzo złą praktykę. Lepiej stosować selektywne uprawnienia do wykonywania poleceń w kontekście root. Niemniej jednak wiele narzędzi Linuxa, w tym standardowe, jak vi, można używać do podwyższania uprawnień w całkowicie legalny sposób. Aby znaleźć odpowiedni sposób, polecam się przyjrzeć. tutaj.

Pierwszą rzeczą, którą należy zrobić po uzyskaniu dostępu do systemu, jest wykonanie polecenia sudo -l. Wyświetli ono zezwolenia na użycie polecenia sudo. Jeśli użytkownik nie ma hasła (na przykład apache lub www-data), wektor podnoszenia uprawnień przez sudo jest mało prawdopodobny. Przy użyciu sudo system poprosi o hasło. Za pomocą polecenia passwd hasła również nie można ustawić, ponieważ poprosi o bieżące hasło użytkownika. Ale jeśli sudo jest dostępne, zasadniczo należy szukać:

wszelkich interpreterów, każdy może wywołać shell (PHP, Python, Perl);
wszelkich edytorów tekstu (vim, vi, nano);
wszelkich przeglądarek (less, more);
wszelkich możliwości pracy z systemem plików (cp, mv);
narzędzi, które mają dostęp do bash, interaktywnego lub w postaci wykonalnego polecenia (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

W Internecie jest wiele przewodników, które sugerują zebranie wszystkich poleceń suid/sgid, jednak rzadki artykuł podaje konkretne informacje, co zrobić z tymi programami. Opcje podnoszenia uprawnień, które nie uwzględniają zastosowania exploitów, można znaleźć tutaj. Również kilka plików wykonywalnych ma specyficzne luki pod wersję OS, na przykład.

W idealnym świecie należy przeskanować wszystkie zainstalowane pakiety przynajmniej przez searchsploit. W praktyce warto to zrobić z najbardziej popularnymi programami, takimi jak sudo. Zawsze istnieje również opcja używania i wspierania rozwoju zautomatyzowanych narzędzi, które podkreślą interesujące pliki wykonywalne z ustawionymi bitami suid/sgid. Listę takich narzędzi przedstawię w odpowiedniej części artykułu.

Skrypty dostępne do zapisu, uruchamiane przez Cron lub Init, w kontekście Root

Zadania cron mogą być wykonywane w kontekście różnych użytkowników, w tym roota. Jeśli w cron ustawione jest zadanie z linkiem do pliku wykonywalnego, i jest on dostępny do zapisu, można go łatwo podmienić złośliwym i wykonać podniesienie uprawnień. Przy tym pliki z zadaniami cron są domyślnie dostępne do odczytu dla każdego użytkownika.

ls -la /etc/cron.d  # pokaż zadania cron

Podobnie sprawy mają się z init. Różnica polega na tym, że zadania w cron są wykonywane okresowo, a w init — przy starcie systemu. Aby je wykorzystać, konieczne będzie ponowne uruchomienie systemu, przy czym niektóre usługi mogą się nie uruchomić (jeśli nie były zapisane w autostarcie).

ls -la /etc/init.d/  # pokazuje skrypty inicjalizacyjne

Możesz również poszukać plików, które są dostępne do zapisu dla każdego użytkownika.

find / -perm -2 -type f 2>/dev/null # znajdź pliki, do których można zapisać dla wszystkich

Metoda jest dość znana, doświadczeni administratorzy systemów ostrożnie korzystają z polecenia chmod. Jednak w sieci w przeważającej większości podręczników opisano ustawianie maksymalnych uprawnień. Podejście niedoświadczonych administratorów systemów 'byle działało' stwarza możliwości do uzyskania wyższych uprawnień w ogóle. Jeśli to możliwe, lepiej sprawdzić historię poleceń pod kątem niebezpiecznego użycia chmod.

chmod +w /path 
chmod 777 /path

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

Sprawdzamy listę użytkowników w /etc/passwd. Zwracamy uwagę na tych, którzy mają powłokę. Można spróbować złamać hasła tych użytkowników - istnieje prawdopodobieństwo, że przez uzyskanego użytkownika w końcu uda się podnieść uprawnienia.

Aby zwiększyć bezpieczeństwo, zawsze zaleca się przestrzeganie zasady minimalnych uprawnień. Warto również poświęcić czas na sprawdzenie niebezpiecznych konfiguracji, które mogły pozostać po rozwiązywaniu problemów – to 'dług technologiczny' administratora systemów.

Własny kod

Warto dokładnie przyjrzeć się plikom wykonywalnym w katalogu domowym użytkownika oraz serwera www (/var/www/, jeśli nie podano innej). Te pliki mogą okazać się zupełnie niebezpiecznym rozwiązaniem i zawierać niewiarygodne obejścia. Oczywiście, jeśli masz jakiś framework w katalogu serwera www, nie ma sensu szukać w nim luk (zero-day) w ramach testów penetracyjnych, jednak zaleca się zlokalizowanie i zbadanie niestandardowych poprawek, wtyczek i komponentów.

Aby zwiększyć bezpieczeństwo, najlepiej unikać używania danych logowania w własnych skryptach oraz potencjalnie niebezpiecznych funkcji, takich jak odczyt /etc/shadow czy manipulacje z id_rsa.

Podnoszenie uprawnień poprzez wykorzystanie luk bezpieczeństwa

Zanim spróbujesz podnieść uprawnienia poprzez wykorzystanie luk, ważne jest, aby zrozumieć przesyłanie plików na docelowy host. Poza standardowymi narzędziami takimi jak ssh, ftp, http (wget, curl) istnieje cały zestaw możliwości.

Aby zwiększyć bezpieczeństwo systemu, regularnie aktualizuj go do najnowszych stabilnych wersji wersji, a także starajcie się używać dystrybucji przeznaczonych na Enterprise. W przeciwnym razie, rzadko, ale zdarzają się sytuacje, kiedy apt upgrade czyni system nieoperacyjnym.

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

Niektóre usługi Linux działają z uprawnieniami użytkownika root. Można je znaleźć za pomocą polecenia ps aux | grep root. Przy tym usługa może nie być ogłaszana w Sieci i być dostępna lokalnie. Jeśli ma publiczne exploity, można je z powodzeniem zastosować: awaria usługi w przypadku niepowodzenia jest znacznie mniej krytyczna niż awaria systemu operacyjnego.

ps -aux | grep root # Linux

Najbardziej udanym przypadkiem można uznać działanie zhakowanej usługi w kontekście użytkownika root. Eksploatacja usługi SMB zapewnia dostęp z uprawnieniami SYSTEM w systemach Windows (na przykład przez ms17-010). Jednak w systemach Linux zdarza się to rzadko, więc można spędzić sporo czasu na podnoszeniu uprawnień.

Eksploatacja luk w jądrze Linux

To droga, którą należy podążać w ostatniej kolejności. Nieudana eksploatacja może prowadzić do awarii systemu, a w przypadku restartu niektóre usługi (w tym te, przez które udało się uzyskać pierwotny shell) mogą nie wstać. Bywa, że administrator po prostu zapomina zastosować polecenie systemctl enable. Ponadto spowoduje to wiele niezadowolenia z twojej pracy, jeśli eksploatacja nie była wcześniej uzgodniona.
Jeśli postanowiłeś użyć kodów źródłowych z exploitdb, koniecznie przeczytaj komentarze na początku skryptu. Oprócz innych rzeczy, zazwyczaj pisze tam, jak poprawnie skompilować dany exploit. Jeśli samemu jest ci leniwie lub terminy wymagały działania 'wczoraj', możesz poszukać repozytoriów z już skompilowanymi exploitami, na przykład. Jednak należy rozumieć, że w takim przypadku otrzymasz kota w worku. Z drugiej strony, gdyby programista rozumiał do bajtu, jak działa komputer i obsługiwane przez niego oprogramowanie, nie napisałby przez całe życie ani jednej linijki kodu.

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

Metasploit

Aby przechwycić i przetworzyć połączenie, zawsze lepiej jest użyć modułu exploit/multi/handler. Najważniejsze to ustawić odpowiedni payload, na przykład generic/shell/reverse_tcp lub generic/shell/bind_tcp. Powłokę uzyskaną w Metasploit można ulepszyć do Meterpreter za pomocą modułu post/multi/manage/shell_to_meterpreter. Posiadając Meterpreter, możesz zautomatyzować proces post-eksploatacji. Na przykład moduł post/multi/recon/local_exploit_suggester sprawdza platformę, architekturę oraz niezbędne do eksploatacji elementy i proponuje moduły Metasploit do podwyższenia uprawnień w systemie docelowym. Dzięki Meterpreter, podwyższenie uprawnień często sprowadza się do uruchomienia odpowiedniego modułu, jednak włamanie bez zrozumienia, co dzieje się pod maską, nie jest "prawdziwe" (musisz jeszcze napisać raport).

Narzędzia

Narzędzia automatyzacji lokalnego zbierania informacji zaoszczędzą ci wiele sił i czasu, jednak same w sobie nie są w stanie w pełni ujawnić ścieżki podwyższania uprawnień, szczególnie w przypadku eksploatacji podatności jądra. Narzędzia automatyzacyjne wykonają wszystkie niezbędne komendy do zbierania informacji o systemie, ale ważne jest także potrafić analizować uzyskane dane. Mam nadzieję, że mój artykuł okaże się dla ciebie przydatny. Oczywiście istnieje znacznie więcej narzędzi, niż te, które wymieniłem poniżej, jednak wszystkie one robią mniej więcej to samo — tu raczej chodzi o gust.

Linpeas

Relatywnie nowe narzędzie, pierwszy commit datowany na styczeń 2019 roku. Obecnie moje ulubione narzędzie. Istota polega na tym, że podświetla najbardziej interesujące wektory podwyższania uprawnień. Zgodzić się można, że łatwiej uzyskać profesjonalną ocenę na takim poziomie, niż analizować monolityczne surowe dane.

Źródło: habr.com