Heartbleed Bug - súlyos OpenSSL sebezhetőséget javítottak

Bug

Hivatalosan a CVE-2014-0160 azonosítót kapta az a súlyos OpenSSL sebezhetőség, amelyre Heartbleed Bug-ként is hivatkoznak. A biztonsággal foglalkozó Codenomicon Ltd. egy saját weboldalt készített a bugnak, amelyen minden fontos információt elérhetővé tett.

A Heartbleed bug lehetővé teszi bárki számára az interneten, hogy olvassa az OpenSSL szoftver sebezhető verziójával védett rendszerek memóriáját. [...] Ezzel lehetővé válik a támadók számára a kommunikációk lehallgatása, a közvetlen adatlopás a szolgáltatásoktól és felhasználóktól, illetve a szolgáltatások és felhasználók megszemélyesítése. [...] A támadó szemszögéből megvizsgáltunk a saját szolgáltatásaink közül néhányat. Megtámadtuk magunkat kívülről, anélkül, hogy nyomokat hagytunk volna. Bármiféle privilegizált információ vagy hitelesítő adat használata nélkül képesek voltunk ellopni magunktól az X.509 tanúsítványainkhoz használt privát kulcsokat, a felhasználóneveket és jelszavakat, az csevegés üzeneteket, az e-maileket, üzleti-kritikus dokumentumokat és kommunikációkat.

A hibát a Google Security munkatársa, Neel Mehta fedezte fel. A javítást Adam Langley és Bodo Moeller készítette el.

A részletek - benne a potenciálisan sebezhető operációs rendszerek listájával - itt.

( trey | 2014. 04. 08., k – 08:27 )

"Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug."

"Exploitation of this bug leaves no traces of anything abnormal happening to the logs."

--
trey @ gépház

( lacika v | 2014. 04. 08., k – 08:44 )

Ubuntu 12.04-ben már javítva:
openssl (1.0.1-4ubuntu5.12) precise-security; urgency=medium

* SECURITY UPDATE: side-channel attack on Montgomery ladder implementation
- debian/patches/CVE-2014-0076.patch: add and use constant time swap in
crypto/bn/bn.h, crypto/bn/bn_lib.c, crypto/ec/ec2_mult.c,
util/libeay.num.
- CVE-2014-0076
* SECURITY UPDATE: memory disclosure in TLS heartbeat extension
- debian/patches/CVE-2014-0160.patch: use correct lengths in
ssl/d1_both.c, ssl/t1_lib.c.
- CVE-2014-0160

Ubuntu 14.04-ben is javítva:
openssl (1.0.1f-1ubuntu2) trusty; urgency=medium

* SECURITY UPDATE: side-channel attack on Montgomery ladder implementation
- debian/patches/CVE-2014-0076.patch: add and use constant time swap in
crypto/bn/bn.h, crypto/bn/bn_lib.c, crypto/ec/ec2_mult.c,
util/libeay.num.
- CVE-2014-0076
* SECURITY UPDATE: memory disclosure in TLS heartbeat extension
- debian/patches/CVE-2014-0160.patch: use correct lengths in
ssl/d1_both.c, ssl/t1_lib.c.
- CVE-2014-0160

-- Marc Deslauriers Mon, 07 Apr 2014 15:37:53 -0400

( goodbyte v | 2014. 04. 08., k – 09:01 )

"Affected users should upgrade to OpenSSL 1.0.1g"

vajon AIX-on az alábbi verziók vajon melyik betűjelnek felelnek meg ?

szerk:
openssl.base 1.0.1.500 --> OpenSSL 1.0.1e
openssl.base 1.0.1.501 --> OpenSSL 1.0.1e

nem elírás az IBM szerint mindkettő az 1e-nek felel meg.

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

( answ | 2014. 04. 08., k – 08:47 )

Érdemes megnézni az ssl/d1_both.c változásait és elszörnyedni.

( uid_228 | 2014. 04. 08., k – 08:49 )

Ha még senki nem mondta volna, akkor: "újabb manyeyeballs success story". :)

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

( ncc1701 | 2014. 04. 08., k – 09:40 )

Éljen az unattended-upgrade csomag. :) Ma reggelre kaptam egy rakat mailt, h frissült a libssl1.0.0 openssl, tegnap reggelre pedig openssh-client openssh-server a csomagok.

Itt azt írja a srác a végén, hogy akkor tudják a kulcsokat kiolvasni pl, ha rögtön a foglalás után helyezkedik el a memóriában. Szerinte ez jópár rendszeren már nem így van, gondolom a randomizálás miatt is pl. Akkor egy modern kernellel pl nem egyszerű konkrét adatot szerezni nem?

--
http://pyftpadmin.earthquake.hu

A heartbleed.com -on viszont ezt irjak:

Can attacker access only 64k of the memory?

There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.

félig off:
egész véletlenül pont szombat óta beszüntették a 2-faktoros hitelesítést is. A spúr g*cik nem bírták kiköhögni annak a nyamvadt +1 db one-time-password SMS-nek az árát a havi számlavezetési díjból, és visszaléptek az évekkel ezelőtti szint elé (akkor még 1 azonosító, 1 login és a password kellett, most viszont már csak 1 azonosító és a password). This world is going straight to hell..

Megnéztem a demot. Már közel egy éve készülök bankot váltani, hát az erste kiesett. Mert az, hogy a belépés nem kétfaktoros, egye fene. De hogy bármilyen művelet elvégezhető (legalábbis a demo alapján) SMS-ben küldött kód nélkül...

Vodánál anyáztam egy sort amikor a beléptető rendszerükből kivették az SMS kódot. De ha a számlarészletezőre vagyok kíváncsi, akkor azért küldenek SMS-t és csak a küldött kód birtokában férek hozzá...

Unicredit netbankja rendben a teszt szerint + van token is... így a pénzemet nem a crackerek lopják továbbra sem, csak az állam :(

Mellesleg lecserélni valódi tanúsítványokat tömegesen nem lesz kis feladat a hitelesítő szervezeteknek sem... kíváncsi leszek kaszálnak vele egy nagyot vagy cserélik a még érvényes tanúsítványokat ingyen... gyanítom az első :(
--
Slapic

Update: a LoginŐr szolgáltatást be (vissza) lehet kapcsolni, csak nem nagyon kommunikálják (hogy finom legyek...)

A tranzakciók közül azokat lehet plusz sms nélkül elvégezni, ahol a címzett számlaszámra már volt sms-es "bólintás", és "megbízható" címzettnek jelölted - ekkor az adott számlaszámra történő újabb utaláshoz nem kell sms-es megerősítő kód, egyébként meg kell.

Belinkelnéd azt a hírdetményt, amiben ez kommunikálva van? Mert gondolom hírdetményben kötelesek az ilyesmit kiadni, nem sunnyoghatják el. Vagy mégis?

A "LoginŐr" sztringre természetesen a tetves keresőjük nem dobott találatot, gondolom full text search licenszre nem futotta már.

Mármint mit kell hirdetményben közzé tenni? Azt, hogy a webes szolgáltatáson módosítást hajtanak végre? Szerintem azt pont nem.

Bemész a netbankba, és az ügyfélszolgálatra kattintva meg fogod találni, hol lehet visszakapcsolni (Személyes beállítások, Belépési SMS kód) - azon a formon szerepel a "LoginŐr" elnevezés, és csak tippelem, hogy ez majd valamikor meg fog jelenni a hirdetményben/ászf-ben, mint díjköteles/választható extra szolgáltatás.

( gabor2 | 2014. 04. 08., k – 12:41 )

Ubuntu 12.04-en ha minden igaz ket csomagot kell upgradelni:

openssl
libssl1.0.0

A jo verzio : 1.0.1-4ubuntu5.12

Mindketto changelogjaban benne van a fix.

Az OpenSSH nem érintett a hibában. Theo de Raadt tegnap módosította az OpenBSD 5.5 errata oldalát, ahova felkerült a Heartbleed bejegyzés.

OpenBSD 5.5 errata 2, Apr 8, 2014: Missing bounds checking in OpenSSL's
implementation of the TLS/DTLS heartbeat extension (RFC6520) which, if
exploited, can result in a leak of memory contents.

After patching, private keys and certificates exposed to services running
this code (for example web/mail server SSL certificates) should be replaced
and old certificates revoked.

Only SSL/TLS services are affected. Software that uses libcrypto alone
is not affected. In particular, ssh/sshd are not affected and there
is no need to regenerate SSH host keys that have not otherwise been
exposed.

--
trey @ gépház

( bra | 2014. 04. 08., k – 13:58 )

En meg ugy tanultam az iskolaban, hogy amiben ssl van, az biztonsagos nem lehet. Orom latni, hogy a tudasom meg ma sem avult el. :)
--
zsebHUP-ot használok!

( uid_2813 | 2014. 04. 09., sze – 11:22 )

Mostmar ertem miert OpenSSL a neve. :)

( uid_2813 | 2014. 04. 10., cs – 13:15 )

Btw, arra gondoltam hogy ez mukodik-e visszafele is? Tehat egy szerver ugyanezekkel a heartbeat request-response uzenetekkel kitudna nyerni a kliens memoriatartalmat?
Ha ugyanez a kod fut le kilensen is, termeszetesen.

Az rfc-t atfutva nekem ugy tunik barmelyik fel kuldheti.

Nem lehet tudni hogy direkt volt-e, es ha igen mi volt a celja vele.
Ha jol gondolom eleg egy sebezheto klienst egy olyan web szerverre csalni ami kitudja hasznalni ezt a sebezhetoseget es a kliens gepenek a memoriatartalmat 'feltolti' a szerverre... Ehhez nem kell megprobalnia mas sebezhetoseg kihasznalni, programot telepitenie, stb.. Lelehet tiltva akar a javascript is es ugy is mukodik. Szolgaltathat akar valos, normalis adatokat is az a szerver.
Gondolom pl. az android openssl-t hasznal, es gondolom ezek nagy resze nem is fog kapni update-et. Bongeszo alltal tarolt jelszavakat esetleg igy is ellehet lopni.

Es ha nem hibas a gondolatmenetem akkor kis kreativitassal biztos lehet meg erdekesebb dolgokat talalni vele.

Szerk.: Masreszt a tamado hasznalhat nem sebezheto klienst - hiszen tud a hibarol - es nem kell felnie hogy visszanyal a fagyi, viszont a hiba 'multifunkcios' marad igy tobb lehetoseggel.

( uid_7086 | 2014. 04. 10., cs – 13:19 )

És mi van a kártyás fizetésekkel?
Olvasom mindenfelé, hogy cseréljünk jelszót. Ami egy bankkártya esetében nem kivitelezhető.
Arról is hallgatnak sok helyen,, hogy a cserének csak akkor van értelme, ha az adott helyen már javítottak a hibát és mélyen hallgatnak a kártyás vásárlásokról. Vajon honnan fogom megtudni, hogy kompromittálódott a bankkártyám? És azt, hogy javították-e a google-nél, yahoonál, mobilszolgáltatóknál, banknál stb stb stb.?

Arról a három számjegyről, ami többnyire a kártya hátoldalán, az aláírás mellett szokott előfordulni. Nem jut eszembe a pontos elnevezése.
Ezt kérik netes vásárlásokkor.
Persze lehet, hogy nem fogtam fel valamit az írásból, mivel félig alszom még most is. :)

Hát ja, csak a legtöbb helyen ez úgy néz ki (tfh dombornyomott MC), hogy kártya újragyártás X pénz (szám, CVC2, lejárat nem változik), addig a letiltás+újragyártás (változnak a kártyaadatok) kb 5*X.

Szóval ja, elméletileg le kéne cserélni a kártyákat, gyakorlatilag viszont kb. senki nem fogja ezt megtenni. Gondolom a webkártyásoknál is van valami költség, ha nem is ekkora.

Na ez az. Viszont az elég komoly összeg, ha úgy vesszük.
És kié a felelősség?
Kinek kell ilyenkor fedeznie a csere költségeit?
Mert ugye én nem tehetek róla, jóhiszeműen jártam el.
A bankom sem feltétlenül tehet róla, hiszen náluk nem szoktam kártyával fizetni.
Szóval elég gázos a dolog, akárhonnan nézem. :(

Van olyan bank, ami az automata által elnyelt/elveszett és megtalált/stb. kártyát is minden sokszó nélkül képes visszaadni az üf.-nek újraaktiválva - miközben ki tudja, kinek-minek került a kezébe meg leolvasójába... És csodálkoztak, amikor nem kértem vissza az elvesztés után azonnal letiltott plasztiklapot. A letiltási díjban ugyanis a kártyacsere költsége nincs benne...

Arra gondoltam, hogy elméletileg a kártyám 3 vagy 4 jegyű kódja csak a bankomnál van eltárolva.

Ha valahonnan kikerült, akkor valószínűleg őtőlük.

Így ha cserélni kell a kompromittálódás miatt a kártyát, akkor őnekik kellene a költséget átvállalni.

Úgy emlékszem egyébként amikor korábban kártyaadatokat loptak, akkor is mindig a bankok kezdeményezték az ingyenes kártyacserét mindenkinél, akiről úgy gondolták, érintett lehet.

Mondjuk van egy Erste kártyám és az OTP felületén rendezem a mobil számlámat.
Itt valaki lenyúlja azt a bizonyos kódot.
Hogy bizonyítom később, hogy az OTP-nél használták ki ezt a hibát és jutottak hozzá a kártyám adataihoz?
(Csak példa, fogalmam sincs, az OTP érintett-e egyáltalán)
Erste ilyen esetben nem hibáztatható, viszont én velük vagyok kapcsolatban.
Akkor most mi van?
Álljam a csere költségeit?
Kockáztassam, hogy illetéktelen kezekbe kerülhettek az adataim?

Szóval akkor azt gondoljuk, hogy nem kell, hogy tárolják a különböző kódokat, elég, ha egyszer beírtam, és ők csak továbbították, akkor is a memóriában marad eléggé sokáig ahhoz, hogy érdemes legyen azt támadni.

Tehát amit feljebb írtam, arra az a válasz, hogy rosszul gondolom.

Valahol, valaki, valamit félreért :)
Amennyire tudom, ezek a kártyás fizetések úgy működnek, hogy van kifejezetten a fizetésre szakosodott cég, aki mondjuk a webáruházzal szerződött és a fizetés rajta keresztül bonyolódik.
Tehát pl. (hasraütéses alapon mondok valamit) van egy Vodás előfizetésed, akkor bejelentkezel az ottani online felületre, jelzed, hogy rendeznéd a számládat, az a számlázási adataiddal továbblök az OTP e célra létrehozott felületére és ott tudod rendezni a kártyás fizetést.
Ezzel az egésszel akkor van gond, ha az OTP támadható verziójú openssl-t használ azon az oldalon, mert akkor onnan - a jelek szerint észrevétlenül (????) - le tudják nyúlni az adataidat, köztük a kártyás fizetéshez szükséges valamennyi adatot. (a csillagok bizonyos állása esetén - teszem hozzá, mert úgy tűnik, azért nem annyira triviális ez a lenyúlás, ahogy elsőre gondoltam és ahogy egyes hírek alapján következtetni lehetett rá)

Erre mondjuk pont nem kell annyira ráparázni, a bankkártya csalások elég gyakoriak, bejáratott ügymenet van, a bankok meg biztosítva vannak.

Pl az én esetemben úgy nézett ki a dolog, hogy valaki elkezdett vásárolgatni a kártyámmal valahol Texas-ban (valószínűleg klónozták, kizárásos alapon egy hónappal korábban a skóciai nyaralásomon).
Kb a 3. vásárlás után vettem észre az sms értesítéseket, felhívtam a megfelelő számot, mondtam, hogy látok ilyen vásárlásokat, de én bizony otthon ülök, és a kártyám a tárcámban...

Letiltották, hét múlva mentem új kártyáért, a pénzt visszakaptam, kártyáért nem fizettem.

