Kedves olvasók, barátaim! Hosszú mérlegelés után úgy döntöttem, hogy a mai napon bezárom a BuheraBlog kapuit. Nem áprilisi tréfa. Ezen a lépésen már hónapok óta rágódom, a hazai szakma utóbbi időben tapasztalt mélyrepülése nem okozója, legfeljebb katalizátora lehetett a döntésnek. Éppen ezért első körben meg is kímélnék mindenkit kritikus gondolataimtól, ehelyett mindenek előtt szeretném megköszönni azt a hihetetlen mértékű támogatást, amit az elmúlt majd' 7 évben kaptam tőletek!

Ez alatt az idő alatt a blog többszörösen túlteljesítette eredeti célját. Az induláskor ez a cél saját ismereteim bővülésének elősegítése, rendszerezése volt. Ebből aztán szép lassan goldenblogos szakmai (hír)oldallá fejlődött a történet, a barátaimmal céget alapítottunk, én pedig a hazai IT-biztonsági szakma egyik arcává avanzsáltam. És ez rendben is volt így.

Azonban eközben a világ, és én is megváltoztunk: Az információbiztonságot felkapta a mainstream média, egymást érik a nagy volumenű adatlopásokról, a hírszerzési szivárogtatásokról, és a feltört kakukkosórákról szóló híradások, és akkor még nem beszéltünk az egyre nagyobb forrásokkal támogatott ezért (szerencsére) egyre gyakrabban feltűnő nívós szakmai eredményekről. Míg annak idején a blog, mint platform ideális formátumot nyújtott ezeknek az újdonságoknak az (akkori szemmel) rapid közlésére, ma már az IT-biztonsági híradás teljes embereket, szerkesztőségeket kíván - szerencsére van is ezekből értékelhető választék* - én pedig egyre kevésbé töltöm szívesen az időmet a blog.hu (egyébként remek :) szerkesztőjében a debugger helyett.

Hét éve az IT-biztonsági hírek, eredmények magyar nyelven történő közlése kuriózum volt, és nagyon remélem, hogy az én munkám is hozzájárult ahhoz, hogy néhány tehetséges embert elkapjon a legjobb értelemben vett gépszíj. Azonban azt is látom, hogy a blog sokakat elkényelmesített: miért vesződjünk a napi hírek bogarászásával, értelmezésével, mikor a Buherán úgyis ott lesznek a legfontosabb tudnivalók? Pedig ma, 2014-ben nem kell többé "underground" fórumokat és IRC csatornákat túrni, aki szeretne, könnyen megtalál minden szükséges anyagot a kedvenc keresőjével, legyen szó hardware backdoorokról vagy éppen a nemzetközi IT-biztonsági trendekről. Aki ezt az energiát nem fekteti be, az jobb, ha más elfoglaltságot keres magának. 

Természetesen a könnyen elérhető információtenger sem hagy minket munka nélkül: el kell tudnunk választani az értékes információt az értéktelentől. Ezen a téren sajnos a blog minden igyekezetem ellenére sem tudott látványos eredményt elérni, a hazai színtéren még mindig évtizedes dogmák és persze a kicsinyes érdekek a meghatározók az érvek és a szakmaiság helyett.

Ennek a felismerése a hazai IT-biztonsági kultúra egésze szempontjából kritikus fontosságú lenne. Nagyon nehéz ugyanis előremutató gondolatokat, eredményeket közvetíteni, miközben a szakértőket a nyakkendőjük és vélt érdemeik, nem pedig tényleges képességeik alapján ítélik meg, ha egy kutatás akkor lesz kimagasló, ha nem kell rajta sokat gondolkodni, és ha a legfontosabb IT rendszerek irányítóinak legnagyobb félelme még mindig az, hogy "fel lehet-e törni" a cég statikus weboldalát.

Ennek a megváltoztatásához közösen kell cselekedniük azoknak, akik úgy érzik, hogy az információbiztonság a hivatásuk és nem csak egy munka a sok közül.

Nem elég egy blog, hanem kell több tucat blog, honlap, portál és profil, melyek közösen állnak ki az értékes mellett, és utasítják el az értéktelent. Az ősleves már készen van, de az evolúciónak kell rendet teremtenie, hogy a megélhetési szakértők, gittegyletek és kamukonferenciák helyén teret kapjanak a szárnyukat bontogató, világszínvonalú magyar hackerek.

Azokat, akik egyetértenek, és azokat, akik vitatkoznának, szeretettel várom a május 22-i Ethical Hacking konferencia után (~17:30) a No Name sörözőbe, ahol a hagyományokhoz méltó tivornya keretében búcsúzunk el a blogtól.

Én persze nem megyek sehová (és ezt vehetitek fenyegetésnek :), Twitteren és IRL is tovább osztom az észt, e-mailben a szokott módon elértek. A posztot a záróbuliig még frissítem a részletekkel, utána a kommentelési lehetőséget globálisan lezárom, és eldobom a blog.hu-s jelszavaimat (a deface-nek sportértéke tehát még kb. három hétig van ;).

"In the underground, integrity lies within
in the underground, image doesn't mean a thing
we can do away with this negativity
it's a golden day we can force them to step down"

* Phrack | Krebs on Security | Ars Technica | Full-Disclosure 

A Heartbleed sérülékenység kapcsán eddig világos volt, hogy:

• A bejelentést követő javítási ablakban minden valamennyire is ismert szolgáltatás esetén gyakorlatilag biztosra vehető, hogy a kiszolgálók által kezelt adatok jelentős része (jelszavak, session azonosítók, egyéb érzékeny adatok) kiszivárgott. 
• A bejelentés előtt nagyjából két éven keresztül szemfüles feketekalaposok és a jobban informált szolgálatok is szimatolhattak a kiszolgálók memóriájában.

A nagy kérdés az volt, hogy mekkora az esélye a privát kulcsok kiszivárgásának? Nos, a Cloudflare felállított egy tesztrendszert, melyen sérülékeny OpenSSL változatot futtattak egy nginx webkiszolgáló alatt, és felkérték az internet népét, hogy ha tudják, szerezzék meg a privát kulcsukat. 

A feladatot 24 órán belül két ember is teljesítette, Fedor Indutny nagyjából 2.5 millió, Ilkka Mattila pedig nagyjából 100.000 szívverés elküldése után volt képes helyreáéllítani a "titkok titkát". 

A privát kulcsok kiszivárogtatása tehát valós környezetben, interneten keresztül is kivitelezhető, bár az akció elég zajos. 

A félreértések elkerülése végett: a privát kulcsokat egy támadó akkor tudja használni, ha megfigyel egy, a kulccsal rejtjelezett (tudom, pongyola megfogalmazás) adatfolyamot. Amíg tehát az eredeti hibát bármelyik bitbetyár a világ bármely pontjáról ki tudta használni, a privát kulcsok leginkább akkor jönnek jól a támadónak, ha történetesen az áldozat mellett ül a Starbucksban (vagy egy fekete dobozban az ISP-nél...). 

Aki eddig nem tette meg cserélje le érintett digitális tanúsítványait!

Nem lepődnék meg ha a mai nap az IT-biztonság fekete keddjeként vonulna be a történelembe: az egyelőre felmérhetetlen súlyú Heartbleed sérülékenység mellett ma lejár a Windows XP (és az Office 2003) biztonsági támogatása, pedig még jócskán vannak élő rendszerek, méghozzá olyan helyeken, amiket egyáltalán nem lenne jó 0wnolva látni. 

A tisztán látás kedvéért, illetve mivel több vonatkozó kérdést kaptam az utóbbi időben, leírom mi jön most:

• Mindenki szépen feltelepíti a mai MS frissítéseket. (az MS14-019-et elmagyarázhatná valaki kommentben btw.)
• Várunk maximum egy hónapot, amíg kijönnek a következő MS javítások
• A hackerek (kalapszíntől függetlenül) elkezdik visszafejteni a patch-eket
• A patchek alapján exploitok születnek, amik így-vagy úgy eljutnak rossz kezekbe is, beszéljünk akár az aktuális nagy Ellenségről vagy egyszerű Zeus banditákról
• Az exploitok szépen lassan be fognak szivárogni a még mindig XP-t használó hálózatokba, és GAME OVER.

Ezek mellett fontos hangsúlyozni, hogy:

• A vírusírtó nem fog megvédeni (sőt0, sőt1)
• A rövidesen felbukkanó "XP-őr" sneakoil termékek főleg nem
• Imádkozni ér, nyafogni nem, volt idő az átállásra

Most pedig:

Az OpenSSL 1.0.1-es főverziójában olyan problémát azonosítottak, ami távoli támadók számára kiszivárogtathatja a kommunikációs csatornák titkosítására használt privát kulcso(ka)t. Igen, jól olvastátok, a hibán keresztül kiszivárgohat a szerver tanúsítvány privát kulcsa is, amivel aztán minden korábbi illetve jövőbeni kommunikáció megfejthető (a Perfect Forward Secrecy-t implementáló csatornák védettek a retrospektív támadásoktól). 

A sérülékenység egy memóriatartalom kiszivárgását okozó implementációs probléma a TLS protokoll heartbeat kiegészítésében, melyen keresztül egyetlen csomag elküldése után legfeljebb 64k adat olvasható ki az érintett processz memóriájából. 

A problémát az OpenSSL könyvtár 1.0.1g változatában javították, az 1.0.0 és 0.9.8 főverziók nem érintettek.

Az OpenSSL csomagot a világ webkiszolgálóinak 66%-a használja, az értinett verziók már két éve forgalomban vannak. Néhány népszerű, valószínűleg érintett Linux disztribució:

• Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
• Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
• CentOS 6.5, OpenSSL 1.0.1e-15
• Fedora 18, OpenSSL 1.0.1e-4
• OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
• FreeBSD 8.4 (OpenSSL 1.0.1e) and 9.1 (OpenSSL 1.0.1c)
• NetBSD 5.0.2 (OpenSSL 1.0.1e)
• OpenSUSE 12.2 (OpenSSL 1.0.1c)

A sérülékenység kihasználása a szerver oldalon nem hagy nyomot ezért a legrosszabb esettel számolva elméletileg minden érintett verziót futtató szolgáltatáson tanúsítványt kellene cserélni a szoftver frissítése mellett. Nem zárom ki, hogy az ügyesebb támadók már gyűjtögetik a nagyobb bankok és levelző szolgáltatók kuclsait... 

Ezen a linken tesztelhetitek a saját (HTTP?) szervereiteket
(A szolgáltatás elég pontatlanná vált az utóbbi időben, javasolt helyi példányokkal tesztelni.)

És ma az XP is megdöglik...

Friss: Itt olvasható egy részletes leírása a problémának (ha a fent linkelt git commit nem lenne egyértelmű). A szerző szkeptikus a privát kulcsok kiolvashatóságával kapcsolatban (bár nem zárja ki a lehetőséget). Én teszteltem párat és azt kell mondanom, hogy ha privát kulcsokat nem is találtam, de kiemelten érzékeny adatokat simán meg lehet szerezni, minden érintett azonnal frissítsen! 

Friss2: Itt például kiesett egy plaintext jelszó a yahoo.com-ból.

Cukiság péntekre: az 5 (öt) éves Kristoffer Von Hassel szeretett volna apukája XBox-án játszani, de a jelszót természetesen nem tudta, ezért más utakon próbálkozott. A kissrác végül rájött, hogy az XBox Live bejelentkező felületén rossz jelszót megadva egy másik képernyő tűnik fel, ahol a beviteli mezőt space-ekkel feltöltve be lehet jelentkezni az igényelt fiókba. 

Kristoferr természetesen először tartott a lebukástól, de végül mikor apja, Dan rájött a dologra, értesítette a Microsoft-ot a cég pedig 50 dollár pénzdíjjal, négy új játékkal és egy évre ingyenes Live előfizetéssel jutalmazta az ifjú hackert, akit a hivatalos dicsőségfalra is feltettek.

Ahogy az várható volt, az RSA körüli "vihar" gyorsan elcsendesült. Az RSA Conference rendben lezajlott, a szakma láthatóan könnyen túllépett azon, ha a világ egyik legnagyobb biztonsági cége lefekszik az NSA-nek - egy kis ingyen pia kérdése volt az egész.

Szerencsére azért nem mindenkit lehet ilyen könnyen lekenyerezni. Neves kriptográfusok nem hagyták békén a témát, és most publikált kutatásukban demonstrálják, hogy milyen hatású volt a hírszerzők által a BSAFE könyvtárba beerőszakolt Dual EC véletlengenerátor a TLS forgalom biztonságára. 

A kutatók munkájából egyrészt kiderül, hogy bár a különböző programnyelvekhez készült könyvtárak között jelentős különbségek vannak, a hátsó kaput tartalmazó véletlengereátor használata mellett egy kisebb cluster is gyakorlatilag pillanatok alatt képes lehet a TLS kapcsolatok teljes megfejtésére. 

A "szervek" számára különösen hasznos továbbá, hogy egyes implementációk olyan nonce értékeket generálnak, melyek alapján egy passzív támadó képes lehet azonosítani, hogy mely szolgáltatások futtatnak támadható implementációkat. 

A kutatás során arra is fény derült, hogy nem a Dual EC volt az egyetlen NSA-nek szánt "easter egg" a csomagban: az úgynevezett Extended Random TLS kiegészítés lehetővé teszi a kliensek számára  aszokásosnál hosszabb nonce értékek elkérését a szervertől. Mivel a backdoor éppen ezeken a nonce értékeken keresztül szivárogtatja ki a véletlengenerátor állapotinformációját, a kiegészítést használó kiszolgálók kapcsolatainak megfejtése akár 65.000-szer gyorsabb lehet. 

Persze mindez az EMC/RSA helyzetén lényegében nem változtat, a cég ugyanolyan megkerülhetetlen szereplő lesz a piacon, mint eddig volt, az igazán fontos, nagy hálózatokban pedig még sok évig ugyanúgy ott fog ketyegni az összes olyan termék, melyek hátsó kapuira még nem derült fény.

Ha szeretnétek tájékozódni, hogy a hasonló csapdahelyzeteket a jövőben hogyan kerülhetjük el, járjatok el Cryptonite-ra!

A Google szakértői célzott támadási kampányt detektált, melyben egy eddig ismeretlen Word sérülékenységet használnak ki a támadók. A probléma az RTF fájlok kezelését érintó memória korrupciós probléma. A most felfedezett exploit a Word 2010-es változatát célozza, de a probléma későbbi verziókban is megtalálható.

A Microsoft Fix-It-et adott ki a problémára.

Szerk: Az SRD posztja a hibáról itt olvasható valamivel több technikai részlettel.

John Cartwright, a legendás Full-Disclosure levelezőlista karbantartója tegnap bejelentette, hogy határozatlan időre beszünteti a lista működését. A Full-Disclosure mozgalom - melynek a levelezőlista az egyik fő bástyája volt - azzal a céllal jött létre, hogy a sérülékenység információk korlátozásmentes közzétételével segítse a kritikus fontosságú információk terjesztését és nem utolsó sorban, hogy rákényszerítse a gyártókat a hibajavításra. Ennek szellemében a lista gyakran volt hangos trollkodástól és flamewaroktól, és sokszor került a jogi osztályok célkeresztjébe is, ez azonban az elmúlt 12 évben működését lényegében nem befolyásolta károsan.

"This is all a sign of things to come, and a reflection on the sad state of an industry that should never have become an industry."

Cartwright záró levelében egyrészt rámutat, hogy az IT-biztonság már nem az ami egy évtizede volt, és hogy a régi szellemiség már jórészt kiveszett a közösségből. Az utolsó cseppet a lista bezárásához egy meg nem nevezett kutató aknamunkája adta, aki megpróbált nagyobb mennyiségű üzenetet töröltetni az archívumokból (nyilván nem ismerte az internet-medence-vizelet analógiát...). Sokan erre a jóképességű nethuszárra gyanakszanak, aki március közepe óta csinál hülyét magából a listán, de ez csak spekuláció.

A lista pótlásán már több jelentős szakértő gondolkozik, egyértelmű alternatíva egyelőre nincs. A sérülékenységinformációkra éhes agyakat egyelőre a Bugtraq-el célszerű táplálni.

A Pwn2Own idén is folytatta útját a felívelő pályán. A HP/ZDI és a Google által közösen rendezett megmérettetésen összesen 850.000 dollár jutalmat osztottak ki, és szép summát utaltak jótékony célra is. 

Pwn4Fun

De persze a sérülékenység-piacon már jól megszokott viták sem maradtak el. Idén a Twitter flame fő gerjesztője a rendezők által a rendes esemény elé szervezett, Pwn4Fun névre keresztelt akció volt. Ennek keretében a szervezők munkatársai (akik a Pwn2Ownon nem vehetnek részt) játszhattak a rendes verseny szabályai szerint, a meghírdetett nyeremények feléért, melyet automatikusan a kanadai Vöröskeresztnek utaltak. 

Sokan ezt a lépést egyszerű marketingfogásnak látják, melynek érdekében a koordinált nyilvánosságrahozatalt támogató szervezők saját elveiket/szabályaikat rúgják fel és a bugok visszatartásával a felhasználókat is veszélyeztetik. 

A Vöröskereszt minden esetre jól járt: a résztvevők a Safari és az IE leütésével 85.000 dollárhoz segítették hozzá a segélyszervezetet.

Pwn2Own

A nyílt versenyen szokásosan tarolt a VUPEN, a franciák 11 exploitot értékesítettek összesen 400.000 dollár értékben, kijászva a Chrome, az Internet Explorer, a Firefox, az Adobe Reader és az Adobe Flash védelmét is. A böngészők közül egyébként a Firefox volt a legnépszerűbb célpont, a program felett GeoHot, Jüri Aedla és Mariusz Mlynski is sikerrel vette át az uralmat. A Safarira idén csak a kínai Keen Team és team509 mozdultak, szintén sikerrel - ők nyereményük egy részét malajziai jótékonysági szervezeteknek ajánlották fel. A legkeményebb célpontoknak számító Internet Explorert és Chrome-ot a VUPEN mellett a Sebastian Apelt - Andreas Schmidt páros illetve egy névtelen kutató is sikeresen pwnolta.

A kijelölt célpontok közül meglepő módon egyedül a Java maradt talpon, egy click-to-play átugrását igénylő exploit demonstrálásától a VUPEN végül visszalépett. A teljes eredménytábla itt tekinthető meg.

Az Unikornis díjat (EMET+böngésző snadbox kitörés, majd SYSTEM szintű kódfuttatás) végül nem vitték el, de ez szvsz. nem a feladat teljesíthetetlenségét, inkább annak életszerűtlenségét jelzi.

Az eredmények jól mutatják, hogy még a legmodernebb exploit mitigációs technikák sem elégségesek egy kellően felkészült támadó megállításához, és hogy a komplex renderelő motorok még mindig gazdag tárházát nyújtják a kihasználható sérülékenységeknek. A javítások (és remélhetőleg a writeupok is) remélhetőleg már utón vannak.

Február végén deface-elték a legfőképp Certified Ethical Hacker (CEH) minősítésről híres EC-Council weboldalát. A szervezet most, három hét (!) elteltével nyilatkozott az esetről (a Facebookos handabandázást nem tekintem komolyan vehető reakciónak), a lényeg:

• A támadók az eccouncil.org domain regisztrátorát kompromittálták és átírták a DNS rekordokat
• Ezt a közlemény nem említi, de miután sikeresen visszaállították a honlapot, a támadók még egyszer deface-elték azt, mivel az admin a korábbival megegyező jelszót használt.
• Az EC-Council cloud alapú infrastruktúrája a domain átirányátson keresztül lehetővé tette, hogy a honlap deface-elésén túl a támadók a cég levelezéséhez is hozzáférjenek (!!)
• A szervezet szakértői nem tudják megállapítani, hogy a támadók milyen érzékeny adatokhoz fértek hozzá (!!!), kártyaadatokhoz minden esetre nem (?!).
• Az viszont biztos, hogy a szervezet sima e-mailben várja a szkennelt azonosító okmányokat a vizsgák lebonyolításához:

Persze mondhatjuk, hogy előfordul az ilyesmi, de ez a történet jó alapot szolgáltatna egy tragikomédiához az incidenskezelésről. Én minden esetre már bánom, hogy valaha fontolgattam a CEH lerakását, most az én papírjaim is a támadóknál vannak.

