Raport CERT Polska 2011 · 2015-12-10 · 8 567891023540 8,%A60dree Raport CERT Polska 2011 2....

Raport CERT Polska 2011

5

55

8

9

10

101112151617211222323242424

25

25252627

30

3034

3232

33

34

34373839

3Raport CERT Polska 2011Spis treści

1 Streszczenie

1.1 Jakczytaćtendokument? 1.2 Najważniejszeobserwacjepodsumowująceraport

2 InformacjeozespoleCERTPolska

3 Wprowadzenie

4 StatystykazgłoszeńkoordynowanychprzezCERTPolska

4.1 Ilośćinformacjiwewszystkichkategoriach 4.2 Phishing 4.3 Stronyzwiązanezezłośliwymoprogramowaniem 4.4 Zpiaskownicydopolskichsieci,czyliadresyodwiedzaneprzezmalware 4.5 Spamzpolskichsieci 4.6 Skanowanie 4.7 Botywpolskichsieciach 4.8 SerweryCommand&Control 4.9 AtakiDDoS 4.10 Atakibrute-force 4.11 SerweryFast-flux 4.12 Otwarte serwery DNS 4.13 Pozostałezgłoszenia

5 StatystykaincydentówobsłużonychprzezCERTPolska

5.1 Liczbaprzypadkównaruszającychbezpieczeństwoteleinformatyczne 5.2 Typyodnotowanychincydentów 5.3 Typyodnotowanychataków 5.4 Zgłaszający,poszkodowani,atakujący

6 Statystykidodatkowe,dotyczącezgłoszeńobsługiwanychręcznie

6.1 Phishingwroku2011

7 Trendywkolejnychlatach

7.1 Liczbaincydentówwlatach1996-2011 7.2 Rozkładprocentowypodtypówincydentówwlatach2003-2011

8 NajważniejszezjawiskaokiemCERTPolska

8.1 Zeus-in-the-Mobile-ZitMo 8.1.1 Symbian 8.1.2 BlackBerry 8.1.3 WindowsMobile



394248

51

5151525455 5657

8.2 SpyEyewPDF 8.3 ZeuS-wariantP2P+DGA-analizanowegozagrożenia 8.4 Wygrałeśnatychmiastowąnagrodę

9 NajciekawszewydarzeniazdziałalnościCERTPolska

9.1 SpołecznościCERTPolska 9.2 KonferencjaSECURE2011 9.3 RaportCERTPolskadlaENISA„ProactiveDetectionofNetworkSecurityIncidents” 9.4 CERTPolskadołączadoAPWG 9.5 PublicznewydanieCapture-HPCwramachHoneynetProject 9.6 ZakończenieprojektuWOMBAT 9.7 ZakończenieprojektuFISHA,przygotowaniadoprojektuNISHA

ARAKIS-wstęp

1. Statystykidotyczącealarmów

2. Statystykidotycząceataków

3. Interesująceprzypadkizaobserwowanychincydentówsieciowych

3.1 Morto-nowyrobaksieciowy3.2 Dziwnyruchnaporcie0/TCP

Raport ARAKIS


58

58

59

61

64

6469

5


Niniejszyraportprzedstawiawybranestatystykizdanychzebranychprzezze-spółCERTPolskaw2011r.wrazzomówieniemiwnioskami.Dokumentjestzorga-nizowanywpodobnysposóbdonaszegoraportuza2010rok.Dziękitemumożemyw tegorocznym raporcie porównać obserwacje z tymi, których dokonaliśmyw rokuubiegłym.

Ważną część raportu (rozdział 4) stanowią informacje na temat zagrożeń w polskich sieciach, przekazywane zespołowi CERT Polska przez różne podmiotyzwiązanezmonitorowaniemireagowaniemnazagrożenia,atakżezwybranychsys-temówCERTPolska.Ponieważuwzględniająoneprawiewszystkichpolskichopera-torów,dająbardzoszerokiobraztego,conaprawdędziejesięwpolskichzasobachinternetowych.

Rozdziały5 i6skupiająsięnadziałalnościoperacyjnejCERTPolska.Dane wnichprzedstawionepochodzązsystemuobsługiincydentów.Obejmująonezdarze-nia,przyktórychbyłainterwencjaCERTPolska.Używanaprzyobsłudzeincydentówklasyfikacjaumożliwiaporównaniatrendówwkolejnychlatachwrozdziale7.

W rozdziale 8 zostały omówione w szczegółach najważniejsze zjawiska, którepojawiłysiębądźuaktywniływsferzebezpieczeństwaw2011rokuiwktórychanalizęzaangażowanybyłzespółCERTPolska.

W Rozdziale 9 omawiamy najważniejsze wydarzenia związane z rozwojem naszegozespołu.

1.1 Jak czytać ten dokument?

Wdrugiejpołowie2011 r. rozpoczęliśmykorzystaniezwielunowychźródełwiedzyoincydentach,cowpłynęłonaznaczącywzrostliczbyzgłoszeńauto-matycznych.

W lutym pojawił się nowy wariant Zeusa atakujący polskich użytkowników. Byłonwyjątkowy,ponieważpozakomputeramiatakowałrównieżtelefonyko-mórkowe.Atakującymógłczytaćimodyfikowaćinformacje-np.zawierającekodyautoryzacji transakcji.Był todrugiwpełniudokumentowany tego typuprzypadeknaświecie.

1.2 Najważniejsze obserwacje podsumowujące raport

Ü

Ü

1. Streszczenie

1.1 Jak czytać ten dokument? / 1.2 Najważniejsze obserwacje podsumowujące raport

6


W kwietniu miał miejsce atak ukierunkowany na użytkowników Internetu. Wmasoworozsyłanymmailuznajdowałasięfałszywafaktura.Pojejotwarciuinstalowałsię trojanSpyEye inastępowałoprzejęciekontrolinadkompute-rem.Od tegomomentubyływykradanewszystkiepoufne informacjewpro-wadzaneprzezużytkownikanastronachinternetowych(wtymwsystemachbankowościelektronicznej).

Od końca kwietnia do czerwca 2011 r. doszło do wielu wycieków danychklientówusługelektronicznych.NajpoważniejszedotyczyłyfirmySony.Zbazdanych należących do niej usług PSN i SENwłamywaczewydostali danełącznie100mlnkontużytkowników,aprawdopodobnie takżeokoło10mlnkartkredytowych.Daneużytkownikówwyciekłytakżem.in.zNintendo,Code-masters,pornograficznegoserwisupron.comorazCitibanku(200tys.kont).CzęśćatakówprzypisywanajestgrupomAnonymousorazLulzSec.

WmajudoszłodowyciekukodutrojanaZeuswwersji2.0.8.9.Choćułatwiłotozwalczanietegozłośliwegooprogramowaniadziękizwiększonymmożliwo-ściomanalizy,pojawiłysięjednocześniedoniesieniaonowychrodzajachmal-ware’u,bazującychnawspomnianymkodzie.

JesieniąpojawiłasięnowawersjaZeusa,wykorzystującadopropagacjiiko-munikacjizkontroleremstworzonąprzezsiebiesiećpeer-to-peerorazgene-rowanienazwdomen(mechanizmpodobnyjakwdobrzeznanymConficke-rze).

W2011rokuzaobserwowaliśmyaż5,5mlnbotów(prawie10mlnzgłoszeń) upolskichoperatorów.Najwięcej,prawie2,5mln,znajdowałosięwsieciachTP.

Podobnie jakw 2010 roku,Conficker był najczęściej występującym botem wpolskichsieciach.Otrzymaliśmyaż2,1mlnautomatycznychzgłoszeń.

Serwisyoferującedarmowealiasysącorazczęściejwykorzystywaneprzezprzestępców:-aż w 84% phishing był umieszczony w domenie .pl z ich użyciem, -25%złośliwegooprogramowaniaobserwowanegowsandbox-achiłączące-gosiędopolskichsieci,wykorzystywałodarmowesubdomeny.

Polskie bezpłatne subdomeny, takie jak .osa.pl czy .bij.pl, zyskują na popularności wśród internetowych oszustów, którzy rejestrują je na potrzebyphishingu.

Ü

Ü

Ü

Ü

Ü

Ü

Ü

Ü

1. Streszczenie


7


Ü

Ü

Ü

Ü

Ü

Ü

Ü

Ü

Ü

WśródincydentówobsłużonychnieautomatycznieprzezCERTPolska,ponadpołowęstanowiłPhishingumieszczonywpolskichsieciach.Zanotowaliśmywzrostażo1/3wstosunkudo2010roku.Należypodkreślić,żewiększośćprzypadkówdotyczyłazagranicznychpodmiotówfinansowychiniestanowiłazagrożeniadlapolskiegoużytkownika.

Najczęściejskanowanymportemwpolskichsieciachbył445/TCPzwiązanyzpodatnościamiwwindowsowejusłudzezwiązanejzSMB.JednakżeliczbaadresówIPskanującychtenportzmalaławstosunkudoroku2010ook.29%.Skanowanianapozostałychportachwrankinguznaczącowzrosływporów-naniudopoprzedniegoroku.

ListanajbardziejzainfekowanychsieciwPolsceodzwierciedlawwiększościwielkośćoperatorówpodwzględemliczbyużytkowników.Ugruntowanawy-dajesiępozycjaoperatorówmobilnych.

NajwięcejserwerówC&CocharakterzeIRC-owymwPolsceznajdowałosięwhostowniachnależącychdopodmiotówmiędzynarodowych(LEASEWEB,OVH),alemającychteżsieciprzypisanePolsce.

NajwięcejzgłoszeńdotyczącychzłośliwychstronWWWdotyczyłodomenta-kich jak strefa.pl, friko.pl, interia.pl, republika.pl, czyli oferującychdarmowąrejestracjęstron.

StosunkowoniewielemamyzgłoszeńatakówDDoS.Nieoznacza tooczy-wiście,żeniematakichataków−wynikatoraczejzniechęcidozgłaszania, itrudnościwykryciatakiejaktywnościprzezstronętrzecią(stądniewielezgło-szeńautomatycznych).

Wśródpolskichoperatorówinternetowychbrakujewolidoblokowaniaportu25TCPdlakońcowychużytkowników,choćskutecznośćtakichdziałańzosta-ławykazanaprzezTelekomunikacjęPolską.

Corazwięcejspamupochodzizsiecioperatorówmobilnych.Dotyczyichjużniemalcopiątezgłoszenie.

WPolsce znajduje się ponad 160 tysięcy źle skonfigurowanych serwerówDNS, któremogąbyćwykorzystywanewatakachDDoS.Problemdotyczy wzasadziewszystkichoperatorów.

1. Streszczenie


8



2. Informacje o zespole CERT Polska

ZespółCERTPolskadziaławstrukturachNASK (Naukowej iAkademickiejSieciKomputero-wej) - instytutu badawczego prowadzącego działalność naukową, krajowy rejestr domen .pl idostarczającegozaawansowaneusługiteleinformatyczne.CERTPolskatopierwszypowsta-ływPolscezespół reagowaniana incydenty (zang.ComputerEmergencyResponseTeam). Aktywnieoperującod1996rokuwśrodowiskuzespołówreagujących,stałsięrozpoznawalnymidoświadczonympodmiotemwdziedziniebezpieczeństwakomputerowego.

Odpoczątku istnieniardzeniemdziałalnościzespołu jestobsługa incydentówbezpieczeństwaiwspółpracazpodobnymijednostkaminacałymświecie,zarównowdziałalnościoperacyjnej,jak ibadawczo-wdrożeniowej.Od1998rokuCERTPolska jestczłonkiemmiędzynarodowegoforumzrzeszającego zespoły reagujące -FIRST1, a od roku2000należy dogrupy roboczejeuropejskich zespołów reagujących -TERENA TF-CSIRT2 i działającej przy niej organizacji Trusted Introducer3.W2005rokuzinicjatywyCERTPolskapowstałoforumpolskichzespołówabuse-Abuse FORUM,natomiastw2010r.CERTPolskadołączyłdoAnti-Phishing Working Group4,stowarzyszeniagromadzącegofirmyiinstytucjeaktywniewalczącezprzestępczościąw sieci.

Do głównych zadań zespołu CERT Polska należy:

1http://www.first.org/ 2http://www.terena.org/activities/tf-csirt/ 3http://www.trusted-introducer.org/ 4http://www.antiphishing.org/

rejestrowanieiobsługazdarzeńnaruszającychbezpieczeństwosieci; aktywnereagowaniewprzypadkuwystąpieniabezpośrednichzagrożeńdlaużytkowników; współpracazinnymizespołamiCERTwPolsceinaświecie; udziałwkrajowychimiędzynarodowychprojektachzwiązanychztematykąbezpieczeństwateleinformatycznego;

działalnośćbadawczazzakresumetodwykrywaniaincydentówbezpieczeństwa,analizyzło-śliwegooprogramowania,systemówwymianyinformacjiozagrożeniach;

rozwijaniewłasnychnarzędzidowykrywania,monitorowania,analizyikorelacjizagrożeń; regularnepublikowanieRaportuCERTPolskaobezpieczeństwiepolskichzasobówInternetu; działaniainformacyjno-edukacyjne,zmierzającedowzrostuświadomościwzakresiebezpie-czeństwateleinformatycznego,wtym:

publikowanieinformacjiobezpieczeństwiewserwisiehttp://www.cert.pl/ orazwserwisachspołecznościowychFacebookiTwitter;

organizacjacyklicznejkonferencjiSECURE; niezależneanalizyitestyrozwiązańzdziedzinybezpieczeństwateleinformatycznego.

9


OdklikulatobserwujemyistotnądlaprofiludziałalnościCERTPolskazmianęwrodzajuotrzymy-wanychprzeznaszzespółzgłoszeń.Corazmniejznichwymagabezpośredniejreakcjiwewnątrznaszegozespołu,aprzedewszystkimtakiezgłoszeniabyłydotychczasprzeznasrejestrowa-ne,obsługiwaneiwykazywanewstatystykach.Otrzymujemynatomiastbardzodużeilościda-nychdotyczącychpolskichsieci,pochodzącegłówniezezautomatyzowanychźródełtworzonychprzezpodmiotyzajmującesiębezpieczeństwemwInternecie.Danetakie,choćnieobsługiwaneprzeznasbezpośrednio,sąprzekazywanewłaściwymoperatoromwramachposiadanejprzeznassiecikontaktów.CERTPolskapełniwięcwtymprzypadkurolękoordynatora.Jesttoroz-wiązaniewygodnezarównodladostawcówdanych,którzyniemusząsamodzielnieposzukiwaćkontaktówdoposzczególnychzespołówreagującychupolskichdostawców,jakidlaoperatorówinternetowych,którzymogązjednegomiejscaotrzymywaćdotycząceichinformacjepochodzą-cezwieluźródeł.

BiorącpoduwagęogrominformacjiprzekazywanychdoCERTPolskawramachkoordynacji,podjęliśmywysiłekustandaryzowaniaichiwykorzystaniawniniejszymraporciecelempełniej-szegozobrazowaniatego,cofaktyczniedziejesięwpolskichzasobachwInternecie.Formułajestzbliżonadonaszegorocznegoraportuzarok2010.Pozwalatonadokonywanieporównańi wychwytywanie trendóww atakach.Warto jednak podkreślić, żew 2011 roku corazwięcejautomatycznychźródełzewnętrznychdostarczałonaminformacje,coutrudniaporównaniazda-nymizubiegłychlat.Staraliśmysięuwzględnićtentrendwanalizach,stosującporównaniatylko naźródłachdanych,któreraportująnamincydentydotyczącezarównoPolski,jakicałegoświa-ta.Pozazgłoszeniamikoordynowanymi,opisujemyrównieżzgłoszeniawymagająceszczegól-nego,bezpośredniegozaangażowanianaszegozespołuwobsługę.Ponadtowraporcieopisu-jemy,naszymzdaniemnajciekawszezjawiskazwiązanezbezpieczeństwemwPolsce-takie, w których analizę byliśmy bezpośrednio zaangażowani. Zawieramy również opis najważniej-szychpozostałychobszarówaktywnościzespołuCERTPolskaw2011roku.

3. Wprowadzenie


10


W roku 2011 r. otrzymaliśmy 21 210 508 zgło-szeńpochodzącychzsystemówautomatycznych. Przeważającawiększośćdotyczyłabotów,skano-waniaispamu.Rozkładpozostałychkategorii,którewyróżniliśmywraporcie,przedstawiaponiższywy-

kres(zwracamyuwagęnaskalęlogarytmiczną!).

Danepochodzązwieluźródełobardzozróżnico-wanymcharakterze.Dlategosposobyichzbieraniaorazprezentacjiznacznieróżniąsięmiędzysobą.

W tejczęści raportuopisujemywynikianaliz informacjidotyczących incydentówbezpieczeństwa,którezostałyzebraneautomatycznie.

4. Statystyka zgłoszeń koordynowanych przez CERT Polska

4.1 Ilość informacji we wszystkich kategoriach

W stosunku do ubiegłego roku rozszerzyliśmykategorie zgłoszeń z 10 na 12 grup.Wyróżnionekategorie to: boty, skanowanie, spam, złośliweadresy URL, ataki brute force (nowa kategoria),otwarte serwery DNS (nowa kategoria), serweryC&C, przypadki phishingu, dane z sandbox-ów, Fast-flux,DDoSipozostałe.

Porównującpowyższedanezdanymiz2010roku(atakżeznaszymraportempółrocznymza2011)możnazaobserwowaćdużywzrostliczbyzgłoszeń.Wynikatoprzedewszystkimzfaktu,żedodaliśmy

wielenowychźródeł informacjiwdrugimpółroczu2011 r.W niektórych przypadkach, jak np. C&C, w wykresie powyżej prezentujemy zgłoszenia,a nie jak w roku ubiegłym unikalne adresy, stądznacznie większa liczba zgłoszeń. Fakt dodawa-nia nowych źródeł utrudnia porównanie z latamiubiegłymi,aleumożliwia lepszezorientowaniesię w poziomie zainfekowania i wykorzystywania doatakówsieciwPolsce.

Wkolejnychpodrozdziałachszczegółowoanalizu-jemywszystkiewyżejwymienionetypyzgłoszeń.

100

1000

1 10 10 000

100 0

00

1 000 0

00

1 000 0

0 000

BOTY

SKANOWANIE

SPAM

OTWARTE SERWERY DNS

ZŁOŚLIWE URLe

BRUTE FORCE

C&C

PHISHING

ADRESY Z SANDBOX-ÓW

FAST-FLUX

DDOS

POZOSTAŁE

9 887 006

5 703 211

467 7560

581 428

179 752

159 687

2 263

2 145

2 119

14 564

16

757

Tabela 4.1. Liczba zgłoszeń automatycznych w poszczególnych kategoriach

11


4.2 Phishing

Pozycja Kraj Liczba zgłoszeń

%udział wzgłoszeniach

1 US 135 405 50,8%

2 HK 17 963 6,7%

3 DE 12 680 4,8%

4 CA 11 943 4,5%

5 GB 9 822 3,7%

6 CZ 8 706 3,3%

7 FR 6 492 2,4%

8 BR 6 240 2,3%

9 RU 5 580 2,1%

10 CH 5 358 2,0%

17 PL 2 120 0,8%

W 2011 roku otrzymaliśmy 266 300 informacji o tradycyjnym phishingu. Informacje te dotyczyły 222214różnychadresówURLw139770dome-nachna40091unikalnychadresach IP.Rozkładliczbyzgłoszeńphishinguwedługkrajów,wktórychbyłumieszczony,widocznyjestwtabeli4.2.1.

W porównaniu z ubiegłym rokiem zwiększył sięudziałStanówZjednoczonych,któresamodzielnieodpowiedzialne są za ponad połowę utrzymywa-nychstronzphishingiem.Jesttozapewnespowo-dowane bardzo korzystnym stosunkiem ceny dojakości usłughostingowych, z którychprzestępcychętnie korzystają, jeśli jest to bardziej opłacalneniż włamywanie się na istniejące strony. Trzebatu zauważyć, że administratorzy takich usług są wtrudnejpozycji,ponieważniejestmożliwemoni-torowaniewszystkich treści, które klienci umiesz-czająnaserwerach.Tymczasemjużbardzokrótkiczasaktywnościstronyphishingowej(odwysłaniaodnośnikówdoniejwspamieażdo jejwykrycia,zgłoszenia i usunięcia) w zupełności wystarczy,aby przestępca uzyskał zwrot kosztów poniesio-nychnajejlegalneutrzymanie.

Tabela 4.2.1. Rozkład liczby zgłoszeń phishingu według krajów

Tabela 4.2.2. Lista domen najczęściej wykorzystywanych do phishingu


è

Co ciekawe, na drugim miejscu według liczbyzgłoszeń znalazł sięHongKong (17 963; 6,7%), anaszóstym-Czechy(8706;3,3%).Wobuprzy-padkachstronyprzypisanebyłydostosunkowonie-wielkiejliczbyadresówIP.WCzechach4772różneadresyURLznajdowałysiępod275adresamiIP(średnio17,35najednym),awHongKongu17640URLprzypadałona705IP(średnio25,02najeden). W istocie w obu przypadkach znacząca więk-szość stron znajdowała się na kilku serwerachhostingowych, pod różnymi adresami, w więk-szości w bezpłatnych domenach np. .co,.colub .tk. Na marginesie, obie te domeny zostały w 2011 roku usunięte przez Google z wynikówwyszukiwarki. Jest to dobitny przykład na to, że pozwalanie na bezpłatną rejestrację domenybezweryfikacjiabonentaniejestnajlepszympomy-słem.Niestety, tego rodzajuprzypadkówniebraktakże na polskim podwórku. Od kilku lat narastaproblem serwisów oferujących bezpłatne subdo-menydosamodzielnegozarządzania,znazwamigenerowanymi wedle uznania. Domeny takie jak .osa.pl czy .bij.pl używane były przez przestęp-cówzcałegoświatadorejestracjiadresówtakich jak1tem.taebao.cem.d2wmj1o.osa.pliwykorzysty-wania ichdophishingu.Łącznieaż5980 (4,3%)domenhostującychphishingznajdowałosięw.pl. Aż 5 033 z nich to bezpłatne subdomeny! Wprzypadkupozostałychdomendoszłonajpraw-dopodobniej do włamania na istniejące strony. Wtabeli4.2.2.znajdujesięlistadomen,zktórychusługnajchętniejkorzystaliprzestępcy.

osa.pl 4 031

bij.pl 576

bee.pl 154

345.pl 118

122.pl 65

orge.pl 56

inn.pl 30

12


Tabela 4.2.3. Rozkład metod wykorzystywanych do phishingu w sieciach polskich operatorów

darmowepoddomeny.pl 528

innedarmowepoddomeny 29

inne rejestracje 69

włamania 208

Tabela 4.2.4. Zestawienie operatorów, których najczęściej dotyczyły zgłoszenia

ASN Nazwa Zgłoszenia IP Zgłoszenia/IP URL

1 15 967 NetArt 514 167 3,08 352

2 12 824 HOME.PL 359 60 5,98 269

3 49 102 CONECTED 186 1 186,00 104

4 5 617 TP 162 40 4,05 91

5 43 470 LiveNet-PL 75 6 12,50 42

6 29 522 KEI 70 24 2,92 60

7 29 314 VECTRA 65 4 16,25 36

8 6 714 GTS 46 8 5,75 34

9 43 333 CISNEPHAX 40 10 4,00 25

10 15 694 ATM 40 4 10,00 19


Takategoriaobejmujezgłoszeniazeźródełauto-matycznychdotycząceprzypadkówutrzymywaniawsieciachpolskichoperatorówplikówzwiązanychze złośliwym oprogramowaniem. Zaliczamy tuprzedewszystkim:

kodsłużącyprzełamaniuzabezpieczeńprze-glądarkilubjednegozjejrozszerzeń,

plikwykonywalny(wtympobieranywwynikudziałaniapowyższegokodu),

plikikonfiguracyjnesłużącedosterowaniauru-chomionymwsystemiezłośliwymoprogramo-waniem.

Aby zmniejszyć zainteresowanie swoimi usługa-mi wśród przestępców, firmy oferujące bezpłatnealiasypowinnyzadbaćoto,abyklientbyłrozliczal-ny (była przeprowadzanaweryfikacja jego tożsa-mości np. z użyciemkarty kredytowej) orazo to,abyniedopuszczalnebyłowykorzystywanienazwserwisów,któreczęstopadająofiaramiphishingu, wszczególnościbanków.

Jeśli chodzi o phishing umieszczony w polskichsieciach (niezależnie od domeny, w której znaj-dował się danyURL), otrzymaliśmy 2 120 takichzgłoszeń,dotyczących1464adresówURLw812domenach na 505 adresach IP. Rozkład strategiiużytychprzyphishinguwsieciachpolskichopera-torówpokazujetabela4.2.3.

Kolejna tabela zawiera informacje o dziesięciuoperatorach, których najczęściej dotyczyły zgło-szenia. Dominacja operatorów hostingowych niepowinnabyćzaskoczeniem,ponieważnajczę-ściejwłaśnietamprzestępcywykupująusługibądźszukająofiarwłamania.Stosunek liczbyzgłoszeńdounikalnychadresówIP,którychdotyczyły,moż-na odnosić do czasu i skuteczności reagowaniadanegooperatora-immniejszy,tymszybciejdanyadresbyłusuwany.

4.3 Strony związane ze złośliwym oprogramowaniem

13


Tabela 4.3.1. Liczba przypadków złośliwego oprogramowania na stronach WWW według lokalizacji geograficznej (kraje)

Pozycja Kraj Procentowyudział wzgłoszeniach

1 US 41,10%

2 CN 15,42%

3 KR 9,62%

4 RU 5,48%

5 DE 4,12%

6 CA 3,03%

7 FR 2,78%

8 UA 2,37%

9 BR 2,17%

10 EU 1,77%

11 GB 1,50%

12 PL 1,43%

13 IT 1,33%

14 CZ 1,12%

15 NL 1,11%

16 JP 0,65%

17 TR 0,65%

18 SE 0,59%

19 HU 0,48%

20 RO 0,35%

POZOSTAŁE 2,94%


Ze względu na fakt, że w drugiej połowie 2011roku zaczęliśmy korzystać z wielu nowych źró-deł informacji, statystyki uległy zmianie. Otrzy-maliśmy znacznie więcej zgłoszeń, liczonychjako unikalne kombinacje dnia zgłoszenia IPiURL.Niezawszezewszystkichźródełotrzymu-jemy informacje o zagrożeniach znajdujących się na serwerach w innych krajach niż Polska. Tak więc, nie zawsze jesteśmy w stanie porów-nać sytuację Polski względem świata - porówna-niarobimytylkonabazieźródeł,któredostarczająnamdanezarównodlaPolski, jakiresztyświata. Do analiz sytuacji wewnątrz polskich sieci wy-korzystujemy natomiast wszystkie źródła, jakie posiadamy.

Statystyki dla świata nie uległy znaczącym zmia-nomwzględem2010roku.Napierwszymmiejscunadal znajdują się Stany Zjednoczone, którychdotyczy41,10%zgłoszeń.Nadrugimmiejscusą Chiny-15,42%.Polska,podobniejakwrokuubie-głym jest na 12miejscu, z podobnymprocentemzgłoszeń-1,43%.

Podobniejakwrokuubiegłym,porównującmiędzysobą poszczególne kraje, w których utrzymywa-ne były pliki związane ze złośliwym oprogramo-waniem, warto zwrócić uwagę na wysoką pozy-cję (poza Chinami) Rosji i Ukrainy. Zestawiającponiższą tabelę z podobną tabelą dla phishinguwidać, że pozycje tych krajów (w szczególnościChin) są istotnie wyższe w kategorii związanej ze złośliwym oprogramowaniem. Tak jak w po-przednimrokuuważamy,żemożliwąinterpretacjąjest to, że pliki ze złośliwym oprogramowaniem w tychkrajachniepojawiająsięwyłączniewwy-niku ślepych ataków hakerskich (wtedy rozkładpowinien być podobny jak dla phishingu), ale żekrajetewybieranesącelowo.Zjednejstronywie-lu chińskich i rosyjskich dostawcówusług hostin-gowychmaopinię „bulletproofhosting” zewzglę-du na trudności w uzyskaniu od nich wsparcia wusunięciuszkodliwychzasobów.Zdrugiejstro-nydośćczęstesąspekulacje,żeinternetowiprze-stępcy działająwChinach,Rosji czy naUkrainieza cichym przyzwoleniem wpływowych środo-wisk. Oczywiście, obie teorie nie wykluczają sięi nie są jedynymi możliwymi wytłumaczeniaminadzwyczaj wysokiej pozycji tych trzech krajów wtabeli.

Łącznie dla Polski (domena .pl i/lub hostowane wPolsce)otrzymaliśmyw2011roku272546zgło-szeń,wtym3000unikalnychIP,38472adresówURLoraz6999domen.Ztychzgłoszeń,179752raportowanych przypadków było hostowanych wPolsceirozkładałosięna2576IP,27991ad-resów URL oraz 5 637 domen. Wśród zgłoszeń ozłośliwychadresachURLzdomeny.plhostowa-nych poza Polską dominowały Niemcy i Francja.Tylko3z424adresówIPpozakrajemznajdowałysięChinach-udostępniałyonezłośliweplikiwyko-nywalne. è

14


Liczba zgłoszeń

Procentowy udział

System autonomiczny Operator

1 30 330 16,87% 12 824 HOME.PL

2 19 336 10,76% 29 522 KEI

3 14 960 8,32% 15 967 NETART

4 13 341 7,42% 16 138 INTERIA

5 10 853 6,04% 12 741 NETIA

Liczba unikalnych

IP

Procentowy udział


1 607 23,56% 12 741 NETIA

2 499 19,37% 12 824 HOME.PL

3 231 8,97% 15 967 NETART

4 163 6,33% 5 617 TP

5 96 3,73% 29 522 KEI

Liczba unikalnych

URL

Procentowy udział


1 4 622 16,51% 12 824 HOME.PL

2 3 832 13,69% 16 138 INTERIA

3 2 093 7,48% 29 522 KEI

4 2 012 7,19% 15 967 NETART

5 1 230 4,39% 12 741 NETIA

Pozycja Liczba unikalnych złośliwych adresów Nazwa domeny

1 1 984 p-upfile.co.cc2 1 040 mypromofile.info3 926 kamp.nazwa.pl4 558 esflores.kei.pl5 493 noclegi-i.pl6 375 dementia.waw.pl7 367 www.sp2osiek.pl8 336 www.teatr-pismo.pl9 314 acletan.strefa.pl

10 295 canrilric.strefa.pl


W zestawieniach największej liczby zgłoszeń,unikalnych IP, adresów URL oraz domen domi-nowali najwięksi dostawcy usług hostingowych:Home.pl, Netart oraz Krakowskie E-Centrum In-formatyczne Jump. Obserwacje te są zbliżonedo tychdokonanychw2010roku,ale inneniż te zpierwszegopółrocza2011-cobyćmożewynika zfaktuuzyskaniadostępudowielunowychźródełinformacji. Czasami jednak w czołówce znajdo-walisiętakżedostawcyusługinternetowych-np. wkategoriinajwięcejunikalnychzłośliwychIPdo-minowałaNetia.RelatywnieniskoznajdowałasięzatoTP.Wartozwrócićuwagęnabrakobecnościwczołówceoperatorówsiecimobilnych.

W tabeli 4.3.5 zilustrowano domeny pod kątemnajwiększej liczby zgłoszonych unikalnych zło-śliwych adresów URL. Pierwszy wniosek to faktbraku domen darmowych wykorzystywanych w phishingu np. bee.pl/osa.pl, widywanych rów-

Tabela 4.3.2. Liczba przypadków zgłoszeń złośliwego oprogramowania na polskich stronach WWW według systemów autonomicznych

Tabela 4.3.3. Liczba przypadków zgłoszeń złośliwego oprogramowania na polskich stronach WWW pod kątem unikalnych IP znajdujących się u polskich operatorów

Tabela 4.3.4. Liczba przypadków zgłoszeń złośliwego oprogramowania na polskich stronach WWW pod kątem unikalnych URL

Tabela 4.3.5. Ranking domen hostujących złośliwe oprogramowanie pod kątem unikalnych adresów URL

nieżw danych z sandbox-ów.Są za towykorzy-stywane inne domeny, które są rozdawane dar-mowo (patrz tabela 4.3.6). Najczęściej złośliweoprogramowanie było dystrybuowane zarówno zchińskiejdomenyp-upfile.co.ccjakimypromofile.info.Złośliweoprogramowanieztychdomenprzyj-mowałopostaćplikuSetupXXX.exe,gdzieXXXtocyfryodwzorowujące jegokolejnewersje.Rozpo-znawanebyłoprzezoprogramowanieantywiruso-wejakotrojanbankowytypuZeus,alewzależnościodwersji, również jako oprogramowanie udające program antywirusowy (tzw. rogue antivirus). Wydaje się, że domeny zostały zarejestrowanespecjalniewtymcelu(takjakdwieostatnieztabeli4.3.5). Inaczejwyglądasprawakolejnychsześciu (poz.3dopoz.7)domenz tabeli,doktórychsięwłamano,anastępniehostowanomalwareróżne-gotypu.

15


Liczba unikalnych IP Nazwa domeny

2 402 strefa.pl1 770 com.pl1 124 friko.pl1 081 interia.pl1 064 republika.pl1 041 nazwa.pl

815 w8w.pl700 yoyo.pl676 waw.pl576 kei.pl493 noclegi-i.pl

Tabela 4.4.1. Adresy odwiedzane przez malware

Tabela 4.3.6. Ranking domen drugiego poziomu, na których hostowano złośliwe oprogramowanie pod kątem unikalnych złośliwych URL

Niestety, nie dysponujemy dokładnymi statysty-kami dotyczącymi rozkładu charakteru złośliwegooprogramowania na stronach. Naszym zdaniemwiodącą formą infekcji użytkownika końcowegosą mechanizmy inżynierii społecznej: użytkowniksam instaluje sobie złośliweoprogramowaniepo-przezściągnięcieiuruchomienieplikuwykonywal-nego.Warto jednak zwrócić uwagę, żew drugiejpopularnejiznaczniegroźniejszejkategoriiataków- drive-by download (atak, w którym cały procesinfekcji odbywa się w pełni automatycznie przezlukęwprzeglądarcelubjejwtyczcewsposóbnie-zauważalnydlaużytkownika)-istotnymzjawiskiem w2011rokubyłyatakinaprzeglądarkiwykorzystu-jąceJavę.DlategozalecamyodinstalowanieJavyna swoim komputerze, jeżeli nie jest niezbędna dowykonywaniacodziennychczynności.


4.4 Z piaskownicy do polskich sieci, czyli adresy odwiedzane przez malware

Takategoriainformacjijestrozszerzeniemkategoriibotyiuwzględniamywniejadresy,któreodwiedza-nebyłyprzezzłośliweoprogramowaniezainstalo-wane w laboratoriach wewnątrz sandbox-u, czyli wdużymskrócie,specjalnieprzygotowanegośro-dowiska, służącego do kontrolowanego urucha-miania różnego rodzaju podejrzanego oprogra-mowania. Zaobserwowaliśmy 2 119 unikalnychadresówWWWoraz FTP, do których łączyło sięoprogramowanieuruchamianewsandbox-ach.

