packer

Packer to narzędzie, które kompresuje albo szyfruje plik wykonywalny tak, że właściwy kod ujawnia się dopiero w pamięci po uruchomieniu. MITRE opisuje pakowanie jako metodę kompresji lub szyfrowania pliku wykonywalnego, która zmienia jego sygnaturę, żeby uniknąć wykrycia opartego na sygnaturach ^[1]. Samo narzędzie nie jest złośliwe: legalne packery zmniejszają rozmiar programów ^[2]. W rękach atakujących służy do ukrycia złośliwego oprogramowania (malware) przed antywirusem i analitykiem.

Jak działa

Spakowany plik składa się z dwóch części: małego kodu rozpakowującego i zaszyfrowanej lub skompresowanej właściwej treści. Po uruchomieniu kod rozpakowujący odtwarza oryginał, zwykle w pamięci, i przekazuje mu sterowanie ^[1]. Na dysku nie ma więc rozpoznawalnego kodu, tylko dane o wysokiej entropii. Przebieg pokazuje schemat poniżej.

RYS. 1Uruchomienie spakowanego pliku

CERT Polska opisał ten moment na przykładzie Emoteta: próbka była dostarczana w postaci spakowanej generycznym packerem, który miał zmylić silniki antywirusowe i utrudnić analizę, a po rozpakowaniu sterowanie trafiało do głównego kodu ^[3]. Warstw może być kilka. W analizie Ramnita z września 2017 roku CERT Polska opisał dwie: zewnętrzne autorskie pakowanie i wewnętrzny, zwykły UPX ^[4].

Odmianą bardziej złożoną jest ochrona przez maszynę wirtualną. Kod zostaje przetłumaczony na format, który wykonuje tylko dołączona do pliku dedykowana maszyna wirtualna ^[1].

Rodzaje

MITRE wymienia zarówno narzędzia ogólnodostępne, jak i packery pisane przez samych atakujących ^[1].

Przy UPX warto odnotować zastrzeżenie twórców: format jest od lat udokumentowany i otwarty, więc programy antywirusowe potrafią zajrzeć do środka spakowanego pliku ^[2]. UPX jest rozpowszechniany na licencji GNU GPL i obsługuje programy dla Windows, macOS i Linuksa ^[2]. Z tego powodu atakujący chętnie dokładają własną warstwę na wierzch, jak w przypadku Ramnita ^[4].

Pakowanie bywa sprzedawane jako usługa. Krebs opisał, że autor exploit kitu Blackhole oferował klientom dodatkową usługę szyfrowania plików za 50 USD miesięcznie ^[7]. Pokrewne pojęcia to zaciemnianie kodu, które zmienia czytelność kodu, a nie jego postać binarną, oraz malware polimorficzny (polymorphic malware), zmieniający postać przy każdej kopii.

W WordPressie

Strony WordPress nie uruchamiają plików wykonywalnych Windows, ale ta sama zasada działa w PHP i JavaScript. Złośliwy kod jest kompresowany i kodowany wiele razy, a na końcu uruchamiany przez eval(). Sucuri w październiku 2019 roku opisał próbkę złożoną z funkcji eval(), base64_decode(), gzinflate(), gzuncompress() i strrev(), która po ponad 90 warstwach ujawniła webshell z menedżerem plików ^[6]. Komentarz w kodzie wskazywał, że warstwy wygenerowało gotowe narzędzie, Blackscorpion Obfuscator ^[6], a nie ręczna praca autora. Liczba warstw nie wynika więc z wyrafinowania atakującego, tylko z ustawienia w programie. Każda warstwa jest prosta do zdjęcia, ale skaner szukający znanego fragmentu webshella nie zobaczy go, dopóki nie zdejmie ich wszystkich. Niebezpiecznik już w 2010 roku pokazywał, jak łatwo oszukać antywirus, pakując złośliwy JavaScript jednym z packerów dostępnych w środowisku Metasploit ^[5].

Dla administratora wynika z tego, że szukanie konkretnego tekstu w plikach nie wystarczy. Wzorcem podejrzanym jest raczej połączenie wykonania kodu z dekodowaniem. Poniższe polecenie wyszukuje takie połączenia w katalogu wp-content; wynik wymaga ręcznej oceny, bo niektóre legalne wtyczki też kodują dane.

grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|gzuncompress|str_rot13)" wp-content/

Sucuri radzi przy analizie zastąpić eval przez echo, żeby PHP wypisał kolejną warstwę zamiast ją wykonać ^[6]. Taką analizę prowadzi się na kopii pliku, nie na działającej stronie. Odpowiednikiem w świecie plików wykonywalnych jest debuger: CERT Polska po rozpakowaniu Ramnita rozpoznawał w pamięci nagłówek pliku PE zaczynający się od znaków MZ, czyli gotowy do analizy oryginał ^[4].

Znaczenie dla wykrywania

Packer atakuje przede wszystkim wykrywanie sygnaturowe. Każde przepakowanie zmienia wygląd pliku, więc stara sygnatura przestaje pasować ^[1]. MITRE zaleca dlatego wykrywanie heurystyczne, aktualne definicje i własne sygnatury dla obserwowanych próbek ^[1]. Jako sygnał wykrycia wskazuje nietypowe przydziały pamięci, po których następuje wykonanie kodu spoza sekcji obrazu programu, oraz wysoką entropię i kod modyfikujący sam siebie ^[1].

Analitycy obchodzą pakowanie, uruchamiając próbkę pod kontrolą. W analizie Ramnita CERT Polska opisał, że mimo szyfrowania rozpakowanie jest proste: wystarczy uruchomić loader w debugerze i zatrzymać go tuż po dekompresji kodu ^[4]. Podobnie działa piaskownica (sandbox), która obserwuje zachowanie pliku zamiast jego wyglądu. Spakowany plik często pełni rolę loadera albo droppera, a rozpakowana treść bywa trojanem bankowym albo inną rodziną złośliwego oprogramowania.

Jak się bronić

• Opierać ochronę na kilku metodach naraz: sygnaturach, heurystyce i analizie zachowania ^[1].
• Na serwerze stosować monitorowanie integralności plików, bo nowy, zakodowany plik PHP jest wskaźnikiem kompromitacji (IoC) niezależnie od tego, czy skaner go rozpoznał.
• Traktować wynik skanera złośliwego oprogramowania (malware scanner) jako wskazówkę. Brak wykrycia nie dowodzi, że plik jest czysty, a samo użycie packera nie dowodzi, że jest złośliwy.