Conficker (znany także jako Downadup lub Kido), to najgłośniejszy medialnie i zarazem jeden z najgroźniejszych w ostatnim czasie robaków. Dla specjalistów zajmujących się bezpieczeństwem komputerowym jest ponadto bardzo interesujący ze względu na zastosowane przez jego twórców nieznane wcześniej rozwiązania. Na początku kwietnia informowaliśmy (zob. wiadomość Conficker – raport z pola walki), że monitorujemy ruch HTTP do pewnej liczby tzw. “polskich domen confickerowych”, z którymi miały się łączyć zarażone tym robakiem komputery. Nasze obserwacje kontynuowaliśmy przez miesiąc w ramach projektu nazwanego Confiture (skrót od Conficker capture). Realizowała go grupa specjalistów zwana NASK Conficker Working Group (w jej skład weszli specjaliści z trzech działów NASK: CERT Polska, Działu Domen, oraz Zespołu Integracji i Bezpieczeństwa). Wyniki obserwacji oraz płynące z nich wnioski umieściliśmy w raporcie, który można ściągnąć z naszej strony (plik PDF: Projekt Confiture). Poniżej przedstawiamy najistotniejsze fragmenty raportu.

Wstęp

Celem projektu Confiture była obserwacja ruchu HTTP do pewnej ilości domen pochodzących z tzw. kwietniowej puli confickerowych polskich nazw domenowych wygenerowanych przez zaimplementowany w robaku Conficker tzw. Algorytm Generujący Nazwy Domenowe (z ang. Domain Name Generation Algorithm). Domeny te miały być używane do ściągania przez zarażone komputery uaktualnień robaka (był to jeden ze sposobów, innym była dystrybucja poprzez wbudowany protokół P2P). Ponieważ robak komunikował się codziennie z innym zestawem domen, monitorowanych przez nas było co najmniej kilka domen “.pl” z każdej dziennej puli od pierwszego do trzydziestego kwietnia. Serwer DNS NASK w odpowiedzi na zapytania o te domeny zwracał adresy IP kierujące do naszego honeypota (a właściwie konfitury, czyli komputera-pułapki), który rejestrował wszystkie połączenia. Jednocześnie monitorowane były zapytania do wybranych serwerów secondary DNS dla domeny “.pl” o wszystkie confickerowe domeny “.pl” z puli kwietniowej. Ponadto nasze wyniki skorelowaliśmy z danymi pochodzącymi z dwóch źródeł zewnętrznych: systemu ARAKIS, oraz obserwacji prowadzonych przez specjalistów z Conficker Working Group.

(more…)

Dwa dni temu, przy okazji naszych przewidywań dotyczących działań robaka Conficker po 1-szym kwietnia wspomnieliśmy, że monitorujemy pewną liczbę domen z którymi zarażone komputery miały się łączyć. W niniejszym artykule chcieliśmy podzielić się dotychczas uzyskanymi informacjami wynikającymi z tych obserwacji.

Wstęp

Domeny przez nas obserwowane pochodzą z kwietniowej listy “polskich nazw domenowych” (”.pl”) wygenerowanych przez rozpracowany przez specjalistów confickerowy Algorytm Generujący Domeny (z ang. Domain Generation Algorithm). Używamy od kilkunastu do kilkudziesięciu domen z  pierwszych dni kwietnia (robak komunikuje się codziennie z innym zestawem domen). Odpowiednie wpisy w serwerze DNS kierowały połączenia do domen na specjalny dedykowany komputer udający serwer www (tzw. honeypot). Aby uniknąć wykrycia i jak najbardziej upodobnić się do serwerów “confickerowych” odwzorowanie domena <-> adres IP wynosi 1:1.

Nasze obserwacje

