Projekt Confiture. Raport z obserwacji ruchu do wybranych confickerowych domen.pl

Transkrypt

1 Projekt Confiture Raport z obserwacji ruchu do wybranych confickerowych domen.pl NASK Conficker Working Group maj

2 Spis treści Wstęp tło wydarzeń... 3 Autoaktualizacja Confickera Algorytm Generowania Nazw Domenowych... 5 Projekt Confiture obserwacje ruchu do wybranych confickerowych domen.pl... 6 Czasowy rozkład liczby połączeń... 7 Geograficzny rozkład źródeł połączeń Źródła zewnętrzne Podsumowanie i wnioski NASK Conficker Working Group Literatura

3 Wstęp tło wydarzeń Robak Conficker, znany takŝe jako Downadup lub Kido, pojawił się w sieci w połowie listopada 2008 roku. Początkowo wykorzystywał tylko lukę w mechanizmie obsługi zdalnych wywołań procedur MRPC (Microsoft Remote Procedure Call) w systemach z rodziny MS Windows opisaną w biuletynie bezpieczeństwa Microsoft MS ( która pozwalała poprzez specjalnie spreparowane zapytanie RPC wykononać dowolny kod na atakowanym komputerze. Conficker szybko się rozprzestrzeniał pomimo wydania przez firmę Microsoft jeszcze przed jego pojawieniem (23 października 2008) poprawki łatającej tę podatność. Kolejne wersje robaka potrafiły propagować się poprzez udostępnione w sieci lokalnej zasoby, oraz zewnętrzne pamięci przenośne. Szacunkowe dane róŝnych grup specjalistów zajmujących się monitorowaniem Confickera donosiły o liczbie zainfekowanych komputerów dochodzących od kilku do kilkunastu milionów i,ii. Robak ten jest największym tego typu zagroŝeniem z okresu ostatnich kilku lat, a kolejne jego wersje posiadają coraz więcej moŝliwości oraz są coraz bardziej wyrafinowane. Rysunek 1: propagacja Confickera i sposób zabezpieczenia się przed infekcją Na rysynku 2 przedstawiona jest linia chronologiczna umiejscawiająca w czasie najwaŝniejsze wydarzenia związane ze sprawą robaka Conficker. Pierwsza wersja robaka została zaobserwowana prawie miesiąc po wydaniu przez firmę Microsoft poprawek bezpieczeństwa nr MS08-067, które łatały lukę wykorzystywaną przez robaka do autopropagacji. Trzydzieści osiem dni później 3

4 pojawiła się kolejna wersja (B), która roznosiła się takŝe poprzez zewnętrzne pamięci i dyski, zasoby sieciowe (takŝe łamiąc słabe hasła), oraz miała zaimplementowane mechanizmy samoobrony, jak wyłączenie automatycznych aktualizacji Windows i wbudowanych systemów bezpieczeństwa, oraz blokada dostępu do kilku stron www związanych m.in. z bezpieczeństwem komputerowym. Conficker.B posiadał takŝe prymitywny mechanizm dystrybucji kodu z uŝyciem protokołu P2P. Dwudziestego lutego zaobserwowano nową, lecz nieznacznie zmodyfikowaną wersję robaka. Część specjalistów oznaczyła go symbolem B++, a część potraktowała jako nową wersję (C). Na początku marca pojawiła się znacznie bardziej zmodyfikowana wersja (oznaczana symbolem C lub D). Ta wersja robaka była dystrybuowana jako uaktualnienie wcześniejszych wersji (takŝe z uŝyciem stron www, których nazwy były wygenerowane przez Algorytm Generowania Nazw Domenowych opisany w następnym rozdziale niniejszego raportu), nie propagowała się juŝ na nowe komputery. Na 1 kwietnia zostało zaprogramowane rozpoczęcie procesu aktualizacji do kolejnej wersji. Conficker.C/D miał rozwinięty mechanizm dystrybucji przez P2P, który był od 8 kwietnia wykorzystany zamiast mechanizmu HTTP do ściągnięcia wersji E. Ta z kolei pozbawiona była mechanizmu autopropagacji oraz aktualizacji z wykorzystaniem stron www (pozostała tylko moŝliwość P2P). Ponadto odnotowano, Ŝe Conficker.E ściągał i instalował inne złośliwe oprogramowanie (m.in. bota Waledac iii,xi ) a na trzeciego maja miał zaplanowane zdezaktywowanie się iv. Rysunek 2: Robak Conficker na linii chronologicznej 4

5 Autoaktualizacja Confickera Algorytm Generowania Nazw Domenowych Conficker (wszystkie wersje) ma wbudowany mechanizm autoaktualizacji. Aktualizacja odbywa się na dwa alternatywne sposoby: poprzez ściągnięcie nowej wersji z serwera www (od wersji A do C/D), lub rozdystrybuowanie jej poprzez wbudowany protokół P2P. Drugi sposób nie będzie opisany w niniejszym raporcie, poniewaŝ celem projektu była obserwacja wyłącznie ruchu HTTP, tak by za pomocą mechanizmu honeypotów moŝliwe stało się określenie liczby zainfekowanych komputerów. Aby skorzystać z pierwszego sposobu robak musi znać (mieć wcześniej zdefiniowane) adresy serwerów www, z których pobierze aktualizację. Twórcy Confickera stworzyli algorytm (Domain Name Generation Algorithm), który generuje pseudolosowe nazwy domen. KaŜdy egzemplarz robaka w wersji C tworzy identyczną listę domen dziennie, ale do połączenia kaŝdy losowo wybiera inny podzbiór 500 z nich. Następnym krokiem miała być rejestracja przez autorów tych domen (przynajmniej części). Z załoŝenia twórców domena taka musi przetrwać (nie zostać zablokowana) jedynie dzień, poniewaŝ codziennie uŝywana jest inna pula nazw. Domain Name Generation Algorithm został szczegółowo opisany przez specjalistów z The Honeynet Project w dokumencie Know Your Enemy: Containing Conficker v. Algorytm w dwóch pierwszych wersjach robaka (A i B) generował w dziennej puli 250 róŝnych nazw domenowych, a w wersji C aŝ W wersji A uŝywanych było tylko 5 krajowych domen najwyŝszego poziomu (cctld, z ang. country code Top-Level Domain), wersji B 7, natomiast w wersji C/D aŝ 110 (w tej grupie znalazła się takŝe polska cctld:.pl ). Prawdopodobnie zwiększona liczba moŝliwych nazw domenowych miała ułatwić właścicielom robaka wcześniejsze zakupienie/zarezerwowanie którejś z nich u odpowiedniego rejestratora (np. poprzez trafienie w nazwę, która nie była zajęta/wykorzystywana) a takŝe jednocześnie utrudnić organizacjom walczącym z robakiem zamykanie lub przejmowanie domen. Rozpracowując kod Confickera w wersji C/D specjalistom udało się takŝe ustalić, Ŝe robak ma zaprogramowane rozpoczęcie procesu aktualizacji od dnia 1 kwietnia 2009 roku. Nie znano więcej szczegółów odnośnie najnowszej wersji, która miała zostać pobrana. Poznawszy algorytm moŝna było uzyskać wszystkie moŝliwe do wykorzystania przez Confickera nazwy domenowe z dowolnej dziennej puli. Dodatkowo znano termin rozpoczęcia procesu aktualizacji. Dawało to specjalistom związanym z bezpieczeństwem komputerowym okazję do pozyskania na własność nazw domenowych zanim zrobiliby to właściciele robaka. Dzięki temu 5

6 uzyskać moŝna było dwa efekty: uniemoŝliwienie uŝycia pozyskanych domen do zaktualizowania kodu robaka, oraz nasłuchiwanie ruchu do tych domen w celu monitorowania połączeń pochodzących od potencjalnie zainfekowanych komputerów. W pierwszym przypadku całkowity sukces (czyli zupełne odcięcie robaka od nowszej wersji kodu) nie mógł się dokonać chociaŝby ze względu na fakt, Ŝe Conficker uŝywa takŝe do autoaktualizacji protokołu P2P. JednakŜe proces ten został robakowi utrudniony. W drugim przypadku monitorując ruch do potencjalnych stron confickerowych moŝna było pozyskać dodatkowe dane dotyczące procesu aktualizacji robaka, a takŝe poznać adresy IP zaraŝonych komputerów. Projekt Confiture 1 obserwacje ruchu do wybranych confickerowych domen.pl Działający w strukturach NASK zespół CERT Polska w ramach projektu Confiture obserwował ruch HTTP do pewnej ilości domen pochodzących z tzw. kwietniowej puli confickerowych polskich nazw domenowych wygenerowanych przez zaimplementowany w robaku Algorytm Generujący Domeny. PoniewaŜ robak komunikuje się codziennie z innym zestawem domen, monitorowanych 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 pułapki). Jako przynęty uŝyliśmy komputera udającego serwer tym celu wykorzystaliśmy narzędzie Honeyd. Do zbierania informacji o przychodzących połączeniach uŝyliśmy natomiast sniffera Tcpdump. Aby jak najbardziej upodobnić się do serwerów confickerowych odwzorowanie domena adres IP wynosiło 1:1. W statystykach odfiltrowany został ruch, który jednoznacznie wskazywał na nie pochodzący od zainfekowanych komputerów. Filtry wynikały z wcześniejszych analiz kodu robaka przeprowadzonych przez specjalistów zajmujących się tym zagroŝeniem. 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. Odrzucić naleŝało więc wszystkie połączenia, które w nagłówku Host miały adres domenowy, a nie 1 nazwa projektu Confiture wzięła się z połączenia słów Conficker i Capture (w wolnym tłumaczeniu przechwycenie Confickera ) i skojarzeniowo nawiązuje do rzeczownika konfitura, który moŝe być uŝywany jako alternatywa dla pojęcia garnek miodu, czyli honeypot. 6

