Browser + CLI-Demo (NuGet/C#) — .NET-7-Edition

Warum ein .NET-7-Fork?

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 wollen. .NET 7 hat am 14. Mai 2024 das Ende des Supports erreicht, aber echte Produktionsumgebungen laufen aus Kompatibilitäts-, Zertifizierungs- oder Betriebsgründen weiterhin darauf. Genau für diesen Fall 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 Änderung der öffentlichen API und ohne Code-Änderungen an der App 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 fixiert das SDK über global.json auf 7.0.x, damit während der Demo keine versehentlichen Upgrades einschleichen.

Übersicht

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 Go, und sie zeigt "Welcome, alice!" an. Unter der Haube leitet sie die Eingabe durch JsonConvert.DeserializeObject<NestedConfig>() von Newtonsoft.Json. Das war's — 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 dass ein Major-Versions-Upgrade erforderlich ist.

Die Schwachstelle: CVE-2024-21907

Was ist die Schwachstelle?

Die Methode JsonConvert.DeserializeObject<T>() von Newtonsoft.Json kann durch das Erstellen tief verschachtelter JSON-Payloads ausgenutzt werden. Beim Deserialisieren in ein typisiertes Objekt (POCO) führt der JsonSerializerInternalReader der Bibliothek echte rekursive Aufrufe aus (CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue → CreateValueInternal), die einen Stack-Überlauf verursachen und zum Absturz der Anwendung führen (Denial of Service).

Wie der Exploit funktioniert

Die App nimmt Benutzereingaben entgegen und parst sie mit 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: alice eingeben → zeigt "Welcome, alice!" an

Exploit: Fügen Sie diese URL in das Namensfeld ein und klicken Sie auf Go:

https://raw.githubusercontent.com/seal-sec-demo-2/json-payload/main/payload.json

Die App erkennt, dass es sich um eine URL handelt, ruft das json-payload ab (tief verschachteltes JSON {"n":{"n":{...}}}) und deserialisiert es über Newtonsoft.Json in die rekursive Klasse NestedConfig — was den Stack-Überlauf auslöst.

Der JsonSerializerInternalReader durchläuft für jede Verschachtelungsebene rekursiv CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue. Bei etwa 5.000 Ebenen Tiefe ist der Thread-Stack erschöpft und die Anwendung stürzt mit einer StackOverflowException ab — der Prozess stirbt sofort (keine saubere Fehlerbehandlung möglich).

Auswirkungen in der Praxis

Mit dieser Schwachstelle können Angreifer:

• die Anwendung zum Absturz bringen, indem sie bösartige JSON-Payloads senden
• einen Denial of Service verursachen, der alle Benutzer betrifft
• Serverressourcen erschöpfen, indem sie den Exploit wiederholt ausführen
• das Rate-Limiting umgehen, da jede Anfrage den Prozess zum Absturz bringt

Warum nicht einfach auf Newtonsoft.Json 13.0.1 upgraden?

Der öffentlich verfügbare Fix erfordert ein Upgrade auf Version 13.0.1. Allerdings bringt ein Major-Versions-Upgrade oft Folgendes mit sich:

• Breaking-API-Änderungen im Serialisierungsverhalten
• Kompatibilitätsprobleme mit anderen Bibliotheken, die bestimmte Versionen erwarten
• Umfangreiche Testanforderungen für alle Serialisierungs-/Deserialisierungspfade
• Risiko von Laufzeitverhaltensänderungen in der Produktion

Das macht die "einfach upgraden"-Lösung zu einem Projekt, das leicht Wochen an Entwicklerzeit verschlingen kann — währenddessen bleibt die Schwachstelle offen.

Wie Seal Security das behebt

Die gepatchte Version von Seal (12.0.2-sp1) fügt Rekursionstiefenschutz hinzu, ohne die öffentliche API zu ändern. Der Patch:

1. Fügt standardmäßige MaxDepth-Grenzwerte hinzu, um unbegrenzte Rekursion zu verhindern
2. Behandelt tiefe Verschachtelung sauber mit ordnungsgemäßen Ausnahmen statt Stack-Überlauf
3. Ändert keine öffentliche API — vorhandener Code funktioniert ohne Änderungen weiter

Dies ist dieselbe Abschwächungsstrategie wie in Newtonsoft.Json 13.0.1, zurückportiert auf 12.0.2 als Drop-in-Ersatz.

Weitere verwundbare Abhängigkeiten

Diese Demo enthält auch weitere verwundbare NuGet-Pakete, die Seal Security patchen kann:

log4net 2.0.5 - CVE-2018-1285 (CVSS 9.8 KRITISCH)

XML-External-Entity-Schwachstelle (XXE) beim Parsen der XML-Konfiguration von log4net. Ein Angreifer, der die log4net-Konfigurationsdatei kontrollieren kann, kann:

• Beliebige Dateien vom Server lesen
• Server-Side Request Forgery (SSRF) durchführen
• Denial of Service verursachen

Hinweis zu System.Net.Http: Die kanonische net9-Demo enthält ebenfalls einen verwundbaren System.Net.Http 4.3.0-Verweis für CVE-2017-0249. Wir haben ihn aus diesem net7-Fork entfernt, weil System.Net.Http in .NET 7 Teil der BCL ist und der eigenständige Paketverweis ein Relikt-Meta-Paket ist — er hat bekannte Randfälle mit dotnet add package --source <local-nupkg>, und genau so wendet die Seal-CLI versiegelte Versionen an. Das Entfernen macht den Schritt seal fix zuverlässig, ohne die Geschichte der Demo zu ändern (HttpClient funktioniert weiterhin einwandfrei; die Laufzeit stellt es bereit).

Voraussetzungen

• .NET 7.0 SDK (Download von Microsoft)
• Seal-Security-CLI v0.3.238 für Windows x64 (direkter Download)

  Windows-CLI-Binärdateien wurden nach v0.3.238 eingestellt. v0.3.238 ist für die NuGet-Sanierung unter Windows voll funktionsfähig.

• Seal-Security-Token (aus dem Seal-Dashboard)

Eine ausführliche Anleitung zur Installation und Ausführung auf Windows Server finden Sie in README-WINDOWS-SERVER.md. Der Schnellstart unten deckt dieselben Schritte in verkürzter Form ab.

Schnellstart (lokaler Windows Server)

1. Umgebungsvariablen festlegen

PowerShell:

$env:SEAL_TOKEN = "your-seal-token-here"
$env:SEAL_PROJECT = "nuget-demo-net7"

2. Die verwundbare App ausführen (vor Seal)

cd seal-security-nuget-demo-net7

# Restore (pulls from nuget.org and the Seal feed — see nuget.config)
dotnet restore

# Build and run
dotnet build
dotnet run

Öffnen Sie http://localhost:5000 — die App läuft mit verwundbaren Abhängigkeiten.

Mit normaler Eingabe testen

Geben Sie alice in das Namensfeld ein und klicken Sie auf Go. Sie sollten sehen: "Welcome, alice!"

Mit Exploit-Payload testen

Fügen Sie die folgende URL in das Namensfeld ein und klicken Sie auf Go:

https://raw.githubusercontent.com/seal-sec-demo-2/json-payload/main/payload.json

Ergebnis ohne Patch: Der Browser zeigt einen Fehler / Verbindungsabbruch — die App ist mit einer StackOverflowException in JsonSerializerInternalReader.CreateValueInternal abgestürzt. Der Prozess ist tot.

3. Den Seal-Security-Fix anwenden

# (Optional — already done above) Restore dependencies first
dotnet restore

# Run Seal CLI to fix vulnerabilities
seal fix . --mode remote -v

# Restore again to pull sealed versions
dotnet restore

# Build and run the patched app
dotnet build
dotnet run

Die App verwendet nun gepatchte Versionen (Newtonsoft.Json 12.0.2-sp1, log4net 2.0.5-sp1).

Ergebnis mit Patch: Fügen Sie dieselbe Exploit-URL ein → die Seite zeigt "Blocked by Seal patch: MaxDepth of 64 has been exceeded." — das gepatchte Rekursionslimit von Newtonsoft.Json hat die tiefe Payload abgewiesen. Der Server läuft normal weiter.

4. Gepatchte Versionen überprüfen

dotnet list package

Sie sollten Pakete mit dem Suffix -sp1 sehen, das auf Seal-Security-Patches hinweist.

Seal-Security-CLI-Integration

Die goldene Regel

Der CLI-Schritt muss unmittelbar nach der Installation der Abhängigkeiten, aber vor dem endgültigen Build eingefügt werden.

# 1. Restore dependencies
dotnet restore

# 2. <--- Run Seal CLI Here
$env:SEAL_TOKEN = "your-seal-token-here"
$env:SEAL_PROJECT = "nuget-demo-net7"
seal fix . --mode remote -v

# 3. Restore again (to get sealed versions)
dotnet restore

# 4. Build
dotnet build

Fix-Modi

Die .seal-actions.yml in diesem Repository listet bereits die drei versiegelten Overrides für den local-Modus auf, sodass seal fix . --mode local -v offline funktioniert (benötigt trotzdem ein Token für den Artefakt-Server).

Konfiguration des Artefakt-Servers

nuget.config-Einrichtung

nuget.config ist vorkonfiguriert, um Seal Security mit Umgebungsvariablen zu verwenden:

<configuration>
  <packageSources>
    <add key="Seal" value="https://nuget.sealsecurity.io/v3/index.json" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <Seal>
      <add key="Username" value="%SEAL_PROJECT%" />
      <add key="ClearTextPassword" value="%SEAL_TOKEN%" />
    </Seal>
  </packageSourceCredentials>
</configuration>

Erforderliche Umgebungsvariablen

Netzwerk-Allowlist (für eingeschränkte Umgebungen)

Die Seal-CLI benötigt ausgehendes HTTPS (TCP 443) zu:

• cli.sealsecurity.io — Scan-/Fix-Konfiguration
• authorization.sealsecurity.io — Token-Validierung
• nuget.sealsecurity.io — Downloads versiegelter .nupkg-Dateien
• d2zko6i8myndc4.cloudfront.net — CDN, das die tatsächlichen versiegelten Artefakte ausliefert (die .sealsecurity.io-Hostnamen leiten hierher weiter)
• api.nuget.org / Standard-Endpunkte von nuget.org — für nicht versiegelte Abhängigkeiten

Überprüfen Sie nach dem Öffnen der Firewall von PowerShell aus:

Test-NetConnection cli.sealsecurity.io -Port 443
Test-NetConnection authorization.sealsecurity.io -Port 443
Test-NetConnection nuget.sealsecurity.io -Port 443
Test-NetConnection d2zko6i8myndc4.cloudfront.net -Port 443

Alle sollten TcpTestSucceeded: True melden.

.NET-7-spezifische Hinweise

Kernbotschaften der Demo

• Keine Code-Änderungen — der Anwendungscode ist identisch mit der ungepatchen Version. Nur die NuGet-Paketversion wurde ausgetauscht.
• Gleiche API — 12.0.2-sp1 ist ein binärkompatibler Drop-in-Ersatz für 12.0.2.
• Zielt auf den tatsächlichen Stack des Kunden — net7.0, nicht net9.0. Kein SDK-Upgrade erforderlich.
• Defense in Depth — schützt alle Codepfade, einschließlich transitiver Abhängigkeiten.
• Öffentliche Patches — alle Patches sind Open Source und prüfbar.
• Selbst .NET nach EOL wird weiterhin gepatcht — das ist der Kernwert: Microsoft liefert keine Sicherheitsupdates mehr für .NET 7, aber Seal hält die bestehende Abhängigkeitsfläche eines Kunden sicher.

Verfügbare versiegelte NuGet-Pakete

Pakete, die von dieser Demo verwendet werden:

Weitere versiegelte NuGet-Pakete, die über den Seal-Feed verfügbar sind (nicht in dieser Demo, zur Referenz aufgelistet):

Lizenz

MIT-Lizenz - Einzelheiten finden Sie in der LICENSE-Datei.