Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

OpenSSL - Fejlövés

2014.04.08. 10:35 | buherator | 25 komment

Az OpenSSL 1.0.1-es főverziójában olyan problémát azonosítottak, ami távoli támadók számára kiszivárogtathatja a kommunikációs csatornák titkosítására használt privát kulcso(ka)t. Igen, jól olvastátok, a hibán keresztül kiszivárgohat a szerver tanúsítvány privát kulcsa is, amivel aztán minden korábbi illetve jövőbeni kommunikáció megfejthető (a Perfect Forward Secrecy-t implementáló csatornák védettek a retrospektív támadásoktól). 

A sérülékenység egy memóriatartalom kiszivárgását okozó implementációs probléma a TLS protokoll heartbeat kiegészítésében, melyen keresztül egyetlen csomag elküldése után legfeljebb 64k adat olvasható ki az érintett processz memóriájából. 

A problémát az OpenSSL könyvtár 1.0.1g változatában javították, az 1.0.0 és 0.9.8 főverziók nem érintettek.

Az OpenSSL csomagot a világ webkiszolgálóinak 66%-a használja, az értinett verziók már két éve forgalomban vannak. Néhány népszerű, valószínűleg érintett Linux disztribució:

  • Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
  • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
  • CentOS 6.5, OpenSSL 1.0.1e-15
  • Fedora 18, OpenSSL 1.0.1e-4
  • OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
  • FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c)
  • NetBSD 5.0.2 (OpenSSL 1.0.1e)
  • OpenSUSE 12.2 (OpenSSL 1.0.1c)

A sérülékenység kihasználása a szerver oldalon nem hagy nyomot ezért a legrosszabb esettel számolva elméletileg minden érintett verziót futtató szolgáltatáson tanúsítványt kellene cserélni a szoftver frissítése mellett. Nem zárom ki, hogy az ügyesebb támadók már gyűjtögetik a nagyobb bankok és levelző szolgáltatók kuclsait... 

Ezen a linken tesztelhetitek a saját (HTTP?) szervereiteket
(A szolgáltatás elég pontatlanná vált az utóbbi időben, javasolt helyi példányokkal tesztelni.)

És ma az XP is megdöglik...

Friss: Itt olvasható egy részletes leírása a problémának (ha a fent linkelt git commit nem lenne egyértelmű). A szerző szkeptikus a privát kulcsok kiolvashatóságával kapcsolatban (bár nem zárja ki a lehetőséget). Én teszteltem párat és azt kell mondanom, hogy ha privát kulcsokat nem is találtam, de kiemelten érzékeny adatokat simán meg lehet szerezni, minden érintett azonnal frissítsen! 

Friss2: Itt például kiesett egy plaintext jelszó a yahoo.com-ból.

 

Címkék: openssl fail heartbleed

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

MonDeekoma 2014.04.08. 14:55:18

Jó kis post! :)

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

Aron bacsi 2014.04.08. 15:43:46

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

buherator · http://buhera.blog.hu 2014.04.08. 15:51:23

@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.

Aron bacsi 2014.04.09. 09:02:57

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.

igorx 2014.04.09. 13:33:58

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

igorx 2014.04.09. 13:35:16

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.

buherator · http://buhera.blog.hu 2014.04.09. 13:45:06

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

igorx 2014.04.09. 13:47:38

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

Aron bacsi 2014.04.09. 14:08:30

@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!

igorx 2014.04.09. 14:13:03

@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 :)

floborm 2014.04.09. 23:22:58

"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

Aron bacsi 2014.04.10. 10:59:17

"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

boldii10 2014.04.10. 11:14:33

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.

buherator · http://buhera.blog.hu 2014.04.10. 11:21:48

@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

boldii10 2014.04.10. 11:26:41

@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).

buherator · http://buhera.blog.hu 2014.04.10. 11:32:27

@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.

boldii10 2014.04.10. 11:40:09

@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 2014.04.10. 11:47:05

@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é...

TF113 2014.04.11. 00:03:32

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

boldii10 2014.04.11. 01:34:58

@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?

buherator · http://buhera.blog.hu 2014.04.11. 09:23:11

@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

Aron bacsi 2014.04.12. 16:15:31

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?

iQwerty 2014.04.15. 14:34:05

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!