zaciemnianie kodu

Zaciemnianie kodu (obfuskacja) to celowe przekształcanie programu lub skryptu tak, żeby działał tak samo, ale był trudny do odczytania i analizy. MITRE opisuje tę technikę jako utrudnianie wykrycia i analizy plików przez szyfrowanie, kodowanie lub inne zaciemnianie ich treści, zarówno w systemie, jak i w trakcie przesyłania ^[1]. Zaciemnianie nie jest samo w sobie złośliwe, ale złośliwe oprogramowanie (malware) używa go powszechnie, bo ukrywa zamiary kodu przed ludźmi i narzędziami.

Jak działa

Zaciemnianie nie zmienia tego, co kod robi. Zmienia tylko jego postać. Nazwy zmiennych i funkcji zastępuje się przypadkowymi ciągami, napisy dzieli na kawałki albo koduje, a całość pakuje w kolejne warstwy, które rozwijają się dopiero w chwili uruchomienia. MITRE wymienia wśród metod kompresję, archiwizację i szyfrowanie ładunku, dzielenie pliku na części ujawniające złośliwe działanie dopiero po złożeniu oraz użycie zmiennych środowiskowych i aliasów do ukrycia wykonywanych poleceń ^[1].

Warstwy zaciemnienia działają jak kolejne opakowania. Analityk albo skaner widzi tylko zewnętrzną warstwę, a prawdziwy kod pojawia się w pamięci dopiero po rozpakowaniu wszystkich. Schemat poniżej pokazuje typowy układ warstw.

RYS. 1Warstwy zaciemnionego skryptu

CERT Polska opisał przykład z Polski. Dropper Ostap, rozsyłany w kampaniach z fałszywymi fakturami, stosował obfuskację polegającą na wyliczaniu łańcuchów znaków ze złożonych wyrażeń, znak po znaku ^[2]. Takie skrypty trafiały do ofiar jako pliki JSE o rozmiarze kilkuset kilobajtów w archiwach dołączonych do maili ^[2]. Duży rozmiar wynikał właśnie z zaciemnienia.

Odmiany

MITRE dzieli technikę na 18 podtechnik ^[1]. Najczęściej spotykane zestawia tabela.

Zaciemnianie JavaScriptu jest znane od dawna. Niebezpiecznik w 2010 roku opisywał, jak złośliwy kod JavaScript pakuje się narzędziami dostępnymi w środowisku Metasploit, żeby oszukać programy antywirusowe ^[3].

W WordPressie

Na stronach WordPress zaciemnianie spotyka się głównie w dwóch miejscach: w kodzie wstrzykniętym przez atakującego i w kodzie wtyczek.

Złośliwy kod na stronie. Webshelle, tylne furtki (backdoor) i wstrzyknięcia w pliki motywów zwykle są zaciemnione, żeby nie rzucały się w oczy przy przeglądzie plików. Sucuri wymienia funkcje PHP typowe dla takiego kodu: eval, base64_decode, gzinflate, preg_replace i str_replace ^[5]. Te same funkcje mają jednak uzasadnione zastosowania we wtyczkach, więc ich obecność nie przesądza o infekcji ^[5]. To częsta przyczyna, dla której wynikiem skanowania jest fałszywy alarm (false positive).

Zaciemnianie bywa też odnawiane automatycznie. Badacze GoDaddy opisali kampanię DollyWay, której kod przy każdej ponownej infekcji losowo zmienia nazwy zmiennych i funkcji oraz dzieli stałe tekstowe losowymi komentarzami ^[6]. Każda kopia wygląda więc inaczej, co utrudnia wykrywanie po sygnaturze. Kod był wstrzykiwany do wszystkich aktywnych wtyczek ^[6].

Kod wtyczek. Katalog wtyczek WordPress.org zakazuje zaciemniania. Wytyczne nie dopuszczają ukrywania kodu technikami podobnymi do funkcji obfuskacji narzędzia p,a,c,k,e,r, mieszania nazw w uglify ani niejasnych nazw w rodzaju $z12sdf813d ^[4]. Uzasadnienie jest dwojakie: nieczytelny kod utrudnia pracę przyszłym programistom i jest częstym sposobem ukrywania złośliwych funkcji ^[4]. Autor musi udostępnić kod źródłowy i narzędzia budowania, w paczce wtyczki albo przez odnośnik w pliku readme ^[4]. Mocno zaciemniony kod w dodatku spoza katalogu jest więc sygnałem ostrzegawczym, szczególnie gdy chodzi o piracką wtyczkę.

Zagrożenia i skutki

Zaciemnianie samo niczego nie niszczy. Jego skutkiem jest to, że inne zagrożenia dłużej pozostają niewykryte. Kod, którego skaner nie rozpoznaje, a administrator nie rozumie, może działać na stronie miesiącami. Zaciemnianie osłabia przede wszystkim wykrywanie sygnaturowe, bo sygnatura opisuje konkretną postać kodu, a zaciemniacz tę postać zmienia ^[6].

Zaciemnianie nie jest też skutecznym zabezpieczeniem własnego kodu. MITRE w opisie słabości CWE-656 ostrzega, że mechanizm, którego siła zależy od ukrycia jego działania, zawodzi, gdy atakujący odtworzy jego budowę. Ukrycie może być drobną częścią obrony warstwowej, ale jako główna ochrona stanowi istotne ryzyko ^[7]. To samo mówi pojęcie security through obscurity.

Jak się bronić

MITRE zaleca przeciw tej technice skanowanie antywirusowe z automatycznym wykrywaniem i kwarantanną, okresowy przegląd miejsc przechowywania ładunków bezplikowych oraz reguły ograniczające zachowanie programów ^[1]. Wykrywanie powinno opierać się na zachowaniu: łączeniu uruchomienia skryptu z tworzeniem zakodowanych plików i wyszukiwaniu przesyłanych plików o wysokiej entropii ^[1].

Na stronie WordPress w praktyce oznacza to:

• porównywanie plików z wzorcem. Monitorowanie integralności plików wykrywa zmianę, nawet jeśli nie rozumie zaciemnionej treści;
• przegląd podejrzanych funkcji z rozwagą. Wyszukanie funkcji wymienianych przez Sucuri ^[5] daje listę miejsc do sprawdzenia, a nie listę plików do usunięcia;
• pobieranie wtyczek tylko z zaufanych źródeł, które wymagają czytelnego kodu ^[4];
• kontrolę kont i dodatków po incydencie. W kampanii DollyWay złośliwy kod był dodatkowo zapisywany jako fragmenty kodu we wtyczce WPCode, a przestępcy zakładali ukryte konta administratora ^[6]. Szerzej opisuje to czyszczenie przejętej strony.

Przykładowe polecenie, które wypisuje pliki z funkcjami wartymi ręcznego przeglądu:

grep -rlE "base64_decode|gzinflate" wp-content/

Wynik trzeba porównać z oryginalnymi wersjami wtyczek i motywów, zanim cokolwiek zostanie zmienione.