09.04.2014, 11:48
Cytat: Jak się okazuje, w OpenSSL przez 2 lata znajdował się błąd, który mógł umożliwić pozyskanie klucza prywatnego używanego przez serwer do szyfrowania ruchu. Błąd znajdował się w kodzie od 2 lat i co gorsza nie będziecie w stanie sprawdzić, czy padliście jego ofiarą — atak nie pozostawia bowiem żadnych śladów. Czy czeka nas wszystkich wymiana/kupno nowych certyfikatów SSL?
Co korzysta z OpenSSL?
Biblioteki OpenSSL używa ok. 2/3 webserwerów w internecie. Ale nie tylko — oprócz Apache i nginx polegają na niej również klienty poczty elektronicznej i inne oprogramowanie . To dzięki niej możliwa jest obsługa m.in. certyfikatów SSL czyli “poczucie bezpieczeństwa oferowane przez kłódkę”
OpenSSL__The_Open_Source_toolkit_for_SSL_TLS
Które wersje są dziurawe?
Wczorajsze advisory OpenSSL poinformowało o błędzie, który otrzymał identyfikator CVE-2014-0160 i w krótkich słowach wyjaśniło jego genezę:
brak tzw. bound checka w obsłudze heartbeatu TLS może powodować ujawnienie 64k pamięci serwera. Na błąd podatne są wersje od 1.0.1 do 1.0.1f oraz 1.0.2-beta wraz z 1.0.2-beta1. —Błąd odkrył Neel Mehta z Google Security.
Starsze wersje nie są podatne, ale paradoksalnie poprzednie błędy w TLS (np. atak BEAST) wymusiły aktualizację do nowych, jak się okazuje jeszcze bardziej dziurawych, wersji OpenSSL…
Atak Heartbleed – sprawdź czy jesteś dziurawy
W internecie dostępny jest już test, weryfikujący, czy dany serwer jest dziurawy. O ile wszystkie testowane przez nas polskie banki nie są podatne na atak (poza jednym), to z giełdami bitcoina jest już odrobinę inaczej
Test_your_server_for_Heartbleed__CVE-2014-0160_
…albo strona testująca nie działa stabilnie — oto komentarz jaki otrzymaliśmy w tej sprawie od Bitcurex:Cytat: Chciałbym poinformować, że nasz serwis jest zabezpieczony na okazję Heartbleed już od dłuższego czasu. Strona, na którą się Państwo powołujecie, w kontekście wprowadzonego przez nas zabezpieczenia, może wprowadzać w błąd.
Mam OpenSSL – co robić, jak żyć?
Po pierwsze, zaktualizuj swój pakiet do wersji 1.0.1g, lub jeśli nie jest to możliwe, zrekompiluj OpenSSL z flagą -DOPENSSL_NO_HEARTBEATS
Po drugie, nie należy wykluczać, że luka była znana w pewnych kręgach, a to oznacza, że przez (maksymalnie) ostatnie 2 lata ktoś mógł wykraść twoje klucze prywatne do certyfikatu SSL, a następnie mając możliwość deszyfrowania ruchu do Twojej maszyny, także wszelkie hasła administratorów lub użytkowników albo ich ciasteczka.
Dlatego, po aktualizacji OpenSSL należy rozważyć:
Wymianę certyfikatu SSL na nowy (to może wiązać się z kosztami zakupu nowego certyfikatu)
Zmianę haseł administratora i/lub użytkowników (mogły zostać podsłuchane)
Skasowanie aktywnych tokenów sesyjnych na webserwerze (mogły zostać podsłuchane)
Należy również uświadomić sobie, że jeśli ktoś posiadał możliwość deszyfrowania ruchu do naszego serwera przez (w wariancie pesymistycznym) nawet 2 lata, to mógł on równie dobrze przejąć krytyczne dokumenty, które wysyłaliśmy/e-mailowaliśmy do serwerów pracujących pod kontrolą OpenSSL — albo wręcz dostać się do serwera przy pomocy naszych danych i przejrzeć wszystkie informacje, które się na nim znajdowały.
Dodatkowe informacje o błędzie “Heartbleed”
Na koniec przypomnijmy, że kilka tygodni temu krytyczny błąd w bibliotece obsługującej SSL/TLS dotknął oprogramowanie Apple …a i GnuTLS miało niedawno swoje problemy.
Jak widać, nie zawsze “Open Source” oznacza, że błędy są wyłapywane natychmiast przez tzw. “community” — lepiej jednak późno, niż wcale.
PS. Techniczna analiza błędu dostępna jest tutaj — a osoby, które odkryły podatność stworzyły specjalny serwis z informacjami na jej temat.
PPS. Ponieważ dziś ujawniono na czym polega atak i udostępniono kod patcha, który go łata, najprawdopodobniej lada chwila rozpoczną się masowe ataki na serwery korzystające z OpenSSL. Dlatego dajcie proszę znać swoim znajomym o tym błędzie — niech jak najszybciej zaktualizują OpenSSL na swoich serwerach.
Źródło:
[Aby zobaczyć linki, zarejestruj się tutaj]
:D