Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Az élet abban különbözik
a sakktól, hogy a játék
a sakk-matt után is folytatódik.
/Isaac Asimov/
2014. szeptember 1.  
 SHA-k: matt? 
   
Friss eredményekről számoltak be az SHA-1 collision kutatás kapcsán 2014. augusztusában több konferencián is (BSidesLV, DEFCON) a Malicious SHA-1 projekt tagjai (közülük többen azon Graz University of Technology kutatói, ami 2007-ben elindította az SHA-1 Collision Search nevű, BOINC grides projektet). A lényeg: már a teljes - 80-körös - SHA-1 algoritmusnál is lehet ütközéseket létrehozni, igaz, csak módosított konstansok mellett!

Ez mit jelent? Maga az SHA-1 lenyomatképző algoritmus 80-körön keresztül hajt végre XOR és rotate műveleteket az adatokon (ld. P2P ütközések bejegyzésemet). Ezen 80-körös ciklus elindításához viszont néhány kezdeti peremfeltételt meg kell határozni: az IV (Initialization Vector: H0..H4) és a konstansok (constant words: K(t)) értékeit az algoritmust leíró szabvány (IETF RFC 3174) tartalmazza.

Ezen szabványban szereplő értékek módosításával voltak képesek ütközéseket produkálni a kutatók. Bizonyítékként több állománypárt is mellékeltek, amelyek bár bitszinten különböznek, de bizonyos konstansok mellett az SHA-1 lenyomatuk megegyezik! Az egyik ilyen állománypár az "eve1.sh" és "eve2.sh". Ezekbe belenézve valóban látszik, hogy különböznek, a lenyomatuk viszont...

Ha az eredeti - szabvány által megadott (5a827999, 6ed9eba1 stb.) - konstansokat felhasználva futtatjuk le az SHA-1 algoritmust, akkor ez a különbözőség a lenyomatokban is látszik (fcb2e7bf18265b08... és 1f362d9221356c48...), de - és ez a lényeg - lehet olyan konstansokat találni (5a827999, 88e8ea68 stb.), amelyek mellett mégis azonosak lesznek ezek a lenyomat (96ed59be04518a27...) értékek (az alábbi példánál a bemeneti konstans K0 még megegyezik a szabványban szereplő értékkel, de K1, K2 és K3 már eltér).

Az SHA-1 algoritmus tehát hamarosan az MD5 sorsára juthat: ismert bemenetek esetén nem lesz szabad alkalmazni (nem ismert bemeneteknél viszont - pl. amikor csak a jelszólenyomatot tudjuk és a bemenetet kell kitalálni - más a helyzet). A kutatók gyorsan leszögezik, hogy SHA-256 esetében egyelőre nem tudnak hasonló trükközést végrehajtani részben azért, mert a legjobb ismert támadással is csak a 31. körben tudtak ütközést produkálni (a 64 körös SHA-256 algoritmusnál), másrészt pedig eleve bonyolultabb a konstansok kezelése ott (SHA-1 esetében minden 20 körre jut 1 konstans, SHA-256 esetében pedig mind a 64 körre külön konstans létezik).

A Malicious SHA-1 esetében a konstansokkal trükköztek, de pár évvel ezelőtt vált ismertté egy olyan támadás is, amelyik az IV-k módosítgatásával tudott rámutatni egy komoly gyengeségre a Merkle-Damgard struktúrát használó lenyomatképző függvényeknél: ez a "length extension attack", amelyről először az MD5 algoritmust használó Flickr API kapcsán írt 2009. szeptember 28-án Thai Duong és Juliano Rizzo.

A sérülékenység igazából a lenyomatolandó adatok nem megfelelő összepakolása esetén használható ki, és ez is csak azért fordulhatott elő szélesebb körben a természetben, mert a Flickr API-ja (amire hajazott többek közt a Scribd, Vimeo és mások API-ja is) pont ilyen szerencsétlen módon működött. Nagyon leegyszerűsítve ez az alábbi eseteket jelenti:
$hash = md5($salt . $to-be-hashed-data);
$hash = sha1($salt . $to-be-hashed-data);
A hiba bemutatásához Marek Lukaszuk (mmmonk) Python kódját (sha1_len_ext_attack.py) használtam fel, minimális módosítás után. A Flickr API példáján kívül azonban Nicolas Favre-Felix (yowgi) mutatott egy életszerű(bb) esetet: lenyomattal védett netbanki tranzakciós paraméterek módosítása a titkos adatok ismerete nélkül. Az alábbi példában egy ilyen netbanki tranzakción keresztül mutatom be a problémát.

Tételezzük fel, hogy a User1234 (uid) nevű felhasználó moneytransfer (event) műveletet akar végrehajtani. A feladó saját maga, azaz User1234 (from), a címzett User8888 (to), az átutalandó összeg pedig 1000 (amount) pénzegység. Ez a tranzakció az 12345678 (txid) azonosítót kapja meg. A tranzakció hitelesítéséhez User1234 megadja a Pass1234 (pwd) jelszavát is, ami felhasználásra kerül a lenyomat kiszámításánál.

A lenyomat értéke (487f551ef831a9a24594f286b32bb7fac4281c36) hozzáfűzésre kerül a tranzakció nyilvános paramétereihez.

Kérdés, hogy hogy lehet hozzáfűzni újabb paramétereket ehhez a tranzakcióhoz úgy, hogy a jelszó ismerete nélkül is tudjunk érvényes (jó lenyomatú) átutalási megbízást létrehozni? Tételezzük fel, hogy a User6666 (to) támadó is szeretne 1000 (amount) pénzegységet kapni User1234 (from) felhasználótól. Ehhez nem kell mást tennie, mint venni az eredeti tranzakció érvényes lenyomatát (487f551ef831a9a24594f286b32bb7fac4281c36), a lenyomatolásra került adatok hosszát (97), illetve a hozzáfűzendő tranzakciós paramétereket, és végrehajtani a padding-et. (A titkos jelszót viszont nem kell ismerni!) Merthogy a háttérben ilyenkor egy padding hajtódik végre a lenyomat, mint IV értékek (H0..H4) beállítása mellett úgy, hogy az adat hossza 64 byte (= 512 bit) legyen, ami SHA-1 esetében pont a blokkok mérete. Ebben az esetben igaz az, hogy a teljes lenyomatolandó string első részét (az eredeti tranzakció paramétereit) változatlanul hagyva mögéjük be lehet szúrni egyéb adatokat is. A padding-elt, és a támadó által hozzáfűzött adat lenyomata (d79c913e23d22609565e28a0ff920250d18f9a72) lesz az új ellenőrzőösszeg. A támadó által módosított tranzakciós adathalmaz így néz ki:

A szerver oldal (mybank.com) megkapja a kérést, végrehajtja a lenyomatképzést a megkapott paramétereken és a titkos jelszón alapulva, az általa kiszámolt értéket összeveti a hash értékével (d79c913e23d22609565e28a0ff920250d18f9a72), majd ha egyezést talál, akkor végrehajtja a tranzakciót (utal pénzt User8888 és a támadó User6666 bankszámlájára is).

A sérülékenység felfedezése után egy fontos szemponttá vált a későbbi SHA-3 algoritmus kiválasztásánál, hogy ne építsen Merkle-Damgard struktúrára, ne legyen érzékeny a "length extension attack" sérülékenységre. Ennek a nyertes Keccak algoritmus eleget is tesz...

Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info