W październiku 2008 roku fiński zespół CERT (FICORA/CERT-FI) został poinformowany przez firmę Outpost24 zajmującą się wdrażaniem rozwiązań bezpieczeństwa sieciowego o obecności krytycznych luk w implementacjach protokołu TCP. Szczegóły odkrytych podatności nie zostały upublicznione – CERT-FI, we współpracy z firmą Outpost24 oraz kilkudziesięcioma producentami sprzętu i oprogramowania, pracują nad oszacowaniem skali problemu i opracowaniem stosownych poprawek. Dokładna charakterystyka odkrytych podatności ma zostać ujawniona, gdy producenci i deweloperzy wyeliminują je ze swoich produktów. Wiadomo jedynie, że problem dotyczy kolejkowania połączeń w protokole TCP i pozwala na przeprowadzenie ataku DoS (ang. Denial of Service). Atak wymaga ustanowienia pełnych połączeń TCP ze zdalnym hostem (ang. three-way handshake), jednak ilość ruchu konieczna do wygenerowania przez atakującego jest stosunkowo mała. Zgodnie z informacjami udostępnionymi przez fiński CERT, prace mające na celu wyeliminowanie tej podatności są na zaawansowanym etapie i najprawdopodobniej jeszcze w 2009 roku producenci wydadzą odpowiednie aktualizacje.

11 czerwca 2009 roku, w magazynie Phrack ukazał się artykuł opisujący nowy mechanizm ataku DoS . Artykuł „Exploiting TCP Persist Timer Infiniteness” autorstwa ithilgore poświęcony jest podatności związanej z mechanizmem czasu oczekiwania (ang. persist timer) wykorzystywanym w protokole TCP do kontroli przepływu (a dokładnie do eliminowania zakleszczeń przy wstrzymaniu transmisji za pomocą zerowej szerokości okna). Spekulowano, że opisany atak jest jednym z ataków zgłoszonych do Fińskiego CERT. Jednakże zespół CERT-FI stwierdził, że chociaż metoda opisana w Phrack’u dotyczy podobnych zagadnień, to nie wykorzystuje słabości protokołu TCP, których dotyczył ich komunikat, a jej upublicznienie w żaden sposób nie wpłynie na koordynowane przez ten zespół prace.

Na czym więc polega nowa metoda ataków DoS ?

Implementacja czasu oczekiwania wyspecyfikowana w dokumentach RFC powstała 20 lat temu i nie była opracowywana pod kątem ochrony przed wysublimowanymi atakami. W ciągu ostatnich lat systemy operacyjne ewoluowały stosując rozwiązania chroniące przez rozmaitymi formami złośliwej aktywności takimi jak ataki DoS, nawet kosztem częściowej niezgodności ze standardami RFC. Jednak implementacja mechanizmu persist timer w jądrach systemu Linux i *BSD (autor artykułu z Phrack’a przeprowadził testy na systemie z jądrem Linux 2.6.18, jak również na systemach *BSD) ściśle stosuje się do RFC i w rezultacie umożliwia przeprowadzenie ataku DoS poprzez wyczerpanie pamięci jądra lub limitów aplikacji sieciowej przy minimalnym wykorzystaniu łącza.

Read more

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

Wstęp

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

Read more

W połowie stycznia opublikowaliśmy raport roczny zespołu CERT Polska dotyczący incydentów zgłaszanych do nas w roku 2008. Obecnie dokument ten został rozszerzony o raport z systemu wczesnego ostrzegania o zagrożeniach w sieci ARAKIS.

W raporcie zamieszczono statystyki dotyczące alarmów generowanych przez system, które są kluczowe z punktu widzenia obsługi systemu. Ponadto opisano kilka interesujących przypadków obserwacji dokonanych przez ARAKISa.

• W 2008 roku operatorzy systemu ARAKIS obsłużyli łącznie 11 335 alarmów (średnio ok. 31 alarmów na dzień), z czego 4% miało najwyższy priorytet, oznaczający realne zagrożenie dla któregoś z podmiotów biorących udział w systemie.
• Zainstalowanych zostało 6 nowych fizycznych sond, a łączna ich liczba wyniosła 54.
• Sondy są umiejscowione w różnych instytucjach państwowych szczebla centralnego (projekt ARAKIS-GOV) oraz w sieci NASK.

Raport z systemu ARAKIS (zintegrowany z raportem dotyczącym obsługi incydentów) jest dostępny w formacie PDF pod adresem: www.cert.pl/PDF/Raport_CP_2008.pdf.