Posts Tagged ‘HoneySpider’

Zagrożenie na www.pajacyk.pl – jednak malware, a nie reklama

24 February 2009

pajacyk-logoW niedzielę 22 lutego na kilku forach internetowych pojawiły się wypowiedzi zaniepokojonych internautów informujące, że ich programy antywirusowe wykrywają złośliwe oprogramowanie na stronie www.pajacyk.pl (na przykład Avast identyfikował je jako VBS:Malware-gen). Przeprowadzona przez nas analiza potwierdziła zagrożenie – jak się okazało do kodu strony Pajacyka został doklejony skrypt JavaScript przekierowujący na inną stronę infekującą internautów trojanem ZBot. Fragment źródła strony z przekierowującym skryptem (zapamiętany przez nas około godziny 10:00 w poniedziałek 23 lutego) wyglądał następująco:

pajacyk-js

Skrypt JS jest zaciemniony (ang. obfuscated) w celu utrudnienia jego analizy oraz oszukania silników antywirusowych – po zdekodowaniu zawiera on ukrytą ramkę IFRAME z inną stroną, która dokładnie w ten sam sposób przekierowuje do właściwej strony zawierającej exploit. Zagrożenie związane ze stroną Pajacyka potwierdził także nasz system klienckich honeypotów HoneySpider Network. Witryna w jednoznaczny sposób została sklasyfikowana jako złośliwa:

pajacyk-hsn

Dzięki wysoko-interaktywnym honeypotom przechwyciliśmy złośliwe pliki wykonywalne z trojanem, które były automatycznie ściągane i uruchamiane przez exploit umieszczony na stronie WWW (tzw. drive-by download):

pajacyk-hsn2

Powyższą zawartość pobraną w wyniku odwiedzenia Pajacyka poddaliśmy skanowaniu antywirusowemu w serwisie VirusTotal – ponad połowa silników AV wykryła zagrożenie:
http://www.virustotal.com/pl/analisis/ce1ade3e46f3089ae3a267c2e0e264bb

Polska Akcja Humanitarna podała informację, że alarmy programów antywirusowych występujące po wejściu na witrynę Pajacyka są spowodowane obecnością reklamy w postaci wyskakującego okienka, którą bardziej czułe antywirusy klasyfikują jako złośliwe oprogramowanie, a zagrożenie nie istnieje. Niestety nie jest to prawdą – kod doklejony do strony infekował internautów, którzy odwiedzili Pajacyka w niedzielę lub poniedziałek rano. Zagrożenie zostało usunięte dopiero w poniedziałek około godziny 10:30. Według statystyk umieszczonych na www.pajacyk.pl, tylko w niedzielę witrynę odwiedziło prawie 100 tysięcy osób. Trudno oszacować ile z nich zostało zainfekowanych, ale skala problemu jest poważna.

Wszystkim osobom, które w tym czasie otworzyły stronę Pajacyka, zalecamy wykonanie pełnego skanowania systemu jednym ze skutecznych w tym przypadku programów antywirusowych (lista wykrywających to zagrożenie silników AV znajduje się w linku do analizy naszej próbki w serwisie VirusTotal). Ponadto w ochronie komputera przed niebezpiecznymi elementami stron WWW (w tym skryptami JavaScript przekierowującymi na złośliwe strony) pomagają wtyczki do przeglądarek blokujące takie elementy (na przykład dodatek NoScript do przeglądarki Firefox). Zapewniają one ochronę przed innymi stronami infekującymi odwiedzających, tym bardziej że przypadek Pajacyka nie jest odosobniony i takie witryny cały czas są obecne w sieci.

Mechanizm doklejania złośliwych skryptów do popularnych stron WWW często polega na wykorzystywaniu zdobytych haseł do serwerów FTP, na których strony te są hostowane. Jeśli komputer webmastera strony jest zainfekowany działającym w ten sposób koniem trojańskim, to przy aktualizacji strony za pomocą klienta FTP trojan przechwytuje dane logowania do konta FTP, po czym ściąga z serwera odpowiedni plik ze stroną główną (np. index.html, index.htm, index.php), dokleja złośliwy skrypt JS (często tuż za znacznikiem <body> lub tak jak w przypadku Pajacyka tuż przed znacznikiem </body>) i na koniec wysyła tak zmodyfikowaną wersję strony z powrotem na serwer FTP. Coraz popularniejsza jest też metoda zorientowana na wykorzystywanie haseł już zapamiętanych w klientach FTP – często dotyczą one aplikacji Total Commander. Dlatego, oczywiście oprócz posiadania programu antywirusowego z aktualną bazą sygnatur, zalecamy nie korzystać z mechanizmu zapamiętywania haseł w tego typu programach. Szczególnie webmasterzy powinni zwracać uwagę i sprawdzać, czy strony przez nich zarządzane nie zostały zaatakowane w podobny sposób.

