Większość z Was pewnie czytała już o najnowszym błędzie w OpenSSL. Zagrożenie nie jest teoretyczne – mamy dowody na to, że hasła użytkowników największych polskich i światowych serwisów wyciekały lub nadal wyciekają.
Błąd, nazwany Heartbleed, polega na wysyłaniu przez serwer własnej pamięci w porcjach po 64 kilobajty w odpowiedzi na każde odpowiednio skonstruowane zapytanie. Pamięć pochodzi z właśnie uwolnionego obszaru procesu OpenSSL, zatem może zawierać bardzo wrażliwe dane – i często zawiera.
Przykłady z naszego podwórka
Nie będziemy tutaj wskazywać konkretnych nazw firm – problem dotyczył wielu z nich a dzięki naszym Czytelnikom poznaliśmy kilkanaście przykładów. Wybraliśmy kilka z nich, a krytyczne dane zostały zanonimizowane.
1. Duży ogólnopolski portal
Co prawda serwery pocztowe zostały bardzo szybko załatane, ale główna domena oraz serwis usługi dysku w chmurze przez wiele godzin wysyłały kawałki pamięci, zawierające takie perełki:
.x-gzip, identity; q=0.9..Accept-Language: en-us..Authorization: Basic emFub25pbWl6b3dhbmVAeHh4LnBsOmF0dXRhamhhc2xvMQ==
Ciąg zakodowany w base64 to oczywiście login i hasło do skrzynki pocztowej. Serwis jest w dobrym towarzystwie, bo nawet Yahoo potrzebowało ponad doby na załatanie serwerów.
2. Duża firma hostingowa – serwer pocztowy
&_user=kontakt%domena.pl&_pass=haslouzytkownika<(hz0=poczta.*.pl; language=pl; roundcube_sessid=[id]
3. Serwis www dużej firmy kurierskiej
menu_name=parcelsMenu&loginKey=xxxxxxx&customerId=xxxxxx&userName=xxxxxx&password=xxxxxx
4. Jedna z największych firm bukmacherskich
Login=xxx%40xxxxx.pl&txtPasswd=xxxxx23&action=login&ajaxcall=ajaxcall
5. Panel obsługi klienta dużej firmy telekomunikacyjnej
action=logowanie&login=1234567&passw=xxxxxxx&submit=Zaloguj
6. Duża polska giełda BTC
if ($debug) printit("STDERR:$input");...fwrite($sock, $input);..}.}..fclose($sock);.fclose($pipes[0]);.fclose($pipes[1]);.fclose($pipes[2]);.proc_close($process);.
To akurat fragment kodu źródłowego, ale w odpowiedziach serwera przewijały się również dane użytkowników.
Fragment przykładowej odpowiedzi serwera
7. Jeden z największych sklepów
&j_username=xxx%40xxxx.pl&j_password=xxxxx&agreement=on
Reakcja firm, które padły ofiara ataku
Takich przykładów otrzymaliśmy dziesiątki. Zabrakło w nich chyba tylko polskich banków. W jednym rzędzie stanęły telekomy, firmy hostingowe, ubezpieczeniowe, biura maklerskie – jak się domyślacie, żadna branża nie zareagowała wystarczająco szybko, by uchronić swoich klientów przed ujawnieniem ich danych. Podatne były także serwery popularnych polskich serwisów „hakerskich”. Jak również nietrudno zgadnąć, żadna, ale to żadna z zaatakowanych firm lub organizacji nie poinformowała swoich klientów o konieczności zmiany haseł (jeśli na taką trafiliście, dajcie znać – pochwalimy).
Co prawda atak nie zostawiał śladów w logach, lecz skoro kod, umożliwiający nieautoryzowane pobranie danych z serwerów, był dostępny już po kilku godzinach od ogłoszenia błędu, to trudno zakładać, że nikt z niego nie skorzystał. Wygodniej jednak oczywiście uznać, że nic się nie stało. Polski rynek ma pod tym względem jeszcze bardzo dużo do nadrobienia.
Co z tym zrobić?
Co prawda jeśli dana firma ma milion klientów, to prawdopodobieństwo, że ktoś złośliwy trafił właśnie na Twoje hasło, jest niewielkie. Niemniej powyższe przykłady pokazują, że było to całkiem realne zagrożenie, zatem my już zmieniliśmy niektóre nasze hasła i rekomendujemy to samo naszym Czytelnikom. Co gorsza, nie wiemy, od jak dawna błąd był znany (a mógł występować od ok. dwóch lat) – zatem nawet, jeśli nie logowaliście się nigdzie w ciągu ostatnich 3 dni, to zmiana haseł nie zaszkodzi. Nawet zmiana hasła jednak może nie wystarczyć, jeśli ktoś wykradł ciasteczko Waszej sesji… Wtedy warto jeszcze się wylogować na wszelki wypadek.
Jeśli zaś szukacie podatnych serwerów, to zrobił to już za Was Robert Graham, który po przeskanowaniu całego internetu ustalił, że 600 000 adresów IP z 28 000 000 odpowiadających na porcie 443 jest ciągle podatnych. Uważajcie jednak, by nie trafić na Heartbleed-honeypota.
Honeypot Heartbleed
Dla tych, którzy doczytali artykuł do końca, w nagrodę link do poświęconego temu samemu tematowi xkcd.
Komentarze
Firma Mojang (ta od Minecraft’a) opublikowała komunikat, w którym „prosi” użytkowników o zmianę haseł
Źródło: http://craftsite.pl/mojang-radzi-zmiane-hasla/19299
Czy możecie wyjaśnić laikowi kiedy konkretnie mogło nastąpić podsłuchanie ?
1. Korzystam z hotspot, brak szyfrowania wpa, ktoś mógł podsłuchać moje hasło gdy logowałem się po https ?
2. Używam np. Neostrady po kablu lan, logowałem się na dziurawą pocztę przez https. W którym miejscu ktoś mógł odczytać hasło ? Routery Orange, inne sprzęty sieciowe po drodze ? Nagle ktoś miał dostęp do tego sprzętu ?
Twoje dane, już odszyfrowane, mógł ujawnić serwer, z którym się łączyłeś.
No ale jak ?
Czytam sobie dziurawą poczta na wp.
Jak niecna jednostka z chin dostanie się do ruchu sieciowego w obrębie Pl ?
Cały szkopuł polega na tym, że nie trzeba podsłuchiwać ruchu sieciowego. Wystarczy w odpowiedni sposób wysłać żądanie do Twojego serwera pocztowego, a zwróci on wycinki ze swojej pamięci operacyjnej. Prawdopodobnie najczęściej nie będzie w nich nic ciekawego, ale może zdarzyć się, że znajdą się tam jakieś hasła. A to, czy akurat w pamięci będzie Twoje, to już rzecz czystego przypadku. Tych ataków nie da się chyba ukierunkować na konkretne osoby.
@Marku,
Atak polega na odczytaniu fragmentu zawartości pamięci RAM po stronie serwera. Jeśli logowałeś się do gmaila przez przeglądarkę i ktoś chwile po Twoim zalogowaniu wykonał atak na serwer a przy tym miał szczęscie (a Ty pecha), że wśród tych gigabajtów RAMu Twoje hasło znalazło się akurat w 64 KB które zostały odczytane, to Twoje hasło już nie jest bezpieczne. Ponadtwo podczas trwania Twojej sesji, atakujący mogł probować wielokrotnie atakować serwer i odczytywać inne fragmenty pamięci RAM zwiększając swoją szansę, że pozna Twoje hasło.
Ifttt też.
dwa dni temu uruchomiłem procedure zmiany haseł a wy mi każecie jeszcze raz ?:(
Wunderlist wysłał do swoich użytkowników informacje o tym jak zabezpieczyli konta.
Ja dostałem dzisiaj o 21:39 maila od IFTTT z prośbą o zmianę hasła.
Jja też
Wczoraj załatałem serwer – dwie strony testujące podały, że jest podatny, po zrobieniu update, pokazały, że jest ok.
Dzisiaj sprawdzam jeszcze raz i pokazuje znowu, że serwer jest podatny o.O
Strony testujące są przeciążone – przez to mogą generować fałszywe alarmy.
a to co się dzieje teraz na http://www.kinoman.tv/ ma jakieś powiązanie z tym co piszecie?
kinoman nie jest podatny na wspomniany w tekście bład
Jest to celowa zagrywka NSA lub pochodnych, ujawnili to co od dawna nazywane było teoriami spiskowymi, aby lud utwierdzić w przekonaniu że tak, open source jest niebezpieczne
Bitcurex?
Jestem laikiem, ale kontom na google raczej nic nie grozi prze to no nie?
@Kuba. Jeżeli rzeczywiście jesteś laikiem to tak, kontom na google raczej nic przez to nie grozi :)
Trochę nieścisłości w tekście:
1. Hasła powinni zmienić wszyscy (korzystający z podatnych serwisów, tylko ciężko stwierdzić, które były podatne), nie tylko logujący się wczoraj lub dziś.
2. Logowanie to także pobranie poczty, użycie komunikatora itd. Często hasła są zapamiętywane, zwł. w urządzeniach mobilnych.
3. Zmiana hasła przed załataniem serwisu (a nadal są niezałatane, także .pl) nie ma sensu.
4. Ignorancja użytkowników jest u nas wielka (patrz komentarz Marka). IMO firmy zwyczajnie boją się informować szeroko. Podejście typowego usera to niestety zwykle „z waszej winy wyciekło moje cenne hasło, którego używam w faftylionie miejsc i co ja biedny teraz pocznę?!”.
5. Atak nie zostawia śladu w logach, a podatność była od dwóch lat. Czyli patrz punkt pierwszy. Bycie pionierem w niesieniu kagańca oświaty w tym przypadku kosztuje, więc pewnie wielu liczy na to, że ktoś w szerokich, niespecjalistycznych mediach napisze, że hasła trzeba zmieniać.
6. Symetrycznie – podejście firm do userów też jest, jakie jest. Sam bym nie napisał (z prawdziwego IP i konta) na wallu na FB większej firmie, że mają (tego) buga. Za dużo przypadków tuszowania własnej ignoracji nerwową reakcją w postaci traktowania tego jako próby włamania (którą de facto jest, ale bądźmy poważni). Testować zdrowego rozsądku sądów mi się nie chce, zakładać anonimowego konta też nie.
Na koniec: jeden z polskich dostawców chmury poinformował – nawet dość zgrabnie i zdecydowanie szybko – o błędzie, ale bardziej w kontekście „aktualizujcie openssl i certyfikaty SSL”. O hasłach ani słowa.
Tumblr informuje o potrzebie zmiany hasła: „Friendly reminder: Now is a great time to change your password. Learn more [http://staff.tumblr.com/post/82113034874/urgent-security-update]”
Również dostałem ostrzeżenie mailowe od tumblr.com (11.04) i jeszcze od jakiegoś serwisu, z którego dawno nie korzystam.
Pojawiają się pierwsze firmy z PL: http://www.blink.pl/openssl-dziura-heartbleed/
GemFury poinformowało, do tego unieważnili wewnętrzne certyfikaty i hasła oraz wylogowali wszystkich.
a cos wiadomo o allegro?