Doadresówtychłączyłosięwsumie2113unikal-nychplików.Ponad31%znichzostałorozpozna-nych przez programy antywirusowe jako złośliweoprogramowanie (na podstawie Cymru MalwareHashRegistry - http://www.team-cymru.org/Servi-ces/MHR/).

Najczęściejobserwowaliśmypołączeniadoserwe-ra geoloc.daiguo.com.Wyodrębniliśmy429 zapy-tań.Wszystkiebyły takiesame,przyczymkażdeznichzostałowygenerowaneprzezzłośliweopro-gramowanieo innej sumieMD5.Są to zapytaniamającenaceluuzyskanie informacjiopochodze-niugeograficznymzainfekowanejmaszyny.

Pozycja URL lub adres IP Liczba zapytań

1 geoloc.daiguo.com 429

2 www.bee.pl 424

3 212.33.79.77 275

4 pelcpawel.fm.interia.pl 167

5 www.bigseekpro.com 72

6 s1.footballteam.pl 61

7 mattfoll.eu.interia.pl 61

8 appmsg.gadu-gadu.pl 61

9 www.tibissa.com 58

10 213.108.56.140 58

Równieczęsto(424razy)notowaliśmypołączeniado serwera www.bee.pl. Jest to serwis oferują-cy darmowe aliasy częstowykorzystywany przezautorów złośliwego oprogramowania do przekie-rowania ofiar do serwerów C&C. Podobnie jak wprzypadkuphishingu, zauważyliśmydośćdużezainteresowanieprzestępcówtegotypuusługami.W sumie odnotowaliśmy aż 520 takich połączeń(tabela 4.4.2.). Poza bee.pl przestępcy wykorzy-stywalidomenyosa.pl,345.pl,bij.plorazorge.pl. è

16



275 razy notowaliśmy połączenia do serwera o adresie IP 212.33.79.77.Wszystkie byływyge-nerowaneprzeztensamzłośliwyplik.Jest toko-munikacja zainfekowanych maszyn do centrumzarządzającego. Bardzo ciekawa sytuacja dotyczy adresów w domenie interia.pl: pelcpawel.fm.interia.pl, rad-son_master.fm.interia.pl orazmattfoll.eu.interia.pl. Wewszystkichprzypadkachwinowajcąbyłkońtro-jańskionazwieSality.Takjakwpoprzednimprzy-padku łączył się on do centrów zarządzających. Interesujący jest fakt,żewszystkieznichznajdo-wałysięwdomenieInterii.

Wprzypadkuappmsg.gadu-gadu.pl,takjakwubie-głym roku,mieliśmy do czynienia z połączeniamiinicjującymidosiecigadu-gadu.

Pozycja Domena Liczbazapytań

1 bee.pl 424

2 osa.pl 48

3 345.pl 32

4 bij.pl 8

5 orge.pl 8

Tabela 4.4.2. Połączenia do bezpłatnych subdomen

Codopozostałychadresów,niestetynieudałosięjednoznacznieustalić,wjakimcelubyłyoneodwie-dzane.Mogłatobyćzarównodziałalnośćzłośliwe-gooprogramowania, jak iruchgenerowanyprzezzwykłe aplikacje sprawdzane przez użytkownika wsandbox-ie.

4.5 Spam z polskich sieci

W 2011 roku otrzymaliśmy 4 677 560 zgłoszeńspamu pochodzącego z polskich sieci. Należypodkreślić, że w ogromniej większości nie doty-czą one pojedynczych niechcianych przesyłek,lecz źródeł - najczęściej zainfekowanych lub źleskonfigurowanychmaszyn,zktórychkażdawysy-łałanierzadkodziesiątkitysięcylistów.Liczbazgło-szeń jest mniejsza niż rok wcześniej, lecz trend w tym roku był nieznaczniewzrostowy, z chwilo-wym spadkiem w okresie wakacyjnym. Ponadpołowa wszystkich zgłoszeń dotyczyła zaledwietrzech operatorów - Netii (31%), Telekomunika-cji Polskiej (17%) orazMultimedia Polska (10%). Daneanalizowaneprzeznasdotycząwiększości,lecz nie wszystkich polskich sieci, stąd nie na-leży ich przenosić na zależności ogólnopolskie. Zależnościpomiędzyuwzględnionymioperatoramisąjednakrzeczywiste.DysproporcjamiędzyTele-komunikacjąPolską iNetią jest łatwodostrzegal-na,wszczególności jeśliwziąćpoduwagęudziałwrynkuobuoperatorów.Wynikaonazrozwiązańtechnicznych stosowanych od blisko dwóch latw Telekomunikacji Polskiej, a przede wszystkimdomyślnego blokowania portu 25 TCP dla użyt-

kowników końcowych. Niestety,mimo znakomitejskutecznościtakiegorozwiązania,niezostałoonowprowadzone dotąd przez pozostałych dużychoperatorów.

Dzieląc liczbę zgłoszeń przez liczbę unikalnychprzypadków,którychdotyczyły (1253528)otrzy-mujemy3,73.Liczbata,biorącpoduwagę,żelicz-bazgłoszeńdlajednegoprzypadkujestsilniezwią-zana z czasem aktywności danego źródła,możebyćtraktowana jakowspółczynnikuporczywości -przyidentycznymsposobieobliczeniadlaposzcze-gólnychsystemówautonomicznychbędzieontymwiększy,imdłużejźródłautrzymująsię„przyżyciu”w danej sieci. Niskie wartościmogąwynikać za-równo ze skuteczności operatora w szybkim ra-dzeniusobiezproblemem, jak i zdynamicznegoprzyznawaniaadresów.W tymdrugimprzypadkuzarażone maszyny są po prostu identyfikowanejakonoweźródłazakażdymrazem,gdyodnawia-jądzierżawę.Należywięcjeinterpretowaćłącznie zliczbązgłoszeń.Uporczywośćdladziesięciusie-ci, którychnajczęściejdotyczyłyzgłoszenia (łącz-nie89,5%),wahałasięod1,23do23,51.

17



Na uwagę zasługują takżewysokie pozycje ope-ratorów mobilnych. Wszyscy oni zmieścili się wpierwszejdziesiątcewedługbezwzględnejliczbyzgłoszeń, łącznieodpowiadajączaniemalcopią-te zgłoszenie (19,5%). Biorąc pod uwagę unikal-neadresyIPzgłoszonejakoźródłaspamu,niemalwszyscy operatorzy wyprzedzają nawet Teleko-munikacjęPolską!Nieconiżejznajdujesięjedynie T-Mobile.Statystykatajestniewątpliwiewynikiemsposobu przyznawania adresów w tych sieciach(krótka dzierżawa DHCP), jednak nie powinnabyć całkowicie lekceważona, ponieważ duże po-

krycie przestrzeni adresowej adresami uznanymiza rozsyłającespammożedecydowaćoumiesz-czaniuznacznychczęścisiecinaczarnychlistach. Toniepozostajebezznaczeniadlaużytkowników,którym nagle zostaje uniemożliwione wysyłaniepoczty. Wydaje się, że operatorzy mobilni będąmusielizmierzyćsięzproblememspamuzichsieci wniedalekiej przyszłości.Tymbardziej, żeusługimobilnegodostępudoInternetunapewnoniebędątracićnapopularności,awwielumiejscachjużdziśsątraktowanejakoalternatywadlastałegołącza.

Tabela 4.5.1. Ranking operatorów według liczby zgłoszeń spamu

ASN Nazwaoperatora Liczba zgłoszeń Udział Liczbaunikalnych

źródeł Udział Uporczywość

1 12741 NETIA 1 452 218 31,0% 391 405 31,2% 3,71

2 5617 TP 797 275 17,0% 107 477 8,6% 7,42

3 21021 MULTIMEDIA 468 932 10,0% 70 265 5,6% 6,67

4 43447 ORANGE 360 078 7,7% 194 319 15,5% 1,85

5 29314 VECTRA 353 998 7,6% 19 664 1,6% 18,00

6 8374 PLUS 265 747 5,7% 188 951 15,1% 1,41

7 39603 PLAY 182 600 3,9% 147 554 11,8% 1,24

8 20960 TelekomunikacjaKolejowa 128 293 2,7% 5 458 0,4% 23,51

9 12912 T-MOBILE 97 283 2,1% 79 278 6,3% 1,23

10 12476 ASTER 78 451 1,7% 3 348 0,3% 23,43

4.6 Skanowanie

Wszystkie zgłoszenia ujęte w poniższych staty-stykach były przekazane automatycznie. Ogółemotrzymaliśmy 5 703 211 zgłoszeń o skanowa-niu, którym źródłem była Polska. W zestawieniu

uwzględniono dane przysyłane przez naszychpartnerówzichsystemówmonitoringuorazpocho-dzącezsystemuARAKIS.

StatystykiwTabeli4.6.1przedstawiająTOP10por-tówdocelowychpodkątemunikalnychźródłowych

adresówIP,którychźródłembyłyadresyIPzPol-ski. è

Najczęściej skanowane usługi

18


Wykres 4.6.2. TOP 10: unikalne źródłowe IP per port

Wykres 4.6.3. TOP 10: unikalne źródła per port (bez 445/TCP)

445/TCP135/TCP139/TCP1433/TCP

25/TCP5900/TCP3389/TCP

80/TCP23/UDP22/TCP

135/TCP

139/TCP

1433/TCP

80/TCP

5900/TCP

3389/TCP

23/UDP

22/TCP

25/TCP

Pierwszemiejscewrankingu-podobniejakwrokuubiegłym-zajmujeport445/TCP.Większośćnaj-poważniejszych, a więc najczęściej wykorzysty-wanych luk w systemach Windows znajduje się w usługach nasłuchających na tym porcie. Jed-nakże pomimo że nadal przewaga tego portunadpozostałymijestbardzoduża,tozmalałaona wstosunkudoroku2010.Ponadtozmniejszyłasięookoło29%sumaryczna liczbaunikalnychadre-sówIP,któreskanowałytenport.


Tabela 4.6.1. TOP 10: porty docelowe pod kątem unikalnych źródłowych adresów IP, których źródłem były adresy z Polski

Pozycja Port docelowy

Liczba unikalnychIP

Zmiana wstosunku do2010r.

Prawdopodobnywiodącymechanizmataków

1 445/TCP 205 243 -29,00% AtakitypubufferoverflownausługiWindowsRPC

2 135/TCP 2 560 0,00% AtakinawindowsowąusługęDCE/RPC

3 139/TCP 2 062 95,00% AtakinausługęNetBIOS/współdzielenieplików idrukarek

4 1433/TCP 1 124 100,00% AtakinaMSSQL

5 80/TCP 914 63,50% Atakinaaplikacjewebowe

6 23/TCP 440 40,00% Atakinausługętelnet

7 22/TCP 435 -1,00% AtakisłownikowenaserwerySSH

8 25/TCP 434 62,00% Prawdopodobnepróbyrozsyłaniaspamu

9 5900/TCP 401 29,00% AtakinaVNC

10 3389/TCP 394 166,00% AtakisłownikowenaRDP(zdalnypulpit)-wdużejmierzeaktywnośćrobakaMorto

Na drugimmiejscu znajduje się nieobecnyw ze-szłorocznym zestawieniu TOP 10 port 135/TCP, na którym domyślnie nasłuchuje usługa WindowsDCE/RPC (DistributedComputingEnvi-ronment /RemoteProcedureCalls).Wielokrotniewykrywanowniejwielepodatności,poprzezjednąznichpropagujesięznanyidziałającyjużoddaw-na robakBlaster.Jednakżew roku2011niebyłonowych robakówwykorzystujących do propagacjiport135.

19



WrankinguTOP10pojawiłysię -opróczwymie-nionegowyżej135/TCP-takżeporty25/TCP(usłu-ga pocztowa SMTP) oraz 3389/TCP. Ten ostatnizwiązany jestzusługąWindowsMicrosoftTermi-nalServerużywającąprotokołuRDP(wykorzysty-wanyprzez tzw.zdalnypulpit).Pojawieniesięgo wrankinguwwiększościprzypadkówspowodowa-ne jest działającym w sieciach od sierpnia roba-kiemMorto,którymasowoinfekowałsystemyWin-dowsipropagowałsiędalej.Cociekawe,Mortoniewykorzystujeżadnejluki,ajedynieodgadujehasłaużytkowników. Jednocześnie - poza aktywnościąrobakaMorto-obserwowaliśmywzrostskanowańnatymporcieniezwiązanychzrobakiem.

W stosunku do roku ubiegłego wzrosło zaintere-sowanieprawiewszystkimiportamiwymienionymiw rankingu, poza 445/TCP. Znaczący wzrost zo-

stałzaobserwowanyprzedewszystkimnaportach1443/TCP(ok.+100%)-usługaMicrosoftSQLSer- ver, 139/TCP (ok. +95%) - usługa NetBIOS, 80/TCP (ok. 64%) - aplikacjewebowe, oraz23/TCP (ok.+40%)-usługatelnet.

Podobnie jak w roku ubiegłym, interesujący jestfakt stosunkowo wysoko ulokowanych ataków nausługinatywnedlasystemówUnix/Linux:telnet (port 23/TCP) oraz SSH (22/TCP).W przypadkuSSHsątowprzeważającejwiększościatakisłow-nikowe.

Ciekawym zjawiskiem jest brak obecności wpierwszejdziesiątceportu5060/UDPzwiązanego z atakami na usługę VoIP. Liczba unikalnych IPnatymporciezmniejszyłasięwstosunkudoroku2010ook.66%.

0 500 1000 1 500 2 000 2 500 3 000

3389/TCP

5900/TCP

25/TCP

22/TCP

23/TCP

80/TCP

1433/TCP

139/TCP

135/TCP

è

2010

2011

Wykres 4.6.4. TOP 10: unikalne IP per port - porównanie z rokiem 2010

20


20


0 50 000 100 000 150 000 200 000 250 000 300 000 350 000

445/TCP 2010

2011

Wykres 4.6.5. Unikalne IP per port 445/TCP - porównanie z rokiem 2010

Tabela 4.6.6. Rozkład zainfekowanych IP w Polsce

Tabela4.6.6.przedstawiarozkładzainfekowanychunikalnychadresówIPnależącychdoposzczegól-nychpolskichoperatorów.

Kolejność numerówAS polskich operatorów jestniemal identyczna jak w roku ubiegłym - jest tojednocześnieodzwierciedleniewielkościposzcze-gólnychoperatorówpodwzględemliczbyużytkow-ników. Jedyna różnica towypadnięcie z rankingu UPC(AS9141).

Liczbazainfekowanychkomputerówwyraźniespa-dławzględemroku2010uwszystkichoperatorów.NajwiększymspadkiemmożeposzczycićsięVec-tra (spadeko57%),ATOM(spadeko46%),ASK(spadeko44%)orazgórującawrankinguTP(spa-deko41%).

Pozycja Nazwaoperatora NumerASN LiczbaunikalnychskanującychIP Zmianawstosunkudoroku2010

1 TP AS5617 74 854 -41,00%

2 NETIA AS12741 43 011 -24,00%

3 DIALOG AS15857 34 684 -26,50%

4 ORANGE AS43447 18 441 -25,00%

5 PLUS AS8374 16 111 -12,40%

6 MULTIMEDIA AS21021 11 762 -27,80%

7 ASK-NET AS25388 2 739 -44,00%

8 VECTRA AS29314 2 052 -57,50%

9 GTS AS6714 1 749 -46,40%

10 T-MOBILE AS12912 1 008 −

Najbardziej zainfekowane sieci w Polsce

21



TPCo

nficke

r

NETIA

Torpig

DIALO

GDN

SCha

nger

PTK-C

ENTER

TEL

Rusto

ckPL

USNE

T

Mebroo

t

MULTIM

EDIA

Irc-bo

tnet

ASK-N

ET

Sality

VECT

RA

Miner

ATOM

Tdss

ERAP

TC (T-

Mobile

)

Inne

140 000

120 000

100 000

80 000

60 000

40 000

20 000

0

2 500 000

2 000 000

1 500 000

1 000 000

500 000

0

Wykres 4.6.7. TOP 10 operatorów w Polsce pod kątem liczby unikalnych skanujących IP

Wykres 4.7.1. Liczba botów według typów

2010

2011

4.7 Boty w polskich sieciach

Kategoriatauwzględniakomputerybędąceczłon-kami botnetów i znajdujące się w polskich sie-ciach, a nieuwzględnione w innych kategoriach. Choć najpopularniejszym zastosowaniem botne-tówjestrozsyłaniespamu,mogąonebyćwykorzy-

stanedodowolnychinnychzastosowań:wykrada-niadanychwymagającychdużegopasma(DDoS)lubdużejmocyobliczeniowejalbopoprostu jakododatkowawarstwaanonimizacji.

è

22



5617

- TP

1274

1 - Ne

tia

4344

7 - Or

ange

3960

3 - Pl

ay

8374

- Plus

1291

2 - T-

Mobile

1585

7 - Di

alog

2102

1 - M

ultim

edia

2931

4 - Ve

ctra

6714

- GTS

2 500 000

2 000 000

1 500 000

1 000 000

500 000

0

Wykres 4.7.2. Rozkład botów w poszczególnych AS-ach

NajwięcejbotówzauważyliśmywAS5617należą-cymdoTP.Byłatoliczbabliska2,5mln,prawieczte-rokrotnieprzewyższającaliczbębotówwAS12741należącymdoNetii(ok.630tys.).Nieulegawątpli-wości,żenajwięcejbotówznajdujesięwsieciachoperatorów,którzydostarczająInternetodbiorcomindywidualnym.Są to duzi dostawcy, tacy jakTP

czy Netia, dostawcy Internetumobilnego - Oran-ge,Play,PlusiT-MobileorazdostawcyInternetu w sieciach kablowych - Multimedia i Vectra. Prawiepołowawszystkichbotów(ok.45%)znajdo-wałasięwsieciTP,zaś12%wsieciNetii.

4.8 Serwery Command & Control

W2011rokuotrzymaliśmy2263zgłoszeń(liczo-nych jako unikalne kombinacje dzień/IP) z syste-mówautomatycznych dotyczących 59 unikalnychserwerówwPolscewykorzystywanychwcharak-terzeCommand&Controldozarządzaniabotne-tami.

Jest to więcej niż w ubiegłorocznym raporcie (za2010rok)ipółrocznym(za2011rok)zewzględu nafaktdodanianowychźródełzewnętrznych.

Pozycja ASN Operator LiczbaunikalnychC&C

1 16 276 OVH 22

2 16 265 LEASEWEB 9

3 5 617 TP 5

4 12 741 NETIA 5

5 28 753 LEASEWEB 2

Tabela 4.8.1. Liczba unikalnych serwerów C&C w Polsce pod kątem lokalizacji

23



4.9 Ataki DDoS

4.10 Ataki brute-force

W roku 2011 otrzymaliśmy 16 automatycznychzgłoszeń zawierających informacje o atakachDDoS na serwery znajdujące się w polskichsieciach. Były to przypadki wydania rozkazu,

Otrzymaliśmy159687zgłoszeńdotyczącychśle-pych prób logowania się do usług. Ataki takie,zwane„brute-force”,służyłykiedyśdoodgadywa-nia haseł metodą prób i błędów. Dziś zazwyczajzwiązanesązpróbamiuzyskaniadostępupoprzezużycie domyślnych haseł, błędów w konfiguracjilubpodatnościwimplementacjifunkcji logowania.

Wszystkie zgłoszenia dotyczyły prób logowa-niadousługiSSH. Ich liczbanieodpowiada jed-nak zdecydowanie skali problemu. Wszystkiepróby pochodziły bowiem jedynie ze 127 uni-kalnych adresów IP.Daje to średnio 1 257 prób/adres, przy czym mediana rozkładu wynosi 11, a85%adresówwygenerowałomniejniż1000prób. Dane te, zgodnie ze statystykami z rozdzia-łu 4.6 pokazują, że ataki na serwisy takie jakSSH są dziś znacznie mniej popularne niż kil-ka lat temu. Z pewnością jest tow dużejmierzekonsekwencją coraz większej skuteczności za-bezpieczeń technicznych, a także polityk bez-pieczeństwa - przynajmniej w zakresie dostępuzdalnego. Włamywacze, zupełnie racjonalnie,poszukują dziś łatwiejszych celów, wykorzystującchoćbyinżynierięspołecznączyaplikacjewebowe,którezdefinicjimusząbyćudostępnionepublicznie.

Większość wspomnianych prób miała miejsce odkońcalutegodokońcamarca2011roku.

Podobnie jakw latachubiegłych,większośćzgło-szeń dotyczyła serwerów IRC (większość rów-nież na przypisanym tej usłudze standardowymporcie6667/TCP).Zdecydowanym lideremzostałdebiutujący w naszych raportach w tej kategoriifrancuskiOVH,którypodobniejakholenderskiLE-ASEWEBmawRIPEsieciprzypisanedoPolski. Wskaliświatowejjużtradycyjnienajwięcejkontro-lerówC&CznajdowałosięwUSA-29,4%.RazemzNiemcamiStanyZjednoczonehostująichprawie50%. Podobnie jak w zeszłym roku, w czołówceznajdują się państwa zachodnioeuropejskie, ta-kiejakFrancja,WielkaBrytaniaiHolandia.WyżejniżwubiegłorocznymraporcieznajdujesięRosja -na3.miejscu.ZkoleiChinyznowuznajdująsięrelatywnie nisko - dopiero na 10 pozycji.Wedługdanychnamdostępnych równieżPolskapod tymwzględemprezentujesiębardzokorzystnie,dopie-rona23miejscu.

Wykres 4.8.1. Kraje, w których najczęściej znajdowały się serwery C&C

AR 1,3%LU 1,3%JP 1,5%ES 1,8%CL 1,8%CN 1,8%TR 1,9%

UA 2,1%CA 3,1%

NL 3,8%

GB 5,0%

FR 5,9% RU 5,9%

DE 13,4%

US 29,4%INNE 20,0%

zauważone na inwigilowanych serwerach C&C. Czteryatakizostaływykonywanenaserwerygier. Pozostałe według naszych analiz dotyczyły użytkowników indywidualnych. Jest to więcej niżw 2010 roku, w którym odnotowaliśmy 11 takich przypadków, jednak w dalszym ciągu niewiele w porównaniu do innych kategorii zgłoszeń. Niestety,niewynikatoztego,żeatakówtakichrze-czywiściejestniewiele.Raczejjesttoproblembra-kumonitorowania w sposób automatyczny przezstronytrzecietegotypuataków.

24



Liczba zgłoszeń ASN Operator613 5 617 TP82 12 741 Netia42 29 314 Vectra16 21 021 Multimedia

3 12 476 Aster1 13 119 ACI

Liczba zgłoszeń

% udział w zgłoszeniach ASN Operator

63574 39,6% 5 617 TP

18667 11,6% 12 741 Netia

16941 10,5% 43 447 Orange

7023 4,4% 20 960 TKTELEKOM

6157 3,8% 6 714 GTS

4116 2,6% 50 994 E-SBL-ASe-SBL.net

3430 2,1% 21 021 MULTIMEDIA

2722 1,7% 29 314 VECTRA

1998 1,2% 29 665 SPEED-SOFT

1798 1,1% 13 000 LEON-AS

4.11 Serwery Fast-flux 4.12 Otwarte serwery DNS

4.13 Pozostałe zgłoszenia

Fast-flux to technologiapolegającana rozprosze-niuinfrastruktury(wszczególnościserwerówtreści)nawielumaszynach-zazwyczajbędącychczęściąbotnetu-wceluutrudnieniajejinwigilacjiiusunię-cia. Metoda ta jest często wykorzystywanam.in.przy phishingu, spamie (do utrzymywania stron, naktórezwabianisąodbiorcy)czydystrybucjipor-nografii. Fast-flux wykorzystuje domeny admini-strowaneprzezprzestępców.Odpowiednie rekor-dysączęstoicykliczniezmieniane,wkażdejchwilioferująckilkaadresówIPdladanejnazwydomeno-wej.W2011r.otrzymaliśmy757zgłoszeńprzypad-ków hostowania domen Fast-flux w adresach IPpolskichsieci.Jaknietrudnosiędomyślić,wszyst-kiekomputerywykorzystywanewprocederzeznaj-dowały się w sieciach dostarczających Internetużytkownikomkońcowym,cowidaćwtabeli4.11.1.

Wtejkategoriiznajdująsięźleskonfigurowaneser-weryDNS,umożliwiającerekursywneodpytywaniezdowolnegomiejscawsieci.Takieustawieniepo-zwala na wykorzystywanie ich w atakach DDoSprzezzwiększeniewolumenu ruchu (traffic ampli-fication)wwynikuzapytańDNSzesfałszowanymadresemźródłowym. W 2011 r. otrzymaliśmy aż 581 428 informacji o160682unikalnychadresachIP,naktórychznaj-dowały się takie serwery. Wskazuje to na sporąskalętegoproblemuwPolsce.Rozkładdziesięciusystemówautonomicznych,wktórychnajczęściejumieszczonebyłyotwarteserweryDNS,znajdujesięwtabeli4.12.1.

Pozostałe14,5tys.zgłoszeńdotyczyłorozmaitychrodzajów automatycznie wykrywanych zagrożeń,przedewszystkimnieprawidłowoskonfigurowanychurządzeń,takichjakserweryproxyczyroutery.

Tabela 4.11.1. Lokalizacja komputerów wykorzystywa-nych do sieci Fast-flux

Tabela 4.12.1. Rozkład dziesięciu systemów autonomicz-nych, w których najczęściej umieszczone były otwarte serwery DNS

Zgłoszeniadotyczyły17różnychdomen,zktórychnajbardziej aktywna korzystała z aż 336 polskichadresów. W przypadku większości domen wyko-rzystywana infrastrukturabyłaznaczniemniejsza,najczęściejobejmującniewięcejniż52polskiead-resyIP(15domen).

Obserwowanyczaswykorzystywaniapojedynczejdomenywpolskichsieciach(prawdopodobniebli-skozwiązanyzjejczasemżycia)wynosiłniewięcejniż2miesiące.Cociekawe,niezaobserwowaliśmyżadnegoprzypadkuwykorzystywaniajednegoad-resudlawięcejniżjednejdomeny.Możetoświad-czyć o tym, że poszczególne botnety nie dzielą zesobąinfrastrukturyiniesąwynajmowanekon-kurencji,przynajmniejdousługFast-flux.

25


5. Statystyka incydentów obsłużonych przez CERT Polska

W roku 2011 obsłużyliśmy 605 incydentów na-ruszajacych bezpieczeństwo teleinformatyczne.

Wnastępnychrozdziałachznajdujesięichszcze-gółowaklasyfikacja.

Ta część raportu poświęcona jest incydentomzarejestrowanym w systemie obsługi zgłoszeń, awięc takim,którezostałyobsłużonebezpośred-nioprzezzespółCERTPolska.Wwieluaspektachsą one uzupełnieniemobrazu zaprezentowanego

wrozdziale3,uwzględniająbowiemzjawiskawy-chodzące poza automatyczne systemy zbieraniainformacji -mniejmasowe, leczczęstopoważne,wymagająceinterwencjiczłowieka.

5.1 Liczba przypadków naruszających bezpieczeństwo teleinformatyczne

5.2 Typy odnotowanych incydentów

Typ/Podtypincydentu Liczba Suma-typ Procent-typObraźliwe i nielegalne treści 2 152 25,12Spam 144Dyskredytacja,obrażanie 3Pornografiadziecięca,przemoc5 3Złośliwe oprogramowanie 39 46 7,60Wirus 2Robaksieciowy 0Końtrojański 5Oprogramowanieszpiegowskie 0Dialer 0Gromadzenie informacji 1 46 7,60Skanowanie 42Podsłuch 0Inżynieriaspołeczna 3Próby włamań 7 23 3,80Wykorzystanieznanychluksystemowych 11Próbynieuprawnionegologowania 5Wykorzystanienieznanychluksystemowych 0Włamania 3 10 1,65Włamanienakontouprzywilejowane 4Włamanienakontozwykłe 2Włamaniedoaplikacji 1Atak na dostępność zasobów 0 14 2,31Atakblokującyserwis(DoS) 3Rozproszonyatakblokującyserwis(DDoS) 11Sabotażkomputerowy 0Atak na bezpieczeństwo informacji 0 3 0,50Nieuprawnionydostępdoinformacji 2Nieuprawnionazmianainformacji 1Oszustwakomputerowe 1 307 50,74Nieuprawnionewykorzystaniezasobów 0Naruszenieprawautorskich 1Kradzież tożsamości, podszycie się (w tym phishing) 305Inne 4 4 0,66SUMA 605 605 100

è5Wszelkie zgłoszenia dotyczące nielegalnych treści w rozumieniu polskiego prawa kierowane są do zespołu Dyżurnet.pl, również działającego w ramach NASK (http://www.dyzurnet.pl/)

Tabela 5.2.1. Incydenty obsłużone przez CERT Polska według typów

26



5.3 Typy odnotowanych ataków

Tak jak w roku poprzednim najczęściej występu-jącym typem incydentów były Oszustwa kompu-terowe (50,74%). Należy zaznaczyć, że w roku2011 odnotowaliśmy ich o 1/3 więcej niż w roku2010 (38,5%).Wgłównejmierze,wpływmiały tuzgłoszeniadotycząceKradzieży tożsamości,pod-szycia się, szczególnie te dotyczące Phishingu. Oszustwa komputerowe stały się zdecydowaniedominującym typem incydentów. Na drugiej po-

zycjiodnotowaliśmyObraźliwe i nielegalne treści. Stanowiły one 25,12% zarejestrowanych przy-padków. Najczęściej w tej kategorii mieliśmy doczynienia ze zgłoszeniami rozsyłanego spamu. Na trzeciej pozycji ex aequo zanotowaliśmy Gromadzenie informacjiorazZłośliwe oprogramo-wanie(po7,6%).Obydwatypymająmniejszyudziałniżwrokupoprzednim.Złośliwe oprogramowanie o5,9%,zaśGromadzenie informacjio2,19%.

Wykres 5.3.1. Rozkład procentowy typów incydentów

Oszus

twa k

ompu

terow

eOb

raźliw

e i ni

elega

lne tre

ściGro

madze

nie in

forma

cjiZło

śliwe

oprog

ramow

anie

Próby

włamań

Dostę

pnoś

ć zaso

bów

Właman

ia

60%

50%

40%

30%

20%

10%

0%

50,74

25,12

7,60 7,60

3,802,31 1,65

Inne

0,66Be

zpiec

zeństw

o info

rmac

ji

0,50

27



5.4 Zgłaszający, poszkodowani, atakujący

W przypadku podtypów incydentów najczęściejwystępowała Kradzież tożsamości, podszycie się (50,41%).Oznacza towzrost ażo1/3wsto-sunku do roku 2010.Praktyczniewszystkie zgło-szone incydenty dotyczyły Phishingu umiesz-czonego na polskich serwerach. Ofiarami byłynajczęściej instytucje finansowe z zagranicy. Odnotowaliśmy 29 przypadków dotyczących polskichpodmiotów.

23,8% incydentów dotyczyło Spamu. Były to w większości zgłoszenia pochodzące ze Spam-Copa, dotyczące polskich komputerów, którewy-syłałyniezamówionąofertęhandlową.Natrzecim i czwartym miejscu odnotowaliśmy kolejno Ska-nowania (6,94%)orazNiesklasyfikowane złośliwe oprogramowanie (6,45%).Wporównaniudo roku2010nauwagęzasługujedwukrotnyspadekincy-dentów dotyczących Niesklasyfikowanego złośli-wego oprogramowania.

Na potrzeby statystyk odnotowywane są trzy ka-tegorie podmiotów związanych z incydentami:zgłaszającyincydent,poszkodowanywincydencie i odpowiedzialnyzaprzeprowadzenieataku,czyliatakujący.

Dodatkowo kategorie te uwzględniane są w roz-biciu na podmiot krajowy i podmiot zagraniczny.

Tabela5.4.1przedstawiazbiorczezestawienieda-nychdotyczącychpodmiotówincydentu.

Wykres 5.3.2. Rozkład procentowy podtypów incydentów

Kradzi

eż toż

samoś

ci, po

dszyc

ie

się (w

tym P

hishin

g) Spam

Skan

owan

ieNie

sklas

yfiko

wane

złoś

liwe

oprog

ramow

anie

Wykorzy

stanie

znan

ych lu

k sys

temow

ychRo

zpros

zony a

tak bl

okują

cy ser

wis (

DDoS

)

Próby

nieup

rawnio

nego

logo

wania

Koń t

rojań

skiWłam

anie

na ko

ntoInż

ynieri

a spo

łeczna

Dyskr

edyta

cja, o

brażan

ie

Pozos

tałe

5.3 Typy odnotowanych ataków

60%

50%

40%

30%

20%

10%

0%

50,41

6,94

23,80

6,451,82 1,82 0,83 0,83

5,450,66 0,500,50

è

28



Podmiot Zgłaszający % Poszkodowany % Atakujący %

Osobaprywatna 41 6,78 27 4,46 6 0,99

CERT6 115 19,01 0 0,00 0 0,00

ISPAbuse 4 0,66 0 0,00 0 0,00

Innainstytucjads.bezpieczeństwa 165 27,27 0 0,00 0 0,00

Firmakomercyjna 264 43,64 323 53,39 448 74,05

Ośrodekbadawczylubedukacyjny 10 1,65 10 1,65 34 5,62

Instytucjaniekomercyjna 0 0,00 1 0,17 8 1,32

Jednostkarządowa 4 0,66 8 1,32 10 1,65

Nieznany 2 0,33 236 39,01 99 16,36

Kraj 126 20,83 80 13,22 520 85,95

Zagranica 478 79,01 299 49,42 13 2,15

Nieznany 1 0,17 226 37,36 72 11,9

Tabela 5.4.1. Rodzaje podmiotów ujętych w klasyfikacji incydentów

6Zawiera zgłoszenia pochodzące z systemów automatycznych, w tym także z systemu ARAKIS

Wykres 5.4.2. Źródła zgłoszeń, atakujący i poszkodowani

CERT

Inna i

nstyt

ucja

ds.

bezpi

eczeń

stwa

Instyt

ucja

nieko

mercy

jna

ISP Ab

use

Jedn

ostka

rząd

owa

Osob

a pryw

atna

Firma

kome

rcyjna

Ośrod

ek ba

dawc

zy lub

eduk

acyjn

y

Niezna

ny80%

70%

60%

50%

40%

30%

20%

10%

0%

19,0%

43,6%

53,4%

74,0%

27,3%

0,0% 0,2% 1,3% 0,7% 1,3% 1,7%6,8% 4,5%

1,0% 1,7% 1,7%5,6%

0,3%

39,0%

16,4%

0,7%

Zgłaszający Poszkodowany Atakujący

29



Wykres 5.4.3. Pochodzenie zgłaszającego, poszkodowanego i atakującego

100%

90%

80%

70%

60%

50%

40%

30%

20%

10%

0%

20,8%

79,0%

13,2%

49,4%

37,4%

86,0%

2,1%11,9%

Polska

Zgłaszający Poszkodowany Atakujący

Zagranica Nieznany

Wroku2011najczęściejotrzymywaliśmyzgłosze-niaodFirm komercyjnych (43,6%).WwiększościdotyczyłyonePhishinguibyłyprzesyłaneprzezin-stytucjefinansowebądźteżpodmiotyjereprezen-tujące.27,3%incydentówbyłozgłoszonychprzezinną Instytucję ds. bezpieczeństwa. Większość znichpochodziłazeSpamCopaidotyczyłarozsy-łaniaspamuprzezpolskichużytkownikówInterne-tu. 19%zgłoszeńotrzymaliśmyod innych zespo-łówCERT.NajczęsciejdotyczyłyonePhishingu.

W ponad połowie przypadków (53,4%) poszko-dowanym podmiotem były Firmy komercyj-ne. Najczęściej padały one ofiarą Phishingu. W 39% Poszkodowany pozostawał Nieznany. Jesttowynikzgłoszeń,dotyczącychgłównieSpa-mu i Skanowania, które były przesyłane przez

Zgłaszającego (np. SpamCopa) w imieniu osóbtrzecich. Ażw74%przypadkówatakującymbyłaFirma ko-mercyjna. Jest towynik,naktórywdużejmierzemająwpływ lokalni dostawcy Internetuorazfirmyhostingowe.CERTPolskazazwyczajnieposiadainformacjiokońcowymużytkowniku,znajdującymsięzabramąlokalnegodostawcyorazowłaścicie-lustronyWWWumieszczonejw farmiehostingo-wej.WówczaszaatakującegoprzyjmujesięostatniznanypodmiotczyliFirmę komercyjną.Najczęściejhostowała ona Phishing oraz rozsyłała Spam. 16,4%Atakującychpozostałonieznanych.Takjak wlatachpoprzednichukrywałsięonzaserweremProxy, botnetem, TOR-em czy przejętą maszynąnieświadomejofiary.

W 2011 roku zgłaszający aż w 79% pochodzili zzagranicy.Jest towynikdużej ilości incydentówdotyczących Phishingu oraz Spamu, które byłyraportowane przez zagraniczne podmioty. Tylko w1/5przypadkówZgłaszającypochodziłzPolski.

Prawiepołowaposzkodowanychpochodziłazza-granicy.WiększościznichpadłaofiarąPhishingu. Ażw37,4%przypadkówpochodzeniaPoszkodo-wanego pozostałonieznane. Jest towynikwspo-

mnianych wcześniej zgłoszeń, składanych np.przez Spamcopa w imieniu osób trzecich. Tylko13,2%PoszkodowanychpochodziłozPolski.

W przypadku Atakujących aż 86% pochodziło z Polski. Jest to naturalną konsekwencją obsługizgłoszeń dotyczących domeny .pl. Tylko 11,9%Atakującychpochodziłozzagranicy.Główniebyłytoincydentydotyczącehostowania Phishingu.

30


6. Statystyki dodatkowe, dotyczące zgłoszeń obsługiwanych ręcznie

Wykres 6.1.1. Phishing - pochodzenie atakującego, zgłaszającego i poszkodowanego

100%

80%

60%

40%

20%

0%

90,79% 93,09%87%

10%4%6,58%

0,33%7,24%

1,97%

Polska

Phishing - pochodzenie atakującego

Phishing - pochodzenie zgłaszającego

Phishing - pochodzenie poszkodowanego

Zagranica Nieznany

6.1 Phishing w roku 2011

Ponieważ docierają do nas głównie zgłoszeniadotyczącepolskichsieci,tonajczęściejodnotowy-waliśmy Phishing umieszczony na polskich ser-werach.Stanowił on90,79%ogółu. Jeżeli chodzi

o zgłaszających to pochodzili oni w większości zzagranicy(93,09%).Ofiarąnajczęściejbyłyrów-nieżpodmiotyzagraniczne(87%).Tylko10%incy-dentówdotyczyłopolskichpodmiotów.

Wykres 6.1.2. Phishing - zgłaszający

80%

70%

60%

50%

40%

30%

20%

10%

0%

71,90%

16,67%9,48%

1,31% 0,65%

Firma komercyjna Osoba prywatna NieznanyCERT Inna instytucja ds. bezpieczeństwa

31


6. Statystyki dodatkowe, dotyczące zgłoszeń obsługiwanych ręcznie

Phishing był najczęściej zgłaszany przez Firmę komercyjną (71,9%). Były to głównie atakowanepodmioty finansowe lub firmy je reprezentujące.16,67% zgłoszeń pochodziło od zespołów typuCERT. 9,48%incydentówzgłosiły Inne instytucje ds. bezpieczeństwa.

W przypadku atakującego, najczęściej mieli-śmy do czynienia z Firmą komercyjną (82,24%). Były to zazwyczaj przypadki Phishingu umiesz-czonego na serwerach firm świadczących usługihostingowe.W ponad 12% przypadków nie uda-

łonamsięustalićtożsamościatakującego.Byłytozazwyczajmaszyny,którehostowałytylkoiwyłącz-niestronępodszywającąsiępoddaną instytucję, awpisywbazieripe.netzawierałytylkodaneISP. Aż 94,74% ofiar stanowiły Firmy komercyjne. Były togłównie zagranicznepodmioty finansowe. W4,61%ofiarapozostałanieznana.Sątoprzypad-ki,gdziewmomencieobsługizgłoszeniafałszywastronazostałajużzablokowana,atreśćzgłoszeniaorazciągiwadresieniewskazywałynakonkretnypodmiot.

Wykres 6.1.3. Phishing - atakujący

Wykres 6.1.4. Phishing - poszkodowani

90%

80%

70%

60%

50%

40%

30%

20%

10%

0%

100%

80%

60%

40%

20%

0%

82,24%

94,74%

12,17%

4,61%

1,64% 1,64% 1,32% 0,99%

0,33% 0,33%

Firma komercyjna

Firma komercyjna

Osoba prywatna

Osoba prywatna

Ośrodek badawczy lub edukacyjny

Jednostka rządowa

Jednostka rządowa

Nieznany

Nieznany

Instytucja niekomercyjna

32


7. Trendy w kolejnych latach

7.1 Liczba incydentów w latach 1996 – 2011

Wykres 7.1.1. Liczba incydentów w latach 1996 − 2010

3000

2500

2000

1500

1000

500

01996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

50 75 100 105 126

741

1 0131 196 1 222

2 5162 427

2 108

1 796

1 292

674605

Kolejny rokz rzęduzanotowaliśmymniejszą licz-bęincydentów.Odklikulatzauważamy,żedocieradonascorazmniejzgłoszeńdotyczącychpolskichISP.Zgłoszeniatrafiająbezpośredniodowłaścicie-lasieci.Poziomobsługi incydentówprzezdużychdostawcówInternetuitreściorazfirmyhostingowejestzrokunarokwyższy.WzwiązkuztymzespółCERTPolska notuje corazmniej próśb o pomoc wprzypadku,gdyniemareakcjizichstrony.

ZgłoszeniatrafiającedoCERTPolskasązatocoraz bardziejpoważneiskomplikowane, jaknp. tedo-tyczące Phishingu i Złośliwego oprogramowania, aprocesichobsługiznaczniesięwydłużył.Obsłu-ga spraw dotyczących kontrolerów odpowiedzial-nych za ataki na użytkowników polskich bankówpotrafizająćnawetkilkatygodni.

33


7. Trendy w kolejnych latach

7.2 Rozkład procentowy podtypów incydentów w latach 2003 – 2011

Wykres 7.2.1. Rozkład procentowy podtypów incydentów w latach 2003 − 2011

Odroku2003statystykisątworzonewoparciuotęsamąklasyfikację.Umożliwia tonamporównanie

rozkładuprocentowegoincydentównaprzestrzeniczasu(patrzwykres7.2.1).

Wroku2011nienastąpiłaznaczącazmianatren-dów zaobserwowanych w poprzednich latach.Skanowania nadal sąmarginalnew porównaniuzlatami2003−2005.Odkilkulatutrzymująsięnapoziomiekilkuprocent.WprzypadkuSpamuodkil-kulatnienotujemydużychwzrostówczyspadków.PomimotegoSpamstanowiniezmiennieznaczącyodsetekincydentów.

Dodatkowo należy podkreślić, że skala zja-wiska jest o wiele większa. CERT Polska od-notowuje tylko zgłoszone przypadki spamurozsyłanego przez maszyny znajdujące się w obrębie domeny .pl. Nadal utrzymuje się wy-raźny trend wzrostowy jeżeli chodzi o incydentydotyczące Kradzieży tożsamości, podszycia się. Jesttowchwiliobecnejnajczęściejpojawiającysięincydent.Wporównaniudo2010roku,zanotowali-śmywzrostwtejkategoriio40%.

90%

80%

70%

60%

50%

40%

30%

20%

10%

0Skanowanie Spam Kradzież tożsamości, podszycie się

2003 2006 20092004 2007 20102005 2008 2011

81,6%

53,9%

4,0%

10,6%10,9%

35,3%

25,9%33,9%

23,8%

50,4%

35,8%

30,0%

22,3%19,2%

12,5%

3,1%2,5%0,2%

28,0%25,2%

51,4%

27,1%24,2%

4,7%7,9% 8,0% 6,9%

34


8. Najważniejsze zjawiska okiem CERT Polska

Wtymrozdzialeopisujemynajważniejszezjawiskazwiązanezbezpieczeństwemwsieciw2011roku,

w których rozpracowanie byliśmy bezpośrednio zaangażowani.

1. W wyniku instalacji złośliwego oprogramowania, atakujący zyskiwał kontrolę nad komputerem ofiary. Nie wiadomo jakie było pierwotne źródło infekcji − zakładamy, że

mogłobyćichwiele,np.specjalniespreparowanastrona WWW, plik .pdf, zainfekowany pendrive czye-mailzawierającyzłośliwyzałącznik.

8.1 ZITMO - Zeus-in-the-Mobile

2. Po zainfekowaniu komputera złośliwe opro- gramowaniepodmieniałow locie(nakompu- terzeofiary)treśćzaufanejstrony.

Popomyślnymzalogowaniudobankupojawiałsięmonit z prośbąo podanie numeruorazwybranie zlistymodelutelefonu.

ZITMO,czyliZeusInTheMobile to zagrożenie,które na początku 2011roku pojawiło się w Pol-sce.Jest tonowaodmia-na trojana ZeuS, którapoza komputerem ofiary

atakuje również jej telefon komórkowy.Atakującymożeczytaćorazmodyfikowaćinformacjezawar-tewSMStakiejakkodyautoryzacjitransakcjiczywiadomości potwierdzające wykonane operacjebankowe.

W jaki sposób infekowane były telefony komórkowe?

35


3. Pouzupełnieniu formularzadaneprzesyłane były do serwera zarządzającego. Atakujący po zdobyciu numeru wysyłał SMS z linkiem

do złośliwego oprogramowania (przeznaczonego nakonkretnymodeltelefonu).

4. Nieświadomy zagrożenia użytkownik próbo- wałotworzyćotrzymanylink.

W konsekwencji na telefonie instalowała sięaplikacja(złośliweoprogramowanie).

è


5. Zainfekowany telefon wysyłał atakującemu SMSzinformacjąopoprawnymzainstalowaniu złośliwegooprogramowania.

Atakujący od tego momentu miał pełną kontrolęnadkomputeremoraztelefonemofiary.

36



Listamodelitelefonów,któremogłystaćsięcelemataku(nanichmogłozostaćzainstalowanezłośli-we oprogramowanie) znajduje się pod adresemhttp://www.cert.pl/wp-content/uploads/atakowa-netel.html. Są to telefony pracujące pod kontrolątrzech systemówoperacyjnych:BlackBerry,Sym-bian oraz Windows Mobile. Wysyłany do ofiarySMS zawierał informację o cyfrowym certyfikacieoraz linkkończącysięciągiemznaków „cert.jad”,„cert.sis” lub „cert.cab” (patrz zdjęcie po prawej).

Należybyćczujnympodczaslogowaniadobanku.Ostrzegawcze światło powinno zapalić się, jeżelizauważymyjakąśnowąinformacjęlubfunkcjonal-nośćoktórejbanknieinformowałwcześniej.Może

byćtopytanieomodel,numertelefonu,czyteżmo-nitopodaniejednocześniewięcejniżjednegokodujednorazowego(TAN).Wtakiejsytuacjizawszenaj-lepiejzgłosićtakiincydentdobiuraobsługibanku.

Rysunek 8.1.1. Ekran proszący użytkownika o podanie numeru telefonu oraz wybranie marki i modelu

Pozainstalowaniunatelefonie,aplikacja(bezwie-dzywłaściciela)wysyłaSMSotreści„AppInstalledOK”nazdefiniowanynumertelefonuzarządcy.Wewszystkich próbkach, którymi dysponował CERTPolska, występował ten sam numer telefonu.

Zaczynał sięonodcyfr44778148**** i pochodził z Wielkiej Brytani. Poniżej zamieszczamy krótkiopisdziałaniaoprogramowanianakażdejzpodat-nychplatform.

Kto mógł zostać ofiarą ZITMO?

Więcej informacji o złośliwym oprogramowaniu

Jak ustrzec się infekcji oraz zapobiec kradzieży danych (i środków pieniężnych)?

37



Na telefony z systemem operacyjnym SymbianwysyłanebyłySMSzawierającelinkdoplikucert.sis. Po zainstalowaniu malware tworzył procesnazwany „Nokia update” (rysunek po prawej). Wpamięci telefonuzapisywałpliki (rysunekponi-żej):

C:\private\20039E30\firststart.datC:\private\20039E30\NumbersDB.dbC:\private\20039E30\settings2.dat

8.1.1 Symbian

è

Wnichprzechowywanebyłyinformacjeoustawie-niachoraznumerach,któremająbyćpodsłuchiwa-neprzeztrojana.

Aby odinstalować złośliwe oprogramowanieotwieramy menedżer aplikacji oraz odnajduje-my aplikację „Certificate”. Następnie z menukontekstowego wybieramy opcję usuń, a po-tem potwierdzamy zamiar usunięcia aplikacji. Wprzypadkupojawieniasięostrzeżeniaokoniecz-nościzamknięciaaplikacjiodpowiadamytwierdzą-

Deinstalacja

co(OK).Porozpoczęciuprocesuusuwaniaaplikacji

powinnopojawićsięoknoprosząceopodaniekodu

lub hasła. Numer ten jest zakodowanywewnątrz

złośliwego programu. Kod umożliwiający usunię-

ciemalware(wprzypadkuinfekcjizlutego2011r.)

to:45930

38


8.1.2 BlackBerry

Paczka infekująca platformę blackberry roz-syłana była w pliku „cert.jad”. Po jego uru-chomieniu ściągany i instalowany był jeden


z plików: „sertificate.jar” lub „sertificate.cod”. Po zainstalowaniu aplikacja widoczna jest wmenu„Opcje->Aplikacje”podnazwą„sertificate”. Po kliknięciu w pozycję z aplikacją pojawia sięokno umożliwiające przeglądanie szczegółowychinformacjinajejtemat.Wtymsamymokniemamyrównież możliwość usunięcia niechcianego opro-gramowaniapoprzeznaciśnięcieprzycisku„Usuń”.Zostanie jedyniewyświetlonymonit potwierdzają-cyusunięcie.Powykonaniuoperacjiodzyskujemykontrolęnadnaszymtelefonem.

39


8.1.3 Windows Mobile

8.2 SpyEye w PDF

W przypadku telefonów z systemem operacyj-nymWindowsMobile,plik instalacyjnyzmalwarenazywał się cert.cab. Podczas instalacji ZITMOprzedstawiałsięjako„netMsgService”.Pozainsta-lowaniuzłośliweoprogramowaniezapisywałousta-wienia w czterech plikach: settings.xml, senders.xml,listnumbers.xml,messages.xml.Sammalwa-renatomiast instalowanybyłwpliku c:\Windows\MailService.exe. Po uruchomieniu program ten

Dzięki współpracy polskichzespołów bezpieczeństwa,związanych inicjatywą Abuse--Forum,udałosięwykryćorazprzeanalizować nowe zagro-żenie. Na początku kwietnia

dopolskichinternautówtrafiaławiadomośće-mailzawierającawzałącznikuzłośliwydokumentPDF. Po jegootwarciukomputer infekowanybyłopro-gramowaniemszpiegowskimSpyEye.Jegogłówne

przeznaczenie towykradanie poufnych informacjipodawanychprzezużytkownikanastronachinter-netowych (w tym systemach bankowości elektro-nicznej).Pootwarciudokumentu i zainstalowaniuzłośliwegooprogramowaniakomputerofiaryłączyłsiędoserwera-kontrolera(C&C)znajdującegosiępod adresem u-buntu.com. Po kilku dniach zain-fekowanie ofiary były kierowane na nowy serwerkontrolera, wydający się być częścią większegobotnetu.

Rozesłanawiadomoście-mail zawierałanastepu-jącepola:

Temat: Your Order No ######### | Pure-mobile Inc. Nadawca: PuremobileIncZałącznik: Order_#########.pdf

W przeanalizowanych próbkach znajdowała siętreśćwjęzykupolskim:

Dziekujemy za zamowienieTwoje zamowienie zostalo przyjete.Numer zamowienia 123-123456789.Bedziesz musial podac ten numer w ko-respondencji.

Wybrales opcje platnosci karta kredy-towa.Twoja karta zostanie obciazona oplata è


Jak wyglądała złośliwa wiadomość?

niebyłwidocznynaliściezadańwstandardowym(wbudowanym) menadżerze procesów. Dopie-ro zainstalowanie dodatkowego oprogramowaniaumożliwiłowyśledzeniedziałającegow tle szkod-nika.Cociekawe,tytułgłównegooknazwiązanegozeszkodliwymprocesempisanybyłcyrylicą(jaknazdjęciu).Niestetyoprogramowanietoniejestrów-nieżwidoczne na liście zainstalowanych aplikacji-coznacznieutrudniausunięcieszkodnika.

40


Po otwarciu załączonego dokumentu PDF, pro-gramAdobe Reader rozpoczyna jego ładowaniei przetwarzanie. Struktura dokumentu PDF jestdrzewemobiektów,z jednymobiektem typuRootjako korzeniem. Adobe Reader przetwarza ko-lejne obiekty, zgodnie z ich kolejnością i pozycją wdrzewie.CzęśćobiektówtoskryptyJavaScript, któremogąbyćwykonywaneprzez silnikEScript(silnik JavaScript firmy Adobe). Do zbadaniadokumentu PDF oraz wyświetlenia obiektów w nim zawartych można użyć programu PDFID (rysunek8.2.1).

Napierwszyrzutokawydajesię,żetendokumentniezawierażadnychobiektówJavaScript.Jest tojednaknieprawda-skryptyukrytesąwskompre-sowanych strumieniach (stream). Są one zazwy-czaj zaciemnione i trudne do zinterpretowania. Taksamojestiwtymprzypadku(fragmentdekom-presowanegokoduwidocznynarysunku8.2.2).

Skrypt ukrytyw skompresowanymstrumieniu zo-stajezdekompresowany iwykonany.Służyondo


umieszczenia shellcodu w pamięci za pomocątechniki„heapspray”.Kiedynastąpiwłamanie(wy-korzystanie lukiw czytnikuPDF), procesor ofiaryrozpoczynawykonywanietegowłaśniekodu.

Szczegółowa analiza złośliwego dokumentu PDF

Rysunek 8.2.1. Analiza dokumentu PDF

Rysunek 8.2.2. Fragment kodu javascript

w wysokosci 1234,00 EUR.

Oplata za zamowienie bedzie opisana na

wyciagu bankowym z karty kredytowej

jako „Puremobile Inc.”

Ta wiadomosc nie jest dowod zakupu

Po otrzymaniu przez nas potwierdzenia

tej wplaty, wyslemy Ci list zwrotny.

W zaleznosci od tego jaka forme wysyl-

ki wybierzesz otrzymasz go wprost

na swoj adres e-mail lub na adres do-

mowy.

Puremobile Inc

41


Abyzabezpieczyćsięprzedwłamaniamitegotypu,należyprzestrzegaćkilkureguł.Przedewszystkimnienależyotwieraćzałącznikówwwiadomościache-mail od nieznanych osób. Oczywiście, czasem- niestety - możemy otrzymaćmaila od zaufanejosoby,którazostałajużzainfekowana.Wtakiejsy-tuacjinależyuważniepatrzeć,czytreśćtegomailaniejestpodejrzana.DodatkowodobrąpraktykąjestwyłączenieobsługiJavaScriptprzezprogramAdo-beReader(rysunek8.2.5).


è

Jak się zabezpieczyć przed takim atakiem?

Jak dokładnie dochodzi do przejęcia kontroli nadprzetwarzanym kodem? Biblioteka AcroForm.apizawiera błąd, który to umożliwia.W trakcie prze-twarzaniaobiektuAcroForm(widocznegowlistingu

ProgramuPDFID),wykonywanaprocedurazakoń-czysięprzedwcześnie,copozwalanawykonanieskoku do biblioteki icucnv34.dll (rysunek 8.2.3).

Biblioteka ta zostanie wykorzystana przez exploit typu ROP (o exploitach tego typu pisaliśmyw artykule z grudnia 2010 roku pod adresem: http://www.cert.pl/news/3078), który wcześniej zo-stałumieszczonywpamięciprzezwspomnianyJa-vaScript.

Jakie są konsekwencje wykonania złośliwegokodu? Przekonaliśmy się o tym przeprowadza-jąc kontrolowane otwarcie badanego dokumentu na komputerze laboratoryjnym. Exploit ładuje bi-blioteki systemowe (rysunek 8.2.4) potrzebnedoprowadzenia transmisji w sieci Internet i próbujepołączyćsięzatakowanegokomputerazezdalnymserwerem.PopołączeniupobieraorazuruchamiapliktypuEXE.JesttotrojanSpyEye,któryjestna-stępniewykorzystywanydoinfiltrowaniakomputeraofiaryikradzieżyjejdanych(np.hasełbankowych).

Rysunek 8.2.3. Kod biblioteki AcroForm podczas wykonywania

Rysunek 8.2.4. Ładowanie nowych bibliotek

Rysunek 8.2.5. Wyłączenie obsługi JavaScript

42



Jeśli w przyszłości Adobe Reader zapyta nas opozwolenienawykonywanieskryptówJavaScriptzawartych w dokumencie, możemy mu odmówić(rysunek8.2.6.)

8.3 ZeuS - wariant P2P + DGA - analiza nowego zagrożenia

Jesienią 2011 roku za-rejestrowanoinfekcje nowymzłośliwymopro-gramowaniem. Ana-l izamechanizmuuru-chamianiazłośliwegooprogramowania, pro-

ces jego ukrywania, czy też sposóbskładowania konfiguracji wskazywały naZeuSa. Jednak podczas monitorowaniazainfekowanych maszyn nie udało sięzauważyć charakterystycznej dla tegotrojana komunikacji z centrum C&C. Pogłębszejanalizieokazałosię,iżpróbkatonajprawdopodobniej nowawersja trojanaZeuSopartanaupublicznionymprzypad-kiemkodzie.Wnowejwersji trojanaauto-rzy skupili się na eliminacji najsłabszegoogniwa - scentralizowanego systemudystrybucji informacji. Poprzednie wer-sjeZeuSaopartebyłyo jeden (lubkilka)zdefiniowanychadresów,podktórymido-stępne było centrum zarządzania C&C.Pozwalałotołatwonamierzyćtakieadresyi poprzez ich blokowanie uczynić botnet bezuży-tecznym.Badanywarianttrojanawykorzystujedwanowekanałykomunikacyjnedopobieranianowychrozkazów(rysunek8.3.1):1. Komunikacjawsiecipeer-to-peer2. MechanizmGenerowaniaDomen

W Internecie dostępne były już wcześniej in-formacje na temat nowego wariantu ZeuSa, ale - z informacji jakieposiadamy -dotychczaso-wapracabadawczaskupiałasięnazarejestrowa-niuimonitorowaniuruchudodomenZeuSowych.

Rysunek 8.2.6

Rysunek 8.3.1.

Podczasnaszejpracyskupiliśmysięnapoznaniuorazmonitorowaniumechanizmówwymianyinfor-macjiprzezsiećP2Porazpróbiezebraniadanychnatematjejkształtu.

43



Wprzypadkumodeluopartegonacentralnym(jed-nym lub wielu) punkcie zarządzania, z góry wia-domojakiekomputerywykorzystywanesądowy-dawania rozkazów. Nowy mechanizm dystrybucjiinformacjiopartyjestobezpośredniąwymianęda-nychmiędzyzainfekowanymikomputerami -czylimodelkomunikacjiPeer-to-peer.Brakcentralnegowęzła zarządzającego w tym modelu powoduje,

iżznacznietrudniejjestznaleźćkomputerydystry-buującenowerozkazy,azablokowaniekanałuwy-mianydanychjestpraktycznieniemożliwe.Dobrzeilustrujetowykres8.3.2.Widać,iżwprzedstawio-nejsiecibrakjestcentralnegopunku(jednegoczyteżwielu),apołączeniamiędzykomputeramimającharakterlosowy.

Wykres 8.3.2. Wizualizacja sieci ZP2P (10 000 węzłów)

Mechanizm wymiany informacji przez siec Zeus-peer-to-peer (dalej ZP2P)

è

44



0 10000 20000 30000 40000 50000 60000

5%

4%

3%

2%

1%

0

Wykres 8.3.3. Rozkład numerów portów UDP w sieci ZP2P (800 000 próbek)

Jak działa sieć ZP2P?

Sieć ta najprawdopodobniej jest oparta na stan-dardzie protokołu Kademlia. Pojedynczy kom-puter (węzeł) w sieci ZP2P identyfikowany jest za pomocą unikalnego identyfikatora UID - którygenerowany jestpodczaspierwszegouruchomie-niazłośliwegooprogramowania.Każdyzkompute-równależącychdosieciZP2Pposiadawpamięci„tablicęsąsiadów”.Zawieraona listęok30pobli-skichwęzłówwsieciZP2P-ichidentyfikatorUID,adres IPoraznumerportuUDP.Lista ta jestwy-korzystywanadowymianydanychorazinformacji.

Wykresy8.3.3oraz8.3.4przedstawiająrozkładnu-merów portówwykorzystywanych do komunikacjiwsieciZP2P.

WsieciZP2Pmożemywyróżnićdwa rodzajeko-munikacji:● Wymiana informacji (z użyciem protokołu UDP):

► (QV) Wymiana informacji o posiadane

przez komputer wersji pliku konfiguracyj

nego

► (QN) Wymiana informacji o węzłach

znajdującychsięw„tablicysąsiadów”danego

komputera,

● Wymiana danych binarnych (z użyciem

protokółuTCP),

► Dystrybucjanowychplikówkonfiguracyjnych.

W przypadku komunikatu typu QN jednorazowoprzesyłanejesttylko10rekordówz„tablicysąsia-dów”. Ten rodzaj komunikacji służy uaktualnianiulokalnejtablicysąsiadówwsieciZP2P.Powykona-niuzapytaniaQNbotzapisujeinformacjeosąsied-nichwęzłach,którychidentyfikatorUIDjestzbliżo-ny do identyfikatora (w metrzce XOR) lokalnegokomputera.

45


0 5000 10000 15000 20000 25000 30000

5%

4%

3%

2%

1%

0

Wykres 8.3.4. Rozkład numerów portów TCP w sieci ZP2P (100 000 próbek)

Wykres 8.3.5. Rozkład liczby dzieci

30000

25000

2̀0000

15000

10000

5000

0

0 50 100 150 200

WprzypadkukomunikatutypuQNjednorazowoprzesyłanejesttylko10rekordówz„tablicysąsiadów”.TenrodzajkomunikacjisłużyuaktualnianiulokalnejtablicysąsiadówwsieciZP2P.Powykonaniuzapyta-niaQNbotzapisujeinformacjeosąsiednichwęzłach,którychidentyfikatorUIDjestzbliżonydoidentyfika-tora(wmetrzceXOR)lokalnegokomputera.

KomunikatytypuQVsłużąsprawdzeniuorazpro-pagacjiinformacjionowychwersjachplikówkonfi-guracyjnych.Jeżeliwęzeł,którywykonałzapytanieQVposiadawersjękonfiguracjistarsząniżwersjapodanawodpowiedzinatozapytanie,wykonaonpołączenie TCP do zdalnego komputera prosząc oprzesłanienowszejwersjikonfiguracji.

Wykresy 8.3.5 oraz 8.3.6 przedstawiają rozkładliczbydzieci i liczbyrodzicówwsieciZP2P.DanepochodzązanalizyodpowiedzibotównazapytaniatypuQNwprzeciągu3tygodni.Liczbydzieci(czyliliczbaróżnychwpisówwtablicysąsiedztwa)możeprzekraczaćwartość30,ponieważtablicasąsiedz-twaulegaćmożeczęstymaktualizacjom.

è


46



Wykres 8.3.6. Rozkład liczby rodziców

6e+05

5e+05

4e+05

3e+05

2e+05

1e+05

0

0 100 300200 500400 600

W laboratorium CERT Polska przeprowadziliśmy mapowaniesieciZP2Ppoprzezmonitorowanieod-

powiedzinakomunikaty typuQN.Zebranew tensposóbadresyIPnaniesionezostałynamapę.

Monitorowanie sieci ZP2P

Wykres 8.3.7. Rozkład adresów IP po mapowaniu sieci ZP2P

47



W przypadku botnetu ZeuS, parametrem dlamechanizmu DGA jest bieżąca data. Lista do-menzawiera1000pozycji i zmieniasięco7dni. Każdaznazwskładasięzciąguznakówodługościod32do48orazjednejzTLD:.ru,.com,.biz,.info,.net

lub.org.Wartozaznaczyć,iżwnazwieniewystępu-jeznak„-”.Poniżejznajdujesięwyrażenieregular-nepozwalającenawyszukaniedomenZeuSowych wlogach:[a-z0-9]{32,48}\.(ru|com|biz|info|org|net)

Jeżeli mechanizm komunikacji w sieci ZP2P zo-stanie zablokowany (np. poprzez zablokowanieodpowiednich portów TCP i UDP na firewallu) -botautomatycznieprzełączasięnazapasowyka-nał komunikacyjny - DGA. Mechanizm DGA jestkolejnym elementem zaimplementowanym w nowej wersji trojana, który znacznie utrudniaposzukiwania oraz odcięcie osoby zarządzają-cejbotnetem.Polegaonnagenerowaniupewnejdługiej listynazwdomenowychwoparciuookre-ślone parametry, a następnie próbie komunikacji

z każdą z wygenerowanych domen. ParametrymechanizmuDGA umieszczone sąw kodzie tro-jana - oraz znane tylko botmasterowi. Może onwłasnoręcznie wygenerować taką listę, wybrać z niej jedną pozycję - a następnie zarejestrowaćwybranądomenęiczekaćnapróbypołączeńzza-infekowanychkomputerów.

Mechanizm wymiany informacji przez sieć ZP2P

Jak rozpoznać infekcję nowym ZeuSem?

ZeuS-owe DGA

ObecnośćnowegowariantuZeuSanakomputerzemożnarozpoznaćprzedewszystkimpoprzezmo-nitorowanieruchusieciowego.Jakwidaćnarysun-ku8.3.8.,przyużyciunarzędziaTCPview(zpakie-tu SysInternals), można zauważyć nowe otwarteportyTCP iUDPprocesu explorer.exe.Dodatko-wo,abyumożliwićkomunikacjęzsieciąZP2P,tro-jandodajedosystemowegofirewallanowereguły. Jakwidaćnarysunku8.3.9.sątodwanowewyjątkipozwalające na nawiązywanie połączeń na okre-ślonych portach TCP i UDP. Zakres tych portówodczytaćmożnazwykresów8.3.2.i8.3.3.

Rysunek 8.3.9. Dodane wyjątki w konfiguracji systemowe-go firewalla

Rysunek 8.3.8. Otwarte porty TCP i UDP wykorzystywane do komunikacji P2P

48



8.4 Wygrałeś natychmiastową nagrodę

Typosquatting bazuje na omyłkowym wpisaniunazwy domeny, którą internauta chce odwiedzić. Jestzjawiskiemobecnymodkilkulat.Wrazzewzro-stempopularnościInternetu,rejestrowaniedomenonazwachnieznacznieróżniącychsięodpopular-nychstałosięcałkiemlukratywnymbiznesem.Możli-wościpopełnieniabłędupodczaswpisywaniaadre-suinternetowegojestbardzowiele,np.pominięcie

Wykres 8.4.1. Liczba możliwych literówek w funkcji długości nazwy domenowej

1600

1400

1200

1000

800

600

400

200

00 2 4 6 8 10

Długość nazwy domenowej

cert.pl

arakis.pl

dyzurnet.pl

ilość

podo

bnyc

h naz

w do

meno

wych

kropkilubpojedynczejlitery,wpisaniesąsiedniegoznakulubwpisaniedwukrotnietegosamegoznaku. Oczywiście wraz ze wzrostem długości dome-ny, szansa na popełnienie pomyłki wzrasta. Wykres 8.4.1 przedstawia liczbę możliwych literówek w funkcji długości nazwy domenowej.Przykładowodla domeny cert.plmożliwe jest za-pisanie341nazwzliterówką,dladomenyarakis.plliczbaliterówekwzrastado826,zaśwprzypadkudyzurnet.pljesttoaż1502.

Nazwy domenowe z literówkami zostały wyge-nerowane przy wykorzystaniu prostych podejść:zamiana znaku na znak sąsiadujący na klawia-turze, pominięcie znaku, dwukrotne wpisanietego samego znaku oraz zastosowanie dwóchwyżej wymienionych podejść jednocześnie. Uwzględnionojedynieunikalnedomeny.

Nastronietyposquattingowejmożnaspotkaćkilkarodzajówtreści:► witrynęzawierającąlinkireklamowe,► witrynękonkurencyjnegoproduktu,► witrynę podszywającą się pod oryginalny serwisiwyłudzającądanejegoużytkowników (phishing),► przekierowaniedooryginalnegoserwisu,► stronę innego produktu, nie związaną ztematykąoryginalnegoserwisu.

49



Rysunek 8.4.2. Wykorzystanie podobieństwa adresu è

Najczęściej spotykane są linki reklamowe (bądźprzekierowanie do strony zawierającej linki rekla-mowe).Wtakimwypadkuzyskiczerpanesąnaza-sadziepay-per-click(PPC)lubpay-per-visit(PPV).Abydochódzwyżejwymienionychprogramówbyłwiększyodponiesionychkosztów,osobytrudniącesiętyposquattingiemrejestrująwieledomen.Istnie-jąserwisyoferującecałąinfrastrukturęwymaganądoczerpaniazyskówzdomenz literówkami (do-mainparking,partnerskieprogramyreklamowe).

Szczególnieniebezpiecznesąstronypodszywają-ce się pod oryginalny serwis i wyłudzające danejego użytkowników (klasyczny phishing). W tymprzypadku cyberprzestępcy czerpią zyski bezpo-średnio wykorzystując uzyskane dane (np. danekartkredytowych,dane logowaniadobanku, itp.)bądźpoprzezichsprzedaż.

Częstospotykanejestprzekierowaniedooryginal-nego serwisu. Taki przypadekwynika zwykupie-niadomenyprzezoryginalnyserwisbądźzawarcieumowy z właścicielem strony typosqauttingowej.Dużeipopularneserwisyinternetowetworząpro-gramy partnerskie, ułatwiające nawiązanie kon-taktuwłaścicielomdomenopodobnychnazwach.Realizowanejesttobezpośredniolubprzypośred-nictwie agencji PR. W takim wypadku właścicielportalupłacizakażdeprzekierowanienieuważne-gointernautynajegostronę.

Ciekawym zjawiskiem, jakie można zaobserwo-wać począwszy od IV kwartału 2011 roku, byłopołączenie typosquattingu z płatnościami SMSPremium.Najczęściejwitryna,najakątrafiainter-

nauta, nie jest w jakikolwiek sposób powiązana zoryginalnąwitryną.Zawiera jednakpotencjalnieinteresujące treści, jak np. informacja o wygra-niu atrakcyjnej nagrody. Aby „uwiarygodnić się”w oczach internauty, takie strony często nawią-zują do witryn, których wizerunek wykorzystująpoprzez zastosowanie łudząco podobnego sza-blonu graficznego bądź kolorystyki, symboli gra-ficznychlubpodobieństwaadresu(rysunek8.4.2).

Takiepołączenie jestwyjątkowoskuteczne,wieleosóbnieświadomychzagrożeniawykonainstrukcjezawarte na poszczególnych witrynach. Osoby tebędąprzekonane,żenp.podanieswojegonumerutelefonuiodesłaniewiadomościtekstowejjestnie-szkodliwe, ponieważ cała komunikacja pochodzi z serwisu traktowanego przez nich jako zaufany.Dodatkowym czynnikiem motywującym jest chęćposiadaniamarkowego gadżetu.Otrzymane póź-niej wiadomości tekstowe są najczęściej trakto-wane jako wiadomości reklamowe, jakie bardzoczęstootrzymujemyodoperatorówtelefoniikomór-kowej(awięcrównieżniesątraktowanejakopo-dejrzane).TymczasemwysyłającwiadomośćSMSnaodpowiedninumerużytkownikwykupujeabona-ment,wramachktóregootrzymujeokreślonąlicz-bę informacji poprzez wiadomości Zwrotny SMSPremium. W przypadku wiadomości SMS Pre-mium,stosownaopłatanaliczanajestzawysłaniewiadomości. Natomiast w przypadku wiadomościtypuZwrotnySMSPremium,opłatanaliczanajestzakażdąotrzymanąwiadomość.Wysokośćopłatmożebyćróżna,szczegółoweopłatysąprzedsta-wionewtabeli8.4.3.

50



Numer SMS Zwrotny Cena netto Cena brutto (VAT 23%)

70xx(x) 0,5zł 0,62zł71xx(x) 1zł 1,23zł72xx(x) 2zł 2,46zł73xx(x) 3zł 3,76zł74xx(x) 4zł 4,92zł75xx(x) 5zł 6,15zł76xx(x) 6zł 7,38zł77xx(x) 7zł 8,61zł78xx(x) 8zł 9,84zł79xx(x) 9zł 11,07zł

8000-8099 bezpłatny bezpłatny80000-80999 bezpłatny bezpłatny81000-81099 0,10zł 0,12zł81500-81599 0,15zł 0,18zł82000-82099 0,20zł 0,24zł82000-82099 0,25zł 0,31zł83000-83099 0,30zł 0,37zł83500-83599 0,35zł 0,43zł84000-84099 0,40zł 0,49zł84500-84599 0,45zł 0,55zł85000-85099 0,50zł 0,62zł

910xx(x) 10zł 12,30zł911xx(x) 11zł 13,53zł912xx(x) 12zł 14,76zł913xx(x) 13zł 15,99zł914xx(x) 14zł 17,22zł915xx(x) 15zł 18,45zł916xx(x) 16zł 19,68zł917xx(x) 17zł 20,91zł918xx(x) 18zł 22,14zł919xx(x) 19zł 23,37zł921xx(x) 20zł 24,60zł925xx(x) 25zł 30,75zł

50100-50199 0,01zł 0,01zł50200-50299 0,02zł 0,02zł50300-50399 0,03zł 0,04zł50400-50499 0,04zł 0,05zł50500-50599 0,05zł 0,06zł50600-50699 0,06zł 0,07zł50700-50799 0,07zł 0,09zł50800-50899 0,08zł 0,10zł

Najczęściejdopieropootrzymaniurachunku,roz-poczyna się dociekanie źródła wysokich opłat.Ustalenieźródławysokiegorachunkuirezygnacjaz usługi abonamentowejmożepotrwaćnawet dokilkumiesięcy.

Połączenie cybersquattingu z typosquattingiemjestwyjątkowoniebezpiecznezpunktuwiedzeniainternauty.Podstawowąmetodąobronyjestuważ-ne wpisywanie adresów. Można również skorzy-staćzkomercyjnychrozwiązańoferowanychprzezproducentów oprogramowania antywirusowego. Dodatkowo można skorzystać z serwerów nazw

OpenDNS. Niestety często wykupywane są linkireklamowe,abydodatkowozwiększyćszansęod-wiedzenia „witrynykonkursowej”.Należywystrze-gaćsiępodawaniaswoichdanych(jaknp.numertelefonubądźadrese-mail)orazpoświęcićchwilę izapoznaćsięzregulaminem.

50900-50999 0,09zł 0,11zł51000-51099 0,10zł 0,12zł52000-52099 0,20zł 0,24zł53000-53099 0,30zł 0,37zł54000-54099 0,40zł 0,49zł55000-55099 0,50zł 0,62zł56000-56099 0,60zł 0,74zł57000-57099 0,70zł 0,86zł58000-58099 0,80zł 0,99zł59000-59099 0,90zł 1,11zł60100-60199 1zł 1,23zł60200-60299 2zł 2,46zł60300-60399 3zł 3,76zł60400-60499 4zł 4,92zł60500-60599 5zł 6,15zł60600-60699 6zł 7,38zł60700-60799 7zł 8,61zł60800-60899 8zł 9,84zł60900-60999 9zł 11,07zł61000-61099 10zł 12,30zł61100-61199 11zł 13,53zł61200-61299 12zł 14,76zł61300-61399 13zł 15,99zł61400-61499 14zł 17,22zł61500-61599 15zł 18,45zł61600-61699 16zł 19,68zł61700-61799 17zł 20,91zł61800-61899 18zł 22,14zł61900-61999 19zł 23,37zł62000-62099 20zł 24,60zł62100-62199 21zł 25,83zł62200-62299 22zł 27,06zł62300-62399 23zł 28,29zł62400-62499 24zł 29,52zł62500-62599 25zł 30,75zł

Podsumowanie

Tabela 8.4.3. Opłaty za zwrotny SMS Premium

51


9. Najciekawsze wydarzenia z działalności CERT Polska

CERTPolskajest obecny wserwisachspo ł e c zno -ściowycho d 2010 roku . Nasz pro f i l na Facebo-

okuśledzijużponad300użytkowników,natomiastkanały Twitter cert_polska i anglojęzyczny cert_polska_en stały się doskonałym uzupełnieniemobszernychwiadomościiraportówpublikowanychnastroniewww.cert.pl.W2011rokuumieściliśmypokilkasetkrótkichnotekwkażdymznich, infor-mując o istotnych podatnościach, ciekawostkachczy spektakularnych wydarzeniach. Cieszy nas, żewiele z nich spotyka się z żywym zaintereso-waniem i są cytowane także przez wpływowychblogerów. Co ciekawe, zdecydowanie większąpopularnością cieszy się kanał cert_polska_enprowadzony po angielsku. Jest on obserwowany

9.1 Społeczności CERT Polska

è

9.2 Konferencja SECURE 2011

przezprzeszło460użytkowników,ponaddwukrot-niewięcejniżwersjapolskojęzyczna.

Jesienią 2011 nasza obecność w mediach spo-łecznościowychzostałarozszerzonatakżeoprofilkonferencjiSECUREnaportaluFacebook.Publi-kujemytaminformacjepraktycznezwiązanezkon-ferencją, odnośniki doartykułów, zdjęcia, a takżewybraneprezentacje.Porazpierwszyprzeprowa-dziliśmytakżekonkursdlafanówprofilu,wktórymmożnabyłozdobyćbezpłatnezaproszenienakon-ferencję.

Zapraszamydodołączeniaorazdokontaktuidys-kusjiznaminałamachtychserwisów.

http://fb.com/CERT.Polska http://twitter.com/cert_polskahttp://twitter.com/cert_polska_en http://fb.com/Konferencja.SECURE

Konferencja SECURE 2011, która odbyła się w dniach 24-26 października 2011 r., była wyjąt-kowa pod wieloma względami. Pierwszego dniaudostępnione zostały aż czterywarsztatyHands--on,cobyło rezultatembardzowysokiegozainte-resowaniatakąformąudziałuwpoprzedniejedycji.DwaznichprowadzonebyłyprzezCERTPolska.Takżeprogramkonferencjibyłbardzobogaty.

Wśród najlepiej ocenionych prelegentów znaleź-li się Raoul Chiesa, który w prezentacji „Cyber Weapons in 2011:An F16 Just FlewOver a 1stWorldWarBattlefield”opowiadałotym, jakzmie-niłysięukładysiłwobliczucyberkonfilktówatakżeDick Hardt - współautor specyfikacji OpenID 2.0 i OAuth 2.0 oraz ekspert od tożsamości online i Piotr Konieczny - założyciel i właściciel portaluniebezpiecznik.pl,nacodzieńzajmującysięszko-leniamizdziedzinybezpieczeństwa.

Wsumiegościliśmy38prelegentów,którzywygło-siliłącznie33prezentacje,przezwiększośćczasupodzielone na trzy równoległe sesje. W sesjachplenarnych wystąpili między innymi Brian Krebs

52


W grudniu 2011 roku Europejska Agencja ds. Bezpieczeństwa Sieci i Informacji (ENISA)opublikowała przygotowany przez CERT Polskaraport dotyczący metod wykrywania sieciowychincydentówbezpieczeństwa-„Proactivedetection ofnetworksecurityincidents”.

Proaktywnewykrywanieincydentówtoprocesod-najdywania złośliwej aktywności w sieci, za któ-rą danyCERT jest odpowiedzialny, przy pomocynarzędzi monitorujących lub z wykorzystaniemzewnętrznych usług dostarczających informacje o wykrytych incydentach, jeszcze zanim właści-cieleatakowanychsiecistanąsię tegoświadomi.Zwiększenieefektywnościtychdziałańjestfunda-

9.3 Raport CERT Polska dla ENISA „Proactive Detection of Network Security Incidents”


-znanybloger,byłydziennikarzśledczyTheWa-shington Post oraz Ryan Seu z zespołu bezpie-czeństwaportaluFacebook.Gościemspecjalnymkonferencji byłRobertKorzeniowski -wielokrotnymistrzświata,mistrzEuropyorazmistrzolimpijskiwchodziesportowym,któryopowiedziałozwiąz-kach odpowiedzialności i rozliczalności sportow-cówzadopingzeświatemonline.

Niemniej interesujące okazały się prezentacje w sesjach równoległych. Mocnym akcentem byłyprezentacje dotyczące zagrożeń przedsiębiorstw,w tym atakówAPT, o których mówił m.in. GavinReidzCiscoSystemsczyWojciechLedzioniMar-cinSiedlarzzrządowegozespołuCERT.GOV.PL.W tym samym czasie techniczne tematy zdomi-nowaneprzezzłośliweoprogramowanieporusza-liTomaszBukowski iTomaszSałaciński zCERTPolska.Poobiedziejednazsesjipoświęconabyław całości zagadnieniom prawnym. Na niej obokAleksandraGacka iMacieja Kołodzieja z portaluspołecznościowegonk.plpojawilisięMichałKluskaiGrzegorzWaniozkancelariiOlesińskiiWspólni-cy. Ci ostatni przedstawili błyskotliwy pomysł naściganie przestępstw popełnianych na blogach i forachwwarunkachpolskiegosystemuprawne-go. Drugiego dnia można było wybierać międzyprezentacjami o bezpieczeństwie VoIP (Sandro

Gauci i JoffreyCzarny) i tymi oobecnych i przy-szłychnarzędziacharmiiiagencjiwywiadu(MichałMłotek i wspomniany wcześniej Raoul Chiesa). Nie zabrakło także prezentacji CERT Polska - Paweł Krześniak opowiadał o wykorzystaniu pa-sywnychdanychzsystemówDNSdoanalizyza-grożeń.

Podobniejakwubiegłymroku,podkoniecdrugie-go dnia oddaliśmy głos uczestnikom konferencji,dająckażdemuokazjędowygłoszeniakrótkiejpre-zentacji„lightningtalk”.Mieliśmydziękitemuoka-zjędoposłuchaniakolejnychośmiudynamicznychibardzozróżnicowanychprelekcji.

Uczestnicy konferencji pozytywnie ocenili bogac-twotematów,atakżeunikatoweprezentacje,spo-śród których wiele zawierało opisy konkretnych,rzeczywistychprzypadków.

Konferencjitowarzyszyłaimprezawieczornawre-stauracjiVapiano, która zapewniła okazję do luź-niejszychrozmów,nawiązaniakontaktów,a takżenabyciasprawnościwewłasnoręcznymprzygoto-wywaniupizzyimakaronu.

mentemprężnegofunkcjonowaniazespołówCERTizwiększeniaichmożliwościobsługiincydentów.

W dokumencie dokonano analizy sposobów, w jaki CERTy, w szczególności narodowe i rzą-dowe, wykrywają incydenty w swoich obszarachdziałalności. Raport zawiera również zestaw naj-lepszychpraktykiużytecznychnarzędzidlanowopowstałych zespołów typu CERT, analizę proble-mówjakimmusząstawićczołaizestawrekomen-dacji dla usprawnienia obsługi incydentów przezzespołyCERT.

Istotnymw tym opracowaniu jest fakt, żew jegopowstanie zaangażowani byli praktycy głównie

53


v

è

Wykres 9.3.1. Właściwości źródeł danych o incydentach, które według zespołów reagujących wymagają poprawy

16

14

12

10

8

6

4

2

0

Dokładność

Pokrycie

Aktualność

Łatwość użycia

Nakład środków

Dokładność Pokrycie Aktualność Łatwość użycia Nakład Srodków


z europejskich zespołów CERT i uznani eksper-ci z dziedziny bezpieczeństwa.Raport opiera się na gruntownym badaniu ankietowym przeprowa-dzonympośród45zespołówCERToraztoczącejsięprzezcałyczastworzeniadokumentudyskusjiekspertów. Ichznacznywkład,obokdoświadcze-niaipracyautorów,pozwoliłnastworzeniewyczer-pującejpublikacjioobsłudzeincydentówprzezze-społyCERT.

W raporcie można znaleźć oceny i opisy ze-wnętrznych źródeł informacji o incydentach orazwewnętrznychnarzędzimonitorujących,zktórychCERTymogąkorzystać,abyzwiększyćswojemoż-liwościdetekcji incydentówbezpieczeństwawco-dziennejdziałalności.

Podczas zbierania materiału do raportu zostałozidentyfikowanychiprzeanalizowanych16poważ-nych przeszkód w procesie wykrywania incyden-tów dotyczących zarówno kwestii technicznych, jak i prawno-organizacyjnych. Pośród przeszkódtechnicznych najczęściej wymieniane były słabajakośćdanych,brakautomatyzacjiwichprzetwa- rzaniu i korelacji. W kwestiach prawnych proble-memsąregulacjedotycząceprywatnościiochronydanychosobowych,któreuniemożliwiająwymianędanych.Dlakażdegozezidentyfikowanychproble-mówzaproponowanyzostałszeregpotencjalnychrozwiązań i rekomendacji dla podmiotów dostar-czającychdaneo incydentach,dla ichodbiorców idlaorganizacjieuropejskichlubkrajowych.

54


Wyniki opublikowanego raportu pomogą zarównonowopowstałym, jak i już istniejącym zespołomCERTznaleźćiskorzystaćzwcześniejnieużywa-nych, a wartych uwagi źródeł informacji, a takżerozważyć wykorzystanie dodatkowych narzędzi wswojej organizacji.Usprawnienie proaktywnegowykrywaniaiprzetwarzaniadanychoincydentach wpływa na sprawność funkcjonowania nie tylkopojedynczegoCERTu,alerównieżwszystkich,któ-rychdanetedotyczą.Tozkoleipozwalazacieśniaćwspółpracęiwymianęinformacjipomiędzyzespo-

łamiCERT,któredużoszybciejsąwstaniereago-wać i rozwiązywać problemy zwiększając bezpie-czeństwoInternetu.

Popełnąinformacjęodsyłamydoraportunastronie:http://www.enisa.europa.eu/act/cert/support/proactive-detectionoraz do wyników badania przeprowadzonegowśródzespołówCERT:http://www.enisa.europa.eu/act/cert/support/proactive-detection/survey-analysis

4%

49%47%

Jesteśmy w pełni usatysfakcjonowani z posiadanych źródeł informacji

Chętnie rozważymy wykorzystanie innych źródeł

Odczuwamy deficyt informacji - jest wiele incydentów, o których nie wiemy

Mamy za dużo źródeł informacji

Wykres 9.3.2. Opinie zespołów CERT dotyczące zadowolenia ze źródeł informacji z obszaru ich działania

Pod koniec 2010roku CERT Polskaprzystąpił do ini-cjatywy Anti-Phi-

shingWorkingGroup. Jest to forum dla podmio-tów zajmujących się zwalczaniemprzestępczościelektronicznej, ze szczególnym uwzględnieniemwyłudzaniadanych.WramachAPWGaktywnesązarównojednostkinaukowo-badawczeczyzespo-łyreagującetypuCERT,jakiwielepodmiotówko-mercyjnych,wszczególnościproducentówkomer-cyjnych systemów filtrowania ruchu, antywirusówitp. Zewnętrzne celeAPWG to przedewszystkim

9.4 CERT Polska dołącza do APWG

analiza trendówzagrożeńorazedukacja-zarów-no decydentów stanowiących o prawie czy regu-lacjach (np. w zakresie rejestracji domen), jak ikońcowychżytkowników.Dobrymprzykłademjestrealizowana w Stanach Zjednoczonych wspólnie zNCSAkampania„STOP.THINK.CONNECT”.Niedasięukryć,żedlawszystkichczłonkówAPWGconajmniejrównieważnymcelemjestnawiązywaniekontaktóworazstaławymianawiedzy,którejsprzy-ja połączenie środowiska akademickiego, teleko-munikacyjnego ikomercyjnego.CERTPolskamawAPWGstatus„researchmember”.


55


O rgan izac ja The HoneynetProject zrze-sza ekspertówz różnych do-

menbezpieczeństwakomputerowego iumożliwiaimłatwąwymianęwiedzyorazwspólnetworzenierozwiązań, których celem jest poprawa bezpie-czeństwaużytkowników Internetu.Udziałworga-nizacji opiera się na wolontariacie - poświęceniuwłasnego wolnego czasu na analizę i rozpozna-wanienowychzagrożeń, tworzenienarzędzi,ma-teriałów edukacyjnych oraz udział w dyskusjach. Odmomentupowstaniaw1999jestjednaznajle-piejrozpoznawanychorganizacjiwmiędzynarodo-wymśrodowiskusecurity.

EkspercizrzeszeniwTheHoneynetProjectpodej-mująwspólnywysiłekmającynaceluwzbogaca-nie istniejącejwiedzyo zagrożeniach imetodachjakichmożnaużyć,abyjezwalczać.Owocemichprac jest zbiór blisko trzydziestu artykułów no-szących wspólny tytuł „Know Your Enemy” („Po-znaj swojego wroga”). Seria opisuje zagadnieniatakie, jak śledzenie botnetów, przedstawia ar-chitektury honeypotów i możliwości ich zastoso-wania, opisuje zagrożenia typu phishing, robakiinternetowe, złośliwe stronyWWWorazwiele in-nych. Odbiorcami artykułów są najczęściej eks-perci codziennie stykający się z zagadnieniamibezpieczeństwa komputerowego, jednakże bar-dziej zaawansowani użytkownicy także znajdą wnichbogateźródłoinformacji.

Dynamiczny charakter zagrożeń, z jakimi eks-perci bezpieczeństwa stykają się na co dzieńwymaga, aby ciągle doskonalili swoje umiejęt-ności związane z ich rozpoznawaniem i ich ana-

9.5 Publiczne wydanie Capture-HPC w ramach Honeynet Project

è


W2011 rokuCERTPolskawziąłudziałwdwóchspotkaniachorganizowanychprzezAPWG-eCri-me Researchers Sync Up w marcu w Dublinie oraz eCrime Research Summit w listopadzie wSanJose,wKalifornii.Natejostatniejkonferencji

Przemysław Jaroszewski zaprezentował studiumprzypadkuinfekcjiZeusemmobilnym(ZITMO).

Więcej informacji oAnti-PhishingWorking Groupmożna znaleźć na stronie http://www.apwg.org/.

lizą.Najlepsządrogądoosiągnięcia tegocelusąpraktycznećwiczenia.TheHoneynetProjectudo-stępniazbiórzaawansowanychzadań,dziękiktó-rym każdymoże sprawdzić swoje siły w analiziezagrożeńtakichjakzłośliweplikiPDF,zagrożeniazwiązanezVoIP,analiza zwykorzystaniem tech-nik reverse-engineeringorazwiele innych.Każde zzadańbazujenarzeczywistymprzypadkuataku,który został wnikliwie zbadany przez ekspertów. Podsumowanie zadaniawskazuje kroki, jakiena-leżało podjąć w celu wykrycia ataku oraz przed-stawia przykładowe narzędzia pomocne w jegoanalizie. Dodatkowym atutem udziału w zadaniu, któremaformękonkursu,sądrobnenagrodyfun-dowaneprzezorganizatorów.

Wiedza, jaką gromadzi organizacja, ma bezpo-średnieprzełożeniewpostacinarzędzitworzonychprzezjejczłonków.Wchwiliobecnejzbiórprojek-tów prowadzonych przez The Honeynet Projectprzekracza20.Zewzględuna to,że jest todzia-łalność non-profit, a jedynym źródłem, z jakiegomożesięutrzymywać,sądotacje,narzędziajakiepowstają,sąowocempracwolontariuszylubczę-ściami większych projektów prowadzonych przezniezależnejednostki,którezgodziłysięjeupublicz-nić.Od kilku latTheHoneynetProject jest takżeaktywnymczłonkiemprogramuGoogleSummerofCode,umożliwiającegostudentomzcałegoświatapracęnadtworzeniemnarzędziopensource.Dzię-ki tego typu inicjatywom powstały nowe, a takżezostały rozwinięte już istniejąceprojekty,któresąpodopiekąorganizacji.

The Honeynet Project jest organizacją między-narodową,składającąsięzponad40kapituł roz-sianych po całym globie.W Polsce od listopada2011roku,dziękizaangażowaniuczłonkówCERT

56


W kwietniu 2011 rokuzakończył się projektWOMBAT - WorldwideObservatory of Mali-cious Behaviour andAttack Threats. Projekt

wystartowałwstyczniu2008rokuwramach7.Pro-gramu Ramowego Unii Europejskiej. Celem pro-jektuWOMBATbyłoutworzenieplatformysystemumonitorowania i analizy zagrożeń internetowych, wszczególnościzłośliwegooprogramowania,którewostatnichlatachstałosiępotężnymnarzędziemw rękach cyberprzestępców. Obok NASK w pro-jekcie brali udział specjaliści ds. bezpieczeństwa zfirmtakichjak:FranceTelecomR&D,Symantec,Hispasec Sistemas (twórcy projektu Virustotal)orazinstytucjinaukowo-badawczych:InstitutEure-com,FORTH,PolitecnicodiMilano,TechnicalUni-versityVienna,VrijeiUniversiteitAmsterdam.Pra-ceprojektowebyłykierowaneprzezzespółCERTPolskaprzywspółpracyDziałuNaukowegoNASK.

9.6 Zakończenie projektu WOMBAT


Polska,działaPolskaKapitułaTheHoneynetPro-ject. W skład kapituły wchodzi grupa ekspertówz CERT Polska, dodatkowo wspieranych przezekspertówzZespołuMetodBezpieczeństwaSie-ci i Informacji działającego w Pionie NaukowymNASK. Misją kapituły jest propagowanie wiedzyo zagrożeniach napotykanych we współczesnejsieci Internet oraz tworzenie narzędzi wspoma-gających wykrywanie i analizę ataków. Dotych-czasowym wkładem w rozwój organizacji jeststworzenie nowszej i stabilniejszej wersji wysoko -interaktywnego klienckiego Honeypota Capture -HPC.PracezostaływykonanewramachrozwojuprojektuHoneySpiderNetwork-wspólnegoprzed-sięwzięciazespołówCERTPolska,GOVCERT.NLorazSURFnet.Autoremoryginalnegooprogramo-waniajestChristianSeifert,amodyfikacjezostaływprowadzoneprzezDziałRozwojuOprogramowa-nia NASK. Capture-HPC z projektu HoneySpiderNetworktonowawersja,którawprowadzaszereg

ulepszeń oraz pozwala na zastosowaniemaszynwirtualnychVirtualBoxorazKVM(oryginałopierałsięnaVMware).Oprogramowaniezostałoustabi-lizowane oraz udostępnione na licencji GPL 2.0.Kodźródłowyhoneypotaoraz instrukcje instalacji iużytkowaniamożnapobraćzestronykapituły.

Kapitułaliczyośmiuczłonków,główniezaangażo-wanych w rozwój projektów związanych z wyko-rzystaniemtechnologiihoneypotówdowykrywania ianalizyróżnegorodzajuataków.EkspercizCERTPolskaprowadzątakżewieleszkoleńikursówprzy-bliżających zagadnienia związane z bezpieczeń-stwem w sieci Internet. Więcej informacji o misjiPolskiejKapitułyTheHoneynetProjectdostępnychjest na stronach internetowych http://cert.pl oraz http://pl.honeynet.org. Wszystkich zainteresowa-nych rozwojem kapituły oraz narzędziami, jakieudostępniamy, zapraszamy do kontaktowania się[email protected].

Pracew projekcie były prowadzonewokół trzechróżnychobszarów:■ zbieraniainformacjiozłośliwymoprogramowa- niu za pomocą crawlerów i honeypotów (wtymudoskonalaniatychtechnikizapropo- nowanienowych),■ rozwojemnowychtechnikwzbogacaniazbie- ranychinformacji,■ zaawansowana analiza zagrożeń, na podstawie korelacji informacji od partnerów projektu w celu identyfikacji przyczyn i zrozu- mieniacharakterystykizjawiska.

Stworzono WAPI (WOMBAT API), który w łatwy iprzystępnysposóbumożliwiadostępdodanychz wielu systemu uczestniczących i rozwijanych wramachprojektu(m.in.Virustotal,SGNET,She-lia, Wepawet, HoneySpider Network, HARMUR,Anubis).KodWAPIzostałudostępnionynalicencjiBSD: http://sourceforge.net/projects/wombat-api/.Kodjeststaleudoskonalany.

57


Projekt FISHAto przedsięwzię-cie, w ramach

którego opracowano prototyp europejskiego sys-temuwymiany informacjiobezpieczeństwiekom-puterowym oraz ostrzegania przed zagrożeniamipojawiającymi sięw Internecie - EISAS (Europe-anInformationSharingandAlertingSystem).Pro-jekt był realizowanyw latach 2009 − 2011w ra-machprogramuKomisjiEuropejskiej „Prevention,Preparedness and Consequence Management ofTerrorismandotherSecurityRelatedRisks”wewspółpracy pomiędzy CERT Polska, węgierskimzespołemCERT(CERT-Hungary)orazniemieckiminstytutem badawczym Internet Security Centre zUniwersytetuGelsenkirchen.

Nadrzędnym celem projektu jest wzrost świado-mości w kwestii bezpieczeństwa on-line wśródużytkowników oraz kadry pracowniczej sekto-ra małych i średnich przedsiębiorstw. Skupieniesię na tych grupach wynika z faktu, że poprzezswoją liczebność odgrywają one kluczową rolę

wbezpieczeństwie Internetu,będąc jednocześniełatwymcelematakówzpowoduniskiejznajomościzagadnieńbezpieczeństwa.

Wramachprojektuprowadzonozarównodziałaniatechniczne,mającenaceluwytworzenieplatformydowymianyirozgłaszaniainformacji, jakidziała-nia polegające na opracowaniu sposobów dotar-cia z przystępną informacjądogrupdocelowych.Owocemwspółpracykonsorcjumjestprototypmo-delowego portalu internetowego oraz autorskiejimplementacji sieci P2P do wymiany informacjipomiędzypodmiotamizkrajówczłonkowskichUniiEuropejskiej,atakżeplankomunikacjizodbiorca-mi.

StworzonywramachFISHAprototypsystemubę-dziebaządokontynuacji pracwpostaci projektuNISHA(NetworkforInformationSharingandAler-ting)w latach2012-2014przez trzechdotychcza-sowychpartneróworazprzeznowegoczłonkakon-sorcjum-fundacjęFCCN(FoundationforNationalScientificComputing)zPortugalii.

9.7 Zakończenie projektu FISHA, przygotowania do projektu NISHA


WkładNASKwprojektdotyczył:● przeprowadzeniaanalizyobecnegostanurze- czy oraz sporządzenia założeń dla środo- wiskaWOMBAT,● pracęnadwspólnymAPI(WAPI),● udoskonalenia i rozwoju systemu klienckich honeypotów-HoneySpiderNetwork,● opracowania narzędzia w oparciu o techniki maszyn uczących się w celu redukcji fał- szywychalarmówdlasystemuCapture-HPC,● opracowanianarzędziadowizualizacji iana- lizypowiązańpomiędzywykrytymizłośliwymi adresamiURL.

Ponadtoniektóre instancje systemuHoneySpiderNetworkzasilałynowopowstaływramachprojektusystemwykrywaniazagrożeńFIRE(FIndingRogueNetworks):http://maliciousnetworks.org/.

Poza rozwojem i opracowaniem narzędzi i sys-temów przez partnerów projektu, przeprowadzo-no również wiele prezentacji na temat osiągnięćprojektu na konferencjach naukowych (np.RAID,DIMVA) i technicznych(np.BlackHat,FIRST,Ho-neynet ProjectWorkshop).Dokumentację projek-tową zamieszczononaoficjalnej stronie projektu: http://www.wombat-project.eu.

58


Raport roczny 2011

System ARAKIS (AgRegacja, Analiza i Klasyfi-kacja Incydentów Sieciowych) jest projektem ze-społu CERT Polska działającego w strukturachNASK. System rozwijany jest we współpracy zDziałemRozwojuOprogramowaniaorazzDziałem Naukowym NASK. Jego głównym zadaniem jestwykrywanieiopisywaniezagrożeńwystępujących wsieci napodstawieagregacji i korelacji danychzróżnychźródeł,wtymrozproszonejsiecihoney-potów(pułapek),darknetu,firewalliorazsystemówantywirusowych. W przypadku podstawowegoźródła danych - honeypotów - system bazuje nadanych pozyskanych z ruchu nieprodukcyjnego. W związku z tym nie jest możliwe wykrywanie i analizowanie ataków precyzyjnych wycelowa-nych jedyniew serweryprodukcyjne (np.DDoS). ARAKIS sprawdza się natomiast w analizowa-niu zagrożeń (głównie automatycznych) propa-gujących się poprzez aktywne skanowanie sieci (wtakimprzypadkujestdużaszansa,żezostanienawiązane połączenie do honeypota), np. robakisieciowe.

Szczególną implementacją systemuARAKIS jestprojekt ARAKIS-GOV wykorzystywany do ochro-ny zasobów teleinformatycznych administracjipublicznej. Jest on obecnie wdrożonyw siedem-dziesięciupięciuinstytucjachadministracjipublicz-nejwewspółpracyzpolskimCERTemrządowym

CERT.GOV.PLdziałającymwstrukturachDeparta-mentuBezpieczeństwaTeleinformatycznegoABW.

Niniejsze roczne podsumowanie jest czwartymtego typu.Głównym celem systemu jest ochronazasobówsieciowychuczestnikówprojektupoprzezwykrywanieźródeł infekcjibędącejwewczesnymstadium. Dzięki pozyskanym informacjom możli-we było również poznanie mechanizmów działa-nia zarówno nowych jak i aktualnych ataków naaplikacjeserwerowe.ProjektARAKISbyłprezen-towany na wielu krajowych i międzynarodowychkonferencjach poświęconych bezpieczeństwu IT.Wielokrotniebył takżewymienianyprzezpolskichi zagranicznych naukowców oraz specjalistów odbezpieczeństwaITwichpublikacjach.

W raporcie zamieszczono m.in. statystyki do-tyczące alarmów generowanych przez system. Sąonekluczowezpunktuwidzeniaobsługisyste-mu, ponieważ zawiadamiają operatorów opisując-zależnieodswojegotypuipriorytetu-zagrożenia i zdarzenia mające znamiona incydentu związa-nego z naruszeniem bezpieczeństwa sieciowe-go. Inne statystyki dotyczą źródeł oraz rodzajówzagrożeń. Ponadto opisano kilka interesującychprzypadkówobserwacjidokonanychprzezsystemARAKIS.

Wstęp

ARAKIS - Raport roczny 2011

59


W roku 2011 w systemieARAKIS zostało wyge-nerowanych 21 307 alarmów - jest to o ponad 6 000 mniej niż w roku 2010. Spadek spowo-dowany był m.in. ogólnoświatowym trendemzwiązanym z odchodzeniem cyberprzestępców od ataków propagujących się przez skanowaniena korzyść atakowania aplikacji klienckich (prze-glądarek internetowych, czytników PDF, itd.),oraz precyzyjnych i ukierunkowanych ataków nawcześniejrozpoznanecele.Wykres1.1przed-stawiarocznezestawieniewszystkichalarmówbezpodziałunatypy.

Największą liczbę alarmów odnotowano głównie w miesiącach wakacyjnych. Złożyły się na nieprzede wszystkim alarmy o priorytecie niskimzwiązanezewzrostem trenduanomalnego ruchuna poszczególnych portach. Alarmy te dotyczyłyzdarzeńpochodzącychzsieciInternet(niebyłytoinfekcje stacji roboczych uczestników systemu). Nagłyitymczasowywzrostliczbyalarmówwmar-cu związany był z problemami z łączem między

sondamiacentrum(alarmydiagnostycznesąpo-wiązanezestatusemsond)iniedotyczyłzdarzeńzwiązanychzbezpieczeństwem.

Znaczna większość wygenerowanych alarmów w roku 2011 miała niski priorytet (72%). Alarmy o niskim priorytecie świadczą zazwyczaj o ano-maliachw ruchu i nie są bezpośrednio związane zincydentami.Następnewkolejnościbyłyalarmy opriorytecieśrednim(12%)orazteopisującestanposzczególnychsond.Najmniejbyłoalarmówopisu-jącychwykryciepoważnychzagrożeńwsieci(6%). Wstosunkudozeszłorocznegozestawieniawidaćwyraźny wzrost procentowych udziałów alarmów owysokiminiskimpriorytecie.Należyjednakwy-raźniezaznaczyć,żeznacznawiększośćalarmówowysokimpriorytecie,którewystąpiływroku2011,nie oznaczała rzeczywistego ataku bądź infekcji, a jedynie wynikała ze specyficznej konfiguracjiurządzeńsieciowych,użyciapewnychprotokołówbądźnarzędzidoaktywnegomonitoringusieci.

1. Statystyki dotyczące alarmów


è

2 600 2 500 2 400 2 300 2 200 2 100 2 000 1 900 1 800 1 700 1 600 1 500 1 400 1 300 1 200 1 100 1 000

900 800 700 600 500 400 300 200 100

0 styczeń luty marzec kwiecień maj czerwiec lipiec sierpień wrzesień październik listopad grudzień

1 5501 585

2 179

2 4322 400

1 5921 757

1 809

1 3941 547 1 540

1 582

Wykres 1.1. Alarmy wygenerowane przez system ARAKIS w roku 2011

60


priorytet średni

priorytet niski

priorytet wysoki

status sond72%

10% 6%12%

Wykres 1.2. Rozkład procentowy alarmów ze względu na priorytety w roku 2011 Poniżejznajdująsięwykresyporównującealarmyzostatnich4lat:


Wykres 1.3. Liczba wszystkich alarmów

Wykres 1.4. Alarmy systemu ARAKIS

30000

25000

20000

15000

10000

5000

0

11335

21307

15341

27580

2008 2009 2010 2011

18000

16000

14000

12000

10000

8000

6000

4000

2000

0priorytet wysoki priorytet średni priorytet niski status sond

2008

2009

2010

2011

61



Jednązważniejszychkategoriizwiązanychzata-kamiwykrywanymiprzezhoneypotysystemuARA-KISjestskanowanieportów.RankingprzedstawialiczbęunikalnychwskalicałegorokuadresówIP,które próbowały łączyć się na poszczególne por-ty.Obrazuje tobezpośrednioskalęzainteresowa-niakonkretnymiportami(awięcusługamisłucha-jącymi na nich) przez złośliwe oprogramowaniebądźnarzędziatypuskanerybezpieczeństwa.Napierwszymmiejscuznajdujesięport445/TCP.Nanimnasłuchujewieleaplikacjizwiązanychzopro-gramowaniem Microsoft, które miało wiele efek-townychlukwykorzystywanychprzeztakierobaki,jakSasserczyConficker.Ciekawostkąjestdrugie

i czwarte miejsce, na którym znajdują się portyzwiązaneznatywnymidlasystemówUnixusługa-mi:telnetiSSH.

Innym ciekawym zestawieniem wydają się byćstatystykiTop10najczęściejdopasowanychregułsystemuSnort.Wtymprzypadkutakżewyznacz-nikiembyły unikalnew skali roku źródłowe adre-syIP.Prawiewszystkieregułypozajednądotycząataków na usługi windowsowe. Pierwsze trzy re-guły dotyczą połączenia RDP na port 3389/TCP(używanyjestprzezusługę„zdalnypulpit”)imogąbyćpowiązanezrobakiemMorto,którypojawiłsię wroku2011.

2. Statystyki dotyczące ataków

Tabela 2.1. Najczęściej atakowane porty

Pozycja Docelowy port/protokół

LiczbawidzianychunikalnychIP Opis

1 445/TCP 79 925 AtakitypubufferoverflownausługiWindowsRPC

2 23/TCP 56 908 Atakinausługętelnet

3 135/TCP 18 799 AtakinausługęWindowsDCE/RPC

4 22/TCP 15 665 AtakisłownikowenaserwerySSH

5 139/TCP 11 273 AtakinausługęNetBIOS/współdzielenieplików idrukarek

6 1433/TCP 9 125 AtakinaMSSQL

7 80/TCP 7 677 Atakinaaplikacjewebowe

8 3389/TCP 6 798 AtakisłownikowenaRDP(zdalnypulpit) -wdużejmierzeaktywnośćrobakaMorto

9 5060/UDP 3 375 AtakinaVoIP

10 4899/TCP 3 010 AtakinausługęRadmin

è

62



Pozycja Kraj Liczbaunikalnych adresówIP

1 US 19 313

2 RU 18 317

3 TR 16 102

4 KR 13 384

5 CN 11 866

6 PL 9 015

7 TW 8 450

8 UA 8 358

9 AE 7 873

10 DE 7 790

Pozycja Kraj Liczbapołączeń

1 CN 2 149 387

2 US 1 641 497

3 RU 631 184

4 UA 450 243

5 KR 432 089

6 TR 418 869

7 PL 386 186

8 DE 323 129

9 TW 207 125

10 GB 195 262

Pozycja RegułaSnort Liczba unikalnychIP

1 ETPOLICYRDPconnectionrequest 85 994

2 MISCMSTerminalserverrequest 80 910

3 ETPOLICYRadminRemoteControlSessionSetupInitiate 77 748

4 ETSCANDCERPCrpcmgmtifidsUnauthenticatedBIND 48 450

5 ATTACK-RESPONSESMicrosoftcmd.exebanner 24 480

6 ETATTACK_RESPONSEPossibleMSCMDShellopenedonlocalsystem 22 487

7 ETPOLICYSuspiciousinboundtoMSSQLport1433 21 485

8 NETBIOSSMB-DSIPC$unicodeshareaccess 20 183

9 ETSCANPotentialSSHScan 16 617

10 ETEXPLOITLSAexploit 16 479

Rozpatrując statystyki geograficznych lokaliza-cji źródeł ataków otrzymujemy ciekawe zestawie-nie: w kontekście unikalnych adresów IP na pierw-szymmiejscusąUSA,nadrugimRosja,na trzecim Turcja, a Chiny dopiero na piątym. Jeżeli nato-

miast rozpatrzona zostanie sama liczba połączeń,bez kontekstu unikalnego adresu IP, na pierwszymmiejscu znajdą się Chiny, a następnie USA i Ro-sja. Wynika stąd, że najwięcej ataków jest z Chin, alepochodząonezestosunkowoniewieluadresówIP.

Zestawienienajbardziejzainfekowanychsystemówautonomicznychujawnia,żenajwięcejunikalnychw skali roku źródłowych adresów IP pochodziło zsiecitureckiegooperatoraTurkTelekomunikasy-onAnonimSirketi(numerAS:9121).

NadrugimmiejscuznajdujesięsiećkoreańskiegoISPKoreaTelecom(AS:4766),anatrzecimEmi-ratesTelecommunicationsCorporation(AS:5384)zeZjednoczonychEmiratówArabskich.

Tabela 2.2. Najczęściej dopasowywane reguły Snort

Tabela 2.3. Najbardziej zainfekowane kraje pod względem unikalnych adresów IP

Tabela 2.4. Najbardziej zainfekowane kraje pod względem liczby przepływów

63



Pozycja LiczbaunikalnychadresówIP NumerAS Kraj Nazwaoperatora

1 12 416 AS9121 TR TTNETTurkTelekomunikasyonAnonim Sirketi

2 10 406 AS4766 KR KIXS-AS-KRKoreaTelecom

3 7 841 AS5384 AE EMIRATES-INTERNETEmirates TelecommunicationsCorporation

4 6 767 AS12741 PL INTERNETIA-ASNetiaSA

5 6 174 AS3462 TW HINETDataCommunicationBusiness Group

6 5 767 AS4134 CN CHINANET-BACKBONENo.31,Jin-rongStreet

7 4 632 AS6147 PE TelefonicadelPeruS.A.A.

8 2 862 AS8452 EG TE-ASTE-AS

9 2 845 AS24863 EG LINKdotNET-AS

10 2 602 AS5483 HU HTC-ASMagyarTelekomplc.

Pozycja Liczbapołączeń NumerAS Kraj Nazwaoperatora

1 983 239 AS4134 CN CHINANET-BACKBONENo.31,Jin-rongStreet

2 328 667 AS4837 CN CHINA169-BACKBONECNCGROUPChina169Backbone

3 290 53 AS9121 TR TTNETTurkTelekomunikasyonAnonimSirketi

4 270 021 AS4766 KR KIXS-AS-KRKoreaTelecom

5 219 077 AS23650 CN CHINANET-JS-AS-APASNumberforCHINA-NETjiangsuprovincebackbone

6 153 623 AS5384 AE EMIRATES-INTERNETEmiratesTelecommuni-cationsCorporation

7 144 942 AS12741 PL INTERNETIA-ASNetiaSA

8 130 050 AS3462 TW HINETDataCommunicationBusinessGroup

9 116 941 AS36351 US SOFTLAYER-SoftLayerTechnologiesInc.

10 114 696 AS5483 HU HTC-ASMagyarTelekomplc.

è

Jeżeli zestawimy liczbę połączeń (bez uwzględ-niania unikalności nadawcy), to - podobnie jak wzestawieniunajbardziej zainfekowanychkrajów-czołowepozycjebędązajmowaćoperatorzychiń-

scy.Potwierdzatofakt,żezChinwidocznychbyłow systemieARAKIS dużo ataków ale pochodziłyonezestosunkowoniewielkiejliczbyIP.

Tabela 2.5. Najbardziej zainfekowane systemy autonomiczne pod względem unikalnych adresów IP

Tabela 2.6. Najbardziej zainfekowane systemy autonomiczne pod względem liczby przepływów

64


Pozycja LiczbaunikalnychIP NumerAS Nazwaoperatora

1 6 767 AS12741 NETIA

2 744 AS5617 TP

3 201 AS21021 MULTIMEDIA

4 167 AS15857 DIALOG

5 69 AS12476 ASTER

6 65 AS29314 VECTRA

7 58 AS35007 MICRONET

8 56 AS42709 BIELSAT

9 43 AS34337 ELPOSCableTV

10 39 AS6714 GTS

Oprócz ochrony, jaką system ARAKIS zapewniłsieciom,wktórychzainstalowanesąsondy,przy-czyniłsiętakżedozrozumieniawielurodzajówza-grożeńpowszechniewystępującychw Internecie.

Dalejwskrócieopisanezostałyciekawsze,naszymzdaniem, obserwacje dokonane przez ARAKIS wminionymroku2011.

W połowie marca 2011 roku „narodził” się nowyrobaksieciowynazwanyMorto.Atakujeonźleza-bezpieczonesystemyMicrosoftWindowswykorzy-stującdotegoceluprotokółRDP(RemoteDesktopProtocol)wykorzystywanyprzeztzw.zdalnypulpit.Mortoniewykorzystujeżadnej lukiwoprogramo-waniu,aatakpoleganapróbieodgadnięcianazwyużytkownikaihasła.PoinfekcjirobakszukawsiecikolejnychkomputerówzuruchomionąusługąRDPi próbuje je zainfekować. Powoduje to znaczącywzrostruchusieciowegonatypowymdlatejusłu-gi porcie 3389/TCP. W zainfekowanym systemie

Morto zabija procesy, które uznaje (po nazwach)zaaplikacjezwiązanezbezpieczeństwem.Jesttobardzopopularnedziałaniewykonywanepoinfek-cji przez złośliwe oprogramowanie. Masową pro-pagacjęMortoodjejpoczątkuobserwujemydziękisystemowiARAKIS.

Regularnywzrostruchunaporcie3389/TCPpoja-wił się 15 sierpnia 2011 r., natomiast 24 sierpnianastąpiłnagłyiwyraźnyskok,któryutrzymywałsiędo26sierpnia.

3. Interesujące przypadki zaobserwowanych incydentów sieciowych

3.1 Morto - nowy robak sieciowy

Innym ciekawym zestawieniem jest rozkładzainfekowanychIPwpolskichsieciach.InaczejniżwstatystykachopisanychwgłównejczęściraportuCERTPolska(danepochodzącezkilkusystemówraportujących,nietylkozARAKIS-a)napierwszymmiejscunieznajdujesięTelekomunikacjaPolska,

lecz Netia z ogromną przewagą unikalnych wskali rokuadresów IP.Cociekawe,w rankingunie ma żadnych operatorów mobilnych. Ponadtowstosunkudoogólnegoobrazuprzedstawionegowrozdziale1,pojawiająsięmniejznanilublokalnioperatorzy.


Tabela 2.7. Zainfekowane adresy IP w polskich sieciach

65


28 sierpnia 2011 r. aktywność na porcie wróci-ła do normy sprzed masowej propagacji Morto. Pokilkutygodniachrobakznowubyłwidocznyijego

aktywność-jużniecomniejsza-obserwowanajestdochwiliobecnej.

20

Tydzień 30 Tydzień 31 Tydzień 32 Tydzień 33

docelowy port 3389/tcp

Od 2011-07-25 09:05:00 Do 2011-08-24 09:05:00

unik

alne

źró

dła

10

0

całkowita Obecna: 55.00 Średnia: 10.48 Maksymalna: 70.00

Środa Czwartek Piątek Sobota Niedziela Poniedziałek Wtorek

100

80

60

40

20

0


Od 2011-07-25 09:05:00 Do 2011-08-24 09:05:00

unik

alne

źró

dła


Piątek Sobota Niedziela Poniedziałek

80

60

40

20

0


Od 2011-08-25 21:38:47 Do 2011-08-30 01:38:47



è

Tabela 3.1.1. Ruch RDP w sieci honeynet (unikalne źródła)



unik

alne

źró

dła

66


liczb

a pr

zepł

ywów

Tydzień 31 Tydzień 32 Tydzień 33 Tydzień 34

40 k

30 k

20 k

10 k

0


Od 2011-07-31 14:05:00 Do 2011-08-30 14:05:00


SkanowaniaRDPwidzianebyłyzarównowhoney-necie(wykresynastr.65), jak iwdarknecie(wy-kres3.1.4).

Warto zauważyć, że w chwili obecnej aktywnośćrobakaMortojestnadalstosunkowowysoka,aport3389/TCPcałyczasznajdujesięwTOP10najczęś- ciejskanowanychportów. Rysunek3.1.5.przedstawiapróbkęsurowegoruchusieciowego-pakietu„connectionrequest”1kompo-nentuX.224służącydonawiązaniapołączenia(fazainicjacjipołączeniaRDP).Widaćwnimustawione „usercookie”2(rozpoczynającesięod„mstshash”),którezawieranazwęużytkownika.

Specjaliści z innych zespołów zajmujących sięanalizą robakaMorto twierdzili,żepróbujesię łą-czyć zawsze na konto „administrator” z użyciem

zestawu predefiniowanych haseł. Do honeypo-tów ARAKIS-a trafiały jednakże próby połączeńzawierające nazwę nie tylko tego użytkownika(chociaż w znacznej większości). Nie jesteśmypewni, czy próby połączeńRDPna konta innychużytkownikówsąteżefektemdziałaniategoroba-ka,czyraczejjesttoinnezagrożenie.Stosowanew systemie ARAKIS nisko-interaktywne pułap-ki nie pozwalają nawiązać pełnej sesji z ataku-jącymi (usługa Remote Desktop nie jest w pełnisymulowana), przez co nie możemy stwierdzić,czy za wszystkimi próbami włamań stoi Morto.

Zpowoduogromnejilościdanychwdalszychanali-zachwykorzystaliśmypełnyzapisruchusieciowego z pięciu najczęściej atakowanych sond systemuARAKISod20do28sierpnia,chybażezostanienapisaneinaczej.

1http://msdn.microsoft.com/en-us/library/cc240470%28v=prot.10%29.aspx 2http://www.snakelegs.org/2011/02/06/rdp-cookies-2/


Tabela 3.1.4. Ruch RDP w sieci darknet (liczba przepływów)

Rysunek 3.1.5. Pakiet nawiązujący połączenie RDP

67


Tabela3.1.6przedstawialistęnajczęściejwykorzy-stywanychnazwużytkowników.

3http://nmap.org/ncrack/

Pozycja Liczbawystąpień Nazwaużytkownika

1 33 692 Administrator2 18 070 administrator3 11 804 a4 4 612 admin5 3 474 ..a(\xFF\xFE\x61)6 3 265 usuario7 2 884 support8 2 074 NCRACK_USER9 644 micros10 624 pos111 369 adm12 322 aloha13 230 skannata14 178 pos15 129 Admin16 126 fax17 100 administrateur

Interesujący ciąg znaków znajduje się na piątejpozycji- jesttoznakdrukowalny(„a”)poprzedzo-nydwomaniedrukowalnymi („FF” i „FE”wkodzie

szesnastkowym).Ciekawewydajesiętakżeużycie„NCRACK_USER”-najprawdopodobniejktośnie-umiejętnie skorzystał z automatycznego skanera(najprawdopodobniejbyłtoncrack3).Wśródnazwużytkowników znalazły się także słowa w wieluinnychniżangielski językach,np. „usuario” (hisz-pański), „skannata” (fiński), „administrateur” (fran-cuski),czy„Verwalter”(niemiecki).

Poprzeanalizowaniukompletnychdanychzsyste-muARAKISz lipca i sierpnia2011 r.wyłoniły sięnoweciekawewnioski.Wprzypadkuzdecydowa-nej większości skanowań, pojedynczy źródłowyadres IP próbował łączyć się do wielu adresówdocelowych przy użyciu pojedynczej nazwy użyt-kownika.Na1800adresówźródłowych,jedynie24łączyłosięnawięcejniżjednąnazwęużytkownika,ztego21najedyniedwieróżnenazwy.Naszeob-serwacjeniesąwięcdokońcazgodnezwcześniej-szymi raportami innych zespołówmonitorującychMorto, według których robak próbuje zalogowaćsięnawieluróżnychużytkowników.

Następnymkrokiembyłaanalizanatężenia ruchuw całym badanym okresie. Wykres 3.1.7 przed-stawiawszystkiepołączeniaRDPzarejestrowaneprzeznaszehoneypotywrozbiciunanazwyużyt-kownika,jakiepróbowanowykorzystać.


è

80000

60000

40000

20000

prób

y po

łącze

ń / dz

ień

0

cze 27 lip 04 lip 11 lip 18 lip 25 sie 01 sie 08 sie 15 sie 29 wrz 05sie 22

aadminAdmin Administr administrator Administrator aloha backup kiosk NCRACK_USER pos root server test user

login

Tabela 3.1.6. Najczęściej używane nazwy użytkowników

Wykres 3.1.7. Nazwy użytkowników użyte podczas prób połączeń RDP

68


Maksymalna liczbapołączeńdziennieprzekracza80000,jednakniewidaćistotnegotrendu.Okaza-łosię,żewiększośćruchugenerowanajestprzezpojedynczeźródła,któreatakujądużezakresyad-resów IP. Dlatego zbadaliśmy jak rozkładały się wczasiepołączeniaodunikalnychźródłowychad-resówIP-powyższywykreszawieradanewyłącz-nie o pierwszym połączeniu z danego adresu IP(nowiatakujący).

Łatwozaobserwować,żeodok.15sierpnia lawi-nowo narastała liczba unikalnych źródeł ataków,którewykorzystywałylogin„a”.Atakującyposługu-jącysię innyminazwamizostaliw tymujęciucał-kowicie zmarginalizowani. Lawinowo narastającaliczba źródeł ataków to charakterystyczna cechaszybko rozprzestrzeniających się robaków, więcmożna przypuszczać, że obserwowany ruch po-chodziłodMorto.Nazwa„a”byłaznana jako jed-na z wykorzystywanych przez Morto, jednak niejesteśmypewni,czemuzaobserwowaliśmywzrostatakówjedynieztąnazwą,anieinnymi(np.„Admi-nistrator”).Istniejeprawdopodobieństwo,żerobaknienawiązawszypełnegopołączenianapoziomiewarstwy aplikacji RDP (wspomniana wcześniejkwestia nisko-interaktywnych honeypotów), za-przestałdalszychpróbzinnąnazwąużytkownika.

Obok znajduje się klasyfikacja państw, z którychwidzianychbyłonajwięcejpróbpołączeńRDP(ata-

ków).Daneznowuzostałyograniczonedopięciunajczęściej atakowanych sond systemu ARAKISod 20 do 28 sierpnia. Warto pamiętać, że choć wliścieuwzględnionotylkopołączenia,wktórychprzesłana była nazwa użytkownika (odrzuciliśmysprawdzania otwartości portu 3389/TCP), to, jakwspomnianebyłowyżej,niemamypewności,czywszystkiepołączeniazwiązanesązrobakiemMor-to.Ponadto istniejeprawdopodobieństwo,żeźró-dłoweadresyIPniesąjednoznacznieźródłemata-ku-mogąbyćtopośrednicy,zaktórymiukrywasięprawdziwyatakujący.Należypamiętać,żewiększesiecizracjiefektuskalimogąbyćwyżej.

Wykres 3.1.9. Liczba skanowań per kraj (robak Morto)

Wykres 3.1.8. Nazwy użytkowników użyte w pierwszym połączeniu każdego unikalnego adresu IP

30000

25000

20000

15000

10000

5000

0

27517

8392 8325

4960

13848

UA PL US RU CZ


połąc

zenie

z un

ikalny

ch IP

/ dzie

ń

0

cze 27 lip 04 lip 11 lip 18 lip 25 sie 01 sie 08 sie 15 sie 29 wrz 05sie 22

2500

2000

1500

1000

aadminAdmin Administr administrator Administrator aloha backup kiosk NCRACK_USER pos root server test user

login

time

500

69


Wykres 3.2.1. Unikalne adresy IP łączące się na port 0/TCP

unik

alne

źró

dła

Poniżejznajdujesięklasyfikacjapaństw,zktórychwidzianychbyłonajwięcejunikalnychatakującychadresówIP.

ZarównoaktywnośćrobakaMorto, jakipozostałeskanowaniaRDPmogązostaćwykrytezapomocąregułSnort.WsystemieARAKISnajczęściejdopa-sowywanąregułanaporcie3389/TCPjest:

● „ET POLICY RDP connection request” (sid:2001329),● „ETPOLICYMSRemoteDesktopAdministra- torLoginRequest”(sid:2012709),● „MISCMSTerminalserverrequest”(sid:1448),● „ET SCAN Behavioral Unusually fast Ter- minal Server Traffic, Potential Scan or Infec tion”(sid:2001972).Wykres 3.1.10. Unikalne adresy IP per kraj

1600 1400 1200 1000 800 600 400 200

0

1476

547 424301

1151

CN US BR DE TR


4http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml 5http://www.dshield.org/

3.2 Dziwny ruch na porcie 0/TCP

Port0/TCPjestwgrejestruIANA4portemzarezer-wowanym.Oznaczato,żeżadnausługaniepowin-nakorzystaćztegoportudokomunikacjisieciowej.Gdywdniu13 listopada2011 rokudosondsys-temuARAKISzaczęłanapływaćwzmożonaliczbapakietów TCP kierowanych na port 0, wzbudziłotonaszezainteresowanie.Próbypołączeńnatenport były widziane zarówno przez honeypoty, jak iwsiecidarknet.Znacznawiększośćpakietówzare-jestrowanychwhoneypotachbyłazniekształcona.Ruchwróciłdonormyzdniem17listopada2011r.

Zarejestrowaliśmy jeszcze krótkotrwały wzrost wdniach30listopada-1grudnia2011r.NaszeobserwacjewtychokresachpokrywająsięzdanymipochodzącymizsystemuDSHIELD5,coświadczyoglobalnymzasięgutejanomalii.

Wykres3.2.1przedstawia liczbęunikalnychadre-sówIPwpięciominutowymoknieczasowym,którepróbowałyłączyćsięnaport0/TCPdohoneypotówsystemuARAKIS.

8

6

4

2

012 13 14 15 16 17 18

docelowy port 0/tcp

Od 2011-11-11 12:04:23 Do 2011-11-18 12:04:23


Total Alarms (NWORM/NPORT) Obecna: 0.00 Średnia: 0.00 Maksymalna: 0.00

è

Obserwacje w honeypotach

70


Wokresie od 13 do 17 listopada 2011 r. zostałozaobserwowanych przez honeypoty ok. 15 000pakietów kierowanych na port 0/TCP. Znacznawiększość z nich (ok. 14 200)miaławnagłówkuustawiony port źródłowy także 0.SamenagłówkiTCPwwiększościbyłyzniekształcone(np.niepo-prawnadługośćnagłówka)lubniemiałysensu(np. wkontekścieustawionychflag).Równieżkombina-cjeflagwydawałysiępozbawionesensu.

JeżelipozanagłówkiempakietTCPzawierałjesz-cze dane (tzw. payload), to zawsze występowałw nim ciąg heksadecymalny A0027D78 (zazwy-czaj ciąg ten występował sam lub poprzedzonybyłciągiemróżnejdługościskładającymsięzzeroraz ewentualnie losowych liczb heksadecymal-nych-wyrażenie regularneopisujący tenciąg, to

[0-9A-F]*0*A0027D78).Tabela 3.2.2. przedstawia statystyki widzianegopayloadu(TOP10).

Wcharakterystyceruchumożnazauważyć,żeciąg000000000000000000000000A0027D78wystę-puje zawsze, tylkonieraz jest przesuniętydopo-czątkupakietu(natyle,żepole„dane”jestpuste,zawierajedynie4bajtyA0027D78lubciągzerjestkrótszy niż 12 bajtów), ewentualnie przesunięciemamiejscewprawo(wtedyciągzer jestpoprze-dzony losowymi bajtami). Losowe bajtywpływająna zniekształcenie nagłówka TCP, w tym niety-powe ustawienie flag. Rysunek 3.2.3. prezentujeprzykład pakietu, którego ciąg przesunięty jestwsposóbzniekształcającypole„opcje”(zaznaczone)orazflaginagłówkaTCP.

Liczbapakietów Payload(hex)640 0 0 0 0 0 0 0 0 A 0 0 2 7 D 7 8615 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A 0 0 2 7 D 7 8602 A 0 0 2 7 D 7 8534 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A 0 0 2 7 D 7 826 D B 1 9 F 9 1 B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A 0 0 2 7 D 7 87 ED8DDA5E000000000000000000000000A0027D787 CE537D46000000000000000000000000A0027D787 C9A7340E000000000000000000000000A0027D786 F 0 8 0 F 2 5 D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A 0 0 2 7 D 7 86 F02FD77C000000000000000000000000A0027D78


Tabela 3.2.2. Zestawienie zawartości danych w pakietach kierowanych do port 0/TCP

Rysunek 3.2.3. Zniekształcony pakiet kierowany na 0/TCP

71


Możetooznaczać,żebajtypowyżejnagłówka IPnie są protokołem TCP (pomimo tego, że w na-główkuIPwpolu„protocol”ustawionajestwartość0x06). Jeżeli tak, toalboktoś testował jakiśswójprotokółwarstwyczwartej,albotestowanebyłyza-chowaniaróżnychstosówTCP/IPnazniekształco-newodpowiednisposóbdane.

Źródłem skanowań w 84% były adresy należącedochińskich ISP (główniepochodzącez jednegosystemu autonomicznego AS4134). Na drugimmiejscu pojawiła się Kanada (6%), a na trzecimUSA (2%). Należy jednak zaznaczyć, że źródło-weadresyIPmogąbyćzespoofowane.Próbyna-wiązaniapołączeniaTCPnaport0zazwyczajniepowinny spotkać się z odpowiedzią (tak też było wprzypadku naszych honeypotów). Jeżeli osobyodpowiedzialne zawytworzenie takiego ruchudoInternetuwiedziały o tym, to nie oczekiwały żad-nych pakietów zwrotnych od docelowego adresuIP,więcadresźródłowymógłzostaćsfałszowany.Wykres3.2.4.przedstawiastatystykizwiązanezeźródłamianomalnegoruchu.

Nie mamy pewności co do przyczyny ani celugenerowania anomalnego ruchu na port 0/TCP. Zjednejstronymogłabyćtozwykłapomyłka,błądlub jakaś formaprojektubadawczego,azdrugiejmogły być to testy zachowania stosów TCP/IP nazniekształconepakietyTCP.Ponieważhoney-poty, jak i większość standardowych usług bądźsystemów, nie generują odpowiedzi na tego typuruch,niewiadomoczyźródłoweadresyIPniebyłysfałszowane (brak jakiejkolwiek interakcji). Obec-nieruchnaporcie0/TCPjestznikomyiniewyróż-niasięztzw.„szumutła”.

Poniżej przedstawiamy regułę dla systemuSnortdopasowującą charakterystyczny ciąg bajtów. Ponieważ opisany ruch jest mocno osobliwy, niewykluczamy,żemożesiętakżepojawićnainnychportach. Dlatego przedstawiamy postać najbar-dziejogólną:

alert tcp any any -> any any msg:”Suspicious 0/TCP payload”; content:”|a0 02 7d 78|”; sid: 120003; rev: 1;)

Wykres 3.2.4. Liczba pakietów per kraj (ruch na port 0/TCP)

Wykres 3.2.5. Liczba pakietów per ASN (ruch na portach TCP)

Wykres 3.2.6. Reguła Snort opisująca anormalny ruch na 0/TCP

12461

10582

962

983

329

962

273

565

182

273

CN

AS4134 AS4812 AS32613 AS4837 AS29550

CA US GB PL

14000

12000

10000

8000

6000

4000

2000

0

12000

10000

8000

6000

4000

2000

0


Podsumowanie


Adres: NASK / CERT Polska

ul. Wąwozowa 18

02-796 Warszawa

tel.: +48 22 3808 274

fax: +48 22 3808 399

Zgłaszanie incydentów: [email protected]

Zgłaszanie spamu: [email protected]

Informacja: [email protected]

Klucz PGP: http://www.trusted-introducer.org/teams/0x553FEB09.asc

Strona WWW: http://www.cert.pl/

http://facebook.com/CERT.Polska

RSS Feed: http://www.cert.pl/rss

Twitter: @CERT_Polska http://twitter.com/CERT_Polska

@CERT_Polska_en http://twitter.com/CERT_Polska_en

Kontakt

Copyright © NASK 2012

Raport CERT Polska 2011 · 2015-12-10 · 8 567891023540 8,%A60dree Raport CERT Polska 2011 2....

Documents

Transcript of Raport CERT Polska 2011 · 2015-12-10 · 8 567891023540 8,%A60dree Raport CERT Polska 2011 2....