isecuritytw/seal-security-nuget-demo-net7.NET 7-Fork von seal-security-nuget-demo: dieselbe CVE-2024-21907-Exploit-Geschichte, neu ausgerichtet für Kunden, die an das .NET SDK 7 gebunden sind.
Dies ist ein neu ausgerichteter Fork des kanonischen seal-security-nuget-demo (der auf net9.0 abzielt). Die Exploit-Geschichte, die Controller und die Liste der versiegelten Pakete sind identisch — nur die TargetFramework unterscheidet sich.
Er existiert, weil die meisten Unternehmenskunden nicht auf das neueste .NET SDK umsteigen können, wenn sie es brauchen. .NET 7 hat am 14. Mai 2024 das Ende des Supports erreicht, aber echte Produktionsumgebungen laufen weiterhin darauf — aus Kompatibilitäts-, Zertifizierungs- oder Betriebsgründen. Genau dafür ist Seal Security konzipiert: Wenn ein Kunde keinen Major-Versionssprung machen kann (oder will), patcht Seal die verwundbare Abhängigkeit an Ort und Stelle unter derselben Version, ohne öffentliche API-Änderungen und ohne Code-Änderungen an der Anwendung des Kunden. Diese Demo ermöglicht dieses Gespräch auf dem tatsächlichen Stack des Kunden, anstatt ihn zu bitten, zuerst net8/net9 zu installieren.
Der Fork pinnt das SDK über global.json auf 7.0.x, damit während der Demo keine versehentlichen Upgrades einschleichen.
Diese Demo-Anwendung ist eine einfache ASP.NET Core Willkommensseite, die Newtonsoft.Json 12.0.2 verwendet, um Benutzereingaben als Konfigurationsobjekt zu parsen. Die App hat ein Namensfeld — geben Sie Ihren Namen ein, klicken Sie auf Los, und sie zeigt „Welcome, alice!" an. Im Hintergrund wird die Eingabe durch JsonConvert.DeserializeObject<NestedConfig>() von Newtonsoft.Json geleitet. Das ist alles — völlig standardmäßige Verwendung einer beliebten JSON-Bibliothek.
Das Problem ist, dass Newtonsoft.Json 12.0.2 (und Versionen vor 13.0.1) CVE-2024-21907 aufweist — eine Denial-of-Service-Schwachstelle mit hohem Schweregrad und einem CVSS-Score von 7.5 (HOCH). Diese Demo zeigt, wie Seal Security die Schwachstelle an Ort und Stelle patcht, ohne ein Major-Versions-Upgrade zu erfordern.
Die Methode JsonConvert.DeserializeObject<T>() von Newtonsoft.Json kann durch konstruierte, tief verschachtelte JSON-Payloads ausgenutzt werden. Beim Deserialisieren in ein typisiertes Objekt (POCO) führt der JsonSerializerInternalReader der Bibliothek wirklich rekursive Aufrufe aus (CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue → CreateValueInternal), die einen Stack-Overflow verursachen, was zum Absturz der Anwendung führt (Denial of Service).
Die App nimmt Benutzereingaben entgegen und parst sie durch Newtonsoft.Json. Wenn die Eingabe eine URL ist, ruft die App zuerst den Inhalt ab — ein realistisches Muster, das von Konfigurationsladern, API-Testern und Webhook-Empfängern verwendet wird:
public class NestedConfig
{
[JsonProperty("n")]
public NestedConfig? N { get; set; }
}
var config = JsonConvert.DeserializeObject<NestedConfig>(name);
Normale Eingabe: Geben Sie alice ein → zeigt „Welcome, alice!" an
Exploit: Fügen Sie diese URL in das Namensfeld ein und klicken Sie auf Los:
https://raw.githubusercontent.com/seal-sec-demo-2/json-payload/main/payload.json
Die App erkennt, dass es sich um eine URL handelt, ruft die json-payload ab (tief verschachteltes JSON {"n":{"n":{...}}}) und deserialisiert sie durch Newtonsoft.Json in die rekursive Klasse NestedConfig — was den Stack-Overflow auslöst.
Der JsonSerializerInternalReader rekursiert für jede Verschachtelungsebene durch CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue. Bei etwa 5.000 Ebenen Tiefe wird der Thread-Stack erschöpft und die Anwendung stürzt mit einer StackOverflowException ab — der Prozess stirbt sofort (keine elegante Fehlerbehandlung möglich).
Mit dieser Schwachstelle können Angreifer:
Der öffentlich verfügbare Fix erfordert ein Upgrade auf Version 13.0.1. Das Upgraden von Major-Versionen bringt jedoch oft mit sich:
Das macht den „einfach upgraden"-Fix zu einem Projekt, das leicht Wochen an Entwicklerzeit in Anspruch nehmen kann — die Schwachstelle bleibt in der Zwischenzeit offen.
Seals gepatchte Version (12.0.2-sp1) fügt Rekursionstiefenschutz hinzu, ohne eine öffentliche API zu ändern. Der Patch:
MaxDepth-Grenzen hinzu, um unbegrenzte Rekursion zu verhindernDies ist dieselbe Minderungsstrategie, die in Newtonsoft.Json 13.0.1 angewendet und als Drop-in-Ersatz auf 12.0.2 zurückportiert wurde.
Diese Demo enthält auch andere verwundbare NuGet-Pakete, die Seal Security patchen kann:
XML External Entity (XXE)-Schwachstelle in der XML-Konfigurationsanalyse von log4net. Ein Angreifer, der die log4net-Konfigurationsdatei kontrollieren kann, kann:
Hinweis zu
System.Net.Http: Das kanonische net9-Demo enthält auch eine verwundbareSystem.Net.Http 4.3.0-Referenz für CVE-2017-0249. Wir haben sie aus diesem net7-Fork weggelassen, weilSystem.Net.Httpunter .NET 7 Teil der BCL ist und die eigenständige Paketreferenz ein rudimentäres Meta-Paket ist — es hat bekannte Randfälle mitdotnet add package --source <local-nupkg>, was genau die Art und Weise ist, wie die Seal-CLI versiegelte Versionen anwendet. Das Weglassen macht denseal fix-Schritt zuverlässig, ohne die Geschichte der Demo zu ändern (HttpClientfunktioniert weiterhin einwandfrei; die Laufzeit stellt es bereit).
Windows-CLI-Binärdateien wurden nach v0.3.238 eingestellt. v0.3.238 ist für die NuGet-Behebung unter Windows voll funktionsfähig.
Eine ausführliche Windows-Server-Installations- und Ausführungsanleitung finden Sie in README-WINDOWS-SERVER.md. Der Schnellstart unten deckt dieselben Schritte in komprimierter Form ab.
PowerShell:
$env:SEAL_TOKEN = "your-seal-token-here"
$env:SEAL_PROJECT = "nuget-demo-net7"
cd seal-security-nuget-demo-net7
# Wiederherstellen (zieht von nuget.org und dem Seal-Feed — siehe nuget.config)
dotnet restore
# Erstellen und ausführen
dotnet build
dotnet run