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

 ( trey | 2014. április 8., kedd - 7:54 )

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.

Idézet:
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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"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

nice

"many eyeballs"

--
NetBSD - Simplicity is prerequisite for reliability

Gratulálok a dobogós helyezéshez!
--
♙♘♗♖♕♔

Tehát a legjobban az járt, akinek rég elavult szervere van :-)
Legalábbis ebből a szempontból biztosan...

--
Slapic

Ez a nap is jól kezdődik...

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

"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ó!"

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

A javítás előtt és után is szar. Egy jól definiált struktúrát hogy lehet ilyen megoldásokkal olvasni, hogy pl. hbtype = *p++;?

--

Restartold a service-t, ami hasznalja.

t

Az eredeti és javított forráskód minőségére gondoltam. Nekem semmi service-em alatt nem fut ilyen.

A hbtype egy unsigned short, a struktúrában a type egy int. Ezt így beolvasni szerintem egyenlő az obfuszkált kóddal.

--

Bbocs, osszezavartal:)

Lazy programming, but not productively lazy.

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

Felfedezték a hibát nem?

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

Ja, meg 2011-ben. :)

---
pontscho / fresh!mindworkz

Még szerencse, hogy van alternatíva, pl. GNUTLS! Oh, wait... :)

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

Bepoccintel egy izaszervert, oszt secure minden.
--
zsebHUP-ot használok!

Hamar munka ritkán jó.

Jó alaposan megnézve meg idáig tartott. :-)

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

Ha azt hiszed, hogy a problémát egy frissített csomag megoldja, akkor olvasd át még egyszer a hiba leírását.

Faja, jól hangzik a leírás is. Remélhetőleg nem találnak be hozzám. Mondjuk tűzfalon csak pár fixip-ről engedek belépést a szerverekhez, szóval ez egy kis biztonságot azért csak ad.

security through obscurity

Jaja. Ennél jobb megoldást még nem találtam, tök üres a fail2ban logja ezeknek a gépeknek.

Ez nem az. Olvass utána jobban. A forrás címek szűrése valódi védelmi réteg.

nekem sajnos most nincs időm hosszan olvasgatni.

Esetleg összefoglalnád, hogy mi kell az új csomagokon kívül?

Persze az összes jelszót lecserélem és új kulcsokat generálok, hiszen ezeket ellophatták, ha jól értem.

Mi egyéb teendőm van?

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 srác nem olyan kreatív, mint a brekkerek ;)

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.

https://netbank.erstebank.hu/ érintett a hibában

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

