Anmelden
Ich möchte für die nächsten 30 Tagen angemeldet bleiben
Deutsch
Several pages in the usergroup are available in English. Click on english to visit these pages.

DotNetNuke News

19.09.2010 | Ankündigungen
Achtung: Gravierendes Sicherheitsproblem in ASP.Net (Sebastian Leupold)
Zwei Hacker haben am vergangenen Freitag auf einer Konferenz in Südamerika  ein Sicherheitsproblem in ASP.Net enthüllt - am Beispiel von DotNetNuke haben sie sich innerhalb weniger Minuten sich damit als Superuser ("Host") einloggen und weitere Software ausführen können. Betroffen sind fast alle ASP.Net Anwendungen.
Microsoft Vice President Scott Gutthrie hat in seinem Blog einen Workaround beschrieben, mit dem die Verletzbarkeit weitgehend verhindert werden kann, unser DotNetNuke Sicherheitsexperte Cathal Conolly hat die nowendigen Schritte für DotNetNuke Sites zusammengestellt, die ich hier kurz übersetzen will:

Betreiber einer DotNetNuke-Installation sollen folgende Aktionen schnellstmöglicht ausführen:
1. In den DotNetNuke Systemeinstellungen prüfen, welche .Net Version verwendet wird.

a. Für Framework 2.0:
   2. in der Web.config die Zeile suchen die mit <customErrors beginnt und durch folgende Zeile ersetzen:
   <customErrors mode="On" defaultRedirect="~/error.html" />
   3. Im Rootverzeichnis eine Datei error.html anlegen (Muster siehe Link)
b. Für Framework 3.5 SP 1 und 4.0:
   2.  in der Web.config die Zeile suchen die mit <customErrors beginnt und durch folgende Zeile ersetzen:
   <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" />
   3.  Im Rootverzeichnis eine Datei error.aspx anlegen, gemäß Muster siehe Link.

Die ASP.Net-Entwickler bei Microsoft arbeiten derzeit mit Hochdruck an einem Fix, um die Lücke dauerhaft zu schließen.

Nachtrag: die Änderungen sind mittlerweile obsolet, bitte die .Net Sicherheits-Updates einspielen!

Kommentare: 4

Andreas Mueller meint

< customErrors mode="RemoteOnly" / >
# 23.09.2010 11:53

Sebastian Leupold meint

Hallo Andreas, RemoteOnly ist auch ok, der Unterschied zu on besteht nur in der Darstellung bei lokaler Betrachtung auf dem Server selbst (localhost). Wichtig ist die einheitliche Umleitung auf eine einzige Fehlerseite. Der Workaround ist in DNN 5.5.1 enthalten, für DNN 4.9.5 ist ein Modul von DNN Corp angekündigt, mit dem der Workaround angewendet wird
# 23.09.2010 11:57

Andreas Mueller meint

RemoteOnly bietet dann doch keinen Schutz "Is the default DotNetNuke web.config secure enough , i’ve read that RemoteOnly is enough to stop this attack? No, it’s not enough to use RemoteOnly (or On) – you need to redirect all the http exceptions to the same file to foil the padding attacks" cathal connolly
# 23.09.2010 12:50

Sebastian Leupold meint

genau das habe ich zuvor auch gesagt :))
# 23.09.2010 13:10