Od początku stycznia grupa serwerów DNS zalewana jest pytaniami ze sfałszowanymi adresami IP nadawcy. Echa tych ataków widziane są w systemie wczesnego wykrywania zagrożeń sieciowych ARAKIS. W ruchu sieciowym pozyskanym do tej pory zidentyfikowaliśmy ok. 20 atakowanych serwerów DNS należących m.in. do Dynamic Network Services (znany jako DynDNS), Verisign, GoDaddy, eNom, Hurricane Electric, TelecityGroup, czy SoftLayer Technologies.
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.
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.
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:
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:
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.