Metoda polegająca na umieszczaniu przekierowań do złośliwych stron na innych popularnych witrynach zyskuje coraz większą popularność wśród cyberprzestępców, ponieważ zaufanie do takich stron jest duże (zdecydowanie większe niż na przykład do adresu wysłanego w spamie), a poza tym są one odwiedzane przez dużą liczbę niczego nie podejrzewających internautów (atakujący nie musi dodatkowo zachęcać do wejścia na taką stronę i rozsyłać jej adresu).

Krytyczna luka w Internet Explorer 7 już wykorzystywana!

20 February 2009

W lutowych biuletynach bezpieczeństwa Microsoft opisał krytyczną lukę MS09-002 w przeglądarce Internet Explorer 7 pozwalającą na wykonanie w systemie dowolnego kodu poprzez wyświetlenie specjalnie spreparowanej strony WWW. Równocześnie opublikowany został patch na tą podatność. Tydzień po opublikowaniu poprawki w sieci pojawił się exploit wykorzystujący lukę MS09-002 w IE 7. Co ciekawe, exploit został stworzony na podstawie poprawki wydanej przez Microsoft z wykorzystaniem technik inżynierii wstecznej (ang. reverse engineering). Krążył on początkowo jako dokument programu Word, rozsyłany jako załącznik w spamie. Dokument zawierał kontrolkę ActiveX, która automatycznie pobierała złośliwą stronę WWW. Zawarty na tej stronie kod ściągał i instalował pod postacią biblioteki .dll backdoora, którego główną funkcją było wykradanie informacji z zainfekowanego komputera.

Ostatnio atakujący wykorzystują wspomnianą lukę także w atakach klienckich na przeglądarki WWW. W tym przypadku nie jest wymagana interakcja użytkownika polegająca na otworzeniu załącznika przesłanego w spamie, a jedynie wejście na spreparowaną stronę WWW zawierającą kod expolita. Infekcja następuje automatycznie, bez ingerencji czy wiedzy użytkownika (tzw. drive-by download). Takie strony już pojawiły się w sieci i są wykorzystywane do infekowania niezałatanych systemów złośliwym oprogramowaniem. Exploit nie jest jeszcze powszechnie wykrywany przez silniki antywirusowe – złośliwy kod wykorzystujący lukę MS09-002 umieszczony na jednej z takich stron jest wykrywany tylko przez 9 z 38 antywirusów z serwisu VirusTotal: http://www.virustotal.com/pl/analisis/a3262a0018e7b02e4e647506a8365091.
Kod z tej strony nie był zaciemniony (ang. obfuscated) – w przypadku zastosowania tej techniki współczynnik detekcji jest jeszcze niższy. Dopiero właściwy plik wykonywalny (zawierający konia trojańskiego) ściągany i uruchamiany przez exploita jest wykrywany przez większą liczbę programów antywirusowych: http://www.virustotal.com/analisis/7c7dc6a0fe92a80f53e65b099ff3391f.

Incydenty związane z luką MS09-002 stanowią kolejne potwierdzenie, że ataki na aplikacje klienckie zyskują na popularności. Zamiast aktywnego poszukiwania celów, jak w przypadku propagacji robaków sieciowych, złośliwy kod umieszczany jest na stronach internetowych pasywnie oczekując na odwiedziny niczego niepodejrzewającego internauty. Do detekcji tego rodzaju zagrożeń został stworzony projekt HoneySpider Network – system klienckich honeypotów bazujący na robotach emulujących przeglądarki jak i na rzeczywistych przeglądarkach uruchamianych w wirtualnym środowisku.

