rootkit

Rootkit to zestaw narzędzi, którego atakujący używa po zdobyciu uprawnień administratora systemu (root), aby ukryć swoje działania i potajemnie utrzymać ten poziom dostępu ^[1]. NIST podaje też szerszą definicję: zbiór plików instalowanych na hoście, które zmieniają jego standardowe działanie w sposób złośliwy i ukryty ^[1]. Rootkit nie służy do włamania, tylko do pozostania w systemie po włamaniu. Jest jedną z najtrudniejszych do wykrycia odmian złośliwego oprogramowania (malware).

Jak działa

MITRE ATT&CK opisuje rootkity jako narzędzia ukrywające programy, pliki, połączenia sieciowe, usługi, sterowniki i inne składniki systemu ^[2]. Robią to, przechwytując i zmieniając wywołania interfejsów systemu operacyjnego, które dostarczają informacji o systemie ^[2]. Gdy administrator prosi o listę procesów albo plików w katalogu, dostaje odpowiedź już „oczyszczoną” przez rootkit. Według MITRE rootkity albo funkcje, które je umożliwiają, mogą działać na poziomie użytkownika, jądra albo niżej, w tym w hiperwizorze lub oprogramowaniu układowym ^[2]. Opisano je dla systemów Windows, Linux i macOS ^[2].

RYS. 1Rootkit przechwytuje zapytanie administratora

Z tego powodu narzędzia uruchomione w przejętym systemie nie są wiarygodne. MITRE zaznacza, że tej techniki nie da się łatwo powstrzymać środkami zapobiegawczymi, bo opiera się na nadużyciu funkcji systemu ^[2]. Wykrywanie polega na szukaniu śladów: nieautoryzowanego ładowania sterowników i modułów jądra albo niepodpisanych rozszerzeń jądra ^[2].

Rodzaje

Rootkity dzieli się według poziomu, na którym działają. Im niżej, tym trudniej je wykryć i usunąć.

Drovorub to zestaw narzędzi dla Linuksa przypisywany grupie APT28; jego moduł jądra ukrywał procesy, pliki, pliki wykonywalne i ślady sieciowe przed widokiem z przestrzeni użytkownika ^[4]. Bootkit według MITRE zmienia sektory rozruchowe dysku, dzięki czemu złośliwy kod wykonuje się, zanim załaduje się system operacyjny ^[3]. Przeciw takim atakom projektuje się bezpieczny rozruch (Secure Boot). Na poziomie firmware MITRE opisuje LoJax, rootkit UEFI użyty do utrwalenia oprogramowania zdalnego dostępu na wybranych systemach ^[2].

Rootkity rzadko działają same. W przykładach zebranych przez MITRE są rootkity łączone z wykonywaniem poleceń i rejestrowaniem danych logowania, a także webshell z modułem instalującym rootkit ^[2]. MITRE odnotowuje też grupę APT41, która wdrażała rootkity w systemach Linux ^[2], czyli na typowej platformie serwerów WWW.

W WordPressie

WordPress działa jako aplikacja PHP na serwerze, więc klasyczny rootkit dotyczy systemu operacyjnego hostingu, nie samej strony. Ma to znaczenie przy hostingu współdzielonym i na własnych serwerach VPS: jeśli napastnik zdobył uprawnienia root, może ukryć swoje pliki także przed skanerami uruchamianymi na tej maszynie ^[2]. CERT Polska zaleca w takim przypadku przywrócenie do ustawień fabrycznych całej maszyny ^[8]. Ostrzega też, że odtworzenie z kopii zapasowej po przejęciu całego hosta grozi przywróceniem mechanizmów utrwalenia atakującego ^[8].

Na poziomie samego WordPressa spotyka się zjawisko podobne, choć to nie rootkit w ścisłym sensie: złośliwy kod ukrywa się przed panelem. CERT Polska opisuje maskowanie trwałego dostępu jako fałszywe rozszerzenia, zwłaszcza w katalogu mu-plugins ^[8]. Dokumentacja WordPressa wyjaśnia, dlaczego to miejsce jest wygodne. Wtyczki mu-plugins nie pojawiają się na domyślnej liście wtyczek, a tylko w osobnej sekcji, i nie da się ich wyłączyć z panelu ^[7]. Nie pokazują się też w powiadomieniach o aktualizacjach ^[7]. Aby taką wtyczkę wyłączyć, trzeba usunąć jej plik z katalogu na serwerze ^[7]. Przegląd zawartości wp-content/mu-plugins przez SFTP powinien więc być stałym punktem kontroli po włamaniu. Obok takich plików napastnicy zostawiają konta administratora o nazwach podobnych do legalnych ^[8] oraz tylną furtkę (backdoor) lub webshell.

Zagrożenia i skutki

Rootkit sam w sobie nie kradnie danych. Daje czas i ukrycie innym narzędziom, na przykład RAT-owi, keyloggerowi czy modułom łączącym się z serwerem C2. Wydłuża przez to czas przebywania atakującego w sieci. Sama technika ukrywania bywa też niebezpieczna dla innych: CERT/CC opisał, że oprogramowanie XCP używało technologii rootkit, a kontrolka ActiveX do jego odinstalowania mogła pozwolić napastnikom pobrać i uruchomić dowolny kod ^[6].

Jak się bronić

• Ograniczać możliwość zdobycia uprawnień root: zasada najmniejszych uprawnień, szybkie łatanie eskalacji uprawnień w jądrze.
• Nie ufać narzędziom uruchomionym w przejętym systemie, bo rootkit zmienia odpowiedzi wywołań systemowych ^[2]; analizę prowadzić z zewnątrz, na przykład na kopii dysku.
• Stosować monitorowanie integralności plików i obserwować ładowanie modułów jądra ^[2].
• Po wykryciu przejęcia hosta nie czyścić go, tylko postawić od nowa ^[8].

Historia i przykłady

Pod koniec 2005 roku głośna stała się sprawa płyt Sony BMG. 8 listopada 2005 roku EFF pisała, że oprogramowanie XCP instalowane z płyt używa technik rootkitów, by ukryć się przed użytkownikiem ^[5]. Ta sama publikacja zwracała uwagę, że wydana przez Sony BMG „łatka”, która miała odkryć ukryte oprogramowanie, stwarzała nowe problemy ^[5]. CERT/CC 16 listopada 2005 roku opublikował notę VU#312073 o kontrolce ActiveX dostarczanej przy odinstalowaniu XCP, oznaczonej jako bezpieczna dla skryptów ^[6].