Lehet, hogy csak szoftvert cseréltek. Én is láttam már olyat, hogy a vadonatúj szoftverrel a szolgáltatás színvonala 5-6 évvel visszaesett. :(

A szoftvert már korábban lecserélték lakossági oldalon a C-ben és C++-ban fejlesztett Cardinal Electra Internet Bankingról Javában fejlesztett és Oracle WebLogic Serveren futtatott (Pegasus?) NetBank platformra.

Azt lehet tudni miert csereltek?


"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Nem tudom, de gondolom pénzügyi okokból. Az Electra külsős cég terméke, amelyet ügyfelek számával arányosan kell licencelni, az új NetBank meg tippre egy "belső" fejlesztés.

Köszi.


"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

.

Részemről csak feltételezés volt, miután átéltem egy ilyet :((((

ui: azt csak halkan kérdezném, hogy eme hiba tesztelgetése ügyfelek által, nem minősül bűncselekménynek? Én nem merném tesztelni még a gmailt sem, pont ezért.

Nem tudom. A magyar jogszabályozás eléggé vacak ebből a szempontból, de muszáj néha szürke területre tévedni, ha az ember lépést akar tartani...

# grep -ic passw yahoo-login-ssl.dump
31681

;)

Csodálkoztam is rajta...

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

Pedig egyébként teljesen jó a netbankjuk - az sms kihajítása miatt erősen gondolkodom azon, hogy kellően finom, udvarias, de melegebb éghajlatra küldős panaszlevelet fognak kapni...

A tranzakciókhoz MÉG küldi az SMS-es password-öt, a sablonként létrehozott célok felé nem szükséges az SMS-kód, ez már elég régóta így van.

Szerintem sablonnál nem csak nem szükséges, hanem nem is lehet sms kóddal utalni.

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

Miért tennék ingyen?

StartCom charges for reissuing SSL certs due to Heartbleed

Nem ők tehetnek róla, ha nálad bugos szoftver volt használatban és amiatt nekik dolgozniuk kell.

--
trey @ gépház

Gesztus?

--
Slapic

Itt a lehetőség olcsóbb SSL tanúsítványokat ígérni, hiszen most sokaknak kell új. Indul a verseny az olcsóbb certekért :)

Unicredit netbankja rendben a teszt szerint

A webszerverük viszont annál inkább érintett volt.

Sberbank is köszöni, jól van, és ott is van token.

Az orosz maffiával amúgy sem érdemes baszkódni..

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.

Ez azért érdekes, mert CIB-nél tavaly meg pont PSZÁF rendelkezés miatt vezették be a kétfaktoros hitelesítést.

Ez a PSZÁF rendelkezés kötelező érvényű? Ha igen, minden pénzintézetnek lenne már 2faktorosa. Ha meg nem, akkor kb. annyit ér, mint egy baráti jótanács. Semmit.

Azt nem tudom, hogy szabály, vagy csak ajánlás, de sok embernél dealbreaker a kétfaktoros auth

Van sms, csak be kell állítani a netbankban, alapban nincs.

Heartbleed Bug teszt

--
trey @ gépház

Egy online sérülékenység-tesztelő eszköz használatakor eléggé meg kell bízni abban, hogy maga az eszköz nem lopja el pl. privát kulcsot...

Forráskód a github-on:

https://github.com/FiloSottile/Heartbleed

./Heartbleed example.com:443

--
trey @ gépház

Debian Wheezy-n:

aptitude install -t testing golang
go get github.com/FiloSottile/Heartbleed
/usr/lib/go/bin/Heartbleed example.com:443

------------------------------------------------------------------------------
www.woodmann.com/searchlores/welcome.htm

Mindhárom squeeze OK, Zential nem ok. -frissítés után ok lett.

Rózsár Gábor (muszashi)

Frissítés + ÚJRAINDÍTÁS minden érintett szolgáltatásnál. Még jó, hogy pár hete a szerver menedzsment képzésen magyaráztam, hogy ha egy lib-ben van a hiba akkor a frissítés nem elég, és pont az openssl-t hoztam példának... megérzés... :-)

--
Slapic

na jó, de ezt a frissítés végén magától megcsinálja a csomagkezelő.

Konkrétan két frissítés jött ki, kedd reggel még nem restartolt, csak délután.

Nekem speciel mindenhol kézzel kellett újraindítanom az nginx-et. (Többnyire Ubuntu 12.04.4)

Egy lib frissítésekor pont, hogy nem. Ha a szolgáltatást nyújtó szoftver csomagja frissül igen. De itt ugye nem az frissül...

--
Slapic

Debian.

libopenssl1.0.0 frissítésekor azt mondja: ezeket a szolgáltatásokat kell újraindítani szerinte: lista
alapból az ember nyom egy returnt és a szolgáltatások leállnak, majd újraindulnak.

Ha valami kimaradt a listából, azt hozzá lehet tenni

Qualys SSL Labs: SSL Server tests

"experimental"-ban tudja már a Heartbleed tesztet

--
trey @ gépház

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.

Hacsak nem telneten vagy konzolon adminolgatod a geped, akkor az ssh-t is erdemes.

Az OpenSSH tudtommal nem használ TLS protokollt, ahol is ez a hiba előjön. Használja az OpenSSL libeket, de másra (pl. kulcsgeneráláshoz)

Es valoban, gondolkozni kene;)
Mea culpa.

t

És nincs az openssh-nak függősége mondjuk a libssl csomag adott verziójára?
Vagy mindegy neki és megy régebbivel is és újabbal is?

Ennek a frissítésnek csomagverzió számban kéne látszódnia, nem pedig lib-verzióban. Szerintem. Azaz akár dependálhat is, de automatikusan jónak kellene lennie (hacsak nem statikusan szerksztett binárisról beszélünk).

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.

Idézet:
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

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!

Mit használsz helyette?

LSD-t.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

ROT-22-őt. Még sosem csalódtam benne, eddig mindig tudta azt, amit ígért.
--
zsebHUP-ot használok!

a te bankod is érintett! ;)

sosem voltam nagy pizzás, de most kipróbálok pár új ízt :)
_____________________________
Powered by 1,3,7-trimetilxantin

Delutan meg a mail.t-online.hu:443 vulnerable volt.
--
zsebHUP-ot használok!

Hat delutan meg a gmail.com is, ugyhogy...

Akkor nyerő vagyok, hogy reggel 9-re minden szerver tesztelve (negatív), ahol gond volt, ott frissítve és újra tesztelve? :)

Ha a problémás gépeken a frissítés után visszavontad a régi tanúsítványt és telepítettél újat, új privát kulccsal, akkor igen.

+ a _rendrakás után_ minden jelszót megváltoztattál (kikényszerítetted, hogy megváltoztassák) amint az elmúlt 2 évben használtak stb.

--
trey @ gépház