Dotychczasowe nasze obserwacje potwierdzają ogólne przewidywania naukowców zajmujących się analizą robaka: od północy czasu GMT zanotowaliśmy wzrost liczby połączeń. Musieliśmy jednakże odfiltrować ruch, który jednoznacznie wskazywał na nie pochodzący od zainfekowanych komputerów. Pierwszym wyznacznikiem był występujący w protokole HTTP nagłówek User-Agent określający przeglądarkę, której klient używa do połączenia się z serwerem www. Conficker identyfikuje się jako Internet Explorer. Kolejnym ważnym punktem był nagłówek HTTP Host – robak najpierw zamienia adres domenowy na IP, a dopiero następnie wykonuje połączenie bezpośrednio na to IP. Odpadają więc wszystkie połączenia, które w nagłówku Host miały adres domenowy, a nie IP.

Na powyższym wykresie przedstawiono ilość połączeń HTTP GET w dziesięciominutowym oknie czasowym dla domen z 1-go kwietnia. Kolorem niebieskim oznaczono prawdopodobne połączenia zarażonych komputerów, natomiast czerwonym ruch, co do którego mamy pewność, że nie jest aktywnością robaka. Czerwony wykres rozpoczyna się z końcem wykresu niebieskiego, nie jest liczony od osi odciętych.

Okazało się, że “nie-confickerowych” połączeń było nadspodziewanie dużo – aż ok. 20% ruchu. Co więcej, ruch ten utrzymywał się na stałym poziomie. Wygląda więc na to, że badacze Confikera mogą mocno przyczynić się do obciążenia łączy i przypadkowych serwerów. Poza tym świadczy to o tym, że zainteresowanie/uwaga poświęcona robakowi jest póki co niewspółmierna do realnego zagrożenia.

Kolejny wykres przedstawia zestawienie połączeń HTTP GET (rozdzielczość, to również dziesięciominutowe okno czasowe) rozszerzone o domeny z dnia 2-go kwietnia (wykres zielony). Dodatkowo, aby pokazać skalę połączeń “nie-confickerowych”, wykres czerwony i niebieski rozdzielono.

(more…)

Pierwszego kwietnia (a więc już za chwilę) ma się zaktualizować najgroźniejszy ostatnimi czasy robak Conficker (zwany także Downadup lub Kido) i… No właśnie, i co? Wiele doniesień prasowych spekuluje najgorsze rzeczy. Wygląda jednak na to, że to szukanie (na wyrost) sensacji i sianie paniki.

Po pierwsze, złośliwe oprogramowanie bardzo często aktualizuje się na komputerze ofiary – Conficker nie jest wyjątkiem. Co więcej, w obecnej wersji tego robaka już istnieje mechanizm aktualizacji poprzez wbudowany protokół P2P! Oczekiwany na jutrzejszy dzień update jest więc lekko “przereklamowany” – byłaby to po prostu kolejna aktualizacja.

To co wydarzy się pierwszego kwietnia to zmiana algorytmu, dzięki któremu już zainfekowane komputery wyszukiwać będą potencjalne źródła update’ów.  Znane są (wygenerowane automatycznie według pewnego algorytmu) domeny, z którymi Conficker będzie się łączył. Zapewne wiele z nich jest już cały czas monitorowanych przez specjalistów od bezpieczeństwa. Przykładem jest tutaj chociażby CERT Polska - monitorujemy pewną liczbę domen, które w przeciągu kilku dni miały być użyte przez twórców Confickera. W przyszłości opublikujemy raport z naszych obserwacji.

Co się więc prawdopodobnie stanie? Każda instancja bota będzie usiłowała się połączyć poprzez HTTP GET z serwerami kryjącymi się pod nazwami z losowej puli 500 domen z 50 000 możliwych danego dnia, w celu sprawdzenia, czy udostępniane są nowe aktualizacje.  Najprawdopodobniej odpytywane przez zarażone komputery serwisy mogą być “zalane” połączeniami, w sposób niezamierzony wywołując efekt podobny jak w ataku DDoS. Narażone na DDoS są więc serwisy, których domeny zostały już wcześniej zarejestrowane w innych celach, nie związanych z Confickerem. Jednakże wydaje się mało prawdopodobne, by twórcy Confickera zdecydowali się na masową aktualizację akurat tego dnia, w którym wszyscy się tego spodziewają i większość specjalistów od bezpieczeństwa monitoruje te adresy. Może wręcz się okazać, że do aktualizacji z wykorzystaniem domen nie dojdzie, albowiem zostanie wykorzystany (lub już został) mechanizm P2P.