7 IP. W połowie miesiąca w wyniku awarii sprzętu nie mógł być zbierany cały ruch, w związku z czym dane zostały poddane aproksymacji z wykorzystaniem informacji dostarczonych z innych źródeł obserwujących ruch sieciowy generowany przez Confickera, w tym z systemu ARAKIS vi. Jednocześnie monitorowane były zapytania do wybranych serwerów secondary DNS dla domeny.pl o wszystkie confickerowe domeny.pl z puli kwietniowej. Dane pozyskane w ten sposób naleŝy traktować jako rozszerzenie informacji pozyskanych z honeypota (naleŝy pamiętać, Ŝe większość zapytań do serwerów nazw pochodziła od innych serwerów DNS). Obserwacją tego ruchu zajmował się Dział Domen NASK. Czasowy rozkład liczby połączeń Liczba domen wykorzystywanych w projekcie Confiture w poszczególnych dniach kwietnia nie była stała (zakres od kilku do kilkudziesięciu domen na dzień). Dlatego aby zachować skalę na wykresach 1 i 3 wyniki obserwacji były uśredniane poprzez dzielenie wartości liczbowych przez liczbę monitorowanych domen danego dnia. W efekcie wykresy pokazują liczby per domena, nie zaś całość ruchu przechwyconego przez nas. Gdybyśmy nie zastosowali takiego rozwiązania wyniki byłyby zdecydowanie trudniejsze do analizy, przez występowanie znacznych dziennych wahań wykresów. Wykres 1 7

8 Na wykresie 1 przedstawiono liczbę połączeń HTTP GET per domena w dziesięciominutowym przedziale czasowym. Czas na osi odciętych, to czas obowiązujący w Polsce (GMT+2). Krótkookresowy trend (wahania Ŝądań w skali jednej doby) związany jest z porą dnia, w której pracowały zaraŝone komputery. Największa liczba Ŝądań HTTP GET obserwowana była w ciągu dnia, a najmniejsza w nocy. Średnia aktywność w nocy była od ok. 50% do ok. 66% niŝsza niŝ w dzień. Dobowe maksimum znajdowało się zazwyczaj między godz. 18. a 20. czasu polskiego natomiast minimum w okolicy godziny 3. Najwięcej Ŝądań HTTP GET per domena w pięciominutowym oknie czasowym zaobserwowano w trzech pierwszych dniach kwietnia prawie 150 (maksimum globalne), czyli jedno zapytanie GET co dwie sekundy. W kolejnych dniach ruch zmalał. Dodatkowo, pomijając trend dobowy, liczba Ŝądań dla domeny w róŝnych dniach była dosyć zróŝnicowana i zaleŝna od rodzaju danego dnia w dni robocze ruch był wyraźnie większy, niŝ w dni wolne od pracy (weekendy i święta). MoŜna to zjawisko nazwać trendem tygodniowym. I tak w pierwszy weekend kwietnia (4-5.04) obserwowany był spadek zapytań o ok. 30%. W poniedziałek, 6.04 natęŝenie tego ruchu powróciło do stanu sprzed weekendu. W środę 8.04 rozpoczął się trend spadkowy. W piątek natęŝenie ruchu było podobne, jak we wcześniejszy weekend. Mogło być to spowodowane przypadającymi wówczas świętami Wielkanocy. Bardziej prawdopodobny jest jednak związek z faktem, Ŝe od 7.04 rozpoczęła się aktualizacja (do wersji E) z uŝyciem kanału P2P vii,xi,xii. W niedzielę wielkanocną zanotowany ruch był najmniejszy. NatęŜenie zapytań HTTP GET w kolejnych dniach po Świętach juŝ nie powróciło do wartości sprzed Świąt, jednakŝe począwszy od wtorku ustabilizowało się i w kolejnych tygodniach wartości w poszczególnych dniach roboczych były podobne (odpowiednio niŝsze wartości weekendowe takŝe się pokrywają). Warto zwrócić uwagę, Ŝe wykres 1 obejmuje jeszcze dwa dni maja (honeypot cały czas działał, wpisy w DNS nadal się znajdowały), natomiast ruch dosyć liniowo maleje do zera, które osiąga 1.05 o godzinie 2:00 czasu polskiego, czyli równo o północy czasu GMT. Jest to czas, od którego Conficker miał zaprogramowane, by wygenerować nową listę nazw domenowych (majowych) i zaprzestać korzystać z listy kwietniowej. 8

9 Wykres 2 Na wykresie 1 został pominięty ruch, co do którego mieliśmy pewność, Ŝe nie pochodzi od zainfekowanych Confickerem komputerów. Gdyby go uwzględnić, to wykres nie zmieniłby się znacząco. Jedynie pierwszego kwietnia obserwowane były tego typu połączenia (liczba Ŝądań HTTP GET pochodząca od niego wynosiła ok. 20% wszystkich zapytań), których liczba przez cały dzień utrzymywała się na w miarę stałym (równym) poziomie. Widać to na wykresie 2, na którym przedstawiono liczbę połączeń HTTP GET w dziesięciominutowym oknie czasowym dla wszystkich monitorowanych domen z 1-go kwietnia. Kolorem niebieskim oznaczono 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). Drugiego kwietnia o godzinie 6-tej ruch ten zniknął. Od tego czasu zaklasyfikowane przez nas połączenia jako nie-confikerowe stanowiły marginalną wartość wszystkich połączeń. Na wykresie 3 przedstawiającym liczbę unikalnych źródłowych adresów IP per domena na dzień takŝe widoczny jest trend tygodniowy (spadek unikalnych IP w trakcie weekendu i świąt). 9

10 Najwięcej unikalnych źródeł łączyło się w dniu , natomiast średnia z całego miesiąca wynosi Najmniejszy ruch był obserwowany w dni świąteczne Potwierdza się, Ŝe po Świętach ruch generowany przez zainfekowane komputery na stałe zmniejszył się w stosunku do okresu przed Wykres 3 Geograficzny rozkład źródeł połączeń Interesujące są statystyki dotyczące umiejscowienia geograficznego zainfekowanych komputerów, które łączyły się z monitorowanymi przez nas domenami. Do zbudowania tego typu statystyk wykorzystaliśmy publicznie dostępny serwis IP to ASN Mapping prowadzony przez Team Cymru ( Najwięcej unikalnych adresów IP pochodziło z terytorium Chin (ponad 232 tysiące). Z państw następnych w kolejności - Rosji i Brazylii pochodziło odpowiednio po 127 i 125 tysięcy unikalnych źródeł. Jest to prawie dwa razy mniej niŝ z Chin. Między trzecim miejscem a kolejnymi jest jeszcze większa róŝnica, która przekracza połowę wartości. Wietnam i Indie były źródłem dla niewiele ponad 50 tysięcy unikalnych IP, Korea i Ukraina w okolicy 45 tysięcy. 10

11 Wykres 4 Pierwszym krajem z listy naleŝącym do Unii Europejskiej były Włochy z liczbą prawie 33 tysięcy unikalnych źródeł. Stany Zjednoczone Ameryki Północnej znalazły się na 17-tym miejscu z liczbą niewiele powyŝej 18,5 tysiąca IP, co jest zadziwiająco małą liczbą. Unikalnych źródeł połączeń z terytorium Polski było stosunkowo niewiele: 8.867, co uplasowało nasz kraj na 25-tym miejscu. Analizując ruch tylko z terytorium RP pod względem dostawców Internetu widać, Ŝe w czołówce zgodnie z przewidywaniami znajdują się największe firmy. PrzewaŜający procent IP naleŝał do sieci Telekomunikacji Polskiej (nieco powyŝej 3 tysięcy). Prawie trzy razy mniej miała następna w kolejności firma Dialog. Kolejna była Multimedia, jednakŝe liczba unikalnych źródeł niewiele róŝni się od czwartej w zestawieniu firmy Netia (w okolicach 400). 11

12 Wykres 5 Analizując te statystyki naleŝy pamiętać, Ŝe na róŝnicę między pierwszą w zestawieniu Telekomunikacją Polską a następnymi dostawcami moŝe takŝe wpływać pozycja rynkowa (liczba klientów) tej pierwszej (wg. Raportu o rynku telekomunikacyjnym za 2008 rok viii sporządzonego przez UKE, TP ma ok. 46% udziałów w rynku stałego szerokopasmowego dostępu do Internetu, następna w kolejności UPC posiada tylko 8,79%). Ogólne liczba zaobserwowanych przez nas polskich adresów IP w odniesieniu do liczby osób posiadających w Polsce dostęp do Internetu (wg. wyŝej wymienionego raportu UKE prawie 4,5 mln.) jest niewielka, co jest pozytywnym zjawiskiem. Kolejna pozytywna wiadomość, to liczba unikalnych źródłowych adresów IP naleŝących do polskich sieci rządowych (administracji publicznej) oraz wojskowych. W ciągu całego miesiąca obserwacji zarejestrowaliśmy tylko 10 adresów IP, które po zamianie na nazwy domenowe naleŝały do gov.pl ; oraz tylko 1 z mil.pl. Istnieje duŝe prawdopodobieństwo, Ŝe te adresy nie są 12

13 poszczególnymi komputerami, a bramami wyjściowymi dla danej instytucji. Oznacza to, Ŝe infekcji poszczególnych stacji roboczych mogło być więcej niŝ odpowiednio dziesięć (gov.pl) i jedna (mil.pl), lecz i tak jest to stosunkowo niewielka liczba (zwłaszcza, jeŝeli weźmiemy pod uwagę liczbę instytucji rządowych spoza szczebla centralnego, np. urzędy miejskie, powiatowe itp., które korzystają z domeny gov.pl). Podobne statystyki dotyczące adresów źródłowych związanych z edu.pl ujawniły, Ŝe w sieciach naukowych było najwięcej infekcji. Łącznie zarejestrowaliśmy 39 takich źródeł. Część z nich jednoznacznie wskazuje na wyjściowe bramy domów studenckich, przez co liczba zainfekowanych stacji roboczych znajdujących się za nimi moŝe być znacznie większa. Ponadto nie wszystkie instytucje naukowe uŝywają w swoich nazwach domenowych edu, przez co statystyki te nie mogą odzwierciedlać nawet przybliŝonej liczby infekcji w sektorze polskiej nauki. Dla danych pozyskanych z serwerów DNS NASK stworzyliśmy statystyki opisujące źródła połączeń z podziałem na kraje, oraz polskich dostawców Internetu. NaleŜy pamiętać, Ŝe większość połączeń pochodziła nie z końcowych komputerów (stacji roboczych), lecz z innych serwerów nazw. Dodatkowo gdy inny serwer DNS raz odpytał się o domenę, to odpowiedź mogła być przez niego zapamiętana przez pewien czas (z ang. cache), przez co ruch obserwowany przez NASK nie odzwierciedlał rzeczywistego interesowania się domeną przez hosty korzystające z danego serwera nazw. Wykres 6 13

14 Z wykresu 6 wynika, Ŝe najwięcej unikalnych połączeń nie pochodziło z terenów Chin (dopiero piąte miejsce), lecz Brazylii. RóŜnica między nimi jest ponad dwukrotna. Być moŝe wytłumaczenie niskiej pozycji Chin, to niewielka liczba umiejscowionych w tym kraju serwerów DNS, co wynikać moŝe z kwestii większego kontrolowania całości ruchu Chiny reszta świata, przez władzę Chińskie. Kolejna rozbieŝność, to stosunek liczby unikalnych źródeł między Brazylią a Rosją (na wykresie 4 są one bardzo podobne). Na stosunkowo wysokiej pozycji (czwartej) znalazły się Stany Zjednoczone Ameryki Północnej, które w zestawieniu honeypotowym były dopiero na 17-tym miejscu. Z podobieństw: takŝe pierwszym krajem z listy naleŝącym do Unii Europejskiej są Włochy; Polska jest na stosunkowo odległym 15-tym miejscu. JeŜeli pod uwagę weźmiemy ruch tylko z terytorium Polski okaŝe się, Ŝe najwięcej zapytań DNS zgodnie z przewidywaniami pochodziło od największego polskiego operatora Telekomunikacji Polskiej prawie cztery razy więcej niŝ z kolejej w klasyfikacji Netii. Dopiero na 7-mej pozycji znalazł się 2-gi w rankingu honeypotowym Dialog. Wykres 7 Wykorzystując narzędzie do zaznaczania punktami na mapie miejsc o podanych współrzędnych geograficznych plot-latlong ( oraz bazę danych zawierającą odniesienia adres IP współrzędne geograficzne MaxMind GeoLite City ( uzyskaliśmy mapę przedstawiającą rozmieszczenie źródeł 14

15 wszystkich zapytań HTTP GET do honeypota Confiture z okresu od 1-go do 30-go kwietnia KaŜdy turkusowy punkt odpowiada lokalizacji geograficznej źródłowego adresu IP. Rysunek 3: Geograficzna lokalizacja komputerów łączących się do honeypota Confiture Animacja pokazująca godzinowe zmiany rozkładu geograficznego źródłowych adresów IP dostępna jest pod adresem Podobną mapę wygenerowaliśmy dla źródeł zapytań DNS do NASKowych serwerów nazw. Rysunek 4: Geograficzna lokalizacja źródeł zapytań DNS 15

16 Źródła zewnętrzne Korelacja danych pozyskanych w ramach projektu Confiture z danymi pochodzącymi z innych systemów (zewnętrznych) pozwoliła na weryfikację naszych obserwacji. Wykorzystaliśmy dwa źródła, omówione poniŝej. System wczesnego wykrywania zagroŝeń sieciowych ARAKIS vi posiada rozproszoną sieć sensorów honeypotowych. Ruch zarejestrowany przez nie w kwietniu na porcie 445/TCP pokazuje liczbę unikalnych (w pięciominutowym oknie czasowym) źródłowych adresów IP (nie jest to ani liczba połączeń, ani przepływów). Przez ten port propaguje się Conficker. Nie są więc to połączenia do serwerów www w poszukiwaniu aktualizacji, ale próby autopropagacji sieciowej robaka. Ponadto naleŝy pamiętać, Ŝe ruch confickerowy nie stanowi 100% ruchu na tym porcie (ze statystyk klastrów wynika jednak, Ŝe jest to większość). Pominąć naleŝy więc wartości liczbowe unikalnych źródeł. Jedyną korelacją, którą moŝna wykonać, jest porównanie trendów (zarówno długookresowych jak i krótkookresowych) wykresów 1 i 3 z wykresem nr 8 pochodzącym z systemu ARAKIS. Wykres 8 Widać wyraźnie występujący równieŝ na wykresie 1 trend dobowy, w którym ruch zazwyczaj osiąga swoje największe natęŝenie między godziną 18-tą a 20-tą, natomiast najmniejsze między północą a godziną 6-tą (uśredniając jest to godz. 3-cia). Istnieje takŝe, chociaŝ jest łagodniejszy, trend tygodniowy (por. wykresy 1 i 3) w niedziele ruch jest mniejszy niŝ w pozostałe dni tygodnia. Nie widać natomiast wyraźnego spadku ruchu w okresie Świąt Wielkanocy. Mniejsze róŝnice mogą wynikać między innymi z faktu, Ŝe nie cały ruch rejestrowany przez ARAKISa na porcie 445/TCP jest generowany przez Confickera. JednakŜe miesięczne minimum (najmniejsza liczba komputerów łączących się na ten port w całym miesiącu) takŝe występuje w okolicy

17 kwietnia (patrz wykres nr 3). Potwierdza się takŝe, Ŝe Polska nie jest źródłem masowych infekcji w rankingu ARAKISa nie znajduje się w pierwszej dziesiątce (przodują Rosja, Brazylia i Chiny). W celu monitorowania i walki z Confickerem powstała grupa Conficker Working Group < skupiająca m.in. ekspertów od bezpieczeństwa komputerowego, producentów oprogramowania ochronnego, systemów operacyjnych oraz sprzętu, oraz dostawców usług, providerów, rejestratorów domen itp. Na stronach CWG ( znajdują się mapy infekcji pokazujące rozmieszczenie geograficzne komputerów zaraŝonych robakiem (stan na pierwszego kwietnia). Porównując mapy poszczególnych rejonów świata z naszą (rysunek 3) widać podobieństwa w umiejscowieniu źródeł (szczególnie w przypadku USA centrum i wschód, a takŝe Ameryki Południowej wschodnie wybrzeŝe). Na mapie Europy sporządzonej przez CWG (rysunek 5) potwierdzają się obserwacje, Ŝe na terenie Polski występowało stosunkowo niewiele infekcji. Rysunek 5: Lokalizacja źródeł zainfekowanych Confickerem komputerów w Europie (stan na 1 kwietnia), wg. Conficker Working Group ix 17

18 Podsumowanie i wnioski Przed 1-szym kwietnia istniało podejrzenie o zalanie zapytaniami HTTP GET serwerów www, które uŝywają confickerowych nazw domenowych (tzw. kolizje domenowe) opisaliśmy to na naszym blogu w wiadomości Conficker: prima aprilis czy zagłada? x. Problem polegał na tym, Ŝe confickerowy algorytm generujący nazwy domenowe potrafił losowo stworzyć nazwę, która przypadkowo jest wykorzystywana w zupełnie innym legalnym celu. Przykładem takiej domeny był nask.pl znalazła się ona w puli domen confickerowych z dnia 18. kwietnia. Szacunkowe dane specjalistów zajmujących się monitorowaniem robaka sugerowały, Ŝe taka domena moŝe w danym dniu zostać w sposób niezamierzony zalana masowymi Ŝądaniami HTTP GET z zainfekowanych komputerów, co mogło spowodować niedostępność takiego serwera (efekt podobny do ataku DDoS). Z naszych obserwacji wynika, Ŝe maksymalna liczba Ŝądań HTTP GET wyniosła ok. 150 na pięć minut (czyli jedno co dwie sekundy), a zazwyczaj była mniejsza. Oznacza to, Ŝe opisany powyŝej problem nie powinien Ŝadnej kolizyjnej legalnej domenie nastręczyć trudności. Potwierdzają to dane dotyczące ruchu na stronie nask.pl wzrost w dniu 18. kwietnia rzeczywiście miał miejsce, lecz był on minimalny i nie spowodował jakichkolwiek problemów. Zatem ruch HTTP powodowany przez zainfekowane Confickerem komputery był zaskakująco niski. Istotnym faktem jest stosunkowo niewielka liczba infekcji występujących na terytorium naszego kraju (co potwierdzają takŝe źródła zewnętrzne). Unikalnych źródeł połączeń z terytorium Polski było zaledwie (25. miejsce na liście wszystkich krajów). Ostatecznie okazało się, Ŝe cały mechanizm aktualizacji za pośrednictwem domen pozostał niewykorzystany do aktualizacji bowiem doszło poprzez mechanizm P2P vii,xi,xii. Autorzy robaka wprowadzili jednak nową technikę utrudniającą skuteczne zwalczanie botnetu. W przeciwieństwie do dotychczas stosowanej metody fast-flux w której pojedyncze domeny sterujące zmieniały swój IP, w tym wypadku zmieniane były domeny (domain fluxing). Nowatorskość robaka spowodowała, Ŝe wiele ekspertów od bezpieczeństwa właśnie na nim skupiła uwagę, co z punktu widzenia autorów było zjawiskiem niepoŝądanym. Spowodowało to szybkie rozpoznanie większości mechanizmów działania robaka. W przyszłości jednak, jeśli więcej botnetów będzie budowana w oparciu o podobną technikę domain fluxing, problem stanie się znacznie powaŝniejszy. Konieczne zatem staje się opracowanie nowego systemu reakcji na tego typu zjawiska, obejmujący operatorów registry, rejestratorów, zespołów typu CERT, organów ścigania oraz innych zainteresowanych. 18

19 NASK Conficker Working Group W skład NASK Conficker Working Group weszli (kolejność alfabetyczna): CERT Polska Tomasz Grudziecki Przemysław Jaroszewski Piotr Kijewski Marcin Mielniczek Tomasz Piłat Dział Domen Andrzej Bartosiewicz Michal Dziarmakowski Krzysztof Olesik Zespoł Integracji i Bezpieczeństwa Systemów Janusz Janiszewski 19

20 Literatura i Neild, Barry ( ), Downadup virus exposes millions of PCs to hijack, CNN, ii Virus strikes 15 million Pcs ( ), UPI, million-pcs/upi / iii W32.Downadup.E Back to Basics, Symantec Security Response Blog, iv W32.Downadup.E Technical Details, Symantec, v Know Your Enemy: Containing Conficker, The Honeynet Project, vi ARAKIS jest systemem wczesnego ostrzegania o zagroŝeniach w sieci korzystającym z róŝnych typów źródeł, więcej informacji na stronie vii Connecting The Dots: Downadup/Conficker Variants, Symantec Security Response Blog, viii Raport o rynku telekomunikacyjnym w 2008 roku, Urząd Komunikacji Elektronicznej, ix x Conficker: prima aprilis czy zagłada?, CERT Polska, xi DOWNAD/Conficker Watch: New Varioant in The Mix?, TrendLabs Malware Blog, xii New Downad/Conficker variant spreading over P2P, CounterMeasures A Trend Micro Blog, 20