Wie in Achtung! Sicherheitslücke in ASP.NET entdeckt beschrieben, kann die Sicherheitslücke in ASP.NET mit wenig Aufwand durch Anpassen der Datei web.config behoben werden.

Zur Klarstellung noch ein paar Nachträge, zusammengefasst aus den Kommentaren in Scott Gu´s blog: Important: ASP.NET Security Vulnerability:

• Muss der Workaround wirklich angewendet werden? Ja! “Yes - please do apply the workaround”
• Auch bei verschlüsselter web.config? Ja. Verschlüsselung ist eine Empfehlung – aber auch dann soll web.config niemals preisgegeben werden. “Encrypting your connection strings has always been our recommended best practice - and prevents someone from identifying them if the web.config file is compromised.”
• Wird es einen Patch geben? Ja! (s.u.) ”The workaround is only a temporary suggestion - we will patch the vulnerability itself at which point it isn't required.  We published the workaround because of worries that someone might try to exploit this before a patch is available.”
• Zur Ausnutzung der Sicherheitslücke in ASP.NET wird versucht, die Unterschiede zwischen HTML Error Code 404 (und Versionen) und 500 (Allgemeiner Fehler) auszulesen. Es soll demnach auch keine eigene 404 er Seite angegeben werden.
  “No - until we release a patch for the real fix, we recommend the above workaround which homogenizes all errors.”
• Nochmals: Der beste Weg, das zu verhindern, ist immer nur EINE Fehler-Website anzugeben - daher auch keine Error-Subelemente verwenden!
  O-Ton Scott: “One of the ways this attack works is that looks for differentiation between 404s and 500 errors.  Always returning the same HTTP code and sending them to the same place is one way to help block it.”
• Im Original-Artikel wird auch erwähnt, dass es mit dem Bug auch möglich sei, den ViewState zu entschlüsseln (“to enable decrypting of ViewState”).
  Scott´s Antwort dazu beschreibt, dass die Ausnutzung darin begründet liegt, dass es ASP.NET erlaubt, CSS, Javascript etc. mit einem Schlüssel als Teil der Anfrage immer downzuloaden. “…a feature in ASP.NET that allows files (typically javascript and css) to be downloaded, and which is secured with a key that is sent as part of the request. Unfortunately if you are able to forge a key you can use this feature to download the web.config file of an application (but not files outside of the application).“
• Es ist – nicht wie ursprünglich beschrieben - nur der Modus customErrors mode=”On” möglich: “RemoteOnly will also work fine.”. Es funktioniert “On” UND “RemoteOnly”, z.B.:
  <customErrors mode="RemoteOnly" defaultRedirect="~/myerror.html" />
• Ja, SharePoint ist ebenfalls betroffen.
• Auch ASP.NET MVC ist betroffen: “Yes - all versions of ASP.NET are affected, including ASP.NET MVC.”
• Betrifft das nur ASPX-Seiten? Nein, auch alle ASP.NET Ressourcen. “This vulnerability impacts ASP.NET resources (not just ASPX pages).”
• Die mögliche Viewstate-Entschlüsselung ist unabhängig vom möglichen Download von ASP.NET Dateien: “The attack vector that was demonstrated publicly (which downloads the web.config file) uses a built-in feature of ASP.NET and is independent of viewstate.”
• Ist auch ASP.NET unter Mono betroffen? Wahrscheinlich nicht “I'm not sure if Mono has the same bug.”
• Wie beschrieben, sollte in jedem ASP.NET Produktivweb customErrors mode=”On” gesetzt sein… ;-)
• Ein Tipp zum Script DetectCustomErrorsDisabled3.vbs: Wenn viele Webs vorhanden sind, ist es oft sinnvoller, die Webs, wo web.config ok ist, einfach nicht auszugeben: Dazu in Zeile 163 einfach ein einfaches Hochkomma ‘ vor der Ausgabe WScript.Echo Path & ": ok" ausgeben:
   
  Noch schöner wäre, die Ausgaben (statt gleich als Messagebox) in einem String zu sammeln und am Ende des Durchlaufs gesammelt (ev. in einer Datei, Notepad o.ä.) auszugeben. Wer Lust hat, das Script weiter anzupassen… (ich bin mit meinen Webservern schon durch… ;-).
• Wenn der angekündigte Patch verfügbar ist, kann wieder die ursprüngliche web.config mit mehreren Error-Elementen verwendet werden.
  Bis es soweit ist: Bitte web.config wie im Artikel beschrieben anpassen! “Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior).  But for right now I'd recommend not differentiating between 404s and 500s to clients. Thanks, Scott”

Danke an Scott und die ASP.NET Community!
Ich hoffe, mit dieser Zusammenfassung sind die wichtigsten Fragen zum ASP.NET Workaround geklärt.
So, do it! ;-)