Pomimo, że uważamy iż nic wielkiego nie stanie się pierwszego kwietnia, to nie zmienia to faktu, że Conficker stanowi duże zagrożenie. Nie należy zatem wpadać w panikę, tylko upewnić się czy infekcja nie występuje na własnym komputerze / we własnej sieci.

Przykładowe narzędzia służące do usuwania Confickera:

• Microsoft Windows Malicious Software Removal Tool
• F-Secure
• McAfee Avert Stinger

Więcej szczegółów o samym robaku i jego związku z pierwszym kwietnia:

• www.secureworks.com
• Know Your Enemy: Containing Conficker (The Honeynet Project)
• SRI International Conficker C Analysis

Poniżej publikujemy listę kwietniowych domen “.pl” (posortowane alfabetycznie), które mają być użyte przez robaka. Jeżeli wasza domena przypadkiem znajduje się na niej – warto przygotować się na ewentualny atak DDoS.

• www.cert.pl/PDF/conficker_pl.txt (133 KB)

Polecamy także poprzednie nasze wiadomości związane z tym zagrożeniem:

• Conficker/Downadup – krajobraz Polski
• Masowy atak nowego robaka
• Krytyczna aktualizacja Microsoft Windows (MS08-067)

Wszystko wskazuje na to, że w sieci od ok. tygodnia na szeroką skalę propaguje się nowy robak wykorzystujący niedawno upublicznioną lukę w systemach operacyjnych z rodziny Windows (biuletyn bezpieczeństwa Microsoft numer MS08-067, o której pisaliśmy w newsie Krytyczna aktualizacja Microsoft Windows z dn. 24.10.2008). Zanim przedstawię szczegóły naszych obserwacji, chciałbym zaapelować do wszystkich, którzy jeszcze tego nie zrobili: jak najszybciej zaktualizujcie swoje Windowsy.

Robak propaguje się przez port 445/TCP, co oczywiście objawia się znaczącym wzrostem ruchu na tym porcie. Według obserwacji naszego system wczesnego ostrzegania o zagrożeniach w sieci ARAKIS wzrost ruchu jest znaczny (kilkakrotnie). Ilość przepływów rejestrowana w tzw. darknecie wynosi ok. trzynastu tysięcy w pięciominutowym oknie czasu. Poniżej wykres ruchu na porcie 445/TCP rejestrowany przez ARAKISowe sondy darknetowe.

Wzrosła również ilość unikalnych hostów, z których robak się propaguje. Jest to widoczne na wykresach honeynetowych przedstawiających ilość unikalnych adresów IP z których nastąpiło połączenie do honeypotów.

Oczywiście nie cały ruch na tym porcie jest generowany przez tego robaka. Port ten wykorzystuje do infekowania wiele robaków (m.in. słynny Sasser). Skąd więc wiadomo, że ten wzrost jest generowany przez nowego robaka, a nie np. przez Sassera? Dane przechwycone przez honeypoty pokazują, że różni się on od typowej komunikacji SMB wykorzystywanej przez inne robaki. Wprawdzie nasze niskointeraktywne honeypoty nie zdołały pozyskać kompletnego robaka, to jednak początkowa komunikacja (dokładanie negocjacja wersji protokołu) jest na tyle odmienna, że wygenerował się nowy klaster.

