Detaillierte technische Analyse und Proof-of-Concept für CVE-2017-9822, eine unsichere Deserialisierungsschwachstelle in DotNetNuke, die zu Remote-Code-Ausführung über manipulierte Cookies führt.
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.
