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

A BitBetyár Blog

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

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

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

Licensz

Creative Commons Licenc

Kritikus ASP.NET sebezhetőség

2010.09.20. 11:46 | buherator | 4 komment

 Nem sokon múlt, de sikerült túlélni a Hacktivity-t, az utóbbi 3 napban viszont még e-mailt nézegetni sem volt időm, így a posztok is elmaradtak, pedig lett volna miről írni. Szerencsére Balássy György a saját blogjában már megírta az utóbbi napok egyik legnagyobb durranásának, egy most nyilvánosságra hozott, ASP.NET alkalmazásokat érintő kripto-problémának az összefoglalóját:

Ahogy korábban már írtam róla, két hacker elég komoly hibát fedezett fel, amely az ASP.NET-es alkalmazások által használt titkosítást érinti. Sajnos a sebezhetőség részleteit csak pénteken hozták nyilvánosságra, ráadásul egy kész eszközt is közreadtak a kihasználására, sőt előtte a Microsofttal sem közölték a pontos módszert, így most a rossz fiúknak két teljes napjuk van, mielőtt a legtöbb webhely gazdája észbe kap (micsoda “véletlen” időzítés). Fontos, hogy a hiba alapvetően az összes ASP.NET-es webhelyet érinti, legyen az egyedi fejlesztésű, vagy kész rendszer, DotNetNuke vagy SharePoint ugyanúgy borulhat. Az üzemeltetőknek gyorsan kell lépniük!

A támadás egy ún. Padding Oracle Attack (semmi köze az adatbáziskezelőhöz), amely egy általános támadási módszer blokk titkosítások ellen – tehát nem csak ASP.NET, hanem például Apache MyFaces ellen vagy egy mezei CAPTCHA ellen is. A módszer alapja, hogy a blokk titkosítások működéséhez fel kell tölteni a blokkokat (padding), és ezt a paddingot a dekriptáláskor ellenőrizni kell. Ezért ha az alkalmazás egy titkosított értéket kap, akkor valójában háromféle dolog történhet:

  1. Ha a visszafejtett érték helyes és a padding is helyes, tipikusan HTTP 200 OK választ kapunk, az alkalmazás működik, ahogy kell.

  2. Ha a dekriptálás után a padding nem helyes, akkor az alkalmazás tipikusan valamilyen kriptográfiával kapcsolatos kivételt dob, és gyakran HTTP 500 Internal Server Error választ kapunk.

  3. Ha a visszafejtés után a padding helyes, de a dekriptált érték nem, akkor az alkalmazás valamilyen egyedi hibaoldalt dob (szintén HTTP 200 OK).

A beküldött értéket manipulálva a támadást brute force módon lehet automatizálni, a válaszul kapott értékekből és a válaszidőkből pedig meghatározható, hogy a fenti három esetből éppen melyik történt.

A dolog szépsége, hogy egy ASP.NET-es webalkalmazásnak számos helyen lehet ilyen titkosított értéket küldeni, a leggyakoribb célpont a query string, a ViewState és az authentication cookie lehet. Brute force próbálkozásokkal mindössze néhány perc alatt meghatározható a titkosításhoz használt initialization vector értéke. Erre már több kész eszköz létezik, az egyiket úgy hívják, hogy Padding Oracle Exploit Tool (POET).

Ha pedig megvan a “titkosító kulcs”, akkor természetesen szinte végtelenek a támadó lehetőségei, például:

  • Képes a titkosított ViewState visszafejtésére, ahol használható információkat találhat (information disclosure).

  • Képes a query string manipulálására. Itt a fő célpont a ScriptResource.axd, amit rá lehet venni a diszken lévő fájlok (pl. web.config) olvasására és visszaküldésére. Egyelőre úgy néz ki, hogy az alkalmazás mappáján kívül nem tud olvasni a támadó.

  • Képes az authentication cookie manipulálására. Ha a cookie szerepköröket is tartalmaz, akkor akár elő is léptetheti magát. Itt egy videó arról, hogy lesz a támadó atyaúristen DotNetNuke-on pár perc alatt, sőt a gépet is megszerzi SYSTEMként.

A korábbi információkkal ellentétben tehát a hiba nem az AES titkosításban van, így nem segít, ha csak az algoritmust állítjuk át.

A Microsoftnál gőzerővel dolgoznak a probléma megoldásán, és a javasolt workaround kidolgozásán. Mivel a sebezhetőség felfedezői nem voltak kimondottan együttműködőek, így a Microsoft is csak a nyilvánossággal egy időben tudta meg a részleteket. Már van egy Security Advisory (2416728), amelyből kiderül, hogy gyakorlatilag az összes .NET Framework verzió érintett, másrészt, hogy a gyors megoldás a web.config fájlban a customErrors szekcióban a mode=”On” és a defaultRedirect attribútum beállítása, valamint a hibaoldalak válaszidejének randomizálása. Fontos, hogy a customErrors=”remoteOnly” beállítás önmagában nem elég (ez a gond például a DotNetNuke-kal is, ami “csak” 600.000 éles site-ot érint), mert úgy még a támadó elég információhoz jut (átmennek a HTTP hibakódok), kell az On és az, hogy az összes hiba esetén azonos válaszoldalt kapjon a hívó.

Készül egy VBS szkript, amellyel könnyen detektálhatóvá válnak a szerverünkön azok az alkalmazások, ahol a customErrors szekció beállítása nem megfelelő. Ez a szkript még nem tökéletes, már többször frissült a blog post, folyamatosan javítják a hibáit. A futtatásához IIS 7-en az IIS 6 Metabase Compatibility modul telepítése szükséges és Run As Administratorként kell futtatni.

Lesz hivatalos patch is, de mivel csak péntek délután óta dolgozik ezen a csapat, még eltart pár napig, amíg az összes framework és operációs rendszer verzión tesztelik és kikerül a Windows Update-re. Ezért különösen fontos, hogy ezt a workaroundot a lehető leggyorsabban alkalmazzuk az összes alkalmazás esetén.

ScottGu pedig írja már a blog postját...

Kiegésztések (2010.09.20.)

  • Scott Guthrie blog postja megjelent és itt olvasható: http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
  • A Microsoft éjjel-nappal dolgozik a javításon, valószínűleg nagyon hamar meg fog jelenni a Windows Update-en, még a következő frissítő kedd előtt. Addig is érdemes a Scott blogjában és a Security Advisory-ban említett workaroundot SOS alkalmazni.
  • Fontos: bár minden szalagcím arról szól, hogy ez egy ASP.NET-es sebezhetőség, nem csak az ASP.NET-et érinti! Más platformon futó alkalmazások is lehetnek célpontok.
  • Egyre több szerveren látunk paddinggal kapcsolatos security exceptionöket, ami arra utal, hogy a támadások, vagy legalábbis a próbálkozások megindultak (bár ez a kivétel önmagában utalhat másra is).
  • A tanszékünkön fejlesztett Lens tesztelő eszközbe bekerült egy alapvető (nem 100%-os) távoli tesztelési lehetőség:http://ethicalhackingaspnet.codeplex.com/

 

 Az eredeti poszt várhatóan frissülni fog, kövessétek az eseményeket ott is!

Címkék: microsoft .net asp.net 0day kriptográfia

Kommentek:

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

Aron bacsi 2010.09.20. 22:44:03

A PadBuster is hasznos joszag teszteleshez: www.gdssecurity.com/l/b/2010/09/14/automated-padding-oracle-attacks-with-padbuster/

Mondjuk ahogy nezem a "__VIEWSTATE" ertekeket nem tul gyakori, hogy kodolva lennenek. Lehet, hogy az a default beallitas, de akkor a legtobb helyen ki van kapcsolva a DotNetNuke portaloknal...

Aron bacsi 2010.09.20. 22:46:24

Google search:
inurl:"webresource.axd?d"

Nincs is elerheto DotNetNuke portal nagyon...

Meister · https://www.facebook.com/Meister1977 2010.09.22. 16:14:13

Vajh' javítást mikorra készítenek hozzá?
süti beállítások módosítása