Klaster opisuje pierwszy etap połączenia SMB, który teoretycznie nie jest atakiem. Podobny payload może być widziany w całkiem legalnym ruchu np. w sieci lokalnej. Jednak z dwóch powodów został przez nas sklasyfikowany jako atak. Po pierwsze, połączenia były nawiązywane do adresów IP pod którymi działają honeypoty, po drugie korelując z obserwacjami i analizami innych specjalistów od bezpieczeństwa (linki do publicznych ciekawych stron znajdują się poniżej) jest wielce prawdopodobne, że jest to aktywność nowego robaka.

Propagację robaka, któremu nadano nazwę W32/Conficker.worm oraz W32.Downadup, opisuje wiele zagranicznych serwisów (m.in. REN-ISAC, ISC SANS, Symantec). Jego funkcjonalność jest już także zaimplementowana w co najmniej jednym zestawie narzędzi dla cyberprzestępców, więc nie dziwi wzrost jego wykorzystania. Infekcje mają na celu wcielenie atakowanego komputera do botnetu w celu późniejszego wykorzystaniu go do popełniania przestępstw w Internecie.

Warto zauważyć, że dostępny jest już od ponad miesiąca patch łatający podatność wykorzystywaną przez robaka. Obserwacje wskazują zatem, że wiele użytkowników systemu Windows nie zaktualizowało go. Dlatego jeszcze raz apelujemy, aby wszyscy użytkownicy tych systemów, którzy tego jeszcze nie zrobili, jak najszybciej je zaktualizowali.

Ciekawe linki związane z nowym robakiem:

• http://blogs.technet.com/mmpc/archive/2008/11/25/more-ms08-067-exploits.aspx
• http://www.microsoft.com/security/portal/Entry.aspx?Name=Worm%3aWin32%2fConficker.A
• https://forums.symantec.com/syment/blog/article?blog.id=vulnerabilities_exploits&thread.id=178
• http://securitylabs.websense.com/content/Blogs/3237.aspx
• http://blog.trendmicro.com/ms08-067-vulnerability-botnets-reloaded/

Doczekaliśmy chyba początku końca czasów pobłażliwości środowiska dostawców dla “kuloodpornego hostingu” i ignorowania nieetycznych lub wręcz nielegalnych zachowań klientów. Jest to radykalna zmiana, bo całkiem niedawno do powszechnie przyjmowanych postaw należało chowanie głowy w piasek z przekonaniem, że rolą dostawcy jest wyłącznie przekazywanie pakietów bez względu na ich treść.

Ostatnim spektakularnym przykładem zmiany postaw jest los McColo Corp., amerykańskiej firmy specjalizującej się w usługach hostingowych. McColo od dawna uznawane było za bezpieczną przystań dla autorów złośliwego oprogramowania i innych przestępców. Po opłaceniu odpowiedniego abonamentu można było być spokojnym, że strona phishingowa, koń trojański czy kontroler botnetu unikną bliższego zainteresowania administratorów. Do wtorku. W następstwie raportu “CyberCrime USA V.2.0” opublikowanego przez Host Exploit, dostawcy wymieniający ruch z McColo zaprzestali współpracy, tym samym odcinając firmę od Internetu. Odczuwalnym efektem zniknięcia McColo był natychmiastowy spadek ilości spamu, odnotowany praktycznie wszędzie. W statystykach liczby zgłoszeń trafiających do SpamCopa jest to blisko 50% (patrz wykres). Także na naszych skrzynkach ubyło ponad 40% niechcianej korespondencji. Dlaczego? Szacuje się, że ze względu na dobre łącza i wspomnianą “kuloodporność”, około połowy kontrolerów botnetów – sieci stworzonych z przejętych komputerów na całym świecie – ulokowane było w McColo. Oznacza to, że wiele zainfekowanych komputerów-zombie straciło swoje centra zarządzania i choć nadal zarażone, nie są już funkcjonalne dla przestępców. Oczywiście, stan taki może się utrzymać tak długo, jak długo nie znajdą się nowe miejsca dla kontrolerów.

