Jó kis post! :)

Nekem a filippo.io/Heartbleed/ oldal semmire nem hoz semmit... szerintem úgy szét van terhelve mint az állat :)

Uhh, nice! Ezt a TLS Heartbeat Extension-t nem ismertem. Most belenéztem az RFC-ébe, de felmerült egy-két kérdés bennem... OK, hogy OpenSSL by default ezzel együtt fordul és -DOPENSSL_NO_HEARTBEATS kapcsolóval ki lehet hagyni, de ha jól látom, akkor valami szerver (?) oldali konfigban megadva a "peer_not_allowed_to_send" értéket eleve el kellene dobnia a beérkező request-eket, nem? És akkor a payload sem jutna érvényre...

"A peer [...] can also choose whether it is willing to receive HeartbeatRequest messages and respond with HeartbeatResponse messages or only willing to send HeartbeatRequest messages. The former is indicated by using peer_allowed_to_send as the HeartbeatMode; the latter is indicated by using peer_not_allowed_to_send as the Heartbeat mode."

Másrészt, ha be is esik egy payload-os request, akkor pontosan milyen adatfolyamot érhet el a támadó? Ha TLS "Application Data" férhető hozzá, akkor pl. az egyeztetett szimmetrikus (pl. AES) kulcs kieshet (?) belőle, session-t elveszi a támadó, szuper, de web szerver aszimmetrikus (pl. RSA) titkos kulcsa csak akkor nyerhető ki, ha "Handshake" adatfolyamot szippant ki, nem? Mondjuk ez sem gond, mert pl. egy netbanki szerveren biztos lefut sok-sok "Handshake" percenként, szóval, a sérülékeny netbanki szervereknél gyakorlatilag már simán kikerülhettek az RSA titkos kulcsok (hacsak nem HW-s RSA kulcstároló volt bekötve az Apache/mod_ssl hátterében ld. "SSLCryptoDevice" direktíva). Náluk javítás után kulcs- és tanúsítványcsere kötelező lesz, gondolom. A DH/DHE (PFS-nek megfelelő) algoritmusok használata esetén viszont valóban jobb a helyzet, azoknál javítás után nem lesz teendő (addig viszont ők is leak-el(het)ik a DH protokoll során egyeztetett szimmetrikus kulcsokat). Még a session átvétele ellen esetleg jó lehet a "SSLSessionCacheTimeout" lecsökkentése, de ettől még, ha az adott "Application Data" adatfolyamhoz kapcsolódó szimmetrikus kulcsot már kinyerték, akkor a benne levő adatot attól még meg tudják fejteni, nem? Lehet, jobban járnak, ha lelövik a sérülékeny szervereket, amíg nem tudnak javítani... Tényleg fejlövésnek tűnik! :D

@Aron bacsi: Az application stream-je plaintextben hozzáférhető, ezt te is letesztelheted könnyen tetszőleges vanilla trigger scripttel. PFS-el az a baj, hogy sok júzer böngészője nem támogatja. HSM nyilván sokat segít. A kulcsok hozzáférhetőségével kapcsolatban szerintem még várjunk egy kicsit, hátha a felfedezők kiadnak egy bőbeszédűbb anyagot.

www.ssllabs.com/ssltest/analyze.html?d=netbank.erstebank.hu

This server is vulnerable to the Heartbleed attack. Grade set to F. (Experimental)

The server does not support Forward Secrecy with the reference browsers.

Erste Netbank még mindig sebezhető, epic fail.

Erste ráadásul pár napja kivette a lakossági netbankból a kétfaktoros azonosítás belépéskor. Okos.

A legjobb, telefonon azt javasolják, változtassam meg a jelszavamat. Mondom rendben, de hasztalan, mert amíg nem javítják a hibát az új jelszavamat ugyanúgy el tudják lopni Erre már nem tudott mit mondani.

@igorx: A kétfaktoros elvileg visszakapcsolható a felületen.

@buherator: Igen, de az átlagos felhasználók többsége nem fogja. Nekem vállalati van, ott van kétfaktoros.

@igorx: Sajna, az sem megoldás. Ha már az ERSTE RSA titkos kulcsa kiszivárgott, akkor man-in-the-middle is lehetséges, és ha közbeékelődött támadón keresztül küldöd az SMS egyszeri jelszavadat a webes form-ban, akkor azt a támadó fogja továbbjátszani és vele épül ki a netbanki session. Szóval, ez ellen nem véd... ERSTE-nél OpenSSL/mod_ssl frissítés ÉS kulcs/tanúsítványcsere kell (+ PFS miatt DH-ra való átállás)! Utána lehet netbankolni ismét biztonságosan!

@Aron bacsi: Így van, ezért sem használtam tegnap óta, most mehetek be papír alapon utalási megbízást adni.

Telefonos kisasszonynak is a man-in-the-middle-t próbáltam konyhanyelven leírni, de "megnyugtatott", hogy tudnak a problémáról, változtassak csak jelszót :)

"Telefonos kisasszonynak is a man-in-the-middle-t próbáltam konyhanyelven leírni, de 'megnyugtatott', hogy tudnak a problémáról, változtassak csak jelszót"

XD

"The bug has been patched. After you patch your systems, you have to get a new public/private key pair, update your SSL certificate, and then change every password that could potentially be affected. [...] At this point, the probability is close to one that every target has had its private keys extracted by multiple intelligence agencies. [...] Has anyone looked at all the low-margin non-upgradable embedded systems that use OpenSSL?"

www.schneier.com/blog/archives/2014/04/heartbleed.html

Több cikk, köztük a debian első reportja azt írta, hogy az 1.0.1g már jó. Pedig úgy tűnik nem, ki is jött egy 1.0.1g-2 a debian source között.

@boldii10: A második patch annyiban különbözik, hogy újraindítja az érintett szolgáltatásokat - ezt egy valamire való rendszergazda is megteszi.

twitter.com/buherablog/status/453486827429969920

@buherator: Saját tapasztalatom szerint a sima 1.0.1g nem volt elég, a kedvedért: újraindítással sem.
A DSA 2896-2 már
"For the unstable distribution (sid), this problem will be fixed soon."
ezt tartalmazza, míg a -1 szerint az 1.0.1g-1 már jó.

Nem szeretem, amikor összevissza kavarnak, és nem mondják meg világosan, hogy tévedtek (ha egyáltalán az volt az eset).

@boldii10: Nálunk az 1.0.1g megoldotta a problémát, de tény, hogy a restartokkal volt szívás (ld. twitt). A javítást magad ellenőrizted, vagy a checker szolgáltatásokon keresztül? Utóbbiak nekünk is adtak FP/FN-t.

@buherator: A sok gépből kettőn volt gond, mindkettőn forrásból volt telepítve az openssl. Az első javítás (egyik gépen "e" verziós, másikon "g") után mind a flippio mind a possible.lv (utóbbi stabilabb) hibásnak jelezte.
Az újraindítás annyira megvolt, hogy kínomban még az apache-ot is újrafordítottam, hátha... (és persze újraindítottam)
Végül a -2 verziók telepítése óta nem ad pozitívokat. A leírásokból én is úgy értettem, hogy a -2-ben nincs új védelem, csak a restart, de gyanús nagyon a dolog...

@boldii10: na most bemérgelődtem és letöltöttem a g-1 és a g-2 patched és összediffeltem, látszólag tényleg csak az újraindítást módosították, tehát innentől az eset átkerül a megoldatlan rejtélyek közé...

Tudnak bármit csinálni mitm nélkül?

@TF113: Igen, random memóriaterületek kerülhettek elő a támadóknál. Korábbi loginok, sessionök, bármi.

Az én kérdésem talán komplexebb: mennyit segít a grsecurity- pax - clear after free patch-e? Nem vagyok szakértő, de legalább ami free-zve volt, azt nem lopták el, De vajon mi az ami nincs free-zve. Végzett valaki valami vizsgálatot a témában?

@boldii10: Az OpenSSL saját memória cache-e miatt nehezebb az ilyen jellegű védekezés, mint normál esetben:

article.gmane.org/gmane.os.openbsd.misc/211963

Nem mintha bárki is meglepődne rajta: www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html

BTW, ha már 2FA... A szerver RSA titkos kulcsokon kívül... Ha tetszőleges 64k memóriát ki tudtak olvasni a szerver memóriából, akkor pl. GMail vagy Facebook 2FA (náluk: TOTP-s, szimmetrikus) felhasználói kulcsait is kinyerhették, azaz azokat is cserélnie kell a júzereknek, nem?

www.cloudflarechallenge.com/heartbleed

Azért tutti ami maggifix, az Erste cserélt tanúsítványt. És igen, visszakapcsolható az SMS, de már pénzért. A biztonságért most már fizetni kell!