Na igen, ez egy jó kérdés. Természetesen az összes jelszót lejártnak minősítettem, de mi lesz azokkal, akik mondjuk egy hónapig nem jelentkeznek be?

Érdekes. Nálam gentoo van érintett openssl verzióval, mégse mondja sebezhetőnek. És jött is ki tegnap friss openssl gentoora is.

--
http://pyftpadmin.earthquake.hu

Lehet hogy tls-heartbeat nelkul forditottad.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azok a szép, darabonként egyforma Gentoo telepítések :-D

Gentoo-ban is lehet központi repot csinálni ;)
--
http://pyftpadmin.earthquake.hu

Akkor az a repó és az abból telepített gépek vélhetően egyformák lesznek, ellenberger a világ összes többi Gentoo-s gépére meg jó esetben többé, rosszabb esetben kevésbé fognak hasonlítani :-P

Mostmar ertem miert OpenSSL a neve. :)

Az összeesküvés-elméletek kedvelőinek ez cukor lesz :)

Former Chief Security Officer for Microsoft the Chairman of the Board of Firm Behind Heartbleed®

--
trey @ gépház

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.

A cikkben linkelt weboldalról:

"When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server."

--
trey @ gépház

Koszi. Amiket cikkeket en olvastam azokban ez az eset nem volt megemlitve.

Ha ez így van, akkor talán nem rosszindulatból rakták be ezt a kódot, nem?

Átfogalmaznád a kérdést, kérlek?

--
trey @ gépház

Ha valaki direkt rakta volna be ezt a sebezhetőséget a kódba, akkor nem úgy csinálta volna, hogy oda-vissza menjen a memory leak.

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.

Igazad van, erre nem gondoltam.

É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.?

A bankkártya kompromittálódás mit jelentene ebben az esetben?

Milyen információ kikerülésétől tartasz?

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

Értem.

Kérhetsz új kártyát szerintem.

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.

CCV volt ami nem ugrott be, most rákerestem, mielőtt kijavítalak és igencsak meglepődtem... :)
http://en.wikipedia.org/wiki/Card_security_code
Aki akarja, számolja meg, hány elnevezése van annak a három számjegynek! :)

Ahány kártyatársaság. Nagyjából... :-P

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

Gondolom a felelősség azé, akié az oldal ahova beírod a kártyaszámodat vásárláskor, hiszen ők használtak sérült openssl verziót. Persze igazából az övék sem, mert nem tudtak róla. Szóval továbbra is jó kérdés.

No de az oldal, ahová beírod, nem tárolja csak továbbítja a kártyaelfogadónak az ellenőrzéshez.
OK, valameddig a memóriában van... de azért nem hiszem, hogy egy webshopot lenne célszerű támadni, ha ilyesmi infót akarnék összeszedni.

De többnyire nem is a webshop oldalára írod be a kódot, hanem az otp, vagy mittomén kinek a fizető oldalára ahova a webshop átirányít.

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

Ennek, hogy jelszót kell cserélni mi a technikai magyarázata? Hogy juthat el a FB jelszavam mondjuk valaki illetéktelenhez?

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

Jogos. És ez mennyire esélyes, hogy bejön? Gondolom hogy még nincsenek tömeges visszaélésekről hírek jót jelent.

2 éve ismert hiba, és ha kihasználták, nem maradt semmilyen nyoma a logokban / IDS / IPS / tűzfal rendszerekben. Szerinted van, aki meg tudja mondani, hogy mennyi az esélye?

2 éve ismert? Én úgy tudom, hogy 2 éve létező, és nemrég fedezték fel. Persze ettől még lehet, hogy mások tudtak róla, és aktívan kihasználják :)

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?

Ha webszerver memóriájához fér hozzá, akkor gondolom az úgy néz ki, hogy a sok szemét közben egyszer csak egy ott egy url, vagy http header, amiben ott van a név és jelszó.

Lásd: http://i.haymarket.net.au/News/Bks5ihoIgAAezgO.png

Láttam már ilyen URL-t nagyon kezdő programozó által elkövetett weboldalon.
Jó régen.

Nehogymár manapság bármelyik bank a világon az URL-be beleírt cleartext jelszóval működjön!

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.

Jelen esetben mindegy, ellenben azt ne felejtsük el, hogy a get és a post nem mindegy - és nem csak azért, mert az egyikben itt, a másikban meg ott megy a szervernek küldött adat :-P

Persze, van egy komoly szemantikai kulonbseg a ketto kozott, de az sem jelentkezik protokoll szinten.

Ezért is írtam, hogy jelen esetben mindegy - a szemantikai különbséget viszont nagyon sokan elfelejtik, vagy nem is tudják, hogy a "GET" idempotens, míg a "POST" meg pont nem :)

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! ;)

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

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/

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!