9:17
8/4/2014

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, któremu nadano nazwę Heartbleed, 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 na samym serwerze. 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 (np. TOR-a lub klienty IM). 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 i podatne na atak Heartbleed?

Wczorajsze advisory OpenSSL poinformowało o błędzie (którego ochrzczono jako Heartbleed), 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 OpenSSL nie są podatne na Heartbleeda, 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_

…chociaż Bitcurex upiera się, że to nieprawda:

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, czy jestem podatny na Heartbleed? 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.

Należy podkreślić, że w zasadzie, ponieważ mamy do czynienia z wyciekiem pamięci serwera (dokładnie 64kb), atakujący może pozyskać (przy sprzyjających okolicznościach) wszystko co znajduje się w pamięci serwera, tj. zarówno klucze prywatne do certyfikatów jak i hasła czy tokeny sesyjne (akurat przetwarzane przez aplikację). Jak pozyska klucz — może podszyć się pod serwer lub deszyfrować ruch skierowany do oficjalnego serwera (i wyławiać ciasteczka/tokeny sesyjne innych użytkowników). Jak pozyska hasło administratora… to wiadomo ;)

Dlatego, po aktualizacji OpenSSL należy rozważyć:

  • Wymianę certyfikatu SSL na nowy (to może wiązać się z kosztami zakupu nowego certyfikatu — ale miejmy nadzieję, że część z wystawców certyfikatów stanie na wysokości zadania i umożliwi darmową wymianę.)
  • 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. Co więcej jeśli serwer nie wspierał tzw. Forward Secrecy, za pomocą pozyskanego klucza można również zdeszyfrować starszy ruch szyfrowany do serwera, o ile atakujący posiada jego zapis.

Heartbleed – dodatkowe informacje

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 Heartbleed 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 Heartbleed 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. Z tego samego względu warto włączyć silniejsze logowanie sesji TLS na ew. urządzeniach typu IDS/IPS.

Przeczytaj także:


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

118 komentarzy

Dodaj komentarz
  1. Na szczęście nie używam SSLa. Uffff nikt mnie nie podsłucha przy pomocy Heartbleed :)

    • merytorycznie co to wnosi do dyskusji? NIKOGO nie interesuje co Ty masz a czego nie masz, a więc będą internetowym ekshibicjonistą “nie jarasz” czytelników niebezpiecznika a co najwyżej siebie…
      Czy wiesz co należy z tym zrobić…?

    • Akurat jeśli nie używasz SSL tym bardziej jesteś narażony, ale widocznie bycie ignorantem w pewnych kwestiach jest szeroko już rozpowszechnione :P

    • @root zapomniał napisać ironia=on Ironia=off i już się denerwujecie… Gdzie poczucie humoru? :)

    • Tacy spece, a nie potrafią zauważyć prostej ironii..

    • @somebuddy: takich “speców” jak ci wyżej to dzisiaj na pęczki. Ot kolejne marne worki mięsa z syndromem Stewiego Griffina dobrały się do klawiatury…

  2. Fantastycznie. Cieszę się, że tak szybko dowiedzieliśmy się o zagrożeniach…ehhh słabo mi, chyba się położę…

  3. Blad? He, he, he. Ktory to juz tego typu?

  4. Nie wyrobię zaraz – onet.pl podatny….

    • Cały dzień wczoraj mail.yahoo.com i fbi.gov były podatne ;)

  5. Po wymianie certyfikatu zalecam unieważnienie starego certyfikatu u dostawcy (CA). Jeżeli atakujący posiadł klucz prywatny, to może się dalej nim posługiwać, przechwytując ruch. Jeśli unieważnimy certyfikat, to zostanie on umieszczony na liście CRL (certificate revoke list), którą pobiera przeglądarka i zasygnalizuje błąd (lub ostrzeżenie) przy takim połączeniu.

  6. “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.”

    no tak ale jeżeli mam ECDHE_RSA to wykradzenie kluczy prywatnych naraża mnie właściwie na MITM, bo nawet jeżeli mają cały ruch sieciowy to nadal mam Forward secrecy

    • “no tak ale jeżeli mam ECDHE_RSA to wykradzenie kluczy prywatnych naraża mnie właściwie na MITM, bo nawet jeżeli mają cały ruch sieciowy to nadal mam Forward secrecy”

      Rozumiem, że mówisz o PFS (Perfect Forward Secrecy)?

      Tak jest to silna metoda, która powinna – ale nie musi – kwestia co atakujący zdobył i co Ty/Twój system przechowuje w pamięci… Czyli jak zwykle metoda implementacji.

  7. r00t czym szyfrujesz ?

    • Zgaduję: Rot-13

    • podwójnym rot13 ;-)

    • Kodem cezara. Do każdego bajtu dodaję jedynkę. Czasem dla utrudnienia do każdej 4-bajtówki zamiast do bajtu.

  8. “youtube.com IS VULNERABLE”.

    Fajnie…

    • Jakaś paranoja. Wykrył to koleś z googla, a gmail jest podatny…

    • Jak testowałem to 2h temu już podatności na gmail-u nie było.

  9. http://filippo.io/Heartbleed/#mail.yahoo.com
    mail.yahoo.com IS VULNERABLE.

  10. Coś dziwnego… chwilę temu widziałem informację, że strona jest podatna, a po kolejnej próbie już jest ok… Ciekawe…

    • Wspominali u siebie na stronie, że mogą być false negatives (a wczesniej, że false positives; tyle, że się rąbneli ;)).
      Na Githubie mają jakiśtam skrypcik do sprawdzania lokalnie danego adresu – dzięki czemu “faktyczny” stan się otrzymuje.

  11. Podana przez Was stronka do sprawdzania podatnosci srednio dziala raz pokazuje ze adres jest podatny raz ze nie.

  12. Nie używam ssl a jednak moja www jest podatna, co wtedy robić?

    • Zignorowac ;) Widac stronka do sprawdzania podatnosci to fake

    • Na początek zamów testy penetracyjne, najlepiej według standardu owasp asvs level 2a, w raporcie będziesz miał napisane co zrobić.

  13. Oczywiście Getinbank leży i kwiczy
    secure.getinbank.pl

    • Sprawdziłem zaraz po 9 i nie był podatny, więc nie wiem o czym mówisz

  14. Własnie na debianie wpadły nowe paczki

  15. Kolejny test via www http://possible.lv/tools/hb/

    I coś do testów lokalnych https://github.com/titanous/heartbleeder

  16. kaspersky.com:443 IS VULNERABLE.

    słodko….

  17. W przypadku Redhat/Centos nie jest wymagane podniesienie do wersji 1.0.1g, ponieważ wersja 1.0.1e relase 16.el6_5.7 według yum built on: Tue Apr 8 02:39:29 UTC 2014 łata podaną podatność przynajmniej według RHSA-2014:0376-1, ale sam nie testowałem;)

    PS: a skąd wiecie że podana stronka nie daje fałszywych rezultatów i nie zapisuje sobie danych adresów? Po co skanować serwery pod kontem dziury szybciej i łatwiej jak pipole sami podadzą adres ;)

  18. Jak długo trzeba czekać na wynik analizy z filippo.io?

  19. Przecież wiadomo nie od dziś NSA wstawia do OpenSource projektów backdoory, wszystko musi być pod kontrolą

  20. Nic w tym dziwnego, ludzie sprawdzaja czy sa podatni i wgrywaja laty, ot i powod roznych wynikow. Na chwile obecne sa podatne przynajmniej 2 polskie banki, moze byc ich wiecej.

  21. ten test to chyba narzędzie do zbierania danych o tym co ludzie wpisują , za pierwszym razem plus.pl pokazało IS VULNERABLE a za drugim że jest ok ….

    • może akurat załatali? :)

    • w 5 sekund, nieźle szybko łatają

  22. interia.pl jest ok, ale już
    poczta.interia.pl IS VULNERABLE

    • już jest ok

  23. No przecież nawet geniusze w wp.pl stwierdzili, że Open Source jest “beee”.
    Punkt 10 tego ich dekalogu:
    http://tech.wp.pl/kat,1009785,title,Poradnik-10-zasad-jak-bezpiecznie-korzystac-z-routera,wid,16514966,wiadomosc.html
    lol

  24. My jesteśmy ok. Bez problemów. Test wypadł pozytywnie.

    • I tak nikt nie bedzie wchodził na jakąś lewą stronę.

    • Błąd logiczny na końcu komentarza.

  25. Dodam, że na jednej z grup na TOR od pół roku staramy się znaleźć remedium na inną dziurę SSL i nie dajemy rady. NSA jest na razie krok przed nami. A oto ta dziura w skrócie:

    openssl req -out MYCSR.csr -pubkey -new -keyout xxx.key
    openssl x509 -x509toreq -in MYCRT.crt -out MYCSR.csr -signkey xxx.key
    openssl req -x509 -new -out MYCERT.crt -keyout xxx.key -days 30

    potem następuje dodanie.
    Więcej info na TOR 2 peron 9 i 3/4 dirrection hog+wart.

  26. ingbank.pl też podatne :(

    • ing już nie

      ipko jeszcze tak

  27. Dzięki za link do tej strony do weryfikacji bo gdyby nie to to bym pewnie olał sprawę a tak już załatane.

  28. Ciekawe kto jest odpowiedzialny za ten blad i czy jest oplacany przez NSA.

  29. Uuuu, grubo.

  30. platforma epuap również podatna na atak :/

  31. Nie wiem czy dobrze kombinuję, ale jeśli możliwe jest podsłuchanie komunikacji do serwera to przy połączeniu, które nawiążemy w celu aktualizacji, ziemny certyfikatów itd. będzie można poznać hasło/klucz do połączenia. Również przesłanie nowego certyfikatu/klucza będzie podsłuchane. Czyli wszystkie zmiany muszą być zrobione z sieci wewnętrznej lub bezpośrednio na serwerze. Czyli jest dość duży problem (w takim przypadku najgorzej jest z serwerami stron w TORze).

    Sam TOR teraz też jest bardzo podatny, wszystkie maile w TORze, sklepy, markety, itd.

    Skoro błąd już jest znany, można podejrzewać że rozpocznie się masowe szukanie podatnych maszyn, kradzieże loginów i haseł do wielu usług i jeśli uda się posłuchać hasła/klucze przy logowaniu na konto root-a to rozwój botnetów.

    Jeśli z czymś się mylę to proszę o poprawienie mnie, ale jeśli mam rację to jest… ciekawie…

  32. Przetestowałem swój serwer i nie było podatności, później zaktualizowałem wszystkie pakiet przy pomocy apt-get i serwer stał się podatny. Wytłumaczy mi ktoś czemu tak się stało i co z tym zrobić?

    • Może miałeś na serwerze OpenSSLa starszego niż 2 lata? :)

    • Środowisko opensource’owe od zawsze było pełne agentów. Vide TrueCrypt stworzony przez Mosad.

    • Hm, pewnie miałeś stare i niepodatne na heartbeat wersje ;d
      Zaktualizowałeś do nowych – dziurawych (lub false positive z przeciążenia sprawdzajki)…

      Anyway, jeśli to debian to jest inna możliwość:
      – wczoraj były aktualizacje openssl (nie znam stanu)
      – dzisiaj rano była aktualizacja openssl – po tej aktualizacji byłem “dziurawy” (ps. ciekawostka – nie chciała restartów serwisów używających openssl, zrestartowałem ręcznie myśląc że coś im się walnęło).
      – dzisiaj po południu była KOLEJNA aktualizacja openssl – tym razem chciało restartów wielu serwisów: apache, bind, ssh, itd. – po tej aktualizacji nie jestem “dziurawy” …
      Dziwne.

    • System to najnowszy debian, więc 2 lat nie ma. Ostatnio aktualizacje instalowałem kilka dni temu.

      Możliwe że masz rację, bo to chyba było po dzisiejszej porannej aktualizacji.

  33. > 2014
    > używanie OpenSSL
    Serio?

    • A czego innego używać?

    • @morsik obecnie wszystko przesyła się plaintextem bo każdy próbuje wszystko odszyfrować, a plaintextu nie złamią!

    • Iczywiście używa się implementacji protokołu SSL dostarczonej przez poważne firmy, jak np. RSA. Dodatkowo ich implementacja używa certyfikowanego generatora kuczb pseudolosowych opracowanego przez uznanych matematyków a nie implementacji 15-letniego Wojtka co dopiero nauczył się jak używać rand().

      No i formularz nie chce zapisywać imienia/e-maila, co rusz to muszę wpisywać. Bleh. Jak by to stało na vBulletinie czy XenForo to by się takie rzeczy nie działy.

    • @William Gates
      Przez uznanych matematyków z NSA, chciałeś powiedzieć.
      http://www.techienews.co.uk/973955/report-nsa-paid-rsa-10m-use-dual-ec-drbg-preferred-random-number-generator/

  34. kb24.pl podatny

    • Sprawdzałem koło 16 dwoma narzędziami i nie był podatny.

    • Dziwne, bo w momencie napisania postu wywalało, że był.
      Po kilku minutach później sprawdziłem ponownie i nie był.

  35. LoL. Niestety nie wszystkie hostingu typu Zen są bezpieczne: http://filippo.io/Heartbleed/#zenbox.pl is VULNERABLE

  36. Z dziury na pewno skorzystało NSA i inne służby.

  37. Ok, ale nie wiem po co robicie blur postaci ASCII w screenshotcie skoro obok zachowaliście postać heksadecymalną? ;-)

  38. Kolejna Firma Hostingowa
    globalnetwork.pl:443 IS VULNERABLE.

  39. Witam
    Czy ktoś moze mi powiedzieć czy wystarczy pobrac i skompilowac (https://www.openssl.org/source/openssl-1.0.1g.tar.gz) openssl w wersji g i zrobic symlnk do nowej paczki czy to nie wystarczy? bibloteki np.?

    • Trzeba podmienić binarkę openssl, binarkę libssl no i zrestartować apacza czy co tam korzysta z tych libów.

  40. A jak taki błąd wykorzystać?

    • Nie rób tego synu…

    • Szybko.

  41. Dzieki chlopaki, jako jedna z niewielu stron w Polskim necie w ogole poruszacie kwestie w dniu dzisiejszym. Wczoraj w nocy cos pobrzmiewalo na Reddicie… Testowalismy na naszym systemie dzis po poludniu i troche mnie prezerazily efekty…

  42. Przekazywanie krytycznych danych najlepiej dodatkowo szyfrować w warstwie aplikacji i/lub przekazywać fragmenty tych danych różnymi kanałami.

    • O RLY?

    • Tak serio – to najlepiej było by aby serwer przechowując twoje zaszyfrowane dane, nie znał i nie przechowywał twojego sekretu… są takie rozwiązania i jest kilku dostawców tak implementujących (celem wysokiej skuteczności) swoje zabezpieczenia..

  43. wydaje mi sie ze ani chrome ani ffoz nke korzystaja z crl:

    https://news.ycombinator.com/item?id=7556909

  44. dla wszystkich zainteresowanych:


    $echo -e “quit\n”
    openssl s_client -connect yahoo.com:443 -tlsextdebug 2>&1
    grep ‘TLS server extension “heartbeat” (id=15), len=1’

    ;)

  45. Jakby napisali to w Javie, to by taki błąd nie był możliwy. Ech, 2014 rok, a ludzie nadal używają technologii z lat 70-tych.

    • Tam gdzie liczy się wydajność nie ma miejsca na języki typu Java…

    • Zawsze mnie bawią wypowiedzi ludzi twierdzących że najlepsze są języki wysokiego poziomu… Języki wysokiego poziomu nie dają takiej kontroli nad działaniami programu jak języki niskiego poziomu. Dlaczego kiedyś aplikacje, które coś robią działały szybciej, niż dzisiejsze aplikacje które robią to samo? Bo były pisane w językach niskiego poziomu i nie używały bajerów takich jak Java/.NET. Java jest wygodnym narzędziem, .NET jest jeszcze wygodniejszy, dzięki temu można skrócić czas realizacji projektów i nie jest wymagana aż taka wiedza jak kiedyś, ale wydajność jest dużo mniejsza. Biblioteki, które muszą działać szybko i optymalnie, żeby zapewnić dobrą “szybkość” pracy serwerów muszą być napisane w językach jak najniższego poziomu. Oczywiście takie biblioteki javy nie nadają się do wielu rzeczy i wymagają javy, co po pierwsze narzuca pewne ograniczenia, a po drugie również pozostawia wiele do życzenia w kwestiach bezpieczeństwa – java jest strasznie dziurawa i przypuszczam że gdyby jej kod był otwarty to codziennie bylibyśmy informowani o błędach takich jak ten w openSSL.

      Jeśli się nie zgadasz to pokaż jakąś bibliotekę w javie o tym samym zastosowaniu co openSSL i udowodnij że działa porównywalnie szybko :)

    • Ja bym bardziej napisal ze tam gdzie przede wszystkim liczy sie bezpieczenstwo nie ma miejsca na wydajnosc.

    • Bezpieczeństwo – Java. Wybierz jedno.

    • Java to na pewno nie bezpieczeństwo. Java jest strasznie dziurawa.

  46. Może jednak warto podać listę banków dla których koniecznie trzeba zmienić hasła!

  47. Czy ktos wie jak dokladnie zrobic ten ekstrakt z memorydump ktory jest na printscr na niektorych stronach? Mamy u nas w LABie 3 rozne wersje ‘openssl.py’ – niby ze zrodla (albo mirror z Google), kazda z nich robi co innego. Ostatnia pokazuje tylko VUNL albo nieVUNL ;)
    Mozecie podeslac jakies linki lub instrukcje jak =udowodnic= ze nasze servery (czyt. moje z pracy) sa podatne na tego typu ataki…
    PS. Wiem, ze sa, ale chce dokladnie obcykac jak to dziala.

  48. Stosując prawo Murphy’ego i brzytwę Ockhama (dla niewtajemniczonych – to był taki słaby żart), dochodzimy do jednego wniosku. Wszelkie certyfikaty powinny być wymienione na nowe, za darmo, ponieważ czas życia nowo generowanego certyfikatu można “dziedziczyć” ze starego. Tyle nakazywała by uczciwość biznesowa, lecz centra certyfikacji zapewne odkryją nową żyłę złota

    • Powazne centra certyfikacji maja w tej chwili rownie wesole miny, co uzytkownicy ich certyfikatow. Nie wiem, jak zachowa sie broker brokera brokera wystawcy najtanszych certyfikatow, ale powazni wystawcy zachowuja sie w porzadku. Pewna polska firma certyfikacyjna – na moja prosbe certyfikat EV zostal dopisany do CRL w ciagu 1h, a nowy zostal wystawiony w 24h i to na caly okres (a nie okres poprzedniego certyfikatu). Jakbym grzecznie poprosil, pewnie wystawiliby tez za darmo certyfikat “przejsciowy”, ale dla swietego spokoju kupilem go za 50 EUR u innego wystawcy.

  49. Jakie są dokładnie tego konsekwencje to się jeszcze dowiemy. Narazie panika, heh. Jak Unizeto jest na giełdzie to chyba można śmiało akcje kupować :)

  50. Jakby kogoś interesowało zabezpieczenie serwerów do czasu załatania to na secliście pojawił się wpis jak zablokować ruch używający heartbeata:
    iptables -t filter -A INPUT -p tcp –dport 443 -m u32 –u32 “52=0x18030000:0x1803FFFF” -j DROP

  51. Z tego co mi wiadomo to heartbeat jest dodtkiem (pluginem) do openssl – powiedzcie proszę więc kto z tego pluginu korzystał “na codzień”, po co on był w ogóle itd.

    • To nie plugin tylko…
      Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) ***>Heartbeat Extension<***… "The Heartbeat protocol…" bo tak się go właściwie nazywa w rfc – nie jest wymagany, więc się go pomija w kompilacji – temu zapewne służy odpowiednia flaga wspomniana wyżej – tu masz szczegóły: https://tools.ietf.org/html/rfc6520 .

  52. piszę “pugin”, bo ponoć za pomocą magicznej flagi, openssl skompilować można bez tego bugu

  53. no i koniec TORa bo uwazam, że ten atak był od dawna skrupulatnie (i skutecznie jak widać) kierowany właśnie na TOR. Kto wiec mysli ze nadal jest w nim anonimowy, biada mu. Tak NSA sie rozprawiło z TORem. Odtąd nowym wersjom openSLLa tez nie nalezy ufac ! Już nigdy.

  54. […] jako jedni z pierwszych w Polsce zwróciliśmy uwagę na atak Heartbleed na OpenSSL. Przypomnijmy, że dzięki niemu atakujący może pozyskać dane, które znajdują się […]

  55. OpenSSL 0.9.8k –> “Server returned error, likely not vulnerable” :D … wsiom zalecam przede wszystkim pracę z firewallem i dogłębną analizę pakietów! Każda wersja ma jakiś swój mniejszy lub większy mankament więc opieranie się na samej aktualizacji nie jest do końca słuszne.

  56. I po update i wymianie certyfikatów okaże się że nowe także posiadają backdoora … ale dowiemy się dopiero za 2 lata … pewnie była potrzeba wymiany backdoorów to NSA sama ujawniła starą podatność by wymienić na nową …

  57. Umarłem, zamazali znaki ascii, zostawili bajty po lewej xD

  58. W World of Tanks oferują 300 “golda” za zmianę hasła – ciekawe czy jest jakiś związek z heartbleed`em? ;)

  59. […] jako jedni z pierwszych w Polsce zwróciliśmy uwagę na atak Heartbleed na OpenSSL. Przypomnijmy, że dzięki niemu atakujący może pozyskać dane, które znajdują się […]

  60. […] nagłośniony m.in. przez serwis Niebezpiecznik.pl, związany jest z narzędziem OpenSSL, które stosuje się przy szyfrowaniu SSL, będącym dla […]

  61. Ja rozumiem, że wszyscy są w szoku. Ale uściślimy: nie wystarczy zamówienie nowego certyfikatu, przecież klucze prywatne tez mogły zostać wykradzione więc po co nam nowy cert do skompromitowanych kluczy?

    Drogi Niebepieczniku, popraw w tekście tą informację, proszę:)

  62. […] donoszą serwisy poświęcone bezpieczeństwu ( niebezpiecznik.pl ) pojawiła się „nowa” krytyczna luka w OpenSSL. Co prawda jest to dziura mająca […]

  63. […] skoczną piosenkę). Pisaliśmy już co prawda zarówno o tym na czym polega atak Heartbleed, jak się przed nim ochronić …oraz uczulaliśmy was na to, że Heartbleed pozwala wykradać dane nie tylko z serwerów, […]

  64. […] Zwracamy uwagę wszystkich administratorów na wykryty niedawno błąd w OpenSSL. Jest to biblioteka wykorzystywana do szyfrowania połączeń na bardzo wielu serwerach, w szczególności mogą być narażone maszyny linuxowe, na których działa dLibra. Błąd umożliwia atakującemu odczytanie części pamięci serwera, co może prowadzić do wykradzenia kluczy szyfrujących, haseł użytkowników i innych ważnych danych. Zaleca się pilną aktualizację biblioteki OpenSSL do wersji 1.0.1g. Należy też rozważyć wymianę certyfikatów wykorzysytwanych do szyfrowania i zmianę haseł dostępowych do systemu, aby zabezpieczyć się przed możliwością wykorzystania danych skradzionych wcześniej (błąd występuje od dwóch lat, dopiero kilka dni temu został opublikowany). Więcej informacji można znaleźć na stronie heartbleed.com, a po poslku na niebezpiecznik.pl. […]

  65. Ja piernicze. Alez wy jestescie naiwni. Cala machina sluzb specjalnych wspolpracuje z producentami sprzetu a wy sie podniecacie takimi banalami. ;p

  66. […] który we wstępnym raporcie potwierdził brak jakichkolwiek backdoorów. A to w świetle ostatnich doniesień na temat błędu w otwartoźródłowym projekcie OpenSSL, znanegojako HeartBleed koiło […]

  67. […] “przebojowego” i “przerażającego” nazywania krytycznych podatności (por. Heartbleed i Shellshock). Brakuje mu też logotypu. Ale społeczność nie próżnuje. Już tworzy własne […]

  68. […] Podatność w Windowsach wpisuje się w czarne pasmo ujawnionych w tym roku poważnych błędów w innych stosach TLS-owych (por. Apple’owski goto fail i Linuksowy Heartbleed). […]

  69. […] przy okazji PR-owymi perełkami z własnymi logotypami i dedykowanymi stronami internetowymi). Był Heartbleed i Shellshock (bash bug), a teraz pora na GHOST, podatność typu buffer overflow, którą […]

  70. […] z wykorzystaniem tej podatności. Nie jest więc źle (a zwłaszcza tak źle, jak było w przypadku Heartbleeda, który po kilku godzinach od ujawnienia był aktywnie wykorzystywany do ataków). Exploit na […]

  71. […] ta dziura jest największą do tej pory odkrytą w Androidzie, a niektórzy wprost nazywają ją Heartbleedem w świecie […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: