(nem hivatalos e-kormányzati témájú oldal)
| Mottó: What do you people think about removing those 2 lines of code? /Kurt Roeckx, OpenSSL programozó/ | ||
| 2014. április 14. | ||
| OpenSSL: Véletlenek és vérző szívek | ||
| Azt mondják, hogy 7 év alatt az emberi szervezet minden sejtje megújul. A szoftveriparra is igaz lehet, hogy - ha a teljes megújulás ritka is, de - 7 évente keletkeznek újabb, fél világot megrengető hibák. Ez nem is tűnne annyira rossz statisztikának, ha nem egy olyan library-ről lenne szó, amit senior szoftverfejlesztők, matematikusok és egy egész open source community felügyel... Az OpenSSL viszont ilyen! Az OpenSSL Debian (és társai) változatait érintő súlyos PRNG hiba óta eltelt 6-7 év, de a nemrég felfedezett Heartbleed miatt ismét álmatlan éjszakák gyötörhették a rendszergazdákat (illetve a paranoiásabb felhasználókat is), akik teljesen bizonytalanok voltak abban, hogy vajon milyen adataik kompromittálódtak, vajon mióta és kik használhatták ki az OpenSSL sérülékenységét. Magáról a hibáról Buherátor már részletesen beszámolt ([1], [2]), én most csak egy gyors - táblázatos, TL;DR - összehasonlítást készítettem a talán legnépszerűbb crypto library két legkomolyabb hibájáról.
A hiba felfedezése körüli eseményeket jól összeszedték egy idővonalba ([14]). A Proof-of-Concept (PoC) kódra sem kellett sokáig várni. Filippo Valsorda tett közzé egy Go nyelven írt alkalmazást, amely a sérülékenységet kihasználva vizsgálja meg a web szerver által visszaadott választ. Ebből deríti ki, hogy az adott web szerver érzékeny-e a támadásra. Ebben a kódban a heartbleed.go állományban látható, hogy a vizsgálathoz elegendő a tgt (Target) változónak megadni a címet (URL), vagy tartománynevet (domain) a parancssori felületen keresztül. Az üzenet payload byte-jainak a "heartbleed.filippo.io" string-et adta meg a fejlesztő (ez visszaadásra is kerül a válaszban). A check_cert segítségével az SSL/TLS web szerver tanúsítvány ellenőrzését át lehet ugrani (magyarázat: néhány, Heartbleed-re sérülékeny web szervernél vélhetőleg csak teszt jelleggel került beállításra SSL/TLS, több esetben lejárt tanúsítványokkal lehet találkozni). A buildEvilMessage() funkció révén összeállított - payload byte-okat tartalmazó, tgt címre elküldendő - üzenethez még a kód hozzáilleszti a padding byte-jait,a "YELLOW SUBMARINE" string-et. Az üzenet elküldése után azt vizsgálja meg a kód, hogy a válaszban megkapott - a szerver memóriájából származó - adatok között szerepel-e a padding byte-ként beküldött érték. Ha igen, akkor a web szerver sérülékeny, más memóriaterületek is kiolvashatók, akár olyanok is, amelyek egy SSL/TLS Application Data adatfolyam során éppen a felhasználó által beküldött jelszavakat tartalmazza, vagy olyan, amely egy SSL/TLS handshake adatfolyam esetén éppen az RSA titkos kulcsot használja memóriába betöltve a - Diffie-Hellman helyett RSA alapon történő - kulcscsere során. A PoC kódot többször lefuttatva látszik is, hogy a kiolvasott adatok mindig mások. Kellően nagy kitartással, illetve adatelemzési szabályok beillesztésével (pl. ASN.1 adatstruktúrák szigorú szabályait nem árt ismerni, ha RSA titkos kulcs után kutakodunk) lehet olyan szerencsénk, mint a CloudFlare Challenge győzteseinek, akik egyik esetben 2,5 millió üzenetből, másik esetben viszont már 100 ezer lekérés alapján ki tudták nyerni a titkos kulcsot ([15]). Jelenleg is akárki ki tudja próbálni a sérülékenység kihasználását, hiszen a PoC kód nyilvánosan elérhető ([16]) ugyanúgy, ahogy a sérülékeny - hazai - web szerverek listája is ([17]).
| ||
| vissza | ||
info@ugyfelkapu.info
