20. rocznica robaka internetowego – czas na podsumowania i wnioski (cz.1)

5 November 2008 TomaszG.

computer wormW niedzielę 2. listopada minęło dwadzieścia lat odkąd po raz pierwszy w sieci Internet pojawił się robak komputerowy (czyli samopowielający się i samopropagujący się przez sieć złośliwy program komputerowy). Jego autorem był Robert Tappan Morris. Został napisany by uwydatnić błędy w ówczesnych unixowych systemach z rodziny BSD, Sun oraz Vax. W założeniu twórcy miał być niegroźny. Jednakże błąd w kodzie spowodował, że szybko rozprzestrzenił się na ok. 6 tysięcy komputerów całkowicie je paraliżując. Usuwanie skutków działalności robaka zajęło 8 dni a szkody oszacowano na 10 mln dolarów. Robert Morris został osądzony i skazany.

Rocznica ta jest doskonałą okazją do podsumowania ewolucji robaków komputerowych, analizy metod ich propagacji, a także prześledzenia zmian w motywacji i celach ich autorów. Można też pokusić się o próbę odgadnięcia ich przyszłości. Poniżej opisane zostaną najciekawsze przypadki robaków internetowych będące swoistymi „kamieniami milowymi” w (nie)bezpieczeństwie sieci Internet.

Przez ponad 10 lat od debiutu robaka Morris praktycznie niewiele powstawało godnych uwagi robaków. To był czas królowania wirusów. Nie miały one właściwości samopropagacji, najczęściej przenosiły się w zainfekowanych plikach na dyskietkach. W roku 1999 zrodził się robak Melissa, który rozprzestrzenił się po Internecie w przeciągu zaledwie kilku godzin. Infekował pliki programów Word i Excel, następnie rozsyłał się samodzielnie jako załącznik e-maili do adresów znalezionych w książce kontaktowej programu pocztowego Outlook ofiary. Infekcja wymagała interakcji od użytkownika, który musiał świadomie otworzyć załącznik. Oprócz obciążenia sieci, jakie powodował w wyniku masowej autopropagacji, niektóre wersje robaka potrafiły wyrządzić szkody w systemie ofiary poprzez kasowanie plików systemowych. Wypisywał także różne komunikaty. Malware był typowo złośliwy i jego celem była po prostu jak Love Letter / ILoveYou computer wormnajwiększa propagacja oraz wyrządzanie szkód w komputerze ofiary.

Rok później ujawnił się robak napisany w języku VBScript, który również rozsyłał się głównie przez pocztę elektroniczną, ale oprócz niej korzystał także z kanałów IRC. Z powodu słów zawartych w temacie e-maili, nazwany został Love Letter lub ILoveYou. Bazował na rozwiązaniach znanych z innego robaka jakim był Christmas Tree EXEC (był aktywny w 1987 roku w sieciach m.in. EARN i BITNET). Jego działalność również ograniczała się do działań niszczycielskich. Łączne straty zsumowane z kilku lat działalności szacowane były na od 5,5 do 10 miliardów dolarów i należą do jednych z najwyższych w historii.

W 2001 roku pojawił się robak, który nie wymagał żadnej interakcji ze strony użytkownika. Nazwany został Code Red i atakował serwery IIS firmy Microsoft. Wykorzystując podatność w ich oprogramowaniu był w stanie poprzez specjalnie spreparowane zapytanie HTTP przepełnić bufor serwera i wykonać na nim swój kod. Na zainfekowanym serwerze podmieniał treść stron internetowych (atak zwany website defacement) i rozprzestrzeniał się dalej. Robak był jednocześnie tzw. bombą logiczną (ang. logic bomb) – po ok. 20 dniach od infekcji uruchamiany był atak DoS na wcześniej zdefiniowane adresy IP (znalazł się tam m.in. adres strony Białego Domu). W przeciwieństwie do wcześniejszych robaków charakterystyczne dla Code Red było to, że nie wyrządzał żadnych większych szkód maszynom, które infekował. Natomiast miał konkretny cel: zaprogramowany był do dalszego dedykowanego ataku na wybrane serwery www. Adresy IP serwerów Białego Domu mogły wskazywać na polityczny motyw twórców robaka.