Przypadek McColo nie jest pierwszym przypadkiem skutecznej samoregulacji wśród dostawców. Pod koniec września podobny los spotkał kalifornijską firmę Intercage, znaną wcześniej jako Atrivo. Również wtedy zadecydowały przekonujące dowody, zebrane przez Security Fix, i świadczące o silnym związku Atrivo z dystrybucją fałszywego oprogramowania antywirusowego i innych koni trojańskich, które posłużyły m.in. do zbudowania Storm – jednego z najbardziej znanych botnetów w historii. W Atrivo umieszczone były także kontrolery tej sieci. Zaledwie po kilku tygodniach od publikacji raportu Security Fix, Intercage znalazł się na internetowym bruku po odcięciu przez wszystkich dostawców, z którymi wymieniał ruch.

Warto zauważyć, że takie kroki są znacznie szybsze i skuteczniejsze niż wyłącznie działania prawne – choć oczywiście tych ostatnich nie należy zaniechać aby konsekwencje dla przestępców szły dalej niż tylko chwilowe zakłócenie pracy.

W nurt samoregulacji środowiska wpisuje się także niedawna decyzja ICANN o odebraniu prawa do rejestracji domen estońskiej firmie EstDomains. Tutaj oficjalnym powodem było pozostawanie na stanowisku prezesa firmy osoby skazanej za przestępstwa finansowe. Nie było jednak tajemnicą, że EstDomains odpowiadało za masowe rejestracje wielu domen służących do nielegalnej działalności, w tym phishingu i dystrybucji złośliwego oprogramowania. Decyzja ta, wydana 28 października, po nieuznanym odwołaniu EstDomains, wejdzie w życie 24 listopada.

Co istotne, kroki takie są bardzo pozytywnie odbierane w środowisku. Nieuzasadnione są więc obawy tych, którzy podnosili argumenty, że mogą być traktowane jako uzurpowanie sobie praw. Miejmy nadzieję, że precedensy z tej jesieni będą wyznacznikiem trendu w zachowaniu dostawców a tych, którzy asekuracyjnie pochodzą do egzekwowania zapisów dotyczących naruszeń w umowach z klientami skłonią do przemyślenia stanowiska. Dodajmy na koniec, że kolejny raport Host Exploit ma dotyczyć Europy. Czekamy z niecierpliwością.

Ciekawe lektury:

Raport Host Exploit dotyczący Atrivo
Washington Post o zniknięciu Atrivo
Washingon Post po raz drugi o zniknięciu Atrivo
Raport Host Exploit na temat McColo
Channel Web o końcu kariery McColo w Internecie
Ostateczna decyzja ICANN o rozwiązaniu współpracy z EstDomains

Dwa dni temu przy okazji dwudziestej rocznicy powstania internetowego robaka opublikowaliśmy pierwszą część opracowania, w którym podsumowujemy i analizujemy rozwój jaki się dokonał w przeciągu tych dwudziestu lat wśród zagrożeń dla użytkowników Internetu. Dzisiaj kolej na drugą ostatnią część.

Problemy stwarzane przez ogólnie pojęte szkodliwe oprogramowanie spowodowały powstanie aplikacji i urządzeń, których celem była ochrona całych sieci bądź pojedynczych komputerów. Powstawało wiele firm, które specjalizowały się tylko w tej dziedzinie i opracowywały wiele autorskich rozwiązań. W 2004 roku po raz pierwszy narzędzia, które zostały stworzone do ochrony, same stały się celem robaka Witty. Co ciekawe atakował on produkty tylko jednej firmy: ISS (Internet Security Systems), m.in. firewalle i systemy typu IDS. Wykorzystując ich podatność był w stanie bardzo szybko się rozprzestrzeniać. Początkowa prędkość propagacji była tak duża (w ciągu pierwszych 10 sekund działalności zostało zainfekowanych 110 hostów, w kolejnych 20 sekundach “tylko” 50 nowych), że wzbudziło to podejrzenia, iż robak posiadał wcześniej zdefiniowaną listę docelowych adresów IP pod którymi działało podatne oprogramowanie. Z czasem prędkość rozprzestrzeniania się spadła, choć i tak była imponująca (ok. 12 000 komputerów w przeciągu 45 minut). Cały kod robaka mieścił się w pojedynczym pakiecie UDP. Witty był silnie złośliwy. Oprócz autopropagacji, konsekwencją której było wygenerowanie dużego ruchu w sieci, nadpisywał lub kasował losowe bloki na dyskach doprowadzając z czasem do uszkodzenia całego systemu plików. Robak miał jeszcze jedną charakterystyczną cechę: zaatakował w niecałe 48 godzin od opublikowania przez ISS informacji o luce, co było na owe czasy wynikiem rekordowym. Uwydatniło to słabość systemów w postaci opieszałym aktualizowaniu oprogramowania przez administratorów, bowiem jak się okazało wielu z nich nie zainstalowało na poprawek czas (zob. wiadomość Witty nie dał szans administratorom).

