9/5/2013
Pod koniec kwietnia, firma Sucuri wraz z ESET-em opisały backdoora, którego odkryto w serwerach Apache. Ponieważ problem dotykał tylko serwerów Apache i to instalowanych przez cpanel, a backdoora łatwo dało się namierzyć robiąc prostego grepa, do ataku nie przyłożono zbyt wielkiej uwagi. Teraz jednak okazało się, że backdoor znajduje się również w innych webserverach, a jego obecność potwierdzono na instancjach odpowiedzialnych za serwowanie kilkudziesięciu najpopularniejszych strona na świecie.
Na czym polega atak Linux/Cdorked
Atakujący po dostaniu się na serwer (wciąż nie wiadomo w jaki sposób) podmieniają binarkę webservera (np. Apache) na taką, która wstrzykuje w serwowaną stronę internetową złośliwy kod (poprzez jeden ok. 30 000 URLi). Następuje wtedy przekierowanie ofiary na strony spamerskie (głównie pornograficzne) lub takie, które próbują infekować komputer ofiary złośliwym oprogramowaniem poprzez Blackhole Exploit Pack.
Jak sprawdzić, czy jesteśmy zainfekowani?
Po pierwszych doniesieniach bagatelizowano problem, ponieważ atak można było przeprowadzić jedynie na serwerach z cpanelem, gdzie proces Apache’a miał uprawnienia roota (sic!). Dodatkowo, backdoora można było łatwo zidentyfikować wykonująć na serwerze polecenie:
grep -r open_tty /usr/local/apache/
lub korzystając z tego narzędzia.
Nginx i Lighttpd też podmieniane
Najnowsze doniesienia mówią o tym, że już nie tylko Apache, ale także nginx oraz lighttpd są backdoorowane. To pokazuje, jak zdeterminowani są atakujący. Skutkami ataku ma być także dotkniętych już 400 serwerów, z czego ok. 50 jest notowanych na Alexa TOP 100 000. ESET ujawnia, że co najmniej 100 000 internautów korzystających z ich produktów próbowano przekierować na złośliwe strony (ponieważ nie każdy internauta ma zainstalowanego ESET-a, to oznacza, że liczba potencjalnych ofiar jest zdecydowanie większa).
Sposób wejścia na system wciąż nieznany
Do tej pory nie jest jasne jak atakującym udaje się uzyskać roota na serwerach na których podmieniają binarki webserverów. Być może chodzi o bruteforce’owanie haseł dostępowych po SSH?
Co ciekawe, złośliwe przekierowanie na zbackdoorowanym webserverze nie uaktywni się, jeśli klientem jest ktoś, kto ma ustawiony język przeglądarki jako: Japoński, Fiński, Rosyjski, Ukraiński, Kazachski lub Białoruski. Inni, o ile posiadają aktualną wersję przeglądarki i wtyczek też mogą się czuć spokojnie (w Blackhole Exploit Packu wykorzystywanym do infekcji na chwilę obecną nie ma 0day’ów).
dobra, ale jak sprawdzic czy moj nginx/lighttpd jest ‘czysty’ ?
może skorzytaj z tripwire ?
Tripwire nic nie da w juz zainfekowanym systemie po co piszesz glupoty
zawsze rada na przyszłość ;-)
# grep -r open_tty /usr/local/apache/
grep: /usr/local/apache/: Nie ma takiego pliku ani katalogu
# locate open_tty
#
Debian, stabilny. Apacz z paczki.
Co jeszcze możemy sprawdzić?
zacznij od manuala grepa ;)
apt-get update && apt-get install debsums
Update bazy: debsums_init
Sprawdzanie sum kontrolnych apacza:
debsums apache2.2-bin
debsums apache2.2-common
Najłatwiej będzie Ci sprawdzić sumy kontrolne Twoich binarek z tymi w paczkach.
W ostatnim tygodniu otrzymywałem curl’a z ruskich serwerów odpytującego o nagłówki (w tym którym jest także nazwa webserwera, curl -I)
root@ocean:~% curl -I google.pl
HTTP/1.1 301 Moved Permanently
Location: http://www.google.pl/
Content-Type: text/html; charset=UTF-8
Date: Thu, 09 May 2013 20:53:45 GMT
Expires: Sat, 08 Jun 2013 20:53:45 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 218
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
a chwile potem bruteforce na ssh z ukrainy (nginx ma ustawione server_tokens na off a ssh fail2ban).
Pokazcie mi gdzie dzis NIE MA backdoora.
na niebezpieczniku.pl!
Szlo by polemizowac.
[…] w jaki przełamano zabezpieczenia serwerów (na pierwszy rzut oka, spawa wygląda na podobną do tej). Co ciekawe, kilka polskich firm hostingowych to tak naprawdę odsprzedawanie miejsca na serwerach […]