Ekstremalny błąd w DNS!

[halapenio 1]

Computer Emergence Reponse Team (CERT) poinformował wczoraj o wydaniu przez wszystkich głównych dostawców oprogramowania DNS poprawki, która eliminuje odkrytą na początku tego roku przez badacza Dana Kaminsky'ego możliwość przejęcia kontroli nad serwerami nazw. Od tamtego czasu Kaminsky współpracował z innymi specjalistami nad przygotowaniem skoordynowanego wydania poprawek.

 

Sprawa ta jest niezwykle poważna i serwery DNS powinny zostać jak najszybciej zaktualizowane. Jako że problem dotyczy nie konkretnych implementacji oprogramowania, ale samego protokołu DNS, podatne na atak są wszystkie serwery na wszystkich platformach! Na szczęście odkrycie luki nie było łatwe, a użycie odwrotnej inżynierii na łatce niczego raczej atakującym nie wyjaśni.

 

W oficjalnym komunikacie CERT można przeczytać, że atakujący dzięki wykorzystaniu luki mógłby dowolnie przejmować kontrolę nad fragmentami Internetu i przekierowywać użytkowników do dowolnych, wrogich im miejsc. Przejmując DNS danego dostawcy Sieci, mógłby milionom jego użytkowników jednocześnie podmienić popularne wyszukiwarki, strony banków, serwisy społecznościowe na ich phishingowe odpowiedniki. Atakując korporacyjne środowiska, mógłby przechwytywać poufne informacje firm i śledzić ich biznesowe zamiary.

 

Dan Kaminsky po odkryciu podatności na atak, zgłosił się do największych specjalistów, w tym do amerykańskiej centrali CERT. Tam wraz ze specjalistami z najważniejszych firm software'owych koordynował przygotowanie poprawki, która miałaby jednocześnie naprawić cały światowy system serwerów nazw. Podczas marcowego kampusu zorganizowanego przez Microsoft, inżynierowie wyznaczyli noc z 8 na 9 lipca 2008 roku, jako datę wdrożenia poprawki – miało to uniemożliwić atakującym na odkrycie luki w systemach i zaatakowanie tych serwerów, które nie byłyby jeszcze odporne.

 

Niestety najprawdopodobniej nie uda się zaktualizować wszystkich serwerów jednocześnie. Nie wszystkie też systemy można załatać automatycznie. Dlatego też dopiero 6 sierpnia 2008 r. podczas specjalnej konferencji dotyczącej bezpieczeństwa DNS, Kaminsky przedstawi szczegóły związane z odkrytą przez siebie podatnością. Uważa się, że do tego czasu jej szczegóły będą już znane hakerom – ale maksymalne odsunięcie w czasie wyjawienia natury podatności pozwoli większości instytucji i firm należycie się zabezpieczyć.

 

Domowi użytkownicy, którzy korzystają z systemów automatycznej aktualizacji oprogramowania będą zabezpieczeni przez twórców swoich systemów operacyjnych. Jedynie bardzo przestarzałe systemy mogą pozostać nie załatane.

 

Jak uważa CERT, nie ma powodów do paniki. Nie istnieją żadne dowody na to, by wrogo nastawieni hakerzy odkryli tę lukę i wykorzystali ją do ataku na ogólnoświatową Sieć. Trzeba jednak przyznać, że w świetle ustaleń Kaminsky'ego, skutki takiego ataku mogłyby być śmiało uznane za globalną katastrofę.

 

Z ujawnionymi przez CERT szczegółami można zapoznać się na stronie www.kb.cert.org/vuls/id/800113.

 

Źródło: securosis.com, CERT.com

 

http://webhosting.pl/kategorie/bezpieczens...stkich_systemow

[swoj-chlop 0]

no ja bym sprobowal przekierowac wszystkie domeny na sedo na godzine, potem wyplacil milion i wtedy zglosil luke

[Noname 49]

Sadze ze troszke wiecej niz milion by Ci sie nakrecilo przez godzine

[halapenio 1]

Wyciekły informacje o luce w DNS

Security | 2008-07-23 00:05:09 | Autor: Piotr Kuźmiński

Do Sieci wyciekły szczegóły techniczne luki w protokole DNS (Domain Name System), która jest w dalszym ciągu obecna w niektórych sieciach.

 

Luka w DNS została odkryta kilka miesięcy temu przez specjalistę ds. bezpieczeństwa, Dana Kaminsky’ego. Współpracował on z największymi producentami oprogramowania, aby stworzyć odpowiednią łatę.

 

Nie załatany protokół DNS może paść ofiarą ataku metodą “zatruwania pamięci” (cache poisoning). Dzięki odpowiednio spreparowanym zapytaniom możliwe jest przekierowanie ruchu pod inny adres IP, co ułatwia dalsze przeprowadzanie ataku typu phishing. Dalsze konsekwencja ataku zależą wyłącznie od fantazji cybeprzestępcy (kradzież haseł, rozprzestrzenianie trojanów, tworzenie sieci botnet, itp.).

 

Kaminsky miał zamiar ujawnić szczegóły techniczne luki w przyszłym miesiącu podczas konferencji Black Hat w Las Vegas, jednakże uprzedził go Halvar Flake, prezes firmy Zynamics i ekspert od tzw. „reverse engineeringu”.

 

Opublikował on na swoim blogu spekulacje na temat genezy błędu. Niedługo potem autentyczność tych informacji potwierdzona została przez firmę Matasano Security, która również pracowała nad luką w DNS.

 

Gdy autorzy rewelacji zorientowali się, cóż takiego uczynili, natychmiast usunęli istotne informacje ze stron, jednakże Google zdążyło już je zaindeksować.

 

źródło: theinquirer.net

[halapenio 1]

Dan Kaminsky, odkrywca poważnej luki w protokole DNS, miał ujawnić szczegóły na sierpniowej konferencji BlackHat. Nie zdążył. Spekulacje na temat usterki pojawiły się najpierw na blogu Halvara Flake'a, niedługo potem firma Matasano Security potwierdziła słuszność jego tezy. Informację podchwyciły media. Teraz wiadomo już o dwóch exploitach wykorzystujących problemy z zabezpieczeniami w DNS.

 

7 sierpnia na konferencji Black Hat Kaminsky miał podać więcej szczegółów na temat luki, którą dwa tygodnie temu łatali najpoważniejsi dostawcy serwerów - odpowiednie uaktualnienia opublikowali Microsoft, Cisco, Red Hat, Sun Microsystems, Internet Software Consortium i inni. Tymczasem Thomas Dullien, dyrektor generalny firmy Zynamics, znany społeczności internetowej jako Halvar Flake, opublikował na swoim blogu domysły odnośnie wspomnianej usterki.

 

Jak podaje Heise Online, mechanizm ataku wygląda następująco: aby zmienić zawartość pamięci podręcznej serwera nazw (caching nameserver), cyberprzestępca zmusza serwer DNS ofiary do wywołania określonych adresów, np. aaa.example.com, aab.example.com, aac.example.com itd. Dla każdego z tych wywołań serwer nazw używa jednego identyfikatora transakcji. Im więcej takich identyfikatorów zostanie wykorzystanych, tym napastnik ma większe szanse na odgadnięcie właściwej kombinacji. Do przeprowadzenia ataku, czyli przekierowania internauty pod inny adres, potrzebna jest sfałszowana odpowiedź wyposażona w jeden z odgadniętych identyfikatorów.

 

Prawdopodobieństwo szybkiego znalezienia właściwego identyfikatora jest niewielkie, chyba że napastnik wykorzysta lukę, odkrytą przez Kaminsky'ego. Serwer nazw, przyjmując odpowiedź na zapytanie od innego serwera, stosuje procedurę o nazwie bailiwick checking. Eliminuje ona informacje, których dodatkowy rekord zasobów (Additional Resource Record, RR) nie zawiera. Chcąc zwiększyć prawdopodobieństwo zmanipulowania pamięci podręcznej, trzeba wprowadzić RR dla www.example.com z adresem IP serwera kontrolowanego przez napastnika.

 

Firma Matasano Security potwierdziła na swoim blogu słuszność domysłów Flake'a, publikując szczegółową specyfikację luki, a wraz z nią informację, że opisany atak przez szybkie łącze internetowe zajmie cyberprzestępcy około 10 sekund. Wpis został usunięty z bloga firmy. W chwili pisania tego tekstu jego kopię można było jeszcze znaleźć w zasobach serwisu amd.co.at. Informacja o ujawnieniu szczegółów luki w DNS szybko przedostała się do mediów.

 

Na blogu PandaLabs opublikowano obszerny artykuł pt. Patch your DNS NOW!!!!!, pojawiły się bowiem dwa exploity wykorzystujące omawiany błąd w zabezpieczeniach: CAU-EX-2008-0002 oraz CAU-EX-2008-0003. Jak wynika z drobiazgowych komentarzy w exploitach, kod z powodzeniem został zastosowany wobec serwerów BIND 9.4.1 i 9.4.2. Autorami exploitów są HD Moore i |)ruid związani z projektem Metasploit.

 

Jak podaje ZDNet, zaktualizowany Metasploit do sfałszowania jednego cache'a potrzebuje od jednej do dwóch minut, trwają jednak prace nad szybszą wersją narzędzia. Na uwagę zasługuje fakt, że jeden z exploitów potrafi podmienić cały wpis rekordu zasobów (RR) wskazujący na serwer nazw przypisany do określonej domeny - w ten sposób cyberprzestępca zyskuje możliwość przekierowania na swój serwer wszystkich stron ulokowanych w zaatakowanej domenie.

http://di.com.pl/news/22508,9.html