Aktywność takich robaków, jak Slammer, Blaster czy Sasser nie słabnie od lat (co potwierdzają m.in. wspomniane wcześniej obserwacje systemu ARAKIS). Nie oznacza to jednak, że cyberprzestępcy nie wymyślają nowych rodzajów ataków. Obecnie obserwowany trend w propagacji malware’u przez Internet wskazuje na to, że coraz częściej do infekowania internautów używane są luki w tzw. programach klienckich (czyli takich, które pozwalają użytkownikowi łączyć się z serwerem), w szczególności w przeglądarkach internetowych i dodatkach do nich. Aby wykorzystać je w tym ostatnim przypadku wystarczy odpowiednio zmodyfikować kod strony www (najczęściej poprzez wstrzyknięcie złośliwego JavaScripta lub odnośnika do zewnętrznej złośliwej strony www). Odwiedzający ją nieświadomy użytkownik jest zarażany bez jakiejkolwiek dodatkowej interakcji (tzw. atak drive-by-download). Ewentualnie można go odpowiednio “zachęcić”, by sam uruchomił jakiś kod nie mając oczywiście świadomości, że jest szkodliwy. Zatem nie ma potrzeby atakować w sposób bezpośredni (aktywny) zwykłego użytkownika – wystarczy umieścić malware na stronie i czekać, aż internauci sami na nią wejdą i się zainfekują. Dzięki temu można być mniej “widocznym” w sieci, bo zamiast aktywnie poszukiwać ofiary generując podejrzany ruch, malware czeka, aż ofiara “znajdzie” jego. Głównym celem robaków w takim przypadku stały się więc serwery www. Wraz z rozwojem Web 2.0 znacznie łatwiej działać robakom atakującym i modyfikującym treść (wstrzykującym złośliwy kod) stron www – nie trzeba polegać tylko na podatnościach serwerów www, wystarczy błędnie napisany skrypt php, asp itp. Robaki PHP, które wykorzystując błędy w skryptach różnych znanych aplikacji nie skupiając się na jednej były wielokrotnie widziane przez system ARAKIS (zob. wiadomość Robak wykorzystujący luki w skryptach PHP). Niejeden profesjonalny serwis www padł też ich ofiarą – chociażby ostatnio miała miejsce infekcja stron internetowych Serious Magic należącej do firmy Adobe Systems (zob wiadomość Infekcja na stronach internetowych Serious Magic – internauci zgrożeni)

