19:30
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.

Na uwagę zasługuje sposób sterowania zbackdoorowanym serwerem. Fałszywa binarka webservera nie ma nigdzie zakodowanego adresu serwera C&C — to atakujący musi się połączyć z serwerem, aby wydawać mu instrukcje lub zmieniać konfigurację. Backdoor, po otrzymaniu odpowiedniego zapytania GET wykonuje zwrotne połączenie na adres IP wskazany przez atakującego.
Cdorked.A

Cdorked.A – komendy

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).

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

13 komentarzy

Dodaj komentarz
  1. 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ść ;-)

  2. # 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

  3. Najłatwiej będzie Ci sprawdzić sumy kontrolne Twoich binarek z tymi w paczkach.

  4. 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).

  5. Pokazcie mi gdzie dzis NIE MA backdoora.

    • na niebezpieczniku.pl!

  6. Szlo by polemizowac.

  7. […] 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 […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: