Jak korzystać z Internetu, gdy Heartbleed jest naprawiany?


119

Istnieje wiele witryn, które nie są obecnie podatne na atak, ale nie mam pojęcia, czy były one podatne kilka dni temu.

Na przykład:

  • twitter.com: Obecnie nie jest wrażliwy, ale certyfikat pochodzi z śr. 05 marca 00:00:00 UTC 2014
  • google.com: Obecnie nie jest wrażliwy, ale certyfikat pochodzi z Śr 12 marca 09:53:40 UTC 2014
  • bankofamerica.com: Obecnie nie jest wrażliwy, ale certyfikat pochodzi z czwartku 05 grudnia 00:00:00 UTC 2013

Co ja robię? Nie użyjesz ich, dopóki nie pojawią się ponownie? Skąd mam wiedzieć, że ponownie wystawiają certyfikat ze świeżymi kluczami? Wygląda na to, że nie powinienem nawet logować się na tych stronach, aby zmienić hasło, ponieważ nie ma możliwości, aby wiedzieć, że to prawdziwa strona internetowa.


4
Możliwy duplikat Co użytkownicy końcowi powinni zrobić z Heartbleed? na security.stackexchange.com
Philipp

Odpowiedzi:


201

Aktualizacje 2014-04-11

Cloudflare podjął wyzwanie, aby zweryfikować, czy ekstrakcja klucza prywatnego była rzeczywiście możliwa. Dokonano tego przy około 100 tysiącach próśb i weryfikuje obawy. Nie jest już teoretyczny, ale udowodniony . Możesz tu przeczytać o tym.

Bloomberg poinformował również, że NSA wie o tym exploicie od co najmniej dwóch lat . Ma to sens, ponieważ NSA ma zasoby, aby zatrudnić analityków, których jedynym zadaniem jest znajdowanie exploitów w takim oprogramowaniu. Teraz, gdy wiemy, że rząd Stanów Zjednoczonych wykorzystuje go od tak dawna, prawdopodobieństwo, że inne państwa go znało i wykorzystało, jest znaczące.


TL; DR Obserwuj ogłoszenia organizacji dotyczące stanu ich systemów, zmieniaj WSZYSTKIE hasła i uważaj na oszustwa / podejrzane działania na ważnych kontach, takich jak bankowość lub inne systemy finansowe.

Aby zrozumieć, dlaczego sytuacja jest tak niebezpieczna, najpierw musimy zrozumieć, co faktycznie robi ten atak. CVE-2014-0160, AKA Heartbleed, to błąd polegający na przeładowaniu bufora, który pozwala osobie atakującej uzyskać do 64 kB pamięci z serwera z wrażliwą wersją OpenSSL.

To brzmi naprawdę źle. Jak to działa w praktyce

Masz rację, to poważna wada, ale wrócimy do tego trochę później. W tej chwili porozmawiajmy o tym, dlaczego exploit działa. Transport Layer Security (TLS) służy do zabezpieczania informacji przez wiele aplikacji, w tym HTTP ( HTTPS ) lub do zabezpieczania SMTPjeśli włączone, na przykład. W RFC 5246, która ustanawia standardy dla TLS, istnieje funkcja znana jako bicie serca. Klient i serwer wysyłają niektóre dane tam iz powrotem, aby utrzymać połączenie przy życiu, dzięki czemu można je później wykorzystać. Teraz w praktyce klient wyśle ​​jakieś dane, a serwer po prostu je odeśle i wszystko jest w porządku. Jednak w wersjach OpenSSL, których dotyczy problem, nie ma możliwości sprawdzenia, czy klient faktycznie wysłał ilość danych, o której powiedział, że tak. Więc jeśli wyślę 1 bajt i powiem serwerowi, że faktycznie wysłałem 64 kB, to z przyjemnością odeśle mi 64 kB. Skąd pochodzą te inne bajty? To jest klucz do problemu właśnie tam. OpenSSL odeśle ci 64 kB - 1 bajt pamięci, do której proces ma dostęp i której pierwotnie nie wysłałeś, w zależności od tego, gdzie jest zapisany 1 bajt.materiał klucza prywatnego¹ i informacje, których serwer odszyfrowuje. Przykładami mogą być: hasła, informacje o karcie kredytowej i / lub kody PIN .

DOBRZE. Co to oznacza dla bezpieczeństwa informacji? Jeśli rozumiesz, jak działa kryptografia asymetryczna, wiesz już, że jest to poważne, ponieważ ujawnienie powoduje, że szyfrowanie jest tylko zaciemnieniem. Oznacza to, że chociaż serwery mogą być załatane i nie wyciekają już pamięci, sesje mogą być niepewne. Możliwe, że został on wykorzystany, zanim został publicznie znany lub w trakcie dokonywania łatania, ale obecnie nie ma metody, która wykazałaby, że miał miejsce atak. Możliwe, że reguły dla IDS mogą być dostępne, ale na razie tak nie jest. Reguły IDS zostały wydane . To samo w sobie jest niezwykle niebezpieczne, ponieważ operatorzy nie wiedzą, czy ich klucze są nadal bezpieczne.

Jesteśmy zmuszeni założyć, że klucze zostały wyciekły, co oznacza, że ​​wszystko, co wysyłasz za pośrednictwem drutu, może zostać odszyfrowane przez osobę trzecią. Jedynym sposobem na złagodzenie tego jest ponowne wygenerowanie kluczy i ponowne wydanie nowych certyfikatów przy jednoczesnym odwołaniu starych. Niestety zajmuje to trochę czasu, ponieważ urzędy certyfikacji bez wątpienia są teraz zalewane tymi żądaniami. Mimo to pozostawia to możliwość ataku typu man-in-the-middle lub inne możliwości phishingu.

Kiedy będzie bezpiecznie? Trudno jest wiedzieć, kiedy będzie bezpiecznie. Niektóre rzeczy, które sugeruję oglądać, to publiczne ogłoszenia wyjaśniające, że błąd został załatany w ich środowiskach lub że nigdy nie były podatne na atak, ponieważ nigdy nie korzystały z wersji, których dotyczy problem. Kiedy ogłosili, że dokonali aktualizacji do nowej wersji OpenSSL, upewniłem się, że używają nowego certyfikatu podpisanego po dacie publicznej publikacji exploita, tj. 07.04.2014.

** Należy pamiętać, że wcześniej zarejestrowany ruch może zostać odszyfrowany, jeśli klucz prywatny wyciekł później.

Co mogę zrobić jako użytkownik, aby się chronić

Przez kilka następnych dni, jeśli będziesz mógł uniknąć korzystania z krytycznych witryn, takich jak bankowość internetowa lub dostęp do internetowej karty medycznej, radzę to zrobić. Jeśli musisz to zrobić, zrozum, że twoja sesja jest potencjalnie zagrożona i przygotuj się na przyjęcie konsekwencji tego. Ponadto, gdy organizacje ogłosiły, że nie są już wrażliwe, należy zmienić hasło ; użycie menedżera haseł może pomóc. Powinieneś także przygotować się do zmiany lub monitorowania wszelkich innych wykorzystywanych informacji, takich jak dane bankowe lub numery kart kredytowych.

Specjalne powiadomienie dla aktywistów

Może to mieć wpływ na wszystko, co korzysta z OpenSSL, w tym Tor . Możliwe jest, że rządy były w stanie wykorzystać tę lukę od czasu jej włączenia do wydań OpenSSL sprzed ponad dwóch lat, ponieważ dysponowałyby ogromnymi zasobami potrzebnymi do poszukiwania takich exploitów i dlatego należy być przygotowanym na to, że informacje mogą nie będzie już prywatny.

** Należy pamiętać, że wcześniej zarejestrowany ruch może zostać odszyfrowany, jeśli klucz prywatny wyciekł później, chyba że wdrożono doskonałe bezpieczeństwo przesyłania dalej (PFS).

¹- Pojawiły się twierdzenia, że ​​prawdopodobnie klucze prywatne nie byłyby w pamięci, ale jednocześnie pojawiły się twierdzenia o pomyślnym wyodrębnieniu klucza. W tym momencie nie jest pewne, która strona jest poprawna.


45
Jest to zdecydowanie najbardziej pouczający fragment tekstu, który przeczytałem o tym nowym, niezwykle szalonym ataku Heartbleed (wszystkie inne artykuły / blog / wiadomości zawierały tylko fragmenty informacji). Dobra robota :) .
Radu Murzea

4
Skąd możemy wiedzieć, że nowe certyfikaty są generowane przy użyciu nowego klucza?

3
Note that previously recorded traffic may be decrypted if the private key was later leaked. Nie, jeśli serwer używa szyfru z tajemnicą przekazywania.
Wes

2
@ Wes Masz rację, że PFS najprawdopodobniej utrzyma bezpieczeństwo ruchu. Starałem się przejść dobrą linię wyjaśniania sytuacji, nie wprowadzając ludzi w błąd. Niestety PFS nie został szeroko wdrożony.
Jacob

6
Podsumowując what is heartbleed bug xkcd.com/1354
GoodSp33d

14

Ryzyko związane z tą podatnością jest nadmiernie przeważane. Mówię to, ponieważ istnieją dowody ZERO, że luka ta była znana lub wykorzystywana przed opublikowaniem jej przez naukowców 2 dni temu.

Pozwólcie, że wyrażę się jasno, pilne jest załatanie wrażliwych stron internetowych, szczególnie tych, które przeprowadzają wrażliwe dane w Internecie. Równie pilne jest załadowanie sygnatur ataku do IDS i narzędzi ochrony przed złośliwym oprogramowaniem. Wewnątrz działu IT powinniśmy zareagować na tę lukę z najwyższym priorytetem.

Powiedziawszy to, nie uważam, aby poziom ryzyka związanego z tą podatnością ze strony prasy publicznej był uzasadniony.

Co ludzie powinni zrobić, aby się chronić? Nie używaj witryn z wrażliwymi wersjami OpenSSL.

Dopóki nie ma dowodów na to, że ta luka została wykorzystana, wszelkie dalsze działania są bezcelowe i motywowane wyłącznie przez FUD. Nie zgadzasz się? Zastanów się nad wieloma lukami ujawnianymi co miesiąc lub kwartał, które pozwalają na wykonanie dowolnego kodu . Te, które dają atakującemu uprawnienia root lub system na poziomie systemu lub w których atakujący może je następnie zdobyć poprzez zwiększenie uprawnień, stanowią tak samo lub większe ryzyko dla bezpieczeństwa wszystkich danych obsługiwanych przez podatne systemy, jak tylko ta luka.

W wielu przypadkach luki te są wykrywane przez dostawcę oprogramowania lub badaczy, którzy informują o tym sprzedawcę. Producent tworzy łatkę i wypuszcza ją na rynek bez publikowania szczegółów podatności. W niektórych przypadkach szczegóły są publikowane, a społeczność bezpieczeństwa publikuje exploity do wykorzystania w narzędziach testujących. Nie reagujemy na tak wiele luk, mówiąc: „Wszystkie nasze tajemnice MOGĄ zostać ujawnione!”

Jeśli istnieją dowody na wykorzystanie, musimy odpowiednio na nie zareagować. Widzę duże ryzyko w przypadku nadmiernej reakcji badaczy, którzy ogłosili tę lukę, oraz w prasie, która wzmocniła swobodną rozmowę naukowców. Płaczą wilki.

- El viejo


9
Ta odpowiedź powinna zostać poddana pod głosowanie więcej IMO. Każdego miesiąca publikowanych jest wiele luk w zabezpieczeniach, które pozwalałyby na kradzież prywatnych kluczy serwerów i nie robi się o nich zbyt wiele zamieszania. Ten jest poważniejszy niż przeciętny ze względu na wszechobecność OpenSSL, ale wciąż jest nadmiernie przeciążony.
alastair

2
„Do czasu i bez dowodów na to, że ta luka została wykorzystana” „Jeśli istnieją dowody na wykorzystanie, musimy odpowiednio na to zareagować”. Dużo mówisz o dowodach wyzysku. Jednak jedną z przerażających rzeczy związanych z błędem Heartbleed jest fakt, że udana eksploatacja jest niewykrywalna po fakcie (chyba że przechowuje się w pełni nadchodzącą wiadomość pulsu za każdym razem w nieskończoność, a nawet wtedy nie ma gwarancji, że udana eksploatacja doprowadzi do naruszenia bezpieczeństwo). W jaki sposób proponujemy ustalić po tym, jak udokumentowano udane wykorzystanie błędu?
CVn