Oczywiście to nie oznacza zupełnego zarzucenia starszych metod infekcji: dalej popularne jest wykorzystanie e-maili. Coraz częściej malware propagowany jest także przez sieci P2P (sieci te wykorzystywane są także coraz chętniej, zamiast IRC, do zarządzania botnetami). Cały czas bardzo popularna i nadzwyczaj skuteczna jest socjotechnika, czyli namówienie internauty, by sam z własnej woli uruchomił (złośliwy) program. W dalszym ciągu po Internecie grasują Sassery, Blastery itp. Ostatnio wykryto w systemach z rodziny Windows groźną lukę, która może być wykorzystywana przez nowego robaka (pisaliśmy o niej w wiadomości Krytyczna aktualizacja Microsoft Windows). Specjaliści od bezpieczeństwa IT potwierdzają, że taki robak już jest wypuszczony do Internetu, lecz nie są to jakieś masowe ilości (przynajmniej na razie nie może być mowy o epidemii). System ARAKIS nie zaobserwował do tej pory aktywności nowego robaka. Być może ze względu na pewne podobieństwa wykorzystywanej luki do tych używanych przez inne robaki (m.in. Sassera) nie jest opłacalne dla cyberprzestęcpców rozwijanie nowego kodu – można go (i jemu podobne) zablokować dosyć łatwo chociażby poprzez filtrowanie na firewallu pakietów kierowanych na porty 445 i 139 TCP (nie wspominając o zwykłej aktualizacji systemu). Warto także zauważyć, że coraz rzadziej wykrywane są tak poważne luki, że mogą być wykorzystane w podobny sposób przez robaki. Obecnie rozwijane metody infekcji (głównie omówione wcześniej wykorzystujące przeglądarkę internetową) oraz te już sprawdzone są najprawdopodobniej bardziej opłacalne i przynoszą lepsze rezultaty.

Jaki jest obecny cel infekowania użytkowników Internetu? Z historii wynika, że najpierw robaki miały pokazać niedoskonałości aplikacji bądź systemów, przynosić sławę twórcom, czy złośliwie usuwać z systemu różne pliki, wyświetlać zabawne lub obraźliwe komunikaty, itp. W chwili obecnej prawdziwym celem twórców malware’u są pieniądze a motywacją zwyczajna chęć zysku. Zdobywają je na różne sposoby. Mogą instalować w systemach ofiar programy szpiegujące i wykradające hasła do kont bankowych czy różnych płatnych gier on-line. Mogą używać szantażu, jak np. twórcy wirusa Gpcode/PGPcoder, który szyfruje pliki multimedialne i dokumenty i odszyfrowuje dopiero wtedy, gdy ofiara wpłaci na konto cyberprzestępcy określoną sumę pieniędzy. Wreszcie (najpowszechniejsza metoda) tworzą z zainfekowanego komputera członka botnetu (tzw. komputer-zombie). Ofiary najczęściej nie zdają sobie sprawy, że ich komputer jest jednym z tysięcy, a nawet być może milionów komputerów kontrolowanych przez właścicieli botnetu (tzw. botmasterów). Co najwyżej zauważą spowolnienie jego pracy lub połączenia internetowego, ponieważ wykorzystywane są zasoby systemowe oraz sieciowe – cyberprzestępcy używają ich do świadczenia swoim “klientom” odpłatnie takich usług, jak rozsyłanie spamu reklamowego, atak DDoS na serwery konkurencji, itp.

Co zatem zrobić, by nie paść ofiarą cyberprzestępców? Nie ma, niestety, niezawodnego rozwiązania. Nie ma także co liczyć na całkowite wyeliminowanie malware’u. W praktyce jesteśmy świadkami swoistego „wyścigu zbrojeń” pomiędzy cyberprzestępcami a osobami walczącymi z nimi. Powinniśmy zatem pilnować, by używane przez nas oprogramowanie i system operacyjny były zawsze zaktualizowane. Mocno zalecane jest używanie systemu antywirusowego oraz firewalla (najlepiej, gdyby także używał ich nasz dostawca Internetu). Przede wszystkim jednak musimy być ostrożni w trakcie surfowania po Internecie i mieć ograniczone zaufanie do wszystkich stron www, e-maili czy wiadomości w komunikatorach internetowych. Zdrowego rozsądku nic nie zastąpi, tak jak edukacji na ten temat (w myśl zasady, że przeciwnik lepiej poznany jest mniej groźny).

W 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 najwię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ć.

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

Skoro 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…