PSF – rootkit dla ubogich

PSF, czyli Process Stack Faker to binarka, którą wykorzystują włamywacze do ukrywania w systemie podrzuconego przez nich złośliwego oprogramowania. PSF stosuje bardzo prostą technikę do ukrycia nazwy obcego procesu pod nazwą innego standardowego procesu w systemie np. httpd, sshd. W tekście zostanie zaprezentowane działanie PSF w praktyce oraz metody, w jaki sposób sprawdzić, czy w systemie nie występuje obcy proces ukrywany przez PSF. Na githubie znajduje się kod tego oprogramowania, ostatnia aktualizacja jest z 2012 roku, ale oprogramowanie to jest z powodzeniem wykorzystywane w 2015 roku.

Poniżej przedstawię historię, gdzie głównym bohaterem będzie Process Stack Faker, odkryty w czasie wykonywania testu penetracyjnego serwera www postawionego na Linuksie.

Zastosowanie PSF

PSF ma za zadanie oszukać rutynowe listowanie procesów za pomocą poleceń ps auwx, ps -ef, top. Skuteczne ukrycie malware’owego procesu w systemie operacyjnym wymaga uprawnień użytkownika uprzywilejowanego i dostępu do systemu na poziomie jądra. Okazuje się, że wiele grup włamujących się do hostów nie dąży do eskalacji uprawnień po zdobyciu dostępu do systemu. Motywacją właścicieli botnetów jest zdobycie jak największej liczby kontrolowanych hostów, które mogą wykorzystywać do różnych celów m.in. skanowań, ataków DDoS itp. W przypadku tzw. bot herders nie ma potrzeby zdobycia uprawnień roota i mogą się oni zadowolić uprawnieniami użytkownika o ograniczonych uprawnieniach, o ile wystarczy to do realizacji ich celów. Tu swoje zadanie świetnie spełnia PSF – ponieważ w prosty, choć mało finezyjny sposób ukrywa przed administratorem uruchomiony przez włamywacza proces.

Przykłady wykorzystania PSF wskazują, że ta binarka jest często stosowana, żeby ukryć proces IRC bouncer’a, który w systemie uruchamia serwer IRC, samemu jednocześnie łącząc się do do innych serwerów na porcie 6667, umożliwiając tym samym kontrolę serwera poprzez polecenia przesyłane przez komunikator.

Historia pewnego włamania

W pracy pentestera zdarza się, że test bezpieczeństwa zamienia się w analizę powłamaniową. Dzieje się tak, gdy po utorowaniu sobie wejścia do systemu i uzyskaniu możliwości wykonywania poleceń powłoki systemu operacyjnego, uświadamiamy sobie, że analizowany host już został wcześniej zhakowany. Tak było również w przypadku mojego spotkania z PSF.

Po uzyskaniu dostępu do powłoki systemowej testowanego serwera www sprawdziłem zadania cron dla użytkownika i poniższy wpis wzbudził moje podejrzenia.

$ crontab -l
* * * * * /var/www/. /y >/dev/null 2>&1

Okazało się,  że włamywacz umieścił skrypt o nazwie y w ukrytym katalogu o nazwie „. „ w folderze domowym użytkownika – /var/www.

Skrypt y wykonywany co minutę jako zadanie w cron miał zapewnić włamywaczowi przetrwanie procesu IRC bouncer’a w systemie. Był to jednocześnie najsłabszy punkt włamania, ponieważ wpis ten jednoznacznie wskazał lokalizację obcego skryptu, co więcej zadanie wykonywane co minutę powodowało znaczny przyrost logów crona. Poprzez monitoring logów crona można łatwo wykryć taką anomalię.

$ cat "/var/www/. /y"
#!/bin/sh
if test -r "/var/www/. /pid"; then
pid=$(cat "/var/www/. /pid")
if $(kill -CHLD \$pid >/dev/null 2>&1)
then
exit 0
fi
fi
cd "/var/www/. " 
./run &>/dev/null

Idąc po nitce do kłębka otwieramy plik run w ukrytym katalogu o ciekawej nazwie „. ” <kropka> <spacja>.

$cat run
./psf -s /usr/sbin/httpd ./init -d /var/www/". "/

W tym miejscu następuje wywołanie programu PSF ukrywającego złośliwy proces init – w tym wypadku był to IRC bouncer.

W jaki sposób PSF ukrywa procesy?

Technika ukrywania procesów jaką wykorzystuje PSF nie jest szczególnie wyrafinowana, dokładna idea opisana jest w komentarzu autora w pliku źródłowym psf.c i polega na wykorzystaniu funkcji systemowej execv (wywołanie w linii 403).

// And now, execute it!
execv(myexec, newargv);

