1/3/2016
Dziś opublikowana szczegóły nowego ataku DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) na serwisy internetowe i serwery pocztowe wykorzystujące szyfrowanie transmisji w oparciu o TLS. Szacuje się, że na świecie podatnych jest 11 milionów serwerów.
Zanim jednak wpadniecie w panikę, zaznaczmy, że atak dotyczy komunikacji w oparciu o TLS wykorzystującej klucze RSA i SSLv2, który — przypomnijmy — z racji wielu słabości jest wycofywany z użycia (i w zasadzie nigdzie nie powinien być już wspierany). Niestety, część serwerów dalej jest w stanie komunikować się po tym protokole, jeśli klient go “wynegocjuje” (bo np. nie wspiera nowszych protokołów).
Dodatkowo, aby atak doszedł do skutku, atakujący musi znajdować się na trasie komunikacji — pomiędzy ofiarą a serwerem, a więc wcześniej należy przeprowadzić atak MITM. Z tego powodu największe szanse na przeprowadzenie ataku mają operatorzy (widzą ruch użytkowników), monitorujące ich służby albo osoby, które w ramach sieci lokalnej skorzystają z techniki ARP poisoningu. A więc podobnie jak w przypadku ataków BEAST, CRIME, BREACH i FREAK oraz POODLE czy Logjam — atak będzie bardzo ciężki do wykorzystania w realnym świecie. Ale jeśli ktoś sprosta atakowi MITM, to wystarczy minuta, aby rozszyfrować dane połączenie danego użytkownika (to ważne! chodzi o połączenie nie klucz prywatny serwera!).
Czy muszę się przejmować tym atakiem?
Jako internauta — nie. Bo niewiele nie możesz z tym zrobić. Jako właściciel serwera, też nie, chyba że celowo włączyłeś protokół SSLv2. Jeśli nie wiesz, czy masz go włączonego — skorzystaj z tego testu i upewnij się że korzystasz z OpenSSL w wersji nie niższych niż 1.0.2g lub 1.0.1s.
Jak informują odkrywcy, nie zaobserwowano, aby ktoś korzystał z tego ataku w internecie (do tej pory). Jeśli ktoś chciałby się zapoznać ze szczegółami technicznymi ataku — polecamy publikację odkrywców i poświęconą atakowi stronę WWW.
Posłuchaj jednego z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te webinary! Praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy oraz darmowy webinar.
Czy ten błąd ma już swoją ikonkę i stronę internetową?
“…i stronę internetową”
Please verify your age below:
4*0+2 = ?
Przecież masz link na końcu artykułu.
Napisałem to w sensie darcia łacha. Nie rozumiem tej mody.
też nie uwierzyłem w atak – nigdzie nie widziałem “nowej” ikony :)
Takie czasy, nikt nie będzie czytał opisów luk na brzydkiej stronie typu CVE, ale jak walniemy jakieś pastele to zainteresowanie przebija sufit.
Korzystając z programu pocztowego ma znaczenie czy mam ustawione smtp czy imap. Połączenie za pomocą SSL/TLS oraz metoda uwierzytelniania : normalne hasło?
1. Potrzebujesz zarówno SMTP (wysyłka) jak i IMAP (odbieranie poczty).
2. Nie ma znaczenia. Znaczenie mają ustawienia samego SSL/TLS. Uwierzytelnianie dzieje się już wewnątrz połączenia.
Raczej nie ma czego się bać, jeśli wierzymy, że admin naszego serwera mailowego jest chociaż quasi-kompetentny.
Na ECDSA nie zadziała :)
Next up: MORON – My Old Router Owned myNetwork.
“users guide to drown”
Step 1: find drowning area
Step 2: put head under water
Step 3: wait
Step 4: die
“Jako internauta — nie. Bo niewiele nie możesz z tym zrobić.”
O jedno “nie” za dużo.
Pozdrawiam.
Ze strony testowej
SSL 2 No
SSL 2 handshake compatibility Yes
Więc jak z tą weryfikacją?
Wygląda na robotę NSA, a raczej grzech przez zaniechanie. Dziwne, że dopiero teraz wychodzi, w czasie wycofywania tego protokołu…
Luka została wykryta mniej/więcej pol roku temu z tym ze dopiero teraz informacje zostały upublicznione, niemiałem czasu dopytać dokładnie o przyczyne, ale mysle ze kombinowali nad 100% skuteczna metoda zabezpieczenia i zalatania buga
RH i Centos już mają paczki wyłączające w zasadzie SSLv2 w OpenSSL – cała seria zmian z 1 marca. Zapewne inne dystrybucje również już są zaktualizowane.
Przecież już w tamtym roku było głośno o podatności tego protokołu. Więc dlaczego twierdzisz, że ” Dopiero teraz ? “
Wydaje mi się że trochę mylisz te podatność z “hearbleed”
*”heartbleed”
Twoja racja jest, Twojsza niż Mojsza ;D
(dokładnie o to mi chodziło)
Wystarczy wyłączyć SSL i po sprawie. IMHO po co to komu
Gdyby ktoś chciał sprawdzić, jak wygląda odporność polskich dostawców hostingu na atak, to zebrane wyniki na podstawie testów Qualys SSL Labs poniżej:
http://hostingraport.pl/zabezpieczenie-hostingow-przed-atakiem-drown