Ponieważ kod exploita został publicznie udostępniony, w najbliższym czasie można spodziewać się wzrostu liczby stron wykorzystujących opisywaną lukę do infekowania użytkowników różnymi wariantami złośliwego oprogramowania. Osobom, które jeszcze nie zaktualizowały systemu, rekomendujemy jak najszybszą instalację łatek MS09-002. Warto zaznaczyć, iż błąd ten występuje tylko w przeglądarce Internet Explorer w wersji 7 (IE 6, jak również inne przeglądarki jak Firefox czy Opera są bezpieczne). Nie oznacza to jednak, że użytkownicy alternatywnych przeglądarek są bezpieczni – w przypadku spreparowanego załącznika Word do uruchomienia strony WWW za pomocą kontrolki ActiveX zostanie zawsze użyty Internet Explorer, niezależnie od ustawień domyślnej przeglądarki. Jest więc niezwykle ważne, aby instalować aktualizacje dla wszystkich przeglądarek zainstalowanych w systemie, nawet jeśli nie wszystkie z nich są używane.

Więcej informacji:
http://www.microsoft.com/poland/technet/security/bulletin/ms09-002.mspx
http://isc.sans.org/diary.html?storyid=5884
http://isc.sans.org/diary.html?storyid=5899
http://blogs.zdnet.com/security/?p=2607

Użytkownicy Internet Explorer zagrożeni! (aktualizacja)

10 December 2008

Ostatnia aktualizacja: 18.12.2008 (przejdź bezpośrednio)

W sieci powszechnie dostępny jest exploit na odkrytą niedawno lukę w przeglądarce Internet Explorer 7. Wczorajsze aktualizacje Micosoft nie łatały wykorzystywanej podatności, co oznacza, że nawet całkowicie zaktualizowane komputery są podatne na potencjalny atak. Exploit wykorzystuje lukę w module obsługującym XML i przepełnia stertę (tzw. atak heap overflow). Wcześniej sprawdza typ i wersję używanej przeglądarki, a także rodzaj systemu operacyjnego.

Przepełnienie sterty wykonuje się tylko dla IE w wersji 7 działającej w systemie Windows XP lub 2003. Nie wiadomo jednak na razie, czy inne wersje przeglądarki bądź systemu Windows (np. Vista) są podatne na atak. Ciekawy jest także fakt użycia funkcji sleep, która powoduje zawieszenie wykonywania kodu javaScript na określony czas (w wersji exploita, którą zdobyliśmy, są to 3 sekundy, natomiast wiadomo, że ta wartość zmienia się). Najprawdopodobniej chciano w ten sposób niejako “ogłupić” automatyczne narzędzia wykorzystywane do zbierania i/lub analizy malware’u.

Szkodliwy kod JavaScript opublikowany został m.in. na wielu chińskich serwisach społecznościowych (głównie forach, także blogach) traktujących o (nie)bezpieczeństwie komputerowym. Potencjalnie można go wykorzystać do wykonania w atakowanym systemie dowolnego kodu (najprawdopodobniej będzie to instalacja trojana lub inne złośliwe oprogramowanie). Wprawdzie brak jest doniesień o masowym wykorzystaniu exploita, jednak może być to tylko kwestią czasu. Należy zwrócić uwagę, że w przypadku masowego ataku taki złośliwy JavaScript może być wstrzyknięty do kodu strony www, którą do tej pory uważaliśmy za bezpieczną. Na razie nie istnieją żadne łaty poprawiające błąd, ale warto pamiętać, że podatna na atak jest tylko przeglądarka Internet Explorer.

Ataki na aplikacje klienckie są coraz chętniej wykorzystywane przez cyberprzestępców, szczególnie te skierowane na przeglądarki internetowe i dodatki do nich. W celu walki z tego typu zagrożeniem powstał projekt HoneySpider Network. Związane z nim nasze klienckie honeypoty potwierdziły zagrożenie, jakie niesie ze sobą opisany wyżej exploit.

Więcej informacji:
http://www.microsoft.com/technet/security/advisory/961051.mspx
http://isc.sans.org/diary.html?storyid=5458

Aktualizacja (czw, 11 gru 2008, 13:53):

Jeszcze wczoraj pojawiła się w sieci wersja exploita, która działa także pod całkowicie zaktualizowanym systemem Windows Vista (zarówno z jak i bez SP1). Obie wersje złośliwego kodu (zarówno ta przeznaczona na Windowsa XP/2003 jak i na Vistę) są modyfikowane (cyberprzestępcy dostosowują je do swoich potrzeb) i najczęściej już nie sprawdzają rodzaju/wersji przeglądarki czy systemu operacyjnego, tylko próbują się wykonać za każdym razem.

