CVE-2017-9822

DotNetNuke (oft abgekürzt als DNN) ist ein CMS (Content-Management-System) und Web-Anwendungs-Framework auf Basis der ASP.NET-Technologie von Microsoft.

Hauptinformationen

• Betroffenes Produkt: DotNetNuke (DNN Platform) – ein beliebtes CMS/Portal .NET.
• Veröffentlichungsdatum: Juli 2017.
• Schweregrad: Kritisch (CVSS ~9.8).
• Art der Schwachstelle: XML External Entity (XXE) / Unsichere Deserialisierung → Remote Code Execution (RCE).
• Betroffen: Versionen vor 9.1.1 – Möglichkeit der Remote-Code-Ausführung über Cookie

Installationsanleitung

Hier verwende ich Windows 10 zum Einrichten und Debuggen des Programms. Die Version, die ich installiert habe, ist 9.1.0. Eine Anleitung zur Installation findet ihr hier. Das Ergebnis nach erfolgreicher Installation sieht so aus:

Analyse

• Laut den gelesenen Berichten liegt diese Schwachstelle in der Cookie-Verarbeitung von DotNetNuke.
• DNN verwendet eine unsichere Deserialisierungsmethode für das Cookie DNNPersonalization.

Debug

• Hier verwende ich dnSpy, einen Decompiler und Debugger für .NET-Anwendungen (C#, VB.NET, F#...). Es ermöglicht das Anzeigen, Analysieren und Bearbeiten von Quellcode aus kompilierten Dateien wie .dll oder .exe für .NET. Die Installation ist hier möglich. Wir müssen zwei Versionen herunterladen, um das Debuggen durchzuführen.

• Öffnen Sie zuerst DotNetNuke.dll mit der 32-Bit-Version und wählen Sie Edit Assembly Attributes (C#).

• Ersetzen Sie dann die Zeile

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

• durch

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default |
DebuggableAttribute.DebuggingModes.DisableOptimizations |
DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints |
DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]

Speichern Sie anschließend.

• Öffnen Sie die 64-Bit-Version mit Administratorrechten und wählen Sie Attach to Process.

• Wählen Sie als nächstes w3wp.exe.

Der Grund für die Wahl von w3wp.exe ist:

• w3wp.exe = IIS Worker Process.
• Es ist der ausführende Prozess des Application Pools in IIS.
• Wenn eine HTTP-Anfrage an die Website gesendet wird, erstellt IIS einen w3wp.exe (oder verwendet einen vorhandenen) zur Verarbeitung der Anfrage (Ausführung von ASP.NET-Code, Verarbeitung von Modulen, Middleware, Datenbankverbindungen usw.).
• Jeder Application Pool kann je nach Konfiguration einen oder mehrere w3wp.exe-Prozesse haben (Webgarten, Recycling).

Als nächstes wählen Sie Debug -> Window -> Modules.

Nach Abschluss werden die Module angezeigt. Klicken Sie mit der rechten Maustaste auf ein beliebiges Modul und wählen Sie Open All Modules.

Schließlich werden alle Assemblys im Zusammenhang mit DNN angezeigt.

• Gehen Sie in DotNetNuke.dll -> PersonalizationController#LoadProfile(int, int).

Diese Funktion dient zum Laden von Personalisierungsdaten (Profil) des Benutzers im DNN-Portal.

• Wenn der Benutzer angemeldet ist → Profil aus Datenbank + Cache laden.
• Wenn der Benutzer anonym ist (nicht eingeloggt) → Profil aus Cookie DNNPersonalization laden.

Hier sollten wir uns auf DNNPersonalization konzentrieren.

• Wenn userId ungültig ist (anonymer Benutzer).

• Prüfen, ob in der Anfrage ein Cookie DNNPersonalization vorhanden ist.

• Wenn vorhanden → XML-Wert aus diesem Cookie holen.

• Wir senden eine 404-Anfrage an die Website und verwenden ein beliebiges DNNPersonalization-Cookie. Mit dnSpy setzen wir einen Breakpoint bei DotNetNuke.dll –> PersonalizationController#LoadProfile(int, int) und debuggen.

• Im Call Stack konzentrieren wir uns auf die Analyse der Klasse PortalSettings.

• Bemerkenswert ist, dass hier eine if-Bedingung verwendet wird, um zu prüfen, ob die aktuelle Anfrage bereits IsAuthenticated ist.

• Bei der von uns gesendeten 404-Anfrage ist sie unauthenticated.

• Fahren wir im Call Stack fort und konzentrieren uns auf Handle404OrException.

• Hier wird geprüft, ob context.User der aktuellen Anfrage null ist. Wenn ja, wird context.User auf den aktuellen Thread-Benutzer gesetzt.

• In Handle404OrException sehen wir, dass die Variable IsAuthenticated jetzt true ist und der Benutzer der des IIS-Servers ist, sodass die Anfrage als authentifizierter Benutzer ausgeführt wird.

• Der Grund für das Problem liegt in diesem Codeabschnitt:

else if (transfer)
{
	if (context.User == null)
	{
		context.User = Thread.CurrentPrincipal;
	}
	response.TrySkipIisCustomErrors = true;
	IHttpHandler handler = new CDefault();
	context.Handler = handler;
	server.Transfer("~/" + text, true);
}

• Wenn context.User noch nicht gesetzt ist → wird Thread.CurrentPrincipal (die aktuelle Identität des Threads) zugewiesen.
• Dadurch erhält die Anfrage Benutzer-/Rolleninformationen bei der weiteren Verarbeitung.

=> Wenn wir beliebige Inhalte in das Cookie mit der Variable DNNPersonalization übergeben, wird dies wie ein normaler Benutzer behandelt.

Als nächstes betrachten wir die Cookie-Verarbeitung

• Immer noch in DotNetNuke.dll –> PersonalizationController#LoadProfile(int, int).