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

A Helykitöltő Orákulum

2010.10.05. 00:05 | buherator | 3 komment

Ebben a posztban megpróbálom öszefoglalni a méltán elhíresült "Padding Oracle Attack" lényegét, ami bizonyára nem kevés álmatlan éjszakát okozott néhány programozónak és egy rakás üzemeltetőnek. 

Matekozni fogunk, szóval igyatok egy kávét vagy ilyesmi!

A legalapvetőbb tudnivaló, hogy a támadás CBC (chipher block chaining) módú blokktitkosítókkal szemben működik. Ennek a működési módnak a lényege, hogy a blokktitkosító eljárást mindig a nyílt szöveg és az előző blokk kriptoszövegének bitenkénti kizáró vagy összegére (a továbbiakban összeg, +) alkalmazzuk, így elkerüljük a sima ECB mód okozta problémákat, tűrhető hibaterjedés mellett. Az első nyílt szöveg blokkot egy szabadon választott inicializáló vektorral (blokk méretű bájtsorozat) adjuk össze, ezt nyílt csatornán továbbíthatjuk a kriptoszöveggel együtt.

A blokktitkosítókat általában úgy alkalmazzák, hogy a nyílt szöveget kiegészítik úgy, hogy annak mérete a blokkméret többszöröse legyen, ezt a kitöltést nevezzük paddingnek. Az egyik legelterjedtebb padding módszerre a PKCS #5 néven szokás hivatkozni, ennek lényege, hogy a kitöltés bájtjainak értéke megegyezik a kitöltés hosszával, valamint mindig sor kerül legalább egy kitöltő bájt hozzáfűzésére a nyílt szöveghez - blokkhatárig tartó bemenet esetén egy teljes blokknyi paddinget alkalmazunk. A támadás szempontjából ez utóbbi tulajdonság lesz lényeges, illetve fontos, hogy a padding legalább megjósolható legyen (véletlen értékek esetén nem rúgunk albdába)

Képletekkel az első blokkra tehát:

  • C=E(P+IV)
  • P=D(C)+IV

A támadás alapját (és nevét) továbbá az adja, hogy szökségünk van egy rendszerre, amely tetszőleges IV-kriptoblokk párra megmondja, hogy helyes-e a padding. .NET-es webalkalmazások esetében ez úgy nézett ki, hogy a szerver 500-as Internal Server Errort (PaddingException) dobott vissza hibás padding esetén, egyébként 200-at.

Vegyük a kriptoszöveg egy blokkját, és egy csupa NULL-byte-ból álló IV-t, a duót pedig küldjük el az orákulumnak. Az orákulum nagy eséllyel azt fogja mondani, hogy a padding rossz, ezért újrapróbálkozunk az IV utolsó bájtjának inkrementálásával. Az eljárást addig folytatjuk, amig az orákulum elégedett nem lesz. Legyen ekkor az IV utolsó bájtjának értéke X. Elég jó esélyünk van arra (bár valójában nem lehetünk biztosak benne...), hogy az orákulum belső dekriptáló eljárásan kimenete blokkméret-1 bájtnyi szemetet, valamint egy 1 értékű bájtot eredményezett mint nyílt szövegblokk (hiszen ez egy érvényes padding). Ekkor tudjuk, hogy

0x01=X+<D(C) utolsó byte-ja>  (*)

mindkét oldalhoz hozzáadva az eredeti IV utolsó byte-ját és X-et (blokkméretű tagok esetén a blokk utolsó bájtját értéstek oda):

  • IV+X+0x01=X+D(C)+IV+X=
    =X+P+X=
    =P

Az egyenlőség bal oldalának minden tagja ismert, a jobb oldalnak meg örülünk :) Ugyanezt a módszert folytathatjuk visszafelé haladva az IV byte-jain, szépen sorban megkapva a nyílt szöveget. 

Ami ezt a támadást a .NET-es webalkalmazásokra nézve különösen veszélyessé teszi az az, hogy ugyanígy elvégezhető tetszőleges nyílt szöveg titkosítása is a Padding Oracle segítségével!

Ismét a (*) egyenletből kiindulva:

  • X+0x01=X+<D(C) utolsó byte-ja>+X=<D(C) utolsó byte-ja>

vagyis D(C) megkapható, így

  • Pi=D(Ci)+Ci-1

miatt az Ci-1 beállításával meghatározható Pi. Fontos megérteni, hogy ez az utolsó lépés az "orákulumban" történik: az általunk adott bemenet Ci és Ci-1 és azt szeretnénk, hogy Pi általunk választott legyen, anélkül, hogy ismernénk D() kulcsát. 

Vegyük észre, hogy az eljárás során "tönkre kell tennünk" (Ci-1)-et, ahhoz, hogy Ci-re jó Pi-t kapjunk. A (Ci-1)-re kapott Pi-1 kimenetet viszont helyreállíthatjuk Ci-2 megfelelő beállításával, és így tovább egészen az IV-ig, aminek a megváltozása jó esetben nem zavar senkit. Persze vannak alkalmazások, ahol az IV rögzített, ilyenkor a nyílt szöveg első blokkja használhatatlanná válik.

A DotNetNuke vesztét az okozza, hogy ezzel a módszerrel létrehozható olyan titkosított süti, ami megmondja a rendszernek, hogy mi bizony adminok vagyunk.

Ez lenne tehát a probléma lényege, igazából nem kell hozzá matematikusnak lenni, hogy az ember megértse. Ettől függetlenül előfordulhat, hogy az interpretációm nem kristálytiszta, kommentben kérdezzetek nyugodtan, vagy olvassátok el Juliano Rizzo és Thai Duong eredeti esszéjét.

Címkék: kriptográfia padding oracle

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.

kutyacica 2010.10.05. 18:54:44

Buttyan Levente a Vaudenay tamadas publikalasa ota oktatja ezt a szakiranyon, a slide deck nagyon jo szerintem (vegen van a padding cucc):

www.hit.bme.hu/~buttyan/courses/BMEVIHI4372/sym-enc.pdf

Az eredeti papert azert tudom ajanlani mert ertekezik a lehetseges megoldasokrol is.
www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf

A lenyeg kb az lenne, hogy a helyes sorrend 1) pad 2) mac 3) titkosit, vagyis visszafele a mac ellenorzes mindig a padding elott es nem utan tortenik, igy a megbuheralt uzenetek mindig ugyanugy mac ellenorzes hiba miatt szallnak el.

Aron bacsi 2010.10.06. 18:43:28

Leventére érdemes odafigyelni kripto terén... Egyébként, jópofa kis támadás ez. Végülis így a "brute force" támadás egy 8 byte-os (64 bites) IV esetén nem max. 2^64, hanem csak max. 8*256 próba...