Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに！

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
seal-security-nuget-demo-net7 — .NET 7 版の seal-security-nuget-demo フォーク: 同じ CVE-2024-21907 エクスプロイトのストーリーを、.NET SDK 7 に固定されている顧客向けに再ターゲットしたもの。 | Kitploit
ツール/GitHubGitHub/isecuritytw/seal-security-nuget-demo-net7
脆弱性分析DevSecOpsサプライチェーンセキュリティ学習と教育厳選リソース
GitHubisecuritytw/seal-security-nuget-demo-net7

seal-security-nuget-demo-net7

.NET 7 版の seal-security-nuget-demo フォーク: 同じ CVE-2024-21907 エクスプロイトのストーリーを、.NET SDK 7 に固定されている顧客向けに再ターゲットしたもの。

リポジトリを見る
3ヶ月前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

ブラウザ + CLI デモ (NuGet/C#) — .NET 7 エディション

なぜ .NET 7 フォークなのか?

これは、標準的な seal-security-nuget-demo（net9.0 をターゲットにしている）を再ターゲットしたフォークです。エクスプロイトのストーリー、コントローラー、シールドパッケージのリストは同一です — TargetFramework のみが異なります。

これが存在する理由は、ほとんどのエンタープライズ顧客が要求に応じて最新の .NET SDK に移行できないためです。.NET 7 は 2024 年 5 月 14 日にサポート終了に達しましたが、実際の本番環境では、互換性、認定、または運用上の理由から、依然として .NET 7 で稼働しています。これはまさに Seal Security が設計されたケースです。顧客がメジャーバージョンアップグレードを実行できない（または実行しない）場合、Seal は脆弱な依存関係を同じバージョンのままその場でパッチし、公開 API の変更も顧客アプリのコード編集も行いません。このデモにより、顧客に net8/net9 を先にインストールしてもらう代わりに、顧客の実際のスタック上でこの会話ができるようになります。

このフォークは global.json で SDK を 7.0.x に固定しているため、デモ中に誤ってアップグレードが紛れ込むことはありません。

概要

このデモアプリケーションは、Newtonsoft.Json 12.0.2 を使用してユーザー入力を設定オブジェクトとして解析する、シンプルな ASP.NET Core ウェルカムページです。アプリには名前フィールドがあり、名前を入力して Go をクリックすると、 と表示されます。内部では、入力を Newtonsoft.Json の に渡します。それだけです — 一般的な JSON ライブラリの完全に標準的な使用方法です。

「Welcome, alice!」
JsonConvert.DeserializeObject<NestedConfig>()

問題は、Newtonsoft.Json 12.0.2（および 13.0.1 より前のバージョン）に CVE-2024-21907 — CVSS スコア 7.5（HIGH） の高深刻度サービス拒否（DoS）脆弱性があることです。このデモは、Seal Security がメジャーバージョンアップグレードを必要とせずに脆弱性をその場でパッチする方法を示しています。

脆弱性: CVE-2024-21907

この脆弱性とは?

Newtonsoft.Json の JsonConvert.DeserializeObject<T>() メソッドは、深くネストされた JSON ペイロードを作成することで悪用される可能性があります。型付きオブジェクト（POCO）への逆シリアル化時、ライブラリの JsonSerializerInternalReader は真に再帰的な呼び出し（CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue → CreateValueInternal）を実行し、スタックオーバーフローを引き起こして、アプリケーションのクラッシュ（サービス拒否）につながります。

エクスプロイトの仕組み

アプリはユーザー入力を受け取り、Newtonsoft.Json を通じて解析します。入力が URL の場合、アプリは最初にコンテンツを取得します — これは設定ローダー、API テスター、Webhook レシーバーで使用される現実的なパターンです:

root@kitploit:~
public class NestedConfig
{
    [JsonProperty("n")]
    public NestedConfig? N { get; set; }
}

var config = JsonConvert.DeserializeObject<NestedConfig>(name);

通常の入力: alice と入力 → 「Welcome, alice!」と表示

エクスプロイト: この URL を名前フィールドに貼り付けて、Go をクリック:

root@kitploit:~
https://raw.githubusercontent.com/seal-sec-demo-2/json-payload/main/payload.json

アプリは URL であることを検出し、json-payload（深くネストされた JSON {"n":{"n":{...}}}）を取得し、Newtonsoft.Json を通じて再帰的な NestedConfig クラスに逆シリアル化します — スタックオーバーフローを引き起こします。

JsonSerializerInternalReader は、すべてのネストレベルで CreateValueInternal → CreateObject → PopulateObject → SetPropertyValue を再帰します。約 5,000 レベルの深さで、スレッドスタックを使い果たし、アプリケーションは StackOverflowException でクラッシュします — プロセスは即座に停止します（グレースフルなエラーハンドリングは不可能）。

現実世界への影響

この脆弱性により、攻撃者は以下を行うことができます:

  • アプリケーションをクラッシュさせる 悪意のある JSON ペイロードを送信することで
  • サービス拒否を引き起こす すべてのユーザーに影響を与える
  • サーバーリソースを枯渇させる 繰り返しの悪用を通じて
  • レート制限を回避する 各リクエストがプロセスをクラッシュさせるため

なぜ Newtonsoft.Json 13.0.1 にアップグレードしないのか?

公開されている修正にはバージョン 13.0.1 へのアップグレードが必要です。ただし、メジャーバージョンのアップグレードには、しばしば以下の問題が伴います:

  • 破壊的な API 変更 シリアル化動作における
  • 互換性の問題 特定のバージョンを期待する他のライブラリとの
  • 広範なテスト要件 すべてのシリアル化/逆シリアル化コードパスに対する
  • 実行時動作変更のリスク 本番環境における

このため、「単にアップグレードする」修正は、開発者の時間を数週間簡単に消費するプロジェクトになり得ます — その間、脆弱性は放置されたままになります。

Seal Security が修正する方法

Seal のパッチ版（12.0.2-sp1）は、公開 API を変更せずに再帰深度保護を追加します。パッチは:

  1. 無制限の再帰を防ぐデフォルトの MaxDepth 制限を追加
  2. スタックオーバーフローではなく、適切な例外で深いネストをグレースフルに処理
  3. 公開 API を一切変更しない — 既存のコードは変更なしで動作し続ける

これは Newtonsoft.Json 13.0.1 で適用されたものと同じ緩和戦略であり、ドロップイン置換として 12.0.2 にバックポートされたものです。

その他の脆弱な依存関係

このデモには、Seal Security がパッチできる他の脆弱な NuGet パッケージも含まれています:

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

log4net の XML 設定解析におけるXML 外部エンティティ（XXE）脆弱性。log4net 設定ファイルを制御できる攻撃者は、以下を行うことができます:

  • サーバーから任意のファイルを読み取る
  • サーバーサイドリクエストフォージェリ（SSRF）を実行する
  • サービス拒否を引き起こす

System.Net.Http に関する注記: 標準の net9 デモには、CVE-2017-0249 用の脆弱な System.Net.Http 4.3.0 参照も含まれています。この net7 フォークでは省略しています。これは、.NET 7 では System.Net.Http が BCL の一部であり、スタンドアロンのパッケージ参照は痕跡的なメタパッケージであるためです — dotnet add package --source <local-nupkg> で既知のエッジケースがあり、これはまさに Seal CLI がシールドバージョンを適用する方法です。これを削除することで、デモのストーリーを変更せずに seal fix ステップを確実に実行できます（HttpClient は引き続き正常に動作します。ランタイムが提供します）。

前提条件

  • .NET 7.0 SDK (Microsoft からダウンロード)
  • Seal Security CLI v0.3.238 for Windows x64 (直接ダウンロード)

    Windows CLI バイナリは v0.3.238 以降で廃止されました。v0.3.238 は Windows での NuGet 修復に完全に対応しています。

  • Seal Security トークン（Seal ダッシュボードから）

詳細な Windows Server インストール + 実行ガイドは README-WINDOWS-SERVER.md にあります。以下のクイックスタートは同じ手順を簡潔にまとめたものです。

クイックスタート（ローカル Windows Server）

1. 環境変数の設定

PowerShell:

root@kitploit:~
$env:SEAL_TOKEN = "your-seal-token-here"
$env:SEAL_PROJECT = "nuget-demo-net7"

2. 脆弱なアプリの実行（Seal 適用前）

root@kitploit:~
cd seal-security-nuget-demo-net7

# 復元（nuget.org と Seal フィードから取得 — nuget.config を参照）
dotnet restore

# ビルドと実行
dotnet build
dotnet run

http://localhost:5000 を開きます — アプリは脆弱な依存関係で実行されています。

通常の入力でテスト

名前フィールドに alice と入力し、Go をクリックします。「Welcome, alice!」 と表示されるはずです。

エクスプロイトペイロードでテスト

次の URL を名前フィールドに貼り付けて、Go をクリックします:

root@kitploit:~
https://raw.githubusercontent.com/seal-sec-demo-2/json-payload/main/payload.json

パッチ未適用の結果: ブラウザにエラー / 接続リセットが表示されます — アプリは JsonSerializerInternalReader.CreateValueInternal で StackOverflowException によりクラッシュしました。プロセスは停止しています。

3. Seal Security 修正の適用

root@kitploit:~
# （任意 — 上記で既に実行済み）最初に依存関係を復元
dotnet restore

# Seal CLI を実行して脆弱性を修正
seal fix . --mode remote -v

# シールドバージョンを取得するために再度復元
dotnet restore

# パッチ適用済みアプリのビルドと実行
dotnet build
dotnet run

アプリは現在、パッチ適用済みバージョン（Newtonsoft.Json 12.0.2-sp1、log4net 2.0.5-sp1）を使用しています。

パッチ適用後の結果: 同じエクスプロイト URL を貼り付けます → ページに 「Blocked by Seal patch: MaxDepth of 64 has been exceeded.」 と表示されます — Newtonsoft.Json のパッチ適用済み再帰制限が深いペイロードを拒否しました。サーバーは正常に動作し続けます。

4. パッチ適用済みバージョンの確認

root@kitploit:~
dotnet list package

Seal Security パッチを示す -sp1 サフィックスが付いたパッケージが表示されるはずです。

Seal Security CLI 統合

黄金律

CLI ステップは、依存関係のインストール直後、最終ビルドの前に追加する必要があります。

root@kitploit:~
# 1. 依存関係の復元
dotnet restore

# 2. <--- ここで Seal CLI を実行
$env:SEAL_TOKEN = "your-seal-token-here"
$env:SEAL_PROJECT = "nuget-demo-net7"
seal fix . --mode remote -v

# 3. 再度復元（シールドバージョンを取得するため）
dotnet restore

# 4. ビルド
dotnet build

修正モード

モード説明
all利用可能なすべての修正を自動的に適用
remoteSeal UI で承認された修正のみを適用
local.seal-actions.yml で定義された修正のみを適用

このリポジトリの .seal-actions.yml には、local モード用の 3 つのシールドオーバーライドが既にリストされているため、seal fix . --mode local -v はオフラインで動作します（アーティファクトサーバーにはトークンが依然として必要です）。

アーティファクトサーバーの設定

nuget.config のセットアップ

nuget.config は、環境変数を使用して Seal Security を使用するように事前設定されています:

root@kitploit:~
<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>

必要な環境変数

変数説明
SEAL_TOKENSeal Security アクセストークン
SEAL_PROJECTプロジェクト ID（例: nuget-demo-net7）

ネットワーク許可リスト（制限された環境向け）

Seal CLI は、以下の宛先への送信 HTTPS（TCP 443）が必要です:

  • cli.sealsecurity.io — スキャン / 修正設定
  • authorization.sealsecurity.io — トークン検証
  • nuget.sealsecurity.io — シールド .nupkg のダウンロード
  • d2zko6i8myndc4.cloudfront.net — 実際のシールドアーティファクトを提供する CDN（.sealsecurity.io ホスト名はここにリダイレクトされます）
  • api.nuget.org / 標準の nuget.org エンドポイント — シールドされていない依存関係用

ファイアウォールを開いた後、PowerShell から確認します:

root@kitploit:~
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

すべて TcpTestSucceeded: True と報告されるはずです。

.NET 7 固有の注意点

項目重要な理由
global.json が SDK を 7.0.x に rollForward: latestFeature で固定net8/net9 がサイドバイサイドでインストールされたマシンが、デモ中に SDK を静かに切り替えるのを防ぎます。
System.Configuration.ConfigurationManager が 7.0.0 に固定標準の net9 デモは 8.0.0 を使用していますが、これは net8 のみをターゲットとしており、net7 では復元に失敗します。7.0.0 は log4net が必要とする同じ API サーフェスを持っています。
csproj で NU1701 が抑制log4net 2.0.5 はレガシーな net4x TFM を宣伝しており、.NET 7 は実行時には受け入れますが、復元時に警告します。この警告は外観上のものであり、抑制によりデモ中のビルド出力がクリーンに保たれます。
Windows x64 用 Seal CLI v0.3.238Windows バイナリが付属する最後のリリース。NuGet 修復に完全に対応しています。Windows バイナリはこのバージョン以降で廃止されたため、新しいリリースを提案しないでください。

デモのトーキングポイント

  • コード変更なし — アプリケーションコードはパッチ未適用バージョンと同一です。NuGet パッケージのバージョンのみが交換されました。
  • 同じ API — 12.0.2-sp1 は 12.0.2 のバイナリ互換のドロップインです。
  • 顧客の実際のスタックをターゲット — net9.0 ではなく net7.0。SDK のアップグレードは不要です。
  • 多層防御 — 推移的依存関係を含むすべてのコードパスを保護します。
  • 公開パッチ — すべてのパッチはオープンソースであり、監査可能です。
  • EOL の .NET でもパッチが適用される — これが中核的な価値です。Microsoft は .NET 7 のセキュリティ更新を提供しなくなりましたが、Seal は顧客の既存の依存関係サーフェスを安全に保ちます。

利用可能なシールド NuGet パッケージ

このデモで使用されるパッケージ:

パッケージ脆弱なバージョンシールドバージョンCVECVSS
Newtonsoft.Json12.0.212.0.2-sp1CVE-2024-219077.5 HIGH
log4net2.0.52.0.5-sp1CVE-2018-12859.8 CRITICAL

Seal フィードから利用可能な他のシールド NuGet パッケージ（このデモには含まれていません。参考用にリストされています）:

パッケージ脆弱なバージョンシールドバージョンCVECVSS
log4net2.0.02.0.0-sp1CVE-2018-12859.8 CRITICAL
System.Net.Http4.3.04.3.0-sp1CVE-2017-02497.3 HIGH
Snappier1.1.01.1.0-sp1CVE-2023-286387.0 HIGH
jQuery.Validation1.17.01.17.0-sp1CVE-2021-212527.5 HIGH

ライセンス

MIT ライセンス - 詳細は LICENSE ファイルを参照してください。

ツールをダウンロード