(nem hivatalos e-kormányzati témájú oldal)
| Mottó: Úszkálj kicsi halacskám Kifoglak téged lassacskán /Junkies: Halacska/ | ||
| 2011. szeptember 1. | ||
| Mai menü: "szósz" és "hekk" | ||
| A kriptográfia elleni támadások során ritkán, de azért lehet találkozni olyan esetekkel, amikor az implementációban (forráskódban, logikában) van hiba, az azonban még kevesebbszer fordul elő, hogy magában a matematikai algoritmusban találnak egyszerűsítési lehetőséget. Ha mégis találnak ilyeneket, akkor szakmai berkeken belül futótűzként elterjed a hír, és remegve mindenki azt kérdezi a másiktól, hogy "Kell-e más algoritmust használni?", "Le kell-e cserélni mindent nagyobb kulcsra?". Kritikus infrastruktúrák, e-közigazgatási rendszerek esetében ezeket a kérdéseket gyorsan, és szakszerűen kell megvizsgálni. A forráskód, a "szósz", ha hozzáférhető, akkor sok okos ember tudja nézegetni, együtt tudják javítani a kisebb-nagyobb hibákat. A forráskód elzárása ("Security by Obscurity") és aztán "véletlen" nyilvánosságra kerülése esetén lehet nagyobb halakat is fogni, de tény, hogy az "open source" világban is hatalmas "hekkek" akadhatnak a hálóba. Elég, ha annyit mondok: OpenSSL? Seed? Random? PID? Debian? A hibát 2008. május 13-án fedezték fel és mint kiderült az összes Debian-alapú rendszer OpenSSL modulját érintette 2006. szeptember 17. (OpenSSL 0.9.8c-1) és a felfedezés napja (OpenSSL 0.9.8g-9) között. Az RSA és DSA kulcsok létrehozásához a kritikus időszakban mindösszesen a PID-et (Process ID) vette alapul a kripto modul, ami alapján max. 32768 kulcspár jöhetett létre. Ezt azért gyorsan ki kell egészíteni azzal, hogy több paraméter is befolyásolja ezeket, mint pl. architektúra (x86, x64, PowerPC), algoritmus (RSA, DSA), kulcshossz (512-4096), kitevő (3, 65537), de a lényegen ez nem változtat: le tudták többen is gyártani az N*32768 kulcspárt, amiket aztán le is lehetett tölteni (pl. x86, RSA, 1024 bit: 30 MB-os állomány volt). A dolog érzékenyen érintette többek közt az egyik hazai hitelesítés-szolgáltató CA-ját is, aki "azonnal" (kivizsgálás után) visszavont több SSL szerver tanúsítványt. A publikus adatok alapján ezek között nem szerepelt e-közigazgatáshoz köthető oldal, de ki tudja, hogy a háttérben hol használtak sérülékeny SSH kulcsokat a rendszergazdák a távoli belépésnél hitelesítéshez, és azokat vajon lecserélték-e a hírek hallatán...?! Miért jó tehát ez a kulcs-kitalálósdi? Ha ránéz valaki egy pl. SSL tanúsítványra, vagy egy rendszergazdai SSH (client authentication) kulcsra, vagy valakinek egy személyes aláíró tanúsítványára, abból ha kiollózza a nyilvános kulcsot, és rákeres az adatbázisban, akkor egyből tudni fogja hozzá a titkos felét is, és máris vissza lehet vele élni. Ha valaki nem tudta letölteni ezeket az adatbázisokat, vagy egyáltalán szeretné maga kipróbálni a kulcsgenerálást, annak az alábbiakban megadom a receptet hozzávalókkal. Végy egy régebbi Debian vagy Ubuntu operációs rendszert (pl. Ubuntu 8.04 LTS) és keverj hozzá egy hibás OpenSSL csomagot (pl. OpenSSL 0.9.8g-4)! Szerezz egy jó tanúsítványt, tisztítsd meg, hámozd le róla a titkos kulcsot és anélkül öntsd bele a rendszerbe (pl. bad.codefromthe70s.org)! Várd meg, amíg kifő a tanúsítványból a nyilvános kulcs és annak paraméterei (pl. a PID-et visszaadja az erre a célra fejlesztett SSL Blacklist nevű Firefox add-on)! A PID-et óvatosan vedd ki, és daráld le pl. a "execwithpid.sh" script segítségével! Amit kapsz, az a nyers titkos kulcs! Gyúrd össze a tanúsítványt a titkos kulccsal ízlés szerinti formába (pl. OpenSSL segítségével PKCS#12 állománnyá), majd dobd bele a tanúsítványtárba, és kóstold meg! A tálaláshoz állítsd vissza a rendszerórát, hogy mutatósabb legyen a dolog, hiszen így akkor nem reklamál amiatt a Windows, hogy a tanúsítvány már rég lejárt! És ezzel már kész is a bitleves, öröm és bódottá van!
Vannak olyanok, akik nem bíznak semmilyen kripto modulban és sajátot készítenek. Aztán valaki megpiszkálja a felszín alatti rétegeket, és meg tudja lepni a világot egy-két "epic fail" történettel. Így történt ez a 27. Chaos Communication Conference (27C3) rendezvényen is 2010. december 29-én, ahol a fail0verflow tagjai bemutatták, hogy a Sony PlayStation3 kripto-rétegében miért is rossz az ECDSA implementáció, amely sokminden sértetlenségét biztosítja a rendszerben. A matematikai levezetésből kiderül, hogy a titkos paraméterhalmaz elemeit, amely egy véletlenszámból (m) és egy titkos kulcsból (k) áll, jelen esetben a véletlenszám állandó értéke miatt két különböző aláírás (R, S) értéke alapján meg lehet határozni. A történet eredménye az lett, hogy a webre felkerült a különböző aláíró kulcsok listája... Ebben a blog bejegyzésben én is csak a matematikát tudom leírni: PlayStation3 hiányában nehéz mással, pl. egy jól működő OpenSSL-lel reprodukálni a hibát.
Érdemes továbbgondolni a dolgot... Mikre lehet képes így egy esetleges támadó? A kínai csapat pl. előrukkolt két különböző tartalmú, de azonos MD5-RSA aláírású X.509 tanúsítvánnyal. Az otthoni kísérletezésnél hasonló módon nemcsak a lenyomattal, hanem az arra épülő MD5-RSA digitális aláírással is lehet trükközni. Ehhez nem kell mást tenni, mint legyártani két különböző adatokkal feltöltött (de azonos lenyomatra módosított) elektronikus számlát (ez ugyebár felkapott téma az e-közigazgatás területén is), majd az egyik - valós adatokat tartalmazó - számla XML állományt alá kell íratni a főnök chipkártyáján tárolt titkos kulccsal. Ha ez megvan, akkor a kódolt lenyomatot át kell emelni a kamu e-számlára - megtehetjük, hiszen, ha a lenyomat ugyanaz, akkor a kódolt lenyomatok is megegyeznek - majd elküldeni a pénzügynek, hogy ellenőrizzék az aláírást, és hajtsák végre a netbanki utalást a számla alapján. A példában hat különböző - akár számlaadatokat is tartalmazható - állományt hoztam létre.
Kapcsolódó anyagok: | ||
| vissza | ||
info@ugyfelkapu.info
