tnot123/cve-2017-9822Analyse technique approfondie et preuve de concept pour CVE-2017-9822, une vulnérabilité de désérialisation non sécurisée dans DotNetNuke menant à une exécution de code à distance via des cookies forgés.
DNN (également appelé DotNetNuke) avant la version 9.1.1 permet l'exécution de code à distance via un cookie, également connu sous le nom de "2017-08 (Important) Exécution de code à distance possible sur les sites DNN".
Qu'est-ce que DotNetNuke ? DotNetNuke est un CMS (système de gestion de contenu) web gratuit et open source écrit en C# et basé sur la plateforme .NET. DotNetNuke est très populaire et largement utilisé sur Internet car vous pouvez déployer une version web DNN en quelques minutes sans avoir besoin de connaissances techniques approfondies. Une autre fonctionnalité importante de DotNetNuke est la capacité de créer ou d'importer des modules personnalisés de tiers construits en VB.NET ou C#. Vous pouvez installer DNN sur une pile comprenant Windows Server, IIS, ASP.NET et SQL Server pour Windows. DNN prend également en charge l'enregistrement avec vérification par email pour les nouveaux utilisateurs, mais vous devez configurer un serveur SMTP valide pour que cette fonctionnalité de sécurité fonctionne. Principales fonctionnalités de DNN • Architecture modulaire : DNN permet une extension facile en installant des modules (modules fonctionnels) développés par la communauté. Les administrateurs peuvent télécharger de nouveaux modules via l'interface d'administration (télécharger des packages .zip) ou les extraire directement dans des dossiers sur le serveur. • Gestion des utilisateurs : Le système fournit des fonctionnalités de sécurité et d'autorisation détaillées (rôles/autorisations) pour les portails et les modules. Les comptes utilisateurs, les rôles et les permissions sont gérés de manière centralisée dans DNN. • Gestion de contenu : Prise en charge de l'édition WYSIWYG, gestion des articles, images, documents… Il existe un système de workflow/publication (publication avec processus de validation) et un versionnage du contenu. Le contenu est stocké sur une base de données (SQL Server) commune. • API et intégration étendue : DNN fournit des API .NET pour les développeurs afin de créer des modules personnalisés (WebForms, MVC, Razor) et d'intégrer des services externes. De nombreuses bibliothèques tierces sont disponibles (thèmes, modules e-commerce, forums, etc.) pour étendre les fonctionnalités. • Interface et thèmes : Le système de skins (thèmes) sépare le contenu de l'interface, permettant une conception web flexible. Les sites web créés avec DNN peuvent changer d'apparence en changeant de skins. • Mécanisme d'installation des modules : Les modules DNN sont empaquetés dans des fichiers ZIP, pouvant être installés via l'interface d'administration ou en les décompressant manuellement. DNN prend en charge à la fois les modules compilés (.NET DLL) et les modules Razor dynamiques ; chaque module peut être autorisé ou révoqué via les paramètres de permission sur chaque page.
Operating Systems: Windows 10 .NET Framework: 4.5.1+ Web Server: Microsoft IIS 10 Database Server: Microsoft® SQL Server® 2019 Express, SQL Server Management Studio Dotnetnuke version 9.1.0 Vous pouvez utiliser les Google dorks suivants pour trouver des versions de Dotnetnuke déployées sur Internet et les vérifier par rapport au site web : 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 " Vous pouvez suivre cet article pour construire l'environnement
Modifiez les propriétés de l'assembly pour les rendre « débogables » ; cela est essentiel car, lors de l'exécution, certaines optimisations sont appliquées et peuvent entraver le débogage : certains points d'arrêt peuvent ne pas être atteints ou certaines variables peuvent ne pas exister. Chargez DotNetNuke.dll dans dnSpy (32 bits) puis sélectionnez Edit Assembly Attributes (C#)
Changez la ligne de
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
à
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
Ensuite, sélectionnez Compile et enregistrez ce module à son emplacement d'origine. Ensuite, lancez dnSpy en tant qu'administrateur et sélectionnez Debug -> Attach to Process
Sélectionnez le processus w3wp.exe
La raison pour laquelle nous devons attacher ce processus pour déboguer est que les applications web sur IIS utilisent généralement des workers processes. Ils sont chargés de traiter les requêtes web envoyées au serveur web IIS pour chaque pool d'applications. Plusieurs workers processes peuvent exister sur une même machine et ils portent tous le même nom : w3wp.exe. Une petite remarque : il peut arriver qu'aucun processus w3wp ne soit en cours d'exécution ; IIS ne démarre les workers processes qu'à la réception de la première requête web.
Revenons au débogage : après avoir attaché le processus, sélectionnez : Debug -> Windows -> Modules
Cliquez sur un module et sélectionnez Open All Modules
À ce stade, dans la fenêtre Assembly, nous pouvons voir tous les modules concernés
