Kritikus 0day ASP.NET sebezhetőség és gyors védekezés

Utolsó kiegészítés: 2010.10.01. (Végjáték! Lásd a cikk végén)

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észíté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/

Kiegészítések (2010.09.21.)

Kiegészítések (2010.09.25.)

  • A javítás sajnos egy hét alatt sem készült el, még mindig várjuk 😦
  • Scott újabb cikkében kiegészítést közölt a korábbi workaroundhoz, konkrétan, hogy célszerű UrlScant is alkalmazni a webszerveren.
  • Frissült a Security Advisory (2416728) is, bekerültek az UrlScan (IIS6) és a Request Filtering Module (IIS7) telepítésének lépései. A Request Filteringnél a script sorban /section:requestfiltering helyett helyesen szerintem /section:system.webServer/security/requestfiltering kellene, biztos majd kijavítják.
  • Kristofer Anderson készített egy POET Sniffer Service-t, ami a logokat elemzi folyamatosan, és jelez, ha a Padding Oracle támadásra jellemző jeleket talál.
  • David L. Penton írt egy listát azokról a beállításokról, amiket célszerű alkalmazni még a web.configban a támadás esélyének csökkentésére. Ezeket egyébként ettől a támadástól függetlenül is érdemes alkalmazni.

Kiegészítések (2010.09.30.)

  • Szép map ez a mai, megvan a javítás, pontosabban megvannak a javítások. Sajnos minden operációs rendszerhez és minden .NET verzióhoz külön patch van, az MS10-070 Security Bulletinben megtalálható mind. Sajnos tudásbázis cikkből is több van, nehéz lesz azonnal felismerni a frissítés száma alapján. A linkek megtalálhatóak a Gu friss blog postjában is a gyakori kérdésekkel és válaszokkal együtt.
  • Fontos: A .NET 3.5 RTM és .NET 3.5 SP1-hez két javítófoltot kell telepíteni, az egyik a 2.0, a másik a 3.5 réteget frissíti.
  • A javítás egyelőre csak a Microsoft Download Centerből érhető le és csak manuálisan telepíthető. Még néhány nap, mire kikerül a Windows Update-re és az automatikus frissítő csatornákra. A kritikus rendszereket érdemes mielőbb kézzel patchelni.
  • A javítás elég tutinak tűnik, már felkerült az Azure szerverekre is.
  • A patchet telepíteni kell a TFS, TFS proxy, SharePoint és Reporting Services szerverekre is.
  • A telepítés után nem kell újraindítani a gépet, de a webszerver és az alkalmazások átmenetileg le fognak állni.
  • Fontos, hogy a patch megváltoztat bizonyos titkosítással és aláírással kapcsolatos részeket az ASP.NET-ben, ezért fontos, hogy egy farm összes gépére egyszerre kerüljön fel a javítás. Ha nem, akkor előfordulhat, hogy az egyik gép által adott forms authentication cookie-t a másik gép nem fogadja el.
  • Marginális eset, de fontos lehet, hogy annak idején az ASP.NET 2.0 RTM (vagy SP1) és a 2.0 SP2 között történtek változások a titkosítás terén. Mivel a 2.0 SP1 a 3.5 RTM része, a 2.0 SP2 pedig a 3.5 SP1 része, ezért gond lehet abból, ha a farm egyes elemei nem azonos verziójú Frameworköt futtatnak. A megoldás, hogy minden gépet ugyanarra a verzióra kell frissíteni.

Kiegészítések (2010.10.01.)

  • A javítások megjelentek a Windows Update-en, tehát elvileg hamarosan minden jólnevelt gépre fel fognak menni automatikusan. Szomorú, de nálam egy sima Windows 7 gépen telepítés után újra akarta indítani az operációs rendszert Szomorú arc
  • Mellékhatásként előfordulhat, hogy egy korábban elmentett perzisztens authentication cookie-t (Emlékezz Rám funkció) a rendszer nem fogad el, de ezt az esetet az ASP.NET automatikusan kezeli és hibaüzenet nélkül át fogja irányítani a felhasználót a bejelentkezés oldalra. Következő alkalommal már nem lesz gondja vele.
  • Ha az alkalmazásban egyedi authentication cookie matató kód van, annak lehet, hogy gondja lesz a cookie új formátumával. Ebben az esetben vagy a kódot kell frissíteni, vagy ha az alkalmazás nem bánja, akkor át lehet nevezni a cookie-t a web.config-ban.
Technorati-címkék: ,,,
Reklámok

2 thoughts on “Kritikus 0day ASP.NET sebezhetőség és gyors védekezés

  1. Visszajelzés: Biztonsági fejlesztések az ASP.NET 4.5-ben « Balássy György szakmai blogja

  2. Visszajelzés: Biztonsági fejlesztések az ASP.NET 4.5-ben - Balássy György szakmai blogja - devPortal

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s