Nyilván az én esetem egyértelmű volt, de igazából ha bizonyítod, hogy nem te vásároltál (pl mert pl valaki weben vásárolt zimbabvei címre), akkor nem érhet kár.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Két módja is van:
- Amikor a támadó végigolvasta a webszerver memóriáját, te épp bejelentkeztél, így a memóriában volt a kódolatlan user neved és jelszavad
- Miután a támadó mmegszerezte a privát kulcsot, képes volt lehallgatni a forgalmat, amit a kulccsal dekódolni tudott

Biztos vagyok benne hogy egy ilyen egyszeruen kihasznalhato lyukat nem kezdtek el rogton kihasznalni... :) Ennyire meg en sem vagyok naiv.
Szerintem jopar emberkenel mar betelt nehany vinyo szerverekrol 'letoltott' adatokkal amig meg _nagyon sok_ a nyitott szerver, kesobb meg raer kimazsolazgatni vagy toolt irni hogy osszelegozza a memoriaterkepet.

Én azt nem tudom, mennyi esélye van, hogy egy mindenféle szeméttel teli memóriadumpból kitalálja, hogy az a 6 karakter az egy jelszó/usernév, ilyesmi vagy egy szöveges dokumentum része, esetleg csak random adat. Vagy esetleg egy 7 karakteres jelszó/usernév egy része. Vagy egy 5 karakteres jelszó/usernév + 1 karakter szemét.

Illetve a külön dumpokból melyik karakterhalmazok tartoznak egy usernév / pass kombinációba, illetve egy dumpon belüli több usernévből és jelszóból melyek tartoznak egymáshoz.

Próbálgatnak?

A HTTP protokol szintjen mar igazan mindegy, hogy GET (URL-ben van az adat) vagy POST (header-ben van az adat) a hasznalt modszer. ;)
A lenyeg amugy az, hogy korlatlanul lehet ujra probalkozni, igy elobb vagy utobb lesz abban a 64kB-ban hasznalhato adat.
Azt se felejtsd el, hogy az adott processz nem mindig a kerneltol kap uj memoriat, hanem ujrahasznalja az ujonnan felszabaditott memoriateruleteket. A felhasznloktol kapott adatok a protokol interaktivitasa miatt gyakran valtoznak, mig az adott alkalmazas tobbi adatstrukturaja hosszu eletu. Igy jo eselye van annak, hogy felhasznaloi adat lesz a valaszban.

( okcomputer44 | 2014. 04. 10., cs – 14:53 )

2 pfSense verzio is erintett az ugyben es meg nincs javitas: https://redmine.pfsense.org/issues/3588 (pfSense 2.1, 2.1.1)
+ OpenVPN is erintett: https://community.openvpn.net/openvpn/wiki/heartbleed

Ha "OpenSSL 0.9.8n" verziod van a pfSense-en, akkor nem vagy erintett a dologban.
Ha ujabb verzio akkor gaz, mert minden cert-et vissza kell vonni es ujra generalni es elkuldeni a usereknek. (ha elkeszult a patch)

OpenVPN:
###########################
Update your OpenSSL library
Revoke your old private keys
Generate new private keys
Create certificates for the new private keys
###########################

Nice! ;)

( johans | 2014. 04. 10., cs – 18:35 )

Kijött a Google első kommunikációja. Vannak érintett 4.1.1-es androidok.

( handler | 2014. 04. 10., cs – 22:33 )

Alexa top1m site bongeszheto/letoltheto, es meg mindig van tobb mint 8ezer .hu domain, amely sebezheto!

"As of 4:00 PM on April 9, 2014, we found that 34% of the Alexa Top 1 Million websites support TLS. Of the websites that support HTTPS, 11% are vulnerable, 27% safely support the heartbeat extension, and 61% do not support the heartbeat extension (and are therefore safe)."

https://zmap.io/heartbleed/

( bra | 2014. 04. 11., p – 12:58 )

Volt mar dolgom olyan ceggel, ahol minden szoftverre feature matrixot kellett kesziteni, megjelolve azt, hogy mi kell belole. Amire nem volt szukseg, azt mind ki kellett kapcsolni (./configure szinten, de volt, hogy sajat branchben kellett ifdefezni kod blokkokat).
Itt speciel ez a modszer vedelmet adott volna. Nyilvan ez is csak egy, a hagyma sok hejabol.
--
zsebHUP-ot használok!