6
-1, ponieważ ten autor tak naprawdę nie rozumie natury ataków, nie sądzę. Po pierwsze, osoby atakujące, które miały taki dostęp, pracowały bardzo ciężko, aby zachować je w tajemnicy i nie dopuścić do ujawnienia dowodów na włamanie. Tego rodzaju błąd, który ogranicza bezpieczeństwo około połowy bezpiecznego ruchu w Internecie, wcale nie płacze wilka. Myślę, że to bardzo poważna sprawa.
Widok eliptyczny

19
Bruce Schneier ma najwyższy szacunek, jeśli chodzi o bezpieczeństwo IT. Cytując swój post na blogu o luce Heartbleed : „Katastroficzne” to właściwe słowo. W skali od 1 do 10 jest to 11 . Już samo to wystarczy, że zdecydowanie nie zgadzam się z twoją lekceważeniem problemu.
abstrask

8
Ten post powinien zostać obniżony. Problem NIE JEST nadmierny, jest to katastrofalna awaria OpenSSL, poza tym, nawet jeśli nie był używany do czasu publicznego ogłoszenia, źli gracze definitywnie narazili go na ryzyko. Jest również wysoce prawdopodobne, że NSA o tym wiedziała (ale nie można tego udowodnić). Istnieją przekonujące teorie wskazujące, że jest to celowy kompromis, chociaż autor zaprzecza.
davidgo

5

Nie każda witryna korzysta z bibliotek OpenSSL dla HTTPS (na przykład istnieją również GnuTLS i PolarSSL) i nie każda wersja OpenSSL jest podatna na zagrożenia (starsze wersje nie były). Oznacza to, że istnieje spora szansa, że ​​wspomniane witryny nie zmieniły certyfikatów, ponieważ nie musiały. Samo spojrzenie na daty wydania certyfikatów nie mówi wystarczająco dużo.

Istnieje wiele narzędzi i witryn, które mogą pomóc w sprawdzeniu, czy witryna jest podatna na atak, na przykład: - http://filippo.io/Heartbleed - https://gist.github.com/mitsuhiko/10130454 - https: / /www.ssllabs.com/ssltest/

Niestety, jak już powiedziałeś, nie mówi ci to, czy tak było. Obawiam się, że kluczową kwestią jest zaufanie: nie ma żadnego obiektywnego sposobu na sprawdzenie, których bibliotek SSL używają i których używają bez informacji wewnętrznych. Musisz mieć nadzieję, że zrobili to, co powinni (ponieważ jest to słuszne, a nawet dlatego, że obawiają się publicznego upokorzenia), a jeśli tak, możesz mieć tylko nadzieję, że są otwarci na to.

Oczywiście zawsze możesz zapytać te strony, czy to ich dotyczy, widziałem wiele stron internetowych, które wydają publiczne oświadczenia na ten temat. Często zadawanie pytań za pomocą mediów społecznościowych takich jak Twitter czy Facebook.

Zatem najlepszą radą, jaką mogę udzielić, jest ogólna rada: uważaj, co zostawiasz w Internecie i na jakich witrynach internetowych ufasz z danymi osobowymi.


3
czeka na pojawienie się nieuniknionego błędu PolarSSL ( jest następny na liście ...)
strugee

1

Jeśli chodzi o ujawnienie kluczy prywatnych, warto dodać, że chociaż ktoś może być w stanie odszyfrować dane w zaszyfrowanej sesji, ponieważ ma teraz klucz prywatny, nadal będzie musiał się ugruntować jako człowiek w trakcie sesji . Nie tylko każdy w Internecie może to zrobić.

Rozumiem, że nadal będą musieli przechwytywać ruch, albo będąc w lokalnej sieci LAN i podszywaniu się pod ARP, albo będąc w stanie przejąć / przekierować ruch, reklamując fałszywe trasy do routerów internetowych. Tego rodzaju ataki zawsze były możliwe, nawet bez tej podatności.


2
Niekoniecznie prawda z Heartbleed. Błąd istnieje, ponieważ dane (które mają być zaszyfrowane) można odkryć, uzyskując dostęp do pamięci RAM. Dlatego nie muszą przechwytywać / wąchać ruchu, aby wykorzystać tę lukę. Jednak na serwerze lub kliencie musiałoby być zainstalowane złośliwe oprogramowanie, a także wymagałby odpowiedniego dostępu do RAM.
ub3rst4r 10.04.14