Exploity ponadto są już powszechnie wykorzystywane do zarażania komputerów internautów: pojawia się coraz więcej stron www, które zawierają wyżej opisany złośliwy JavaScript. Są to głównie strony chińskie (domena .cn), do których odnośniki (URL) są wstrzykiwane w zawartość innych “legalnych” stron. Jak udało się ustalić specjalistom zajmującym się tym problemem komputery infekowane są najczęściej złośliwym oprogramowaniem wykradającym hasła do gier online. Oczywiście cyberprzestępcy mogą równie dobrze wykorzystać malware, który np. wykrada hasła do banków, numery kart kredytowych, czy zmienia komputer ofiary w członka botnetu (tzw. komputer-zombie).

Korzystając z serwisu Virustotal.com wysłaliśmy do przeskanowania przez silniki antywirusowe kilka wariantów exploita. Oto linki do wyników analiz:

Więcej informacji można znaleźć na stronach:
http://blogs.zdnet.com/security/?p=2296
http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20081210

Aktualizacja (czw, 18 gru 2008, 10:30):

Microsoft wydał patch łatający opisaną wyżej lukę (biuletyn bezpieczeństwa oznaczony numerem MS08-078). Apelujemy zatem do wszystkich użytkowników systemów Windows o jak najszybsze zaktualizowanie swojej przeglądarki Internet Explorer nawet, jeżeli nie jest ona używana do surfowania po internecie (ponieważ wiele aplikacji – jak np. Gadu-Gadu – korzysta z niej i przez to pośrednio jest podatne na ataki). Można to zrobić poprzez:

  • Aktualizacje automatyczne (dostępne w Panel sterowania),
  • korzystając z witryny Microsoft Update
  • ściągając odpowiednią do posiadanego systemu i wersji przeglądarki poprawkę bezpośrednio ze strony Centrum Pobierania Microsoft i instalując ją ręcznie.

Ile domen fast-flux w spamie?

30 October 2008

W ramach projektu HoneySpider Network, poza opracowywaniem sposobów rozpoznawania złośliwych bądź podejrzanych stron WWW przez klienckie honeypoty, pojawiła się konieczność rozpoznawania, czy badany URL należy do sieci fast-flux czy nie. Decyzja taka wpływa na sposób badania takiego URLa – zdarzają się bowiem przypadki, w których część komputerów sieci fast-flux przekierowuje nie na złośliwe strony, ale na strony nieszkodliwe. Może się też zdarzyć, że IP zwracane w odpowiedzi na zapytanie o domenę w danym momencie są nieosiągalne, co powoduje, że pająki sieciowe nie zbadają prawidłowej strony.

W NASK opracowano więc narzędzie, pozwalające rozpoznać czy dana domena należy do sieci fast-flux czy nie. Narzędzie umożliwia sprawdzenie dużej ilości domen w krótkim czasie, tak aby wykorzystywany algorytm mógł zostać dodany do pająków sieciowych opracowywanych w ramach projektu. Zaimplementowano własną metodę, bazując na uwagach zawartych w Honeynet Project: Know Your Enemy: Fast-Flux Service Networks. Metodę zweryfikowano empirycznie oraz porównując z metodą opracowaną przez Thorsten’a Holz’a. W porównaniu do wspomnianej metody, algorytm opracowany w NASK umożliwia uzyskanie szybszych wyników, bez konieczności zapytań do zewnętrznych serwisów whois przy zachowaniu podobnych wskaźników skuteczności.

Zbadaliśmy URLe przychodzące w spamie do skrzynki pocztowej cert@cert.pl oraz spamtrap’ów CERT Polska. Każdy URL przychodzący w spamie wysłany był do pająka sieciowego, który badał stronę i ściągał kolejne URLe z badanych stron. W przypadku spamu z ostatnich dni na cert@cert.pl, wydobyto bezpośrednio z maili 2748 unikalnych URLi (2106 unikalnych domen). Po zapytaniach pająków o te URLe uzyskaliśmy w sumie 2664 unikalnych domen. Z tych domen:

  • 1965 zostało sklasyfikowanych jako nie należących do fast-flux
  • 455 już się nie resolvowało
  • 244 okazało się być domenami typu fast-flux

