Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Padding Oracle támadás hardver tokenekkel szemben

2012.06.30. 16:41 | buherator | 1 komment

Ha az "RSA" és a "feltörés" kifejezések egy mondatban szerepelnek, az általában masszív hírfolyamot generál, nem történt ez másként a Project-Team Prosecco legújabb, hardver tokeneket és biztonsági kártyákat vizsgáló kutatásának esetében sem. Az persze általában kimarad az újságból, hogy nem csak az RSA Inc. termékei érintettek, valamint hogy az a "feltörés" mi a csodát is jelent pontosan - emiatt a vállalatnál véleményem szerint jogosan vannak kiakadva.

A szóban forgó hardver tokenek többek között arra jók, hogy kulcsokat tároljunk bennük, méghozzá úgy, hogy azokat csak a token birtokában lehessen használni (az egyéb funkciókat, mint például az egyszeri jelszavak generálását a támadás nem érinti). A kulcsok ezért nyilván nem nyerhetők ki az eszközből, még a token tulajdonosa által sem. Annak érdekében viszont, hogy a kulcsokról biztonsági mentéseket lehessen készíteni, a tokenek képesek tartalmukat titkosított formában - "csomagoltan" - exportálni. A csomaghoz tartozó mesterkulcsot csak az eszköz ismeri, a csomagot a legitim felhasználó sem bonthatja ki, csak importálhatja az eszközére. 

Felhasznált irodalom

Az eredeti publikáció

Matthew Green - A bad couple of years for the cryptographic token industry

Nate Lawson - Why RSA is misleading about SecurID vulnerability

Nate Lawson - RSA repeats earlier claims, but louder

Sam Curry - Don’t Believe Everything You Read…Your RSA SecurID Token is Not Cracked

Sam Curry- Still Not Cracked: a further dive into the PKCS #1 v1.5 vulnerability

A francia kutatóknak azonban sikerült találniuk egy módszert, amivel a csomagok tartalma a csillagok megfelelő együttállása esetén megfejthető, ezt a támadást pedig egy sor eszközön sikerrel demonstrálták. A csillagok megfelelő együttállása nagyjából azt jelenti, hogy a támadónak ismernie kell a felhasználó PIN kódját és hozzá kell férnie az eszköz PKCS#11 szerint megvalósított interfészéhez (ezt, hogy látni fogjuk, akár távolról is megteheti) néhány ezer kérés elküldésének erejéig, ami hardvertől függően perceket, esetleg néhány órát jelent. 

Ez a támadói modell első látásra erős, de ha feltételezzük, hogy az áldozat gépét gyökérig megtörték (magyarítás FTW!), máris optimális ökoszisztémát teremtettünk. Vegyük észre, hogy a tokenek egyik feladata éppen az, hogy ilyen esetekben is védjék a kulcsokat!

De hogyan is lehetséges mindez? A kutatók alapvetően most is Padding Oracle támadást hajtottak végre szokásos CBC módú blokktitkosítók, illetve az asszimmetrikus RSA algoritmussal szemben (ennek részleteiről egy külön posztot tervezek). Kis ismétlés: a Padding Oracle támadásnál a sérülékeny rendszer a normálistól eltérő (időtartamú) választ ad, ha elrontjuk a paddinget, így a támadó manipulált kriptoszövegeket küldhet a rendszernek, aki jó orákulumként apránként kiszivárogtatja a nyílt szöveget. Fontos megjegyezni, hogy a támadás a titkosítás kulcsát nem fedi fel (de ez nem is érdekel minket).

token_stats.jpg

Valójában egy bizonyos Daniel Bleichenbachernek köszönhetően 1998 óta ismert, hogy a PKCS#1 szabvány 1.5-ös verziójának megvalósításai sérülékenyek ilyen támadásokkal szemben. Gondot jelent viszont, hogy ezek az apró tokenek elég lassúak, az orákulumtól pedig sokat kell kérdezni, így a teljes támadás lebonyolításához irreálisan sok időre lenne szükség. A kutatók legfőbb eredménye, hogy Bleichenbacher támadását sikerült optimalizálniuk olyan szintig, hogy a támadás a gyakorlatban is kivitelezhetővé vált. Ehhez egyrészt matematikai okosságra, másrészt egyszerre több, eltérő "erősségű" orákulumra, illetve a nyílt szöveg struktúrájának részleges ismeretére volt szükség. Ilyen módon a támadás időtartama a fenti táblázatban látható értékek szerint alakul a különböző eszközökön. Fontos kiemelni, hogy a támadást nem muszáj egy lélegzetvételből letudni, a 21 perc kijöhet például három 7 perces alkalomból is.

Ahogy a poszt elején is írtam, az RSA/EMC elég sokat kapott az eset kapcsán, és két blogposztban is igyekeztek helyretenni a tényeket, valamint védeni a termék becsületét. Ezekben a nyilvánvaló pontatlanságok, tárgyi tévedések jogos helyesbítésén túl azonban olyan gondolatok is szerepeltek, melyek mellett nem lehet szó nélkül elmenni:

  • Egy munkaállomás teljes komprommitációja esetén a token kulcsainak komprommittálása nem jelent előnyt a támadónak - Akkor miért költünk rá pénzt? [trollface] :) Optimális esetben a támadó csak addig garázdálkodhatna, amíg a token csatlakoztatva van hozzá - a támadás kivitelezése után azonban ezt bármikor megteheti (amíg le nem cserélik a kulcsokat).
  • A cég ügyfelei egyébként is rendkívül biztonságtudatos vásárlók, akik csak a szükséges időre hagyják a tokent a gépükben, és olyan kifinomult biztonsági kontrollokat is alkalmaznak, mint pl. antivírus - Ehhez nem fűznék kommentárt...

A cég emellett természetesen komolyan veszi és értékeli a kutatást, és egy olyan megoldáson dolgozik, melyben a jelenleg kompatibilitási okok miatt engedélyezett PKCS#1 v1.5-öt alapértelmezetten kikapcsolják.

Címkék: kriptográfia rsa emc securid

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Aron bacsi 2012.06.30. 21:38:46

Tudtommal is a C_UnwrapKey() fv-t a PKCS#12 (.pfx/.p12) fájlok HW tokenre történő importálásánál használják, az RSA SecurID-nél meg ilyenek nincsenek (szóval, az RSA/EMC védekezése érthető). Fejlesztői szemmel nézve a történetet azonban érdemes elolvasni a "countermeasures" részt is: az "authenticated encryption" alatt a "CKM_AES_GCM" és "CKM_AES_CCM" mechanizmusokat értik a kutatók. Az alábbi 2008-as specifikációban van róluk szó:
ftp://ftp.rsa.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20a5d1.pdf
süti beállítások módosítása