Skąd. Może to być zagrożone także atakiem Man-In-The-Middle. Ponadto zrzut pamięci nie tylko wpływa na tę sesję, możliwe jest (w zależności od zawartości bloku pamięci), aby zobaczyć niezaszyfrowane nazwy użytkowników i hasła innych użytkowników, a także klucze prywatne, aby ułatwić dekodowanie całego ruchu [poprzez atak MITM]
davidgo

Myślę, że powinienem być trochę jaśniejszy, że chodziło mi głównie o użycie skompromitowanych kluczy po załataniu serwera.
PeterJ

0

Możesz wprowadzić adres URL witryny w LastPass Heartbleed Checker, a dowiesz się, czy witryna była lub nadal jest podatna na atak i kiedy jej certyfikat został zaktualizowany.

Istnieje również rozszerzenie Chrome o nazwie Chromebleed , które ostrzega, jeśli odwiedzasz witrynę, na którą wpływa Heartbleed.

Mashable.com ma listę dobrze znanych witryn, bez względu na to, czy zostały naruszone, i czy należy zmienić hasło. Co ciekawe, nie wpłynęło to na żadną z witryn na liście banków i biur maklerskich.



-1

Ogólnie rzecz biorąc, powiedziałbym, że nie pozwól, by paranoja dotarła do ciebie. Realistycznie po prostu możliwość odszyfrowania ruchu i uzyskania hasła to nie to samo, co faktyczne.

Jeśli używasz uwierzytelniania dwuskładnikowego (i powinieneś) w witrynach takich jak Twitter, Facebook, Gmail i bankowość, nie powinieneś się zbytnio martwić, a nawet jeśli nie, prawdopodobnie nie masz nic przeciwko.

Jeśli czujesz potrzebę zmiany wszystkich haseł, musisz iść naprzód i zrobić to tam, gdzie czujesz, że jest to potrzebne. To naprawdę wszystko.


1
uwierzytelnianie dwuskładnikowe nie powstrzyma złośliwej strony przed zrobieniem czegokolwiek, co jest możliwe w związku z tym exploitem. Nie jestem pewien powodu, dla którego to wychowujesz. Uzyskanie dostępu do kont społecznościowych nie jest tak naprawdę problemem osoby, która może skorzystać z tego exploita w OpenSSL.
Ramhound

1
@ramhound Wspomniałem w komentarzach przed usunięciem komentarzy, dwa czynniki pomagają, ponieważ gdy witryna ma nowy certyfikat wydający jakiekolwiek hasła, które mógł mieć atakujący, nie są już przydatne. Ponieważ nie ma sensu zmieniać hasła, dopóki nie zostanie wydany nowy certyfikat (a serwery załatane), a zyskujesz natychmiastowe ponowne zabezpieczenie konta przed możliwym wyciekiem poświadczeń, które mogło mieć miejsce, gdy atakujący posiadał klucz prywatny. Ponadto Twitter i Facebook są ważne, ponieważ można ich używać jako jednokrotnego logowania w wielu innych witrynach (w tym także, jak sądzę?)
Sirex

Hasło jest nadal pomocne, ponieważ ludzie używają tego samego hasła, tak, nawet osoby korzystające z uwierzytelniania dwuskładnikowego. Tak długo, jak atakujący może w zasadzie zrzucić dane sesji, może wykonać atak MiTM przeciwko tobie.
Ramhound

Tak, ale ponowne użycie haseł to osobne niepowodzenie. Chodzi mi o to, że dwa czynniki pomagają złagodzić dotkliwość i długowieczność następstw, ale tak, to nie pomoże w wykorzystaniu faktycznego błędu.
Sirex

@Sirex O ile nie mogę stwierdzić, że żadna witryna, do której loguję się przy użyciu uwierzytelniania dwuskładnikowego, nie unieważniła plików cookie na moim komputerze. Jest to oczywiście ich porażka, ale mam na myśli, że w tej chwili uwierzytelnianie dwuskładnikowe nie jest wybawcą. Osoba atakująca może dość łatwo przechwycić pliki cookie i wykorzystać je na własne żądanie. Ponadto, ponieważ nie ma sposobu, aby dowiedzieć się, czy ktokolwiek wykorzystał ten błąd (nawet dla administratorów systemu), jedynym bezpiecznym założeniem jest to, że został on wykorzystany. Wiem na przykład, że chase.com był nadal podatny na atak od środy rano. Mało prawdopodobne, że napastnicy tego przegapili.
CrazyCasta
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.