Ha nem látom a saját szememmel, nem hiszem el: az Apple fiaskója után kiderült, hogy a nyílt forrású alkalmazások százai által használt GnuTLS könyvtár is tartalmazott egy ránézésra hasonló, lényegében azonos hatású (köszönj el a tanúsítvány hitelesítéstől), bár valamivel komplikáltabb hibát, amit most sikerült javítani.

A vonatkozó diff szerint a problémák az X.509 tanúsítványok ellenőrzését (ugye?) végző kód több függvényét érintik, én azt gyanítom, hogy a változásokat cirka 10 éve (!!!) bevezető kóder szimplán nem úgy értelmezte a hibajelzési konvenciókat, ahogy kellett volna (meg néha elfelejtette inicializálni a változóit).

    if (result < 0)
    {
      gnutls_assert (); 
---   goto cleanup;
+++   goto fail;
    }

+++ fail:
      result = 0; 

    cleanup:
    //...
      return result

Nincsenek szavak.

Szerk: Diff javítva, thx tr3w!

A rendkívül szofisztikált és hosszan tartó (marketing) kampányok listájának legújabb állomása a nyomok szerint orosz gyökerekkel rendelkező Uroburos akció, melynek nyomaira a GData szakértői bukkantak rá. Az elkészült elemzés szerencsére valamivel több információt közöl a kártevő működéséről a szokásos "tud képernyőképet készíteni és lehallgatja a Skype-ot [értsd: mikrofonodat] is" túristacsalogatónál.

Megtudhatjuk például, hogy a program képes P2P kommunikációra is az internetről szeparált rendszerekről történő adatkijuttatás érdekében, virtuális NTFS fájlrendszereket és rendes kriptót használ, a készítők tehát semmi képpen sem a legkissebb ellenállás irányába haladtak.

A(z eddigi) legérdekesebb részletre azonban a kernelmode.info fórumozói hívták fel a figyelmet:

A kártevő rootkitet telepít, de nem akárhogy: a kezdeti payload titkosítottan tartalmazza a VirtualBox egyik eredeti, bár elavult driverét, ami máig hiteles digitális aláírással rendelkezik, így egyszerű felhasználók számára is betölthető. A driver azonban tartalmaz egy sérülékenységet: a felhasználói módból érkező IOCTL-eket a meghajtó olyan pufferelési módban kapja, hogy az operációs rendszer semmilyen vizsgálatot nem végez az átadott struktúrákon illetve címeken. Mivel a driver maga sem implementál semmilyen ellenőrzést (ez okozza a sérülékenységet), a felhasználói módú program (esetünkben az Uroburos) korlátlan hozzáférést kap a kernel címtartományához.

A kártevő ezt arra használja ki, hogy kikapcsolja a Windows tanúsítványellenőrző rutinját, így ezek után Szása bármilyen aláíratlan drivert is simán betölthet.

A módszer amellett, hogy szerintem igen elegáns, felhívja a figyelmet a kód aláírás korlátaira (hiába aláírt a  kódod, ha sérülékeny, tágabban értelmezve a tanúsítvány csak a kód eredetét, nem a szándékát igazolja), illetve a tanúsítvány lejárati idők megfelelő megválasztásának fontosságára is.

Kernelszakértők javítsanak ki, ha valami ülyeséget írtam, köszi!

Az Apple nagy nehezen kiadta a foltot a GOTO fail problémára. A frissítés az SSL kezelés mellett számos távoli kódfuttatásra illetve sandbox-kitörésre alkalmas problémát javít. 

A frissítés telepítése után sokan SSL gondokra panaszkodnak, a konteógyártást mindenkire rábízom

For the protection of our customers, Apple does not disclose, discuss, or confirm security issues until a full investigation has occurred and any necessary patches or releases are available.

Az Apple ma kiadott iOS frissítésében (7.0.6, 6.1.6) egy különösen veszélyes problémát javított a készülékekkel szállított SSL könyvtárban. Úgy tűnik, Stefan Essernek sikerült megtalálnia a problémát okozó kódrészletet, amivel az Apple előkelő pozícióra tett szert a hülye hibák ranglistáján:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
// ...
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;

err = sslRawVerify(ctx,
ctx->peerPubKey,
dataToSign, /* plaintext */
dataToSignLen, /* plaintext length */
signature,
signatureLen);
// ...

fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;

}

Amint látjátok, egy feltehetően véletlenül becsúszott(?) sorduplikáció azt eredményezi, hogy a kód hibaágra fut még az SSL tanúsítvány tényleges ellenőrzése előtt, ami nem lenne akkora baj, ha a függvény visszaadott hibakódja nem jelezne sikert (err=0, nincs hiba). Így a hibás implementáció gyakorlatilag bármilyen tanúsítványt elfogad. (Komolyan érdekelne, hogy egy ilyen problémára miért nincs legalább egy unit teszt az Apple-nél...)

A durva az, hogy a Register szerint a probléma az OS X 10.9.1-et is érinti, javítás azonban egyelőre csak a 10.9.2 bétájában áll rendelkezésre (vagy talán ott sem). Szintén kellemetlen helyzetben vannak a jailbreakerek, akik számára egyelőre nem áll rendelkezésre a frissített verziókra szánt evasi0n.

Friss: Kutyacica tesztjei szerint a probléma legalább 2013 márciusa óta fenn áll. Ez azt jelenti, hogy az Apple megvalósítását használó SSL kliensek (pl. Safari) már legalább egy éve nem voltak megbízhatók.

Friss2: A legfontosabb információk, az eszközök tesztelésére használható tesztek, illetve linkek a nem hivatalos patchekhez a gotofail.com-on vannak összegyűjtve.

FX előadásait, anyagait azért érdemes figyelemmel követni, mert belőlük az ember általában minimális idő alatt megkapja az ismereteknek azt a letisztult, kikristályosodott változatát, amit egyébként csak több hónapnyi tanulás, gyakorlat után ismerne fel (ez egyfajta guru definiciónak is elmenne, de nem akartam nagyon ömlengősre venni a figurát). 

Felix most volt olyan kedves, és közzétette azt a cikket, amit a NATO egyik kiberbiztonsággal foglalkozó kiadványában jelentettek meg Sandro Gaykennel közösen. A "Vissza az alapokhoz: A hálózati higiénián túl" címet viselő tanulmány 10 rövid oldalban foglalja össze, hogy mi a probléma a napjainkban is érvényes biztonsági paradigmákkal, és hogyan változtathatnánk szánalmas helyzetünkön.

Mert hogy a helyzetünk szánalmas, a cikk rögtön azzal indít, hogy a számítógéphálózatok védelme legalább egy évtizeddel le van maradva a támadási módszerek mögött. Ennek okaként a szerzők négy alapvető, de hibás  paradigmát mutatnak be, melyeket megpróbálok néhány mondatban összefoglalni:

