Kilka godzin temu badacze Google opublikowali informację o skutecznym ataku na protokół SSL. Atak ten umożliwia odczytanie zaszyfrowanych informacji przesyłanych przez użytkownika. Co to oznacza? Na to pytanie odpowiadamy w artykule.
Od kilku dni po sieci krążyły plotki o tajemniczym, nowym ataku na SSL, który wkrótce ma zostać ujawniony światu. Plotki okazały się prawdziwe – krótko po północy Google opublikowało informację o ataku na SSLv3, który nazwany został POODLE (skrót od (Padding Oracle On Downgraded Legacy Encryption). Odkrywcami ataku są Bodo Möller, Thai Duong oraz nasz rodak, Krzysztof Kotowicz.
Na czym polega atak i kto jest nim zagrożony? Poniżej trzy poziomy wyjaśnienia :) Przy okazji tu można sprawdzić podatność własnej przeglądarki.
Dla zwykłego użytkownika
Problem dotyczy tylko połączeń szyfrowanych (tych „z kłódeczką”), lecz to właśnie te połączenia są najważniejsze, bo w nich najczęściej przesyłane są faktycznie poufne dane. Nie jest to atak na serwery (nie umożliwia „włamania” na serwer), a na transmisję między przeglądarką a serwerem.
Jego przeprowadzenie wymaga od atakującego możliwości podsłuchiwania ruchu pomiędzy komputerem użytkownika a serwerem. Oznacza to, że jeśli korzystasz z dobrze zabezpieczonego, zaufanego WiFi, to raczej nie ma problemu. To samo dotyczy połączeń kablowych. Ryzyko powstaje, jeśli korzystasz z publicznych lub niezaufanych sieci WiFi (np. dworce, kawiarnie itp.). Oczywiście również połączenia kablowe czy zabezpieczone mogą zostać podsłuchane – jednak nie zrobi tego raczej „zwykły haker”, a np. NSA.
Przeprowadzenie ataku wymaga również, by przeglądarka, z której korzystasz, obsługiwała JavaScript. Oznacza to, ze większość urządzeń aplikacji na urządzeniach mobilnych (np. klient Twittera czy Facebooka) jest bezpieczna.
Gdy warunki do przeprowadzenia ataku będą spełnione, atakujący może odczytać np. Twoje ciasteczko sesyjne. Oznacza to, że będzie mógł np. przeczytać Twoją pocztę albo zobaczyć stan konta, ale nie pozna Twojego hasła ani nie zrobi w Twoim imieniu przelewu (jeśli zabezpieczony jest np. kodem SMS).
Przed atakiem można się zabezpieczyć. W zależności od używanej przeglądarki:
Firefox: trzeba wejść do ustawień (about:config) i zmienić opcję security.tls.version.min na „1”,
Chrome: trzeba uruchamiać z wiersza poleceń z parametrem -ssl-version-min=tls1 (kiedyś można było wyłączyć w opcjach, ale użytkownikom wydawało się, że TLS 1.0 jest niższy od SSLv3 i wyłączali nie to, co trzeba).
Internet Explorer: panel sterowania -> opcje internetowe -> zaawansowane -> odznaczyć „Użyj SSl 3.0”
Szczegółowe instrukcje w języku angielskim można znaleźć pod tym linkiem.
Ustawienia Internet Explorera
Dla średnio zaawansowanych użytkowników
Atak dotyczy protokołu SSLv3, który ma 15 lat i od dawna nie powinien być wykorzystywany. Czemu zatem ciągle obsługują go wszystkie przeglądarki? Zapewne dlatego, że obsługuje go ciągle wiele serwerów. A czemu obsługuje go wiele serwerów? Bo jest to najwyższa wersja protokołu, którą obsługuje nieśmiertelny Internet Explorer 6.
Tu krótkie przypomnienie – następcą SSLv3 jest TLS1.0 (wynika to zapewne z animozji między Microsoftem a Netscape). TLS 1.0, 1.1 i 1.2 nie są podatne na POODLE. Czemu zatem na atak podatne są przeglądarki, które obsługują TLS i łączą się z serwerami, obsługującymi TLS?
Niestety, mimo iż TLS zapewnia właściwą obsługę negocjacji protokołu w trakcie połączenia, to niektóre jego implementacje są tak popsute, że wprowadzono dodatkowy mechanizm zabezpieczający. Kiedy nie udaje się nawiązać połączenia TLS (bo np. jest notorycznie zrywane), serwer i przeglądarka wybiorą SSLv3. Pierwszym elementem ataku jest zatem oszukanie serwera, że nie da się nawiązać połączenia TLS, by doszło do połączenia SSLv3.
Do ataku niezbędny jest złośliwy JavaScript po stronie klienta. Zakładając jednak, że atakujący i tak musi móc podsłuchiwać ruch ofiary, nie jest trudno podłożyć JS do przeglądarki. Skrypt JS może być wykonany w dowolnym kontekście, ponieważ jego zadaniem jest przesyłanie do serwera, którego ciasteczko chce poznać atakujący, setek żądań za pomocą przeglądarki.
Właściwa część ataku polega na odpowiednio precyzyjnym manipulowaniu żądaniami skryptu, by w trakcie ich szyfrowania w trybie blokowym CBC zawartość ciasteczka była przesuwana o jeden bajt. Atak zaczyna się od 1 bajtu ciasteczka w ostatnim bloku, który jest uzupełniany do pełnych 8 bajtów. Dzięki odkrytej luce w protokole wystarczy maksymalnie 256 żądań do serwera, by odkryć zawartość 1 bajtu ciasteczka. W kolejnej fazie w ostatnim bloku znajdują się już 2 bajty ciasteczka – znany i nieznany. Ponownie wystarczy 256 żądań by odczytać bajt nieznany. I tak nx256, gdzie n to długość ciasteczka.
Dla użytkowników, którzy 3DEs/AES liczą ołówkiem na papierze
Nie udajemy, że wszystko rozumiemy tak dobrze, by Wam to wyjaśnić, a już na pewno nie zrobimy tego lepiej niż Adam Langley. Polecamy.
Co dalej?
Wygląda na to, że SSLv3 trzeba po prostu definitywnie wyłączyć, bez oglądania się na użytkowników IE6 i administratorów tych kilku serwerów, które jeszcze tylko ten protokół obsługują. Google zrobi to wkrótce w Chrome (obecnie blokuje przełączanie na niższy protokół, jeśli dostępny jest wyższy), w jego ślad pewnie pójdą także producenci innych przeglądarek. Administratorzy serwerów, czy chcą, czy nie, też będą musieli się dostosować.
- citibank.pl
- wakacje.pl
- cinema-city.pl
- jobs.pl
- strazgraniczna.pl
Źródła:
Komentarze
„ywdawało się, że TLS 1.0 jest wyższy od SSLv3” – wydawało się, że TLS 1.0 jest niższy od SSLv3. Chyba tak powinno być. Przepraszam że wytykam błędy w komentarzu
dzięki, poprawione
To ja wnoszę o jeszcze jedną poprawkę, tym razem z formatowaniem. Tło artykułu jest ciemnoszare, więc to, co na szaro i czarno jest słabo widoczne: „Bodo Möller, Thai Duong oraz nasz rodak, Krzysztof Kotowicz.” oraz „about:config) i zmienić” i dalej).
Przepraszam – poprawione.
Teraz też jest imho źle „kiedyś można było wyłączyć w opcjach” – co wyłączyć? Wystarczy dodać „to”, czyli „kiedyś można było to wyłączyć w opcjach”.
Adam nie ma w zwyczaju się obrażać i wzorcowo wszystko od razu poprawia:) A jak wiadomo nie u wszystkich jest to normą:)
„Przeprowadzenie ataku wymaga również, by przeglądarka, z której korzystasz, obsługiwała JavaScript. Oznacza to, ze większość urządzeń mobilnych jest bezpieczna.”
Dlaczego? Jaka przeglądarka mobilna nie obsługuje JS?
Treść poprawiona, bo nie było jak widać jasne.
A co z Operą? Jest jakiś sposób na wyłączenie SSLv3?
Nie znalazłem.
http://blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-attacks/
Testowałem wszystkie przeglądarki, jakie mam pod ręką na https://www.poodletest.com/
Ze zdziwieniem skonstatowałem, ze Iceweasel 29.0.1 oraz Opera 12.16 (budowane ze źródeł pod Linux) od kopa mają wyłączoną tą podatność. Chromowi musiałem natomiast dorzucić „–ssl-version-min=tls1” do ulubionego sposobu uruchamiania.
To samo w Firefoksie pod Windowsem (u mnie akurat 34.0a2), ze zdziwieniem stwierdziłem, że test nie wykrywa podatności na ten atak…
W operze next podajesz ten sam parametr dla opera.exe w ostatnim katalogu aktualizacji. (domyślnie uruchamiasz opere przez launcher.exe)
u mnie wygląda to tak: „C:\Program Files (x86)\Opera Next\25.0.1614.35\opera.exe” –ssl-version-min=tls1
Hmm… ale… urzadzenia mobilne tez obsluguja javascript :P
Inaczej chyba moja praca bylaby nikomu niepotrzebna :D
Treść poprawiona, bo nie było jak widać jasne.
Dla użytkowników nginx’a polecam zastosować:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
Jak widać ogranicza szyfrowanie do TLS’a
A admini BRE BANKu gwizdza sobie na takie dziury:
https://online.mbank.pl/
https://moj.multibank.pl/
Skojarzyl mi sie Miś i scena w szatni: Nie mamy Panskiego płaszcza i co nam Pan zrobisz?
Mi się łączy przez TLS…
Nszczcie nie ma takiego banku BRE.
Co do Opery (12.17): Preferencje -> Zaawansowane -> Bezpieczeństwo -> Bezpieczne protokoły
Firefox 32.0.3 mimo (standardowego) ustawienia „security.tls.version.min” na „0” – niepodatny.
Gdzie to sprawdzić jakie to połączenie wszedłem na citybank w logowanie, klikam w kłódke a tam TSL_RSA_WITH_AES_256 itd. To chyba jest TSL ?
jakiś pomysł jak zabezpieczyć najnowsza operę?
Your connection to http://www.citibankonline.pl is encrypted with 256-bit encryption.
The connection uses TLS 1.2.
Już poprawili, czy też po prostu można zmusić do użycia SSLv3??
„wynika to zapewne z animozji między Microsoftem a Netscape”.
SSL powstał jako własnościowy protokół Netscape. Pierwszą wersją wykorzystywaną w przeglądarce tej firmy była 2.0.
Potem Netscape zrobił jeszcze wersję 3.0 oraz 3.1. Przy tej ostatniej jednocześnie przedstawił protokół do standaryzacji i ten stał się standardem szyfrowania o nazwie TLS 1.0.
Tak więc SSL 3.1 i TLS 1.0 to praktycznie to samo, tylko pierwsze jest nazwą komercyjnego produktu własnościowego a drugie nazwą otwartego standardu.
Netscape zaprzestał rozwijania samodzielnie własnego protokołu i od tej pory rozwój sterowany jest przez IETF.
Tu nie chodzi raczej animozje. To jak z javascript i ecmascript – w sumie to samo tylko pierwsze jest komercyjnym produktem jednej firmy (tak jak jscript pewnej innej firmy) a ecmascript to standard.
A byli byście łaskawi wyjaśnić co za pomocą tego błędu można podsłuchać.
Bo ktoś zadał takie głupie pytanie o ryzyko.
Ja rozumiem że kontrolując część tekstu jawnego można część komunikacji SSyL
podsłuchać ? czy całą można
Najnowsze Comodo Chromium Secure (z numerkiem 36.1.1) można uruchamiać bez dodatkowego parametru. Wynik testu – not vulnerable.
Najnowszy CCS ma numerek 36.1.1.3 (oparty na Chromium 36.0.1985.97). Sorry za błąd (too much work – time to sleep). Pozdrawiam. :)
Mam wątpliwości co do wiarygodności wyników testu na http://www.poodletest.com.
Wcześniej sprawdzałem kilka przeglądarek opartych na Chromium (Comodo Dragon 33.1.0.0, SRWare Iron 37.2000.0.0, Comodo Chromium Secure 36.1.1.3), oczywiście przy wyczyszczonym cache’u i uruchamianych „na czysto”, bez parametru –ssl-version-min=tls1 i na poodle.com miałem teriera.
Dzisiaj sprawdziłem podatność przeglądarek w tym teście:
https://www.ssllabs.com/ssltest/viewMyClient.html
Wszystkie zaliczyły na dzień dobry fail. „Your agent is vulnerable”. a w sekcji Protocol Features przy SSL 3 miałem Yes.
Dopiero uruchomienie z parametrem –ssl-version-min=tls1 problem rozwiązało – obsługa SSL v3 jest wyłączona.
Natomiast jeśli chodzi o Firefoxa, tym co nie lubią grzebać w about:config polecam zainstalować dodatek SSL Version Control i w opcjach dodatku ustawić ręcznie obsługę TLS (minimum 1.1)
https://addons.mozilla.org/pl/firefox/addon/ssl-version-control/