DNN (auch bekannt als DotNetNuke) vor Version 9.1.1 ermöglicht Remote-Code-Ausführung über Cookies, auch bekannt als „2017-08 (Wichtig) Remote-Code-Ausführung auf DNN-Websites möglich“.
Was ist DotNetNuke?
DotNetNuke ist ein kostenloses Open-Source-Web-CMS (Content-Management-System), das in C# geschrieben ist und auf der .NET-Plattform basiert. DotNetNuke ist sehr beliebt und wird im Internet weit verbreitet eingesetzt, da eine DNN-Webinstanz in nur wenigen Minuten bereitgestellt werden kann, ohne dass viel technisches Wissen erforderlich ist. Eine weitere wichtige Funktion von DotNetNuke ist die Möglichkeit, benutzerdefinierte Module von Drittanbietern zu erstellen oder zu importieren, die mit VB.NET oder C# entwickelt wurden.
DNN kann auf einem Stack installiert werden, der Windows Server, IIS, ASP.NET und SQL Server für Windows umfasst. DNN unterstützt außerdem die Verifizierung neuer Benutzerregistrierungen per E-Mail, allerdings muss ein gültiger SMTP-Server konfiguriert sein, damit diese Sicherheitsfunktion funktioniert.
Hauptfunktionen von DNN
• Modulare Architektur: DNN ermöglicht eine einfache Erweiterung durch die Installation zusätzlicher Module (Funktionsmodule), die von der Community entwickelt wurden. Administratoren können neue Module über die Admin-Oberfläche hochladen (.zip-Pakete) oder sie direkt in ein Verzeichnis auf dem Server entpacken.
• Benutzerverwaltung: Das System bietet Sicherheitsfunktionen und detaillierte Berechtigungen (Rollen/Berechtigungen) für Portale und Module. Benutzerkonten, Rollen und Berechtigungen werden zentral in DNN verwaltet.
• Content-Verwaltung: Unterstützt WYSIWYG-Editierung sowie die Verwaltung von Beiträgen, Bildern, Dokumenten usw. Es gibt ein Workflow-/Veröffentlichungssystem (Veröffentlichung von Beiträgen über einen Freigabeprozess) und eine Versionsverwaltung für Inhalte. Die Inhalte werden in einer gemeinsamen Datenbank (SQL Server) gespeichert.
• API und erweiterte Integration: DNN bietet eine .NET-API für Entwickler, um benutzerdefinierte Module (WebForms, MVC, Razor) zu entwickeln und externe Dienste zu integrieren. Zahlreiche Drittanbieter-Bibliotheken (Oberflächenthemes, E-Commerce-Module, Foren usw.) sind verfügbar und erweitern die Funktionalität.
• Oberfläche und Themes: Das Skin-System (Themes) trennt Inhalt und Oberfläche und ermöglicht so flexibles Webdesign. Mit DNN erstellte Websites können ihr Erscheinungsbild durch das Wechseln von Skins verändern.
• Modul-Installationsmechanismus: DNN-Module sind in ZIP-Dateien verpackt und können über die Admin-Oberfläche oder durch manuelles Entpacken installiert werden. DNN unterstützt sowohl kompilierte Module (.NET-DLLs) als auch dynamische Razor-Module; der Zugriff auf jedes Modul kann über die Berechtigungseinstellungen der jeweiligen Seiten gewährt oder entzogen werden.
Betriebssysteme: Windows 10
.NET Framework: 4.5.1+
Webserver: Microsoft IIS 10
Datenbankserver: Microsoft® SQL Server® 2019 Express, SQL Server Management Studio
DotNetNuke-Version 9.1.0
Die folgenden Google-Dorks können verwendet werden, um im Internet verfügbare DotNetNuke-Installationen zu finden und sie anhand der Website zu prüfen:
inurl:dnn.js
inurl:dnn.modalpopup.js
inurl:dnn.servicesframework.js
inurl:dnn.xml.js
inurl:dnncore.js
inurl:/Portals/0/
inurl:/DesktopModules/
inurl:/DNNCorp/
inurl:/DotNetNuke
inurl:/tabid//Default.aspx
inurl:/tabid//language/*/Default.aspx
intext:"by DNN Corp "
Zum Aufbau der Umgebung kann diesem Artikel gefolgt werden:
Ändere die Assembly-Attribute auf „debugbar“. Dies ist unbedingt erforderlich, da zur Laufzeit einige Optimierungen angewendet werden, die das Debuggen behindern können: Manche Breakpoints werden möglicherweise nicht ausgelöst oder manche Variablen existieren nicht.
Lade DotNetNuke.dll in dnSpy (32 Bit) und wähle dann „Edit Assembly Attributes (C#)“.
Ändere die Zeile von
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
auf
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
Wähle anschließend „Compile“ und speichere dieses Modul wieder am ursprünglichen Ort.
Starte als Nächstes dnSpy mit Administratorrechten und wähle Debug -> Attach to Process.
Wähle den Prozess w3wp.exe.
Der Grund, warum dieser Prozess zum Debuggen angehängt werden muss, ist, dass Webanwendungen auf IIS normalerweise Worker-Prozesse verwenden. Deren Aufgabe ist es, die eingehenden Webanfragen an den IIS-Webserver für jeden Application Pool zu verarbeiten. Auf einem Rechner können mehrere Worker-Prozesse vorhanden sein, die alle denselben Namen w3wp.exe tragen. Ein kleiner Hinweis: Es kann vorkommen, dass gerade kein w3wp-Prozess läuft, da IIS die Worker-Prozesse erst startet, wenn die erste Webanfrage eintrifft.
Zurück zum Debuggen: Nach dem Anhängen des Prozesses wähle: Debug -> Windows -> Modules.
Klicke auf ein Modul und wähle „Open All Modules“.
Nun sind im Assembly-Fenster alle zugehörigen Module sichtbar.
Deserialisierung ist der Prozess, bei dem Byteströme interpretiert und in Daten umgewandelt werden, die von der Anwendung ausgeführt werden können.
Das Hauptproblem bei der Deserialisierung besteht darin, dass sie in den meisten Fällen Benutzereingaben verarbeitet. Das bedeutet, dass schädliche Payloads in das von der Anwendung erwartete Format eingeschleust werden können, um die Logik zu manipulieren, Daten offenzulegen oder sogar Code remote auszuführen.
DotNetNuke verwendet das Cookie DNNPersonalization, um Personalisierungsoptionen anonymer Benutzer zu speichern (Optionen für authentifizierte Benutzer werden über deren Profilseite gespeichert). Laut Bericht liegt die Schwachstelle in der Verarbeitung des DNNPersonalization-Cookies. Dieses Cookie wird zum Laden des Benutzerprofils verwendet, kann jedoch auch ohne Authentifizierung ausgelöst werden, wenn eine nicht vorhandene Seite aufgerufen wird (404-Fehler). Der Einstiegspunkt dieses Bugs befindet sich in der Funktion LoadProfile im Modul DotNetNuke.dll. Wir dekompilieren dieses Modul mit dnSpy und analysieren es genauer:
Bei PersonalizationController#LoadProfile(int, int)
Wenn userId ungleich null ist, wird der Variablen text der Wert des DNNPersonalization-Cookies aus der Anfrage zugewiesen, anschließend wird Globals#DeserializeHashTableXml aufgerufen.
Globals#DeserializeHashTableXml ruft XmlUtils#DeSerializeHashtable auf.
Der Verarbeitungsablauf ist wie folgt:
Verwende Burp, um eine Anfrage zu senden, die den Status 404 auslöst, zusammen mit dem Cookie DNNPersonalization.
Hier ist zu sehen, dass die zur 404-Behandlung aufgerufene Funktion Handler404OrException eine Aufrufkette ausgelöst und Personalization.LoadProfile(int,int) aufgerufen hat.
Bemerkenswert an dem obigen Code ist die if-Bedingung, die prüft, ob die aktuelle Anfrage bereits IsAuthenticated ist. Offensichtlich war unsere gerade gesendete Anfrage eine nicht authentifizierte Anfrage an einen nicht existierenden Einstiegspunkt. Warum wird die aktuelle Anfrage also als authentifizierter Benutzer ausgeführt?
Beim weiteren Debuggen, weiter unten im Stack, sieht man in AdvancedUrlRewriter#Handle404OrException eine else-if-Schleife wie folgt:
Hier wird geprüft, ob context.User der aktuellen Anfrage null ist. Ist dies der Fall, wird context.User der aktuelle Thread-Benutzer zugewiesen. Mit einem Breakpoint ist das folgende Ergebnis sichtbar:
Die Variable IsAuthenticated hat nun den Wert true, und der zugewiesene Benutzer ist der Benutzer, der den aktuellen Thread ausführt und zur Gruppe IIS APPPOOL des IIS-Servers gehört. Daher wird die Anfrage als authentifizierter Benutzer ausgeführt. Der Grund für diese Logik ist, dass der 404-Handler aufgerufen wird, bevor HttpContext.User gesetzt wird, und der weitere Verarbeitungsablauf auf User.IsAuthenticated basiert. Um Null-Reference-Fehler zu vermeiden, weisen die Entwickler dem User-Objekt das WindowsPrincipal-Objekt des aktuellen Threads zu.
XmlSerializer ist Microsofts eigene Serialisierungsklasse, die zum Konvertieren zwischen XML-Strings und -Objekten verwendet wird. Ihr Namespace ist: System.Xml.Serialization.
Beispiel für die Verwendung von XmlSerializer:
Voraussetzung für einen RCE-Angriff über XmlSerializer ist, dass der Datentyp kontrolliert werden kann, der an den Konstruktor von XmlSerializer übergeben wird. Das heißt, die Datentypen, die zu einem Gadget führen, müssen an die Eigenschaft XmlSerializer.mapping übergeben werden.
Das bekannteste Gadget für Angriffe auf die XML-Deserialisierung ist ObjectDataProvider. Dieses Gadget kann mit dem Tool ysoserial.net erzeugt werden.
Grundsätzlich kann man mit dieser Klasse jede Methode jeder beliebigen Klasse aufrufen.
Beispielsweise können wir Process.Start mit den folgenden Parametern aufrufen:
ObjectDataProvider o = new ObjectDataProvider(); o.MethodParameters.Add("cmd.exe"); o.MethodParameters.Add("/c calc"); o.MethodName = "Start"; o.ObjectInstance = new Process(); Console.ReadKey();
Erstellen eines XML-Deserialisierungs-Payloads mit dem obigen Code:
ResourceDictionary wird für die WPF-Entwicklung verwendet; da es sich um WPF handelt, muss die Sprache XAML verwendet werden. Schauen wir uns zunächst einen Payload an, der ResourceDictionary zur Ausführung von Befehlen nutzt.
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:d="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:b="clr-namespace:System;assembly=mscorlib" xmlns:c="clr-namespace:System.Diagnostics;assembly=system"> <ObjectDataProvider d:Key="" ObjectType="{d:Type c:Process}" MethodName="Start"> <ObjectDataProvider.MethodParameters> <b:String>cmd</b:String> <b:String>/c calc</b:String> </ObjectDataProvider.MethodParameters> </ObjectDataProvider> </ResourceDictionary>
Erklärung dieses XAML:
Die Ausführung des obigen Codes entspricht ObjectDataProvider -> Person.Evil(). Wenn ein RCE-Angriff über XmlSerializer durchgeführt wird, sieht der Ablauf wie folgt aus: ObjectDataProvider -> XamlReader.Parse() -> ObjectDataProvider -> System.Diagnostics.Process.Start("cmd.exe","/c calc")
Das Ziel ist es nun, ein Objekt zu finden, das beim Deserialisieren Code ausführen kann. Im POC wird die Funktion PullFile von DotNetNuke.Common.Utilities.FileSystemUtils verwendet, um „beliebiges Datei-Upload“ auszunutzen.
Wir erhalten obj.xml:
Payload senden
Nachdem DNN die Cookies deserialisiert hat, trifft auf dem HTTP-Server eine Anfrage an /cmd.aspx ein, d. h. die Deserialisierung war erfolgreich. Die Webshell wurde auf DNN hochgeladen.
Ähnlich kann die Funktion WriteFile von DotNetNuke.Common.Utilities.FileSystemUtils ausgenutzt werden, um Dateien zu lesen.
