Doplnění 29.9.2010 – včera večer vydal Microsoft mimořádný ASP.NET hotfix. Více info zde. Všechny níže uvedené postupy, jak se případnému útoku bránit, již nejsou potřeba. Pozor ale na známé problémy tohoto patche.
Doplnění 25.9.2010 – Scott Guthrie na svém blogu publikoval další informace, jak před vydáním hotfixu minimalizovat potenciální riziko. Tentokrát jde o instalaci a konfiguraci nástroje URLScan. Tato úprava probíhá na serverové úrovni (nikoliv po jednotlivých aplikacích) a je časově i technicky nenáročná. Pokud máte IIS 7.5, lze místo URLScan použít Request Filtering feature dle instrukcí uvedených ve Workarounds tohoto článku, případně dle tohoto minimalistického návodu – nainstaluj fíčuru a spusť:
appcmd set config /section:requestfiltering /+denyQueryStringSequences.[sequence='aspxerrorpath=']
Doplnění 21.9.2010 – Microsoft revidoval Security Advisory 2416728 s tím, že již mu jsou hlášeny ojedinělé aktivní útoky prostřednictvím níže popisované zranitelnosti. Před chvílí jsem byl upozorněn, že Michal Valášek napsal modul do IIS 7.x, který zjednodušuje současnou dostupnou obranu proti případnému útoku. Bližší info zde – Modul pro jednoduchý workaround bezpečnostní chyby v ASP.NET.
V noci z pátku na sobotu byl na nějaké bezpečnostní konferenci demonstrován kód, který umožňuje dekryptovat data zaslaná ze serverové ASP.NET stránky na klienta (třeba ViewState data). To je sice hloupé, ale týkalo by se to vždy pouze jednoho konkrétního uživatele. Objevená chyba však umožňuje daleko horší věc – stáhnout ze serveru libovolné soubory, k nimž má identita aplikačního poolu, v němž daný web běží, právo přístupu. A to už je blbé, hodně blbé. Útočník si tak může stáhnout třeba soubor web.config, v němž jsou často uloženy connection strings do databází včetně jmen, hesel, definice používaných webových služeb se jmény a hesly, definice IP restrikcí, definice omezení přístupů do částí webu jen pro konkrétní uživatele nebo jejich skupiny – tohle jsou informace, které rozhodně nejsou určené nikomu nepovolanému.
Útok využívá zahlcení serveru různými požadavky a sledováním, jak na ně server odpovídá. Následně analyzuje odpovědi různých 4xx a 5xx chyb a z nich si odvodí šifrovací klíč. Útočník analyzuje i reakční dobu serveru a od toho odvozuje, o jaký typ chyby se jedná. Stažení souboru je možné zneužitím mechanismu, pomocí kterého se na klienta stahují třeba kompletní client-side javascript nebo css soubory.
Napadnutelné jsou všechny existující verze ASP.NET, na všech serverech, včetně Core, x86, x64, ia64. Napadnutelná je tak teoreticky jakákoliv ASP.NET aplikace, Sharepointu, Exchange či ASP.NET MVC nevyjímaje. Hotfix zatím není, v Microsoftu mají patrně perný víkend a skřípou zuby, že ti inženýři, kteří danou chybu objevili, ji zveřejnili předtím než je dostupná záplata. Jedinou obranou je tak “workaround”, který poskytuje alespoň naději, jak zpomalit postup útočníka. O kompletní obraně bohužel hovořit nelze, neboť I z jednoho chybového stavu lze odvodit ten nešťastný klíč.
“The problem is in the AES encryption algorithm, which allows cracking the cipher by using oracles.”
Microsoft tým připravil VBScript DetectCustomErrorsDisabled3.vbs, jenž se pod administrátorskými právy spustí na serveru. Ten vypíše všechny nalezené ASP.NET aplikace (neboli adresáře, v nichž se nachází web.config) a informaci, zdali jsou zranitelné či nikoliv. K dispozici je též PowerShell skript, pokud již někdo nechce pracovat s VBS.
Následně je třeba zvolit jeden ze dvou postupů omezení působnosti útočníka – první způsob se týká ASP.NET FW 3.5 (včetně) a nižších (tj. 2.0, 1.1, 1.0). Druhý způsob, který je aspoň trochu sofistikovanější, se týká ASP.NET FW 3.5 SP1 (včetně) a vyšších (tj. zatím pouze 4.0).
Základem uvedeného workaround je využití pouze jedné jediné chybové stránky a jednoho jediného http error návratového statusu. Tím se útočníkovi znesnadní identifikace různých typů chyb a odvození šifrovacího klíče.
V případě ASP.NET FW <= 3.5 je doporučeno nasazení statické chybové stránky. Pokud se jedná o ASP.NET FW >= 3.5 SP1, doporučuje se ASPX chybová stránka s využitím nových direktiv ASP.NET 3.5 SP1.
Záměrně zde neuvádím žádné konkrétní kusy kódu, problém je tak ožehavý, že se na jeho odstranění pracuje ve dne v noci a doporučené postupy se mohou každou chvíli změnit. Dá se očekávat, že poté, co bude alespoň v základu připraven a otestován QFE, bude okamžitě uvolněn mimo standardní měsíční termín vydávání patchů.
Pozor na bezhlavé uplatňování doporučeného kódu, můžete si velmi snadno odepsat OWA v Exchange, Sharepoint atd. a to i v případě, kdy detekční skript uvedený výše nenašel v daných adresářích žádný problém – ten způsobí až přidání parametrů v kořenovém web.config souboru!
Doporučené odkazy:
Important: ASP.NET Security Vulnerability/ScottGu’s Blog – blog s podrobnějšími informacemi, které jsem jinde nenašel, průběžně doplňováno
Update on ASP.NET Vulnerability/ScottGu’s Blog – doplněné instrukce o nasazení URLScan nástroje
Frequently Asked Questions about the ASP.NET Security Vulnerability – doplnění k předešlému zdroji
Understanding the ASP.NET Vulnerability – zde je detekční skript
Microsoft Security Advisory (2416728) - zde jsou doporučené úpravy web.config a kód chybové stránky, aktualizováno 24.9.
Kritická bezpečnostní chyba v ASP.NET – článek Michala Altaira Valáška o tomto problému
ASP Security Flaw Detect – detekční skript pro zranitelné web aplikace v Powershellu
Dealing with the “Padding Oracle” ASP.NET Security Vulnerability – jak to funguje 2
”Padding Oracle” ASP.NET Vulnerability Explanation – jak to funguje 1
Security Advisory 2416728 (Vulnerability in ASP.NET) and SharePoint – jak ošetřit Sharepoint
Addtional Information about the ASP.NET Vulnerability – jak rozpoznat útok z logu
Otestování úspěšnosti nasazeného workaround – http://www.vas_server.tld/neexistujici.aspx
Doplnění 20.9.:
Z našeho dnešního testování vyplývá, že není důležité, jaký framework daná aplikace používá, ale jaký framework je na serveru nainstalován. To se nejsnadněji zjistí z Add or Remove Programs, resp. Uninstall a program. Zde je vidět nejvyšší nainstalovaná verze FW (W2008R2), resp. všechny nainstalované .NET FW (W2003).
Doplnění 21.9.:
V případě, že nedisponujete v síti funkčním IDS, mělo by být možné útok zachytit a omezit na IIS7 pomocí volitelného modulu Dynamic IP Restrictions. V tuto chvíli dostupné pouze jako Beta 2.
Doplnění 22.9.:
Zareagoval též český MSDN blog v přípsěvku Michaela Juřka v příspěvku Pozor na bezpečnostní chybu v ASP.NET !!! Je to vcelku krátké, leč důrazné upozornění na závažnost této chyby.
Doplnění 24.9.:
Na blogu týmu Exchange serveru se objevil příspěvek potvrzující zranitelnost v Exchange 2003 a vyšších. Popisuje, jak útok detekovat, ale neobsahuje žádné dodatečné postupy zabezpečení. A na konci uvádí “We do not have an ETA for this fix being available at the time of writing.” Takže nasazení workaround, případně modulu od Michala Valáška, je i nadále aktuální.