W przypadku testu spamu ze spamtrap’ów, wydobyto bezpośredniu z maili 2840 unikalnych URLi (2159 unikalnych domen). Po zapytaniu pająków o te URLe uzyskaliśmy w sumie 2473 unikalnych domen. Z tych domen:

  • 1796 zostało sklasyfikowanych jako nie należących do fast-flux
  • 550 już się nie resolvowało
  • 127 okazało się być domenami typu fast-flux

W pierwszym przypadku ilość domen fast-flux kształtowała się na poziomie 9,2%, w drugim 5,1%. Oznaczo to, że fast-flux jest częstym zjawiskiem wykorzystywanym w spamie, uzasadniając tezę, że aby skutecznie analizować URLe ze spamu, kliencki honeypot musi być w stanie poprawnie rozpoznawać takie domeny.

Projekt HSN – testy wydajności systemów plików

28 October 2008

Niniejszym wpisem rozpoczynamy cykl artykułów opisujących interesujące zagadnienia związane z projektem HoneySpider Network. Będą one zawierać charakterystykę problemów, jakie napotkaliśmy przy rozwoju tego klienckiego honeypota, jak również kwestie popularnych ataków na przeglądarki WWW i technik wykorzystywanych przez cyberprzestępców.

Podczas wdrażania modułu HSN o niskim poziomie interakcji (bazującym na robotach emulujących przeglądarki) zaistniała konieczność szybkiego pozbycia się plików ściągniętych przez te roboty. Jak się okazało, kasowanie dziesiątek milionów małych plików rozproszonych po skomplikowanej strukturze katalogów wcale nie jest procesem szybkim – czas takiej operacji przeprowadzonej na systemie plików EXT3 był liczony w godzinach. Stąd zaistniała konieczność przeprowadzenia testów wydajnościowych popularnych systemów plików, których wyniki prezentujemy poniżej.

Rozpatrywaliśmy 5 popularnych systemów plików dostępnych domyślnie w większości dystrybucji linuksowych: EXT3, XFS, ReiserFS, JFS, EXT4Dev. Zaprojektowany test polegał na utworzeniu na partycji z testowanym systemem plików 1 miliona różnej wielkości plików rozproszonych po 1000 katalogów, a następnie zmierzeniu czasu ich kasowania za pomocą polecenia rm. Aby uzyskać powtarzalność testu, na każdym systemie plików tworzona była identyczna struktura plików i katalogów.

W celu upodobnienia takiego zbioru plików do ściągniętych przez roboty stron internetowych, tworzone pliki cechowały się różnym rozmiarem rzędu kilkudziesięciu kB (średnio 37kB). Cała struktura plików miała w sumie rozmiar około 38 GB (w zależności od specyfiki konkretnego systemu plików). Uzyskano następujące czasy kasowania:

  • EXT3: 2667 s
  • XFS: 5345 s
  • ReiserFS: 222 s
  • JFS: 4840 s
  • EXT4Dev: 3764s

Uzyskane wyniki pokazują bardzo wyraźną przewagę ReiserFS pod względem szybkości kasowania, co potwierdza powszechną opinię o dobrych wynikach tego systemu plików przy operacjach na małych plikach (zwłaszcza do 4 kB). Pozostałe systemy plików mają dość zbliżone wyniki (rzędu kilkudziesięciu minut), choć można zauważyć nieco lepsze rezultaty EXT3. Niestety najbardziej obiecujący pod względem wydajności ReiserFS obecnie nie jest już wspierany (o tym dlaczego nie jest już wspierany zainteresowani mogą przeczytać na przykład tutaj).

Nie zdecydowaliśmy się na testy jego następcy, systemu Reiser4, gdyż jest on we wczesnej fazie testowej i nie wszedł jeszcze do stabilnej wersji jądra Linuksa. Dylemat między szybkim lecz niewspieranym ReiserFS a zdecydowanie wolniejszymi pozostałymi systemami plików doprowadził do powstania odmiennej koncepcji – na ściąganą przez roboty zawartość stron internetowych przeznaczona byłaby cała partycja, a czyszczenie odbywałoby się przez ponowne utworzenie wybranego systemu plików (za pomocą mkfs). Taka operacja jest stosunkowo szybka – w zależności od konkretnego systemu plików trwa od kilku do kilkudziesięciu sekund i nie zależy od ilości plików zgromadzonych na partycji.