(nem hivatalos e-kormányzati témájú oldal)
| Mottó: Titkos üzenet száll a széllel /TNT: Titkos üzenet/ | ||
| 2012. november 22. | ||
| Hackni | ||
| Idén is izgalmasra sikeredett a Hacktivity konferencia, amely 2012. október 12-13. között került megrendezésre Budapesten. Ezúttal előadóként is volt lehetőségem mesélni arról, hogy kollégáimmal milyen érdekességekre bukkantunk a Windows tanúsítványtárának védelmét, illetve a chipkártyák alacsonyszintű kommunikációs csatornáit vizsgálva (ez utóbbiról már volt pár szó a "Chip-csirip" bejegyzésemben is).
A jogszabályi téren a "felpuhulás", a szoftveres tokenek helyzetének erősítése a mobilos megoldások elterjedését is elősegítheti. Kétségkívül sokkal gyengébb biztonságot jelentenek a szoftveres tokenek (a hardveresekkel szemben), de a jelenlegi jelszavas védelmekhez képest még így is lényegesen jobbnak számítanak. Ezeknek kissé ellentmondóan, de pont mostanában fognak bevezetni különböző kártyákat, azaz hardveres tokeneket is, amelyek között lesznek olyanok, amelyek támogatnak aszimmetrikus kriptográfiát (PKI) is.
A tapasztalatokat Windows környezetben szereztük, ezért hiteles architektúra ábráért is a Microsoft oldalát bogarásztuk végig. Gyorsan hozzáteszem azonban, hogy a dump-olt és visszajátszott APDU üzeneteket ugyanilyen formában, Linux-on futó OpenSC-vel is végig lehet vinni...
Nézzük meg, hogy miképp lehet kibányászni titkos kulcsokat egy védettnek hitt Windows tanúsítványtárból!
A szoftveres tokeneket is lehet úgy tárolni a Windows-ban, mint a jelszavakat a böngészőkben, csak éppen nem érdemes... Ha már szoftveres tokeneket használunk, akkor legyünk biztosak abban, hogy a tárolt adat legalább rejtjelezett, és ezáltal védi a tikos kulcsokat (ld. PKCS#12 típusú állományok)! Merthogy a Windows tanúsítványtára...
... merthogy a Windows tanúsítványtára dobál ugyan jelszó-bekérő ablakot, meg erős védelem checkbox-ot, meg exportálhatósági flag-et a kulcsok telepítése során, de ezek a védelmek mind megkerülhetők (erre már Jason Geffner is felhívta a figyelmet).
Az általunk fejlesztett segédalkalmazással a jelenleg használatos Windows rendszerekben lehetőség van a tanúsítványtár védelmi mechanizmusait kijátszva az importált titkos kulcsok kinyerésére (CRYPT_EXPORTABLE flag átírása) még akkor is - és ez fontos - ha erős védelmet ("Enable strong private key protection") rendeltek hozzájuk!
A lényeg tehát, hogy a kulcsokat ne importáljuk, hanem tároljuk .p12/.pfx állományként, erős jelszóval védve (rejtjelezve), illetve olyan alkalmazásokat használjunk, amelyek tudják az ezen formátumban tárolt kulcsokat is kezelni.
Nézzük meg, hogy mennyit ér a hardveres tokenek (pl. chipkártyák) jelszavas, PIN kódos védelme!
Ez is érdekes, de most nem session-típusú cache-re gondoltunk, hanem alkalmazásszintűre! Azt tudjuk rég, hogy ha nem húzzuk ki a chipkártyát az olvasóból, akkor adott session végéig elég akár egyszer megadni a jelszót, PIN kódot (CSP-től függ). Az viszont kérdéses, hogy ha ismét bedugom a kártyát, akkor be tudom-e pl. valami konfigurációs állományból olvastatni a jelszót és felhasználni authentikációhoz (a felhasználó tudta nélkül)?
Nos, a CryptSetProvParam() függvény csodákra képes! Ha egyszer megadja valaki a chipkártyája jelszavát pl. egy trójainak irat- és dokumentumkezelő rendszernek, hogy a munkafolyamatban könnyedén tudjon elektronikus aláírási műveleteket végrehajtani, akkor utána a háttérben már a felhasználó tudta nélkül is tudja hívni az alkalmazás a hardveres tokenek funkcióit. Fontos megjegyezni, hogy ezen probléma ellen a PIN-pados kártyaolvasók sem jelentenek védelmet, hiszen a jelszó-bekérő ablak akkor dobódik fel, ha más módon nem került átadásra a PIN kód - itt azonban ez megtörtént, azaz ablak sincs...
Hmm, ha egy rendszer használ ilyenfajta jelszótárolást akár ideiglenesen is, akkor a legjobb, ha valaki független fél átnézi ezen rendszer forráskódját, hogy a használat után törlik-e megfelelően az érzékeny adatokat, illetve egyáltalán a használat maga megfelelő-e.
Nézzük meg, hogy mennyit ér a CSP komponensek védelme!
A CSP-típusú aláírás, amit a Microsoft rak rá egy ilyen audit végén a dll-ekre egy plusz réteg a szokásos, dll-eken is levő "code signer" típusú aláírásokon felül, amiket viszont mi, fejlesztők rakunk rájuk.
A kérdés tehát az, hogy mit ér ez a nagy felhajtás, ha úgyis csak a registry-ben CSP-ként megadott, elsődleges dll-en levő aláírást vizsgálja a Windows, az importált dll-ekkel (amikbe bármit írhatunk utólag is) pedig nem törődik?
A CSP-k utódaiként érkező KSP-k még annyi felülvizsgálaton sem fognak átesni, mint elődeik. Kérdés, hogy ki fogja auditálni a Microsoft helyett pl. a kritikus infrastruktúráknál alkalmazandó kriptográfiai kódokat? És milyen kulccsal kerülnek aláírásra a KSP-k, ha nem fog ebben a folyamatban résztvenni a Microsoft? Még csábítóbb célpontok lesznek a Windows tanúsítványtár root-jai között szereplő, kevésbé védett CA-k (DigiNotar-utódok?)...
Nézzünk bele az APDU-szintű, chipkártyás kommunikációba! Vajon, mit látunk belőle?
A WinSCard.dll alá van írva, mégsem kerül ellenőrzésre kellőképpen, Windows rendszermappában van, de máshonnan is betölthető hamisított példány, a forráskódja pedig kint kering a neten (ld. ApduView és APDUPlay). Mi kell még egy jó kis DLL preloading attack-hoz? Írhatunk saját alkalmazást, amin keresztül kommunikálva a kártyával lementhetjük az adatforgalmat, de berakhatunk egy hamisított dll-t akár a kártya driver mappájába is. A történetben viszont nem is a megfigyelhetőség ténye a fontos, hanem az, hogy maga a megfigyelt kommunikáció nem rejtjelezett! FAIL! Ezen azért meglepődtünk mi is! Csoda, ha így bármyilyen trójai el tudja kapni a chipkártya jelszavát, PIN kódját és vissza tudja játszani a hardveres tokennek?
Pedig ezen rétegről, a kommunikációs csatorna rejtjelezéséről külön fejezet is szerepel a HUNEID kártya specifikációjában...
Nézzük meg, hogy mitől lesz ez a történet EPIC FAIL!
Tehát ez a megfigyelhetőség az RDP session-ön becsatornázott hardveres tokenekre is igaz! Fontos azonban megjegyezni, hogy a PIN pados kártyaolvasó jelszó-bekérése nem figyelhető meg ilyen módszerrel (más típusú üzenet látható, érték nélkül), azaz ha még nem tudódott ki a PIN kód, a PIN pados kártyaolvasó használata növeli a biztonság szinjét.
RDP-n keresztül ne használjunk távoli gépre belépve, az otthoni gépünkre csatlakoztatott chipkártyát! Sem akkor, amikor rendszergazdaként lépünk be mondjuk aláírni a naplóállományokat, sem akkor amikor - chipkártyás authentikációt használó - banki ügyeket akarunk intézni ilyen módon távolról. Figyelem! A félreértések elkerülése érdekében jelzem, hogy a demo videóban szereplő hitelesítés-szolgáltató kártyakibocsátási eljárása megfelelő, abban nincsen hiba, tetszőleges hitelesítés-szolgáltató tetszőleges - nem eID-típusú - kártyájával végrehajtható az APDU-csomagok ilyen módon történő megfigyelése, kimentése és visszajátszása!
| ||
| vissza | ||
info@ugyfelkapu.info
