isecuritytw/seal-security-nuget-demo-net7.NET 7 fork de seal-security-nuget-demo : même scénario d'exploitation de la CVE-2024-21907, réorienté pour les clients verrouillés sur le SDK .NET 7.
Ceci est un fork reciblé du dépôt canonique seal-security-nuget-demo (qui cible net9.0). Le scénario d'exploitation, les contrôleurs et la liste des paquets scellés sont identiques — seul le TargetFramework diffère.
Il existe parce que la plupart des clients en entreprise ne peuvent pas migrer vers le dernier SDK .NET à la demande. .NET 7 a atteint la fin de support le 14 mai 2024, mais de nombreux environnements de production tournent encore dessus pour des raisons de compatibilité, de certification ou opérationnelles. C'est précisément le cas d'usage pour lequel Seal Security est conçu : lorsqu'un client ne peut pas (ou ne veut pas) effectuer une montée de version majeure, Seal corrige la dépendance vulnérable sur place dans la même version, sans changement d'API publique ni modification de code dans l'application du client. Cette démo permet d'avoir cette conversation sur la pile technologique réelle du client au lieu de lui demander d'installer d'abord net8/net9.
Le fork épingle le SDK à 7.0.x via global.json afin que des mises à niveau accidentelles ne s'infiltrent pas pendant la démo.
Cette application de démonstration est une simple page d'accueil ASP.NET Core qui utilise Newtonsoft.Json 12.0.2 pour analyser la saisie utilisateur comme objet de configuration. L'application possède un champ de nom — saisissez votre nom, cliquez sur Go, et elle affiche « Welcome, alice! ». En coulisses, elle fait passer la saisie par JsonConvert.DeserializeObject<NestedConfig>() de Newtonsoft.Json. C'est tout — une utilisation tout à fait standard d'une bibliothèque JSON populaire.
Le problème est que Newtonsoft.Json 12.0.2 (et les versions antérieures à 13.0.1) présente CVE-2024-21907 — une vulnérabilité de déni de service de haute sévérité avec un score CVSS de 7,5 (ÉLEVÉ). Cette démo montre comment Seal Security corrige la vulnérabilité sur place sans exiger de mise à niveau de version majeure.
La méthode JsonConvert.DeserializeObject<T>() de Newtonsoft.Json peut être exploitée en créant des charges utiles JSON profondément imbriquées. Lors de la désérialisation dans un objet typé (POCO), le JsonSerializerInternalReader de la bibliothèque effectue des appels véritablement récursifs (CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue → CreateValueInternal) qui provoquent un débordement de pile, entraînant le plantage de l'application (déni de service).
L'application prend la saisie utilisateur et l'analyse via Newtonsoft.Json. Si la saisie est une URL, l'application récupère d'abord le contenu — un modèle réaliste utilisé par les chargeurs de configuration, les testeurs d'API et les récepteurs de webhooks :
public class NestedConfig
{
[JsonProperty("n")]
public NestedConfig? N { get; set; }
}
var config = JsonConvert.DeserializeObject<NestedConfig>(name);
Saisie normale : Saisissez alice → affiche « Welcome, alice! »
Exploit : Collez cette URL dans le champ de nom et cliquez sur Go :
https://raw.githubusercontent.com/seal-sec-demo-2/json-payload/main/payload.json
L'application détecte qu'il s'agit d'une URL, récupère le json-payload (JSON profondément imbriqué {"n":{"n":{...}}}), et le désérialise via Newtonsoft.Json dans la classe récursive NestedConfig — déclenchant le débordement de pile.
Le JsonSerializerInternalReader récure à travers CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue pour chaque niveau d'imbrication. À environ 5 000 niveaux de profondeur, cela épuise la pile du thread et l'application plante avec une StackOverflowException — le processus meurt instantanément (aucune gestion d'erreur gracieuse possible).
Avec cette vulnérabilité, les attaquants peuvent :
Le correctif publiquement disponible exige une mise à niveau vers la version 13.0.1. Cependant, les mises à niveau de version majeure introduisent souvent :
Cela fait du correctif « il suffit de mettre à niveau » un projet qui peut facilement prendre des semaines de temps de développement — laissant la vulnérabilité ouverte entre-temps.
La version corrigée de Seal (12.0.2-sp1) ajoute une protection de profondeur de récursion sans changer aucune API publique. Le correctif :
MaxDepth par défaut pour empêcher une récursion illimitéeC'est la même stratégie d'atténuation appliquée dans Newtonsoft.Json 13.0.1, rétroportée en 12.0.2 comme remplacement direct.
Cette démo inclut également d'autres paquets NuGet vulnérables que Seal Security peut corriger :
Vulnérabilité d'entité externe XML (XXE) dans l'analyse de configuration XML de log4net. Un attaquant qui peut contrôler le fichier de configuration log4net peut :
Note sur
System.Net.Http: La démo net9 canonique inclut également une référence vulnérableSystem.Net.Http 4.3.0pour CVE-2017-0249. Nous l'avons omise de ce fork net7 car sur .NET 7,System.Net.Httpfait partie de la BCL et la référence de paquet autonome est un méta-paquet vestigial — il présente des cas limites connus avecdotnet add package --source <local-nupkg>, ce qui est exactement la façon dont la CLI Seal applique les versions scellées. Le supprimer rend l'étapeseal fixfiable sans changer le scénario de la démo (HttpClientfonctionne toujours parfaitement ; le runtime le fournit).
Les binaires CLI Windows ont été interrompus après v0.3.238. v0.3.238 est entièrement fonctionnel pour la remédiation NuGet sur Windows.
Un guide détaillé d'installation et d'exécution sur Windows Server est disponible dans README-WINDOWS-SERVER.md. Le démarrage rapide ci-dessous couvre les mêmes étapes sous forme condensée.
PowerShell :
$env:SEAL_TOKEN = "votre-jeton-seal-ici"
$env:SEAL_PROJECT = "nuget-demo-net7"