1. Perimeter biztonság: Egyszerű, könnyen megvédhető hálózati komponensekkel dolgozunk, melyek közül elegendő a hálózat határán állókat megvédeni, így a hálózatunk belseje is biztonságos marad - Ennek a nézetnek a helytelenségét talán magyarázni sem kellene, a rendszereink napról napra komplexebbek, a határok pedig egyre kézzelfoghatatlanabbak.
2. Kiválasztott (támadási) vektor: Ha észlelünk egy lehetséges támadási útvonalat, teszünk ellene, tekintet nélkül a rendszerünk többi részére. - A szerzők jó érzékkel a titkosítást hozták példaként, ami megfelelően alkalmazva hatékony lehet bizonyos támadási formákkal szemben, a támadók azonban adaptívak, így jó kriptó esetén más utat fognak találni rendszerünk kompromittálására (ld. pl. kliens-oldali biztonság).
3. Észlelés: Detektáljuk a rosszindulatú tevékenységet mialatt az megtörténik. - Ebben a megközelítésben amellett, hogy a védekező félnek eleve ismernie kell az észlelendő tevékenység paramétereit (így meg is akadályozhatná azt),  reménytelen versenyt kell futni a támadóval a hatékony reakció érdekében. 
4. Sérülékenység azonosítás: Tárjunk fel sérülékenységeket, és kényszerítsük a gyártókat javításra (full-disclosure) - A baj itt az, hogy a hibák feltárása illetve javítása valójában a játék egy szereplőjének sem áll érdekében gazdaságilag. A sérülékenység piac bimbózása mellet a FD is sorvad.

Ezek a paradigmák lecserélésre szorulnak, a szerzők pedig a következőket ajánlják a jövő rendszereinek tervezéséhez:

1. A Megelőzés-Észlelés-Helyreállítás háromszög: A megelőzési módszereinket folyamatosan fejleszteni kell a támadások fejlődésével összhangban. Felismerve, hogy így sem fogunk minden támadást megelőzni, fektessünk hansúlyt az észlelésre, de az előzőektől eltérő módon, a sérülékenység-kihasználás utáni (post-exploitation) periódusra fókuszálva, mikor a támadónak már a mi pályánkon kell játszania. Végül támaszkodjunk olyan rendszerekre, melyek ismert jó állapota egy sikeres támadást követően könnyedén visszaállítható. (a szerzők itt - talán meglepő módon - a cloud technológiára kacsintanak).
2. Tiszta lap: Egykor kevésbé praktikusnak, vagy megvalósíthatatlannak tűnő ötleteket érdemes újra górcső alá venni. A rendelkezésünkre álló (egykor elképzelhetetlen) számítási kapacitással sok rendszerelem működése formálisan verifikálható lehet, vagy miért ne építhetnénk Harvard architektúrájú gépeket?
3. Interfészek védelme LangSec-kel: A különböző rendszerkomponensek kommunikációjához szükséges nyelvek, és az ezeket feldolgozó forráskódok automatikus generálására és verifikálására ma már léteznek alkalmazható módszerek. Mennyivel szebb lenne a világ, ha az X.509 feldolgozókat nem szerencsétlenebb sorsú embertársainknak kellene leprogramozniuk?
4. Decentralizált és finomhangolható bizalom: A felhasználók jogosultságkezelésétől a PKI infrastruktúráig a bizalmi rendszereket elosztott alapokra kell helyezni. 

Bár ezek az új paradigmák meglévő rendszereinkbe nehezen vagy egyáltalán nem építhetők be, a régi elvek lecserélését mihamarabb meg kell kezdeni, ha nem akarunk még több hátrányt felhalmozni a támadókkal szemben. Ennek első színtere a nagybiztonságú rendszerek, pl. katonaság, repülésirányítás, ipari irányítás lehetnek, de remélhetőleg az újítások (ahogy sok ma is használt megoldás) a civil szférába is átszivárognak majd.

És ugyan ezek a távlatok sokaknak érdektelenül távolinak tűnhetnek, a megfogalmazott elvek, látásmódok alkalmazása a mindennapok során is hasznos lehet, a teljes anyagot nyomatékosan ajánlanám minden IT-biztonságban érdekelt vezető, döntéshozó figyelmébe!

Az Internet Explorer 0-day ellen kiadott ideiglenes folt megjelenésével nagyjából egy időben a FireEye újabb célzott 0-day kampányt azonosított. A támadók külpolitikával foglalkozó illetve gazdasági oldalakon keresztül egy Flash 0-day exploitot használnak (az Adobe figyelmeztetője patch linkekkel együtt itt olvasható), hogy hozzáférjenek különböző, szintén külpolitikával foglalkozó civil szervezetek rendszereihez. 

Az exploit ezúttal rosszul frissített rendszereket támad, melyeken az 1.6-os Java vagy foltozatlan Office változatoknak köszönhetően fel tudnak használni statikus helyre betöltődő DLL-eket az ASLR kijátszására. A sikeres hibakihasználás után a shellkód ismert trójaiakat telepít a célpontokra. 

A Microsoft ideiglenes javítást adott ki az Internet Explorer célzott támadásokban kihasznált 0-day hibájához. A FixIt eltéríti az érintett MSHTML API-kat, és a meglévő funkcionalitás újrafelhasználásával helyre rakja a referencia számlálókat, ami a sérülékenységet megszűnteti, viszont memory leaket hagy maga után - ezt az apróságot a feltehetően jövő hónapban érkező, végleges javítás fogja megszűntetni.

A sérülékenységről további elemzést olvashattok az exploitot felfedező FireEye-nál, illetve egy kínai kollega blogján.

Az exploittal kapcsolatban egyelőre nem világos, hogy hogyan képes kitörni az Internet Explorer Védett Módjából. Egy érdekes elmélet szerint az alacsony integritású kód elméletileg detektálhatja, hogy jó helyen jár-e, és csak a megfelelő célpontnál aktiválja a nagy értéket hordozó privilégiumemelő rutint - szívesen látnék ebből egy PoC-t :)

A Citizen Lab egy elég érdekes tanulmányt közölt az olasz székhelyű, kormányzati felhasználásra szánt spyware-eikről elhíresült Hacking Team lenyomozhatatlan szervereinek lenyomozásáról. A felderített célpontok között pedig egy magyar cím is szerepel.

Miután a Citizen Lab közölte a kiszolgáló IP-jének első három oktettjét, a szervert pedig még aktívként tüntették fel, gondoltam játszom egy kicsit. Úgy tűnik nagyjából 5 perc alatt sikerült megtalálni az ominózus RCS (Remote Control System) szervert a Telekom egyik fix IP-knek fenntartott tartományában - a kiszolgáló lenyomozása remek házifeladat tanulni vágyóknak :)

7973ED02A4A9A2387A99C4410FC0B1DC9012FBE5C605C845AD6A17F31802E12B

A Citizen Lab a kiszolgálók azonosításakor egyrészt a magukat egyszerű HTTP szervereknek álcázó RCS válaszok mintáira, másrészt a kiszolgálók SSL tanúsítványaira hagyatkoztak, a proxy láncokat pedig az csomagok fragmenteket azonosító IPID mezőjének figyelésével azonosították. Ez a mező régebbi operációs rendszereken globálisan használt és kiküldött csomagonként inkrementálódik, az értékéből tehát következtetni lehet arra, hogy egy kiszolgáló hány csomagot küldött ki a megelőző időszakban. A szakérők beküldtek egy csomagot egy RCS szerverként azonosított hosztra, és figyelték, hogy mely más szerverek IPID értékei növekednek ezzel szinkronban. Ilyen módon egy kis statisztikát bevetve a bizonytalanságok enyhítésére elég biztos eredményeket lehet kapni, azonban a Citizen Lab eredményei még így sem 100%-ig meggyőzőek. Maga a tanulmány is számos alkalommal hangsúlyozza, hogy feltevéseket, nem bizonyított, vagy egyenesen bizonyíthatatlan állításokat fogalmaz meg.

Egyebek mellett például a műfaj sajátosságaiból adódóan soha nem állíthatjuk teljes bizonyossággal, hogy egy szolgáltatást nyújtó hoszt és az azt használó személy(ek) fizikai elhelyezkedése között kapcsolat lenne, tehát simán elképzelhető, hogy a Dataplexben zümmögő gépet valójában az etióp elhárítás használja, vagy éppen fordítva, ezért messze menő következtetéseket ezen adatok alapján nem érdemes levonni. Szerk.: Az viszont annál érdekesebb, hogy Magyarországhoz köthető spyware mintákat is találtak...

A kriptográfiát fejlesztői, tesztelői, kódelemzői szemmel nézve fontos ismerni azokat az ökölszabályokat, amelyek alapján a függvényeket biztonságosan meg lehet hívni, a jó prímeket ki lehet választani. Pontosan ezen ökölszabályok kerülnek bemutatásra az RSA algoritmus esetén Szabó István (ELTE) előadásában:

• mik a jó prímek tulajdonságai, mennyire legyenek egymástól távol, milyen legyen az arányuk,
• prímtesztnél hány ciklusig kell azt futtatni ,
• kell-e aggódni a beégetett kicsi "e" értékek miatt chipkártyás kulcsgenerálásoknál,
• a kulcsokat milyen méretű adatra kell legalább alkalmazni 

Időpont, helyszín: 2014. február 21. 19:00, H.A.C.K  (Az erre fogékonyabbaknak Facebook event)

A FireEye eddig ismeretlen 0-day Internet explorer exploitot azonosított. A célzott "watering-hole" támadásokban kihasznált use-after-free sérülékenység a böngésző 9-es és 10-es változatait érinti, a támadók most a 10-esre lőnek. Az exploit Flash-es heap-spray-t használ az ASLR megkerülésére, és egy ROP lánc lefutása után gey egy byte-os XOR-ral obfuszkált ZXShell RAT-t pottyant az áldozat gépére (ez a trükk gondolom az AV-knak ismét megugorhatatlan feladatot jelent). Érdekesség, hogy az exploit képes detektálni, ha az áldozat EMET-et használ, ilyenkor a támadók visszavonulót fújnak. Az IE 10 sandbox kijátszásának módjáról egyelőre nem áll rendelkezésre információ.

A FireEye szerint a támadás sok hasonlóságot mutat két korábbi 0-day kampánnyal, melyek amerikai illetve japán célpontokat érintettek. Ez, és a trójai is arra utal, hogy ismét keletről fúj a szél. 

A Microsoft elismerte a probléma létezését, javítás egyelőre nincs. A kockázatok a Flash letiltásával, EMET belövésével, vagy alternatív böngésző használatával csökkenthetők.

Friss: Itt olvasható egy analízis a sérülékenységről, itt látható egy strings kimenet a payloadből, itt pedig a visszafejtett SWF spray.

Sokat gondolkoztam azon, hogy mit is írjak a legújabb "szuperkártevőről" és a Kaspersky vonatkozó jelentéséről [62 oldal PDF], az érzelmeim ugyanis elég vegyesek. 

Egyrészt nincs kétségem afelől, hogy valóban egy jelentős erőforrásokkal rendelkező csoport, jó eséllyel valamilyen állami hírszerző szervezet áll a Maszk mögött. Ezt támasztja alá a célpontok köre, a (feltehetően) többplatformos payload készlet, a felhasznált nem-biztos-hogy-0-day Flash exploit és még biztos egy sor más dolog amit a Kaspersky nem tett közzé a nyomozás érdekében. 

Ugyanakkor nem tudok szó nélkül elmenni néhány dolog mellett, ami nem kifejezetten a "The Mask" kutatását, inkább a biztonsági ipar egészének működését érinti.

A biztonsági cégek nagyjából a Stuxnet óta néhány havonta iszonyatos marketing csinnadrattával ünneplik egy-egy új "APT" kártevő felfedezését, elemzéseket, sajtóközleményeket adnak ki, konferenciát szerveznek, a marketing osztálynak meg kiadják, hogy a legújabb "csodafegyver" márkanevétől ihletten rajzoljanak vagány illusztrációkat - így végül saját sikerükként adják el azt, hogy éveken keresztül nem voltak képesek elvégezni azt a feladatot, amiért az ügyfeleik fizettek nekik.

Persze lehet azzal érvelni, hogy ilyen "rendkívül kifinomult" malware-eket nagyon nehéz elkapni, de ha áttekintjük pl. a Maskról közzétett információkat, akkor láthatjuk, hogy a rejtőzködő funkciók nem elsősorban a biztonsági termékek kijátszásához, hanem a manuális elemzés megnehezítésére lettek kitalálva - a szoftveres detektálás elkerülése láthatóan nem okozott komoly problémát.

És ez még mindig nem a tudomány teteje. Nem kell elmenni az CIA-ig, hogy az ember a Stuxnetéhez hasonló információ-kitalicskázó P2P infrastruktúrát és teljesen aszinkron C&C kommunikációt vagy a diszket nem érintő payloadokat lásson. Ha a maszkos fejlesztők kicsit dolgoztak volna még a kódjaikon, a Gausshoz hasonlóan használhattak volna dinamikusan változó titkosítási kulcsokat, és akkor a Kaspersky riportja is minden bizonnyal jóval soványabb lenne. De spanyol ajkú barátainknak nem kell megerőltetniük magukat, nyugodtan dolgozhatnak akár nyílt-forrású backdoor kódokkal, Metasploittal, vagy akár PoisonIvy-val is, és az sam baj, ha benne hagynak némi debug adatot a kódban.

Végül érdemes megnézni, hogy milyen megoldásokat kaphatunk ezekre a problémákra. Érdekes módon a világraszóló elemzések jellemzően nem tartalmaznak fejezeteket arról, hogy az adott gyártó milyen kritikai tanulságokat vont le a saját védelmi megoldásaival kapcsolatban, vagy hogy a jövőbeni termékek hogyan fognak jobb minőséget nyújtani a felhasználóik számára. Mivel az előremutató technológiákat felvonultató, a modern igényeket kielégíteni hivatott biztonsági rendszerek ára a legtöbb felhasználó számára a felfoghatatlan nagyságrendbe esik, technológiai értelemben valójában nincs is kivel versenyezni a felhasználók kegyeiért. 

A virtuális világ kémei pedig kényelmesen hátradőlhetnek: a "legkifinomultabb" hátsó kapuk most is ott ketyegnek a célpontok gépein, és várhatóan ott is maradnak, amíg az operátor a dolga végeztével ki nem adja a "SEFDESTRUCT" parancsot.

Microsoft

MS14-005: Az XML Core Services sérülékenysége lehetővé teheti, hogy egy speciális weboldal segítségével fájlokat olvassunk ki a látogatók számítógépéről illetve betekintést nyerjünk idegen domaineken megjelenített tartalmakba (pl. bejelentkezés után elérhető információk). A Windows szerver változatain alapértelmezetten érvényes emelt biztonsági beállítások védelmet nyújtanak a sérülékenység kihasználása ellen. 

MS14-006: Nagy számú IPv6 Router Advertisement csomag kiküldésével egy távoli támadó DoS-t idézhet elő Windows 8 és Server 2012 rendszereken. 

MS14-007: Egy sandbox kitörésre kiválóan alkalmasnak látszó sérülékenységet javítottak a Direct2D alrendszerben. A probléma webböngészőn keresztül kihasználható, és sikeres kihasználás esetén rendszer szintű kódfuttatást eredményez. Minden Windows 7 és újabb rendszer érintett.

MS14-008: Ez a sérülékenység újabb gyönyörű példája annak, amikor egy biztonsági funkció generál új támadási vektort egy rendszerben: a Mirosoft Forefront Protection for Exchange hibája tetszőleges kódfuttatásra ad lehetőséget speciális e-mail csatolmányok ellenőrzésekor. A szoftver 2010-es változata érintett.

MS14-009: Három hibajavítás a .NET keretrendszerhez. A legérdekesebb ezek közül a James Forshaw által felfedezett type traversal probléma, ami tetszőleges alkalmazás elindítására ad lehetőséget a böngészőből - feltételezem ez a bug ért Jamesnek 100.000 dollárt a BlueHat Prize keretében.

MS14-010: Ez az ehavi Internet Explorer frissítés, ami szokásosan a böngésző minden változatán javít kritikus besorulású sérülékenységeket. Érdekesség, hogy a figyelmeztetőben sokak mellet köszönetet mondanak ennek a csókának is.

Egy további firssítés keretében a megtiltja az MD5-tel integritásellenőrzött digitális tanúsítványok használatát a Root Cert. Programban résztvevő hitelesítő szervezetek esetén. A frissítés nem települ automatikusan, de installálása mielőbb javasolt.

Adobe

A múltkori rendkívül Flash frissítés után az Adobe ebben a hónapban csak a Shockwave Player windowsos és maces változataira adott ki javítást. A folt egy két darab kódfuttatásra alkalmas sérülékenységet javít, a javítási prioritás 1-es.

Az Adobe soron kívüli frissítést adott ki a Flash Player windowsos, linuxos és maces változataihoz. A rendkívüli frissítést egy vadon felfedezett 0-day exploit indokolja. A KrebsOnSecurity szerint a hibajavítás kapcsolatban lehet a Kaspersky által detektált "The Mask" célzott kampányhoz, ami a megszellőztetett információk szerint különösen kifinomult exploitokkal, rootkittel és bootkittel valamint speciálisan a Kaspersky víruskergetőjével szemben kifejlesztett modullal is operált. Részleteket a biztonsági a cég a négy nap mulva megrendezésre kerülő éves konferenciáján hoz nyilvánosságra.

Friss: Juteszembe, ha valaki szeretne Flash Playerrel játszani, Attila posztja a Pintool és a Flash Player pároztatásáról hasznos olvasmány lehet.

Friss (20140205): A Kaspersky szakértője cáfolta a KrebsOnSecurity-t, a most javított sérülékenységnek nincs köze a The Mask kampányhoz.

Friss (20140205): A Kaspersky egy részletesebb elemzést is közölt az exploitról.

Idén tavasszal is megrendezésre kerülnek a kliens-oldali exploitok Grand Prix-jai, a Pwn2Own és a Pwnium.

Pwn2Own 2014

A nagyobb hagyománnyal bíró, a kliens-oldali exploit mitigációk zászlóshajóinak számító webböngészőket célba vevő Pwn2Own összedíjazása idén majdnem 650.000 dollár, a legdrágább - vagyis leginkább védett(nek vélt) - célpontok idén is a Google Chrome és az Internet Explorer lesznek, 64 bites Windows 8.1-en. Az új operációsrendszerben a sandboxinra eddig is használt Mandatory Integrity Control, valamint a "szokásos" ASLR és DEP mellett újabb megerősítéseket kapott a heap manager, így a heap metaadatok manipulálása, illetve a heap spraying még nehezebbé vált - utóbbi faktorban természetesen a 64 bites címtér is  nehezítést jelent.

A fenti böngészők megdöntéséért 100.000 dollár üti a szerencsések bitbűvészek markát - a szerencsére a memória randomizáció mellett a sorsolásos rendszer miatt is szükség lesz, a versenyzők próbálkozási sorrendjét ugyanis véletlenszerűen döntik el, és csak az első sikeres próbálkozó részesül díjazásban. Hogy ezért a pénzért milyen akadályokon kell átverekednie magát egy hackernek, arról egy jó összefoglalót olvashattok itt Ivan Fratic jóvoltából.

A többi vcélpont közül talán meglepő módon az Adobe Reader és Flash böngészőkiegészítők érnek a legtöbbet (75.000 dollár), jelezve, hogy a jelentős fuzz tesztelés és a kiegészítők védett módba szorítására tett erőfeszítések érdemben növelték az egykor hírhedt szoftverek biztonsági szintjét. Ez után következik a Safari + OS X kombó (65.000) majd a Firefox +Windows 8.1 (50.000) végül a Java (30.000), utóbbi beépülő esetén a click-to-play kijátszása is elvárt. 

Végül, de nem utolsó sorban idén megjelent egy új kategória, az Unikornis, melyben 150.000 dolláros fődíjjal jutalmazzák azt, akinek sikerül egy EMET-tel védett böngésző sandboxból kiugrania kizárólag böngészőt érintő hibák kihasználásával, majd ez után közepes integritású felhasználói folyamatból SYSTEM-re emelnie a jogkörét egy operációsrendszer hibát kihasználva.

Pwnium 2014

A Pwnium a Google saját versenye (a Pwn2Own-ban ők fizetik a költségek negyedét, a maradék a HP/ZDI-é), melyben kifejezetten a Chrome OS biztonságát akarják felmérni és persze bevásárolni eddig nem nyilvánosságra hozott bugokból. A verseny összdíjazása idén e millió dollár, melyből  minden olyan versenyző részesülhet, aki sikeresen demózni tud egy böngésző vagy rendszer szintű hozzáférést biztosító, böngészőn keresztül triggerelt exploitot (110.000 dollár exploitonként), illetve meg tudja tartani a gép feletti uralmat annak újraindítása után is (150.000 dollár). A versenyen ezen kívül különböző bónuszok kaphatók a különösen agyafúrt megoldásokért.

Az idei Pwnium különlegessége, hogy a célpontok között a HP ARM architektúrájú Chromebookja is szerepelni fog, ami gyakorlatilag egyfajta beavatási szertartásnak tekinthető: mostantól (valójában persze már jó ideje) a jellemzően ARM-mal hajtott mobil eszközök is valódi, értékes célponttá váltak, melyek megerősítésére (és hibáinak felkutatására) az x86-os családhoz hasonló figyelmet kell szentelnünk.

A HWSW egész jó összefoglalót közölt a Reginaldo Silva által felfedezett, a Facebook által 33.500 dollárral jutalmazott sérülékenységről. Most a Sensepost közölt egy mélyebb technikai összefoglalót, melyből kiderül néhány fontos részlet azzal kapcsolatban, hogy mégis hogyan lehet egy nagyjából szabványosank tekinthető OpenID autentikációból távoli kódfuttatást kicsikarni.

1. OpenID

A történet természetesen az OpenID-val kezdődik. Az OpenID egy nyílt autentikációs protokoll, melynek segítségével egy-egy kiválasztott szolgáltató igazolhatja a felhasználók "digitális személyazonosságát" több más szolgáltató felé. Példaként az oldal jobb szélén díszeleg a StackExchange kitűzőm:

A StackExchange oldalára pedig bárki be tud lépni (OpenID terminológiában ő a Relaying Party) pl. Google vagy Facebook azonosítójával (ők az OpenID Providerek), mindezt úgy, hogy a Stack Exchange a Google/FB jelszavunkat soha nem érinti. Így egyszerűsödik a jelszómenedzsment és csökken a támadási felület, mindenki boldog. 

Mivel az OpenID-t sok különböző szolgáltató használja, természetesen sok különböző megvalósítás is létezik, a problémák pedig hagyományosan itt kezdődnek. Reginaldo első lépésben nem is a Facebook iránt, hanem a népszerű OpenID megoldások iránt érdeklődött, és talált is hibát, először a Drupal megvalósításában, majd a Google szolgáltatásaiban is (ezért a cég 500 dolláros jutalmat ajánlott fel neki).

Mielőtt azonban a konkrét hiba részleteit taglalnánk lássuk, hogy hogyan is lehet az OpenID-t megetetni adatokkal! A felhasználónak (User-Agent) először is meg kell mondania a RP-nak, hogy OpenID-val szeretne belépni, ebben a lépésben pedig azt is közli a UA, hogy hol található a kívánatos OP. Az RP ez után elballag a megadott OP címére, és mindenféle adatokat kér tőle - hogy pontosan milyeneket, az a következő fejezetből derül ki, nekünk most arra érdemes odafigyelnünk, hogy a UA (vagyis esetünkben a támadó) a kezdeti kérés mellett az OP címét vagyis az OP által visszaadott adatokat is kontrollálja!

Vegyük észre továbbá, hogy Reginaldo esetében az Facebook nem OP, hanem RP szerepben van, a támadás az RP-ket célozza!

2. XML External Entity Injection

Miután megkapta az OP címét, az RP megkezdi az ún. discovery fázist, melyben lekérdezi az OP-től, hogy találhatók a tényleges szolgáltatás végpontok, ezek milyen verziójú OpenID protokollt támogatnak stb. Ezek az információk két féle forámban érkezhetnek: HTML-ben illetve XRDS-ben, utóbbi esetet nevezzük Yadis discovery-nek és lényegében egy XML alapú formátumról van szó.

Itt jön képbe az XML External Entity Injection: az XML entity-k (enetitások?) lényegében aliasok komplexebb (vagy nehezebben kifejezhető) struktúrákra, mindenki által ismert példák a < > &, melyek foglalt karaktereket helyettesíthetnek egy dokumentumban. Az entity-k behelyettesítését az XML feldolgozók általában automatikusan elvégzik. Az external entity-k annyiban különlegesek, hogy ez a behelyettesítés nem valamilyen elre definiált, szabványos módszer szerint történik, hanem a behelyettesítendő érték az XML dokumentumon kívüli, akár futtatókörnyezet, vagy operációs rendszer szinten elérhető adat alapján jön létre. Ilyen módon a következő dokumentumot (az OWASP-tól kölncsönöztem) feldolgozva az &xxe; entitás helyére a /dev/random "tartalma" kerül...

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

... a folyamat (rosszabb esetben a rendszer) pedig memória hiányában összedől. Ha pedig a következő dokumentum tartalma feldolgozás után valahogy visszajut a felhasználóhoz, az /etc/passwd is kiolvashatóvá válik:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

3. PHP

De hogy lesz ebből kódfuttatás? A fenti két lépés az OpeinID wikioldala elolvasása után nagyjából kézenfekvő lehet annak, aki tudja mi az az XEE, de aki kicsit beleásott a témába, az azt is tudhatja, hogy az ezek a támadások általában nem túl erősek az XML szabvány szigorú megkötései (karakterkészlet, jól formázottság) miatt. A magam részéről ilyen problémákkal szinte kizárólag Java alkalmazásoknál találkoztam - mint tudjuk, a Java meg az XML kéz a kézben jár, a népszerű javás XML feldolgozóknál pedig alapértelmezetten engedélyezett a külső entitások feldolgozása (ellentétben pl. a .NET-tel) - és a sérülékenységek besorolása általában megragadt a sárga-közepes kockázatú kategóriában. De hála a Tervezőnek, XML-t feldolgozni PHP-val is lehet...

A PHP egyik biztonsági körökben közkedvelt lehetősége a különböző erőforrás wrapperek használata. Egy egyszerű URL lekérdezéskor pl. a 'http://' wrappert hívjuk segítségül, hogy hozzáférjünk a webes tartalomhoz, de a php:// wrapperen keresztül (megfelelő konfiguráció mellett) egy helyi file include probléma egy csapásra kódfuttatássá varázsolható. 

A poén az, hogy ezek a wrapperek a XML entitások feldolgozásakor is működnek, így egy elegáns base64-el megoldhatjuk a formátumellenőrzésből fakadó problémákat:

<!ENTITY a SYSTEM 'php://filter/read=convert.base64-encode/resource=/etc/passwd'>

Az expect:// burkolóval pedig kódot is futtathatunk:

<!ENTITY a SYSTEM 'expect://id'>

Vége a játéknak.

Utóirat

Itt ragadnám meg az alkalmat, hogy (ismét) felhívjam a figyelmet az Offensive-Security összefoglalójára a saját bug bounty programjukkal kapcsolatos tapasztalataikról. Ajánlott olvasmány minden potenciális résztvevőnek, kiírónak, és hőbörgőnek!