Rodzina funkcji exec*() pozwala zastąpić jeden proces innym na podstawie przekazanych argumentów. Zatem program psf uruchamia proces o nazwie init (argument myexec) pod nazwą /usr/sbin/httpd (argument newargv). Jest to logiczne z uwagi na fakt, że zaatakowany serwer posiadał uruchomiony serwis www o tej nazwie, co więcej na serwerze produkcyjnym nie dziwi widok wielu procesów uruchomionych z tą nazwą w danym momencie czasu.

Przypatrzmy się dokładniej, jak wygląda argument newargv, ponieważ tu następuje całe oszustwo. W linijce 315 kodu PSF znajdziemy operację dodawania pustych znaków ’ ’ do fałszywego polecenia newargv:

if (n > 1)
	{
		// Build space-padded fake command
		memset(fakecomm, ' ', sizeof(fakecomm) - 1);
		fakecomm[sizeof(fakecomm) - 1] = '';
		strncpy(fakecomm, spoof, strlen(spoof));
		newargv[0] = fakecomm;
	}
	else

Zatem PSF uruchamia binarkę init  i ukrywa ją pod nazwą /usr/sbin/httpd  dodając do niej spacje 0x20, a prawdziwe wywołanie procesu znajduje się poza ekranem- Wot technika!

Trick z linkiem symbolicznym przeciwko top

W przypadku programu top autor PSF musiał zastosować inne podejście, ponieważ domyślnie top  wyświetla nazwy plików odpowiedzialnych za uruchomienie danego procesu. W tym celu PSF tworzy link symboliczny w katalogu plików tymczasowych do binarki pod nazwą której ma nastąpić ukrycie:

ls -al /tmp/
lrwxrwxrwx 1 www-data www-data 10 Feb 21 12:01 /tmp/.psf_1 -> /usr/sbin/httpd

Autor w kodzie ostrzega jednak, że ten trick nie zadziała na systemach BSD ponieważ jądro tych systemów wskaże nazwę oryginalnego pliku, a nie tego wskazanego przez link.

Jak wykryć obecność PSF w systemie?

PSF jest skuteczny jedynie w przypadku listowania procesów za pomocą standardowych poleceń, użycie niestandardowych przełączników lub innych monitorów umożliwi odkrycie obecności tego faker’a np. za pomocą jednego z poniższych sposobów:

• Ponieważ standardowe użycie polecenia ps powoduje, że prawdziwe argumenty ukryte się poza ekranem, zatem należy użyć polecenia ps auwx  –cols 1024, aby zwiększyć szerokość ekranu.
• Pusta linia w czasie listowania procesów za pomocą polecenie ps auwx powinna zwrócić uwagę wskazując, że może to być przesunięcie charakterystyczne dla PSF w celu ukrycia prawdziwego wywołania programu.
• Podejrzany proces możemy sprawdzić poprzez wyświetlenie zawartości jego pliku cmdline, ponieważ będzie tam zawarta informacja o pierwotnym poleceniu odpowiedzialnym za uruchomienie procesu o numerze [pidn].

  cat /proc/[pidn]/cmdline

• Uruchomienie innych niż ps i top monitorów procesów.
• Analiza otwartych plików za pomocą lsof umożliwi nam ujawnienie prawdziwej nazwy polecenia, które uruchomiło podejrzany proces o numerze [pidn].

  lsof -l [pidn]

• Analiza logów i wykrywanie anomalii z nimi związanych, szczególnie log cron rośnie w ogromnym tempie, gdy co minutę uruchamiane jest zadanie pozwalające zachować złośliwy kod w systemie.
• Sprawdzenie zadań crontab -l  wszystkich użytkowników systemowych.

Warto również pamiętać, że za pomocą plików /etc/cron.allow i/lub /etc/cron.deny możemy kontrolować, którzy użytkownicy mają prawo dodawać zadania do harmonogramu cron’a. Pliki te nie są domyślnie utworzone w systemie Linuks. Wpis  root do pliku /etc/cron.allow zapewni, że tylko uprzywilejowany użytkownika będzie mógł dodawać zadania do cron’a. 

Podsumowując, sam twórca autokrytycznie ocenił, że technika wykorzystana w programie PSF do ukrycia jednego procesu pod inną nazwą jest:

Sorry, it’s very dumb and very ugly…

Jednakże, często proste rozwiązania okazują się skuteczne. Niewątpliwie zaleta PSF jest to, że nie wymaga podwyższonych uprawnień w przeciwieństwie do skomplikowanych rootkitów i może się zdarzyć, że rutynowy przegląd procesów w systemie spowoduje, że nie wykryjemy uruchomionego malware’u na serwerze.

–j23