Wichtiger Hinweis für Hoster, IT-Pros und Developer, die ASP.NET Websites betreiben und verwalten! Vor wenigen Stunden hat der Chef der Microsoft Developer Division, Scott Guthrie (Mr. Red Poloshirt ;-), in seinem Blog auf eine kürzlich entdeckte Sicherheitslücke in ALLEN ASP.NET Versionen hingewiesen.

Hier geht es zum Original-Artikel: Important: ASP.NET Security Vulnerability

Durch Ausnutzen der Sicherheitslücke kann ein Angreifer die (normalerweise geschützten) Dateien einer ASP.NET Website herunterladen – zum Beispiel die Datei web.config, die üblicherweise in jeder Webanwendung vorhanden ist und sensitive Daten, wie Datenbank Connection Strings und ähnliche Web-Einstellungen, enthält.

Die Sicherheitslücke funktioniert auf Basis von speziell präparierten Anfragen an den Webserver, welcher Errorcodes zurückliefert, die zum Entschlüsseln der retournierten Daten verwendet werden können. Also nichts, was im normalen Betrieb oder “zufällig” passieren kann, sondern nur durch gezielte Attacken und entsprechend viele Abfragen ausspioniert werden kann.

Dennoch, diese Sicherheitslücke betrifft ALLE ASP.NET Versionen von 1.0 bis 4.0!

Der Workaround dagegen ist zum Glück sehr einfach:

Die Datei web.config in jedem Web muss den Eintrag customErrors mode=”On” und eine eigene Fehlerseite definiert haben, wie folgt:

<configuration>       
   <system.web>
      <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>       
</configuration>

So werden Webs durch eine eigene Fehlermeldung geschützt.

Normalerweise sollte bei einem Produktivweb soundso eine eigene Error-Seite(n) hinterlegt sein… Hinweis: Der mode RemoteOnly darf auch verwendet werden! (updated 20.09.2010)

Achten Sie bei Webs unter .NET 3.5 SP1 und .NET 4.0 auf den zusätzlichen Key redirectMode=”ResponseRewrite”.

“The important things to note above is that customErrors is set to “on”, and that all errors are handled by the defaultRedirect error page. Note the use of redirectMode=”ResponseRewrite” with .NET 3.5 SP1 and .NET 4.0. There are not any per-status code error pages defined – which means that there are no <error> sub-elements within the <customErrors> section.  This avoids an attacker being able to differentiate why an error occurred on the server, and prevents information disclosure.”

Call to action:

Sehen Sie alle Webs auf Ihrem Webserver durch, oder lassen Sie sich von einem kleinen Script helfen, welches alle Websites auf dem IIS durchläuft und meldet, ob die web.config entspricht oder nicht.

Bei mehreren Webs: Laden Sie am besten das Tool von www.asp.net/media/782788/detectcustomerrorsdisabledv30.zip herunter und entpacken Sie es:

aspnet_script_1

Starten Sie DetectCustomErrorsDisabled3.vbs (erfordert ADSI Unterstützung und IIS6 Management-Tools).

Damit werden alle Webs auf dem Webserver durchlaufen und deren web.config geprüft.

aspnet_script_2

Nun wird jedes Web durchlaufen:

aspnet_web_config_ok

Ist web.config ok oder nicht ok?

aspnet_script_3

Nicht ok: Öffnen Sie die angezeigte web.config und suchen Sie nach der Einstellung “customErrors”. Der relevante Abschnitt kann dann zum Beispiel so aussehen:

aspnet_web_config_wrong

Ausbessern von customErrors in mode=”On” – wichtig ist auch, eine eigene defaultRedirect-Webseite (die natürlich im Web vorhanden sein muss) anzugeben, hier ooops.aspx.

Und es dürfen KEINE Error Subelemente für einzelne Status-Codes definiert sein.
Die korrigierte web.config sieht also so aus:

aspnet_web_config_fixed

Wenn im Web keine web.config vorhanden ist, muss diese Datei nach obigem Muster neu angelegt werden.

Das Script ist zwar nicht super-komfortabel, aber ausreichend. Alternativ kann natürlich auch ein Search & Replace-Tool (wie z.B. Seeker o.ä.) verwendet werden.

Das wars.

Zum Testen, ob der Eintrag richtig gesetzt wurde und das eigene Fehlerhandling funktioniert, rufen Sie das Web mit einer falschen Seite auf und sehen Sie nach, ob die eigene Fehlerseite folgt.

z.B. http://www.meinweb.at/falsch.aspx

Microsoft wird bald einen Patch veröffentlichen, um dieses Problem zu beheben.

Bis es soweit ist: Kontrollieren Sie Ihre ASP.NET Webs und passen Sie gegebenenfalls die web.config-Dateien wie oben beschrieben an!

Mehr Infos zu dieser Sicherheitslücke finden Sie hier:

Ich wünsche weiterhin sicheres Web-Hosting!