W tym samym roku pojawił się robak o nazwie Nimda (słowo „admin” czytane od końca). Był poniekąd połączeniem pomysłowości dotychczasowych robaków. Infekował zarówno komputery klienckie jak i serwery. Rozprzestrzeniał się na wiele sposobów: przez wiadomości e-mail (jako załącznik), w sieci LAN poprzez udostępnione zasoby sieciowe, z wykorzystaniem podatności w serwerach www (podobnie do Code Red), użyciem tylnych wejść pozostawionych przez inne robaki (w tym także Code Red), oraz infekowanie poprzez luki w przeglądarkach internetowych (złośliwy kod umieszczany na stronach www zaatakowanych wcześniej serwerów). Miał także właściwości typowe dla wirusa: dopisywał się do wykonywalnych plików i czekał na interakcję użytkownika. Dzięki tak zróżnicowanym metodom propagacji robak był w stanie bardzo szybko się rozprzestrzeniać.

MS SQL Slammer computer wormW roku 2003 wybuchła epidemia robaka Slammer, który wykorzystywał podatność w serwerze bazodanowym MS SQL. Rozprzestrzeniał się bez jakiejkolwiek interakcji użytkownika poprzez pakiety UDP, a cały jego kod zajmował tylko 376 bajtów. Dzięki specyfikacji komunikacji UDP (brak nawiązania połączenia i weryfikacji przesłanych pakietów), a także dzięki niewielkiemu rozmiarowi (jeden pakiet wystarczył do wyexploitowania luki i w konsekwencji infekcji) propagacja Slammera osiągnęła niesamowite tempo – liczba zainfekowanych komputerów podwajała się co 8,5 sekundy! To powodowało gigantyczny wzrost ruchu w sieci (Slammer skanował “na ślepo”, bez wcześniejszej weryfikacji czy ma do czynienia z serwerem MS SQL), co skutkowało całkowitym wysyceniem łączy i niemożliwością korzystania z sieci (swoisty atak DoS). Brak łączności oczywiście dotknął wszystkich podłączonych do sieci, nawet jeżeli nie używali atakowanego oprogramowania. Pomimo istnienia łat na lukę wykorzystywaną przez robaka jego aktywność w Internecie jest nadal bardzo duża, co potwierdzają obserwacje dokonane przez system ARAKIS (od dawna góruje w rankingu najczęściej dopasowywanych reguł Snortowych oraz statystykach aktywności klastrów).

W tym samym roku, wykorzystując podatność w module RPC systemów z rodziny Windows, pojawił się robak Blaster (zwany także Lovesan). Początkowo został zaprojektowany, by w ściśle określonym czasie (13.08.2003) wszystkie zainfekowane nim komputery przeprowadziły jednocześnie atak TCP SYN flood na witrynę windowsupdate.com. Fakt ten odkryto przed tą datą, więc (pomijając fakt użycia nie do końca odpowiedniego adresu) Microsoft prewencyjnie czasowo zamknął tą stronę. Skutkiem ubocznym działalności Blastera na niektórych systemach był natomiast okresowy samoczynny restart komputera co kilka minut. Kolejne mutacje robaka służą obecnie do przenoszenia innych złośliwych programów (głównie trojanów) i – tak samo jak w przypadku Slammera – pomimo dostępnych poprawek Blaster jest nadal bardzo “popularny” w Internecie (co również potwierdzają obserwacje ARAKISa).

W kontekście Blastera warto wspomnieć o robaku Welchia (zwanym również jako Nachi). Otóż został on zaprogramowany by… walczyć z Blasterem. Wykorzystując lukę podobną do tej exploitowanej przez Blastera rozprzestrzeniał się na podatne komputery a następnie ściągał i instalował poprawki Microsoftu łatające podatności. Dodatkowo usuwał z systemu – jeżeli znalazł – Blastera a po pewnym okresie czasu kasował sam siebie. Pomimo dobrych intencji autora oraz niedestruktywnej dla systemu działalności robak jest uważany za szkodliwy, ponieważ jego propagacja zapychała łącza internetowe. Ponadto witryna Microsoft, z której ściągane były łaty, miała problemy z obsługą połączeń pochodzących z łatanych “na siłę” komputerów.

MyDoom, Bagle vs. Netsky/SomeFool computer wormSkoro mowa o “wojnie robaków”, to należy wspomnieć o trzech znanych robakach: MyDoom, Bagle (zwanym także Beagle) i Netsky (inaczej SomeFool). Wszystkie trzy rozprzestrzeniają się przez pocztę e-mail (wartym odnotowania faktem jest, że korzystają z własnych silników SMTP a nie z konta pocztowego ofiary). Twórca tego ostatniego był w konflikcie z autorami pierwszych dwóch, więc napisał robaka usuwającego ich malware z zainfekowanych systemów. W przeciwieństwie do robaka Welchia nie był on jednak zaprogramowany tylko do “dobrych celów”, lecz miał cechy typowego malware’u, także te “uciążliwe” – zainfekowany nim komputer potrafił w zadanych godzinach (najczęściej wczesno-porannych)  zacząć wydawać nieprzyjemne dla ucha dźwięki. Oczywiście jego propagacja mocno obciążała łącza oraz serwery pocztowe. Wszystkie trzy robaki od pojawienia się w 2004 roku doczekały się bardzo wielu mutacji i są aktywnie wykorzystywane w Internecie przez cyberprzestępców do dziś (głównie ze względu na wbudowaną funkcjonalność serwera SMTP).

Do dzisiaj (oczywiście pomimo istnienia odpowiednich łat) również szeroko wykorzystywany jest robak Sasser, który masowo infekował systemy Windows już w 2004 roku. Cyberprzestępcy korzystają z jego ciała by zarazić ofiarę swoim malware’em (najczęściej są to różnego rodzaju trojany). Interesujący jest fakt, że robak ten sam posiadał pewną lukę, która została wykorzystana przez innego robaka o nazwie Dabber. Tym razem autor tego ostatniego bynajmniej nie miał dobrych intencji: komputery zainfekowane przez Sassera były po prostu “przejmowane” przy pomocy Dabbera i dalszego wykorzystywania w cyberprzestępczej działalności.

Ciąg dalszy (część 2) tutaj…

Ile domen fast-flux w spamie?

30 October 2008 piotrk

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.

Phreaking w erze telefonii VoIP

28 October 2008 marcinm

Od połowy września 2008 roku w sieci obserwowane są skanowania w poszukiwaniu niezabezpieczonych bramek PSTN, które umożliwiają zestawienie połączenia pomiędzy siecią VoIP a publiczną siecią telefoniczną PSTN. Takie niepoprawnie skonfigurowane bramki PSTN umożliwiają atakującemu wykonywanie połączeń telefonicznych do abonentów publicznej sieci na koszt właściciela takiej bramki.

Atak polega na wysyłaniu (najczęściej na port 5060/UDP) pakietów zawierających żądanie INVITE protokołu SIP. Żądanie takie w zamierzeniu służy do inicjowania połączeń głosowych. Atakujący może dowolne sfałszować nagłówki żądania SIP (takie jak numer wywołujący czy identyfikator połączenia), jednak adres IP atakującego w opisywanym scenariuszu nie jest fałszowany, aby umożliwić mu otrzymanie odpowiedzi (a tym samym informacji o powodzeniu ataku). Gdy taki pakiet dotrze do publicznie dostępnej bramki PSTN, nastąpi przekazanie połączenia do publicznej sieci PSTN. Co ciekawe, gdy taki pakiet trafi do telefonu VoIP, nastąpi wywołanie (to właśnie dzwoniące telefony VoIP były jednym z symptomów, dzięki którym zauważono opisywane skanowania). Podejrzane żądania INVITE zostały także zauważone przez system wczesnego ostrzegania ARAKIS – pierwsze obserwacje pochodzą z 14 września 2008 roku. Dnia 2 października nastąpił znaczny wzrost takiej aktywności, co doprowadziło do wyzwolenia reguły systemu wykrywania włamań Snort “VOIP INVITE Message Flood“. Tak przedstawia się przykładowy pakiet protokołu SIP zarejestrowany na porcie 5060/UDP zawierający podejrzane żądanie INVITE:

Aby zapobiec tego typu atakom, administratorzy bramek PSTN lub serwerów proxy SIP powinni wyeliminować możliwość nieautoryzowanego dostępu do tych usług. Zabezpieczenie powinno polegać na umożliwieniu korzystania z bramek tylko wybranym adresom IP (jeśli oprogramowanie bramek nie udostępnia takiej funkcjonalności, powinien zostać zastosowany firewall) lub tylko uwierzytelnionym użytkownikom. Centralki PBX (np. Asterisk) powinny zostać skonfigurowane w taki sposób, aby odrzucać nieautoryzowane żądania połączeń do sieci PSTN.

Więcej szczegółów w artykule Analysis of a VoIP Attack.

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

marcinm

Krytyczna aktualizacja Microsoft Windows

24 October 2008 TomaszG.

Infekcja na stronach internetowych Serious Magic – internauci zgrożeni

17 October 2008 TomaszG.

Jak sprytnie przekierować internautę?

14 October 2008 TomaszG.