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!