LDAP Injection: 忘れられた企業セキュリティ脅威

はじめに

サイバーセキュリティの専門家はSQLインジェクション攻撃に対してますます警戒していますが、企業認証システムの影に潜むより巧妙な脅威があります：LDAPインジェクションです。この忘れられた攻撃ベクターは、Active Directory環境の重要な構成要素であるLightweight Directory Access Protocol（LDAP）を標的としています。世界中の数百万の組織がユーザー認証と認可に依存しています。

約20年前から文書化されているにもかかわらず、LDAPインジェクションは2025年でも依然として重大な脆弱性です。最近のセキュリティアドバイザリには、Gladinet CentreStackに影響するCVE-2024-37782や、Windows Active Directory Domain Servicesを狙ったCVE-2025-29810などがあり、この攻撃ベクターが企業のセキュリティに依然として深刻なリスクをもたらしていることを示しています。組織がより公に知られる脅威から守るために急ぐ一方で、LDAPインジェクションは静かに攻撃者に認証を回避させ、機密ユーザーデータを抽出し、Active Directory環境内で権限を昇格させることを可能にしています。

LDAPと企業認証における役割の理解

LDAPとは何か？

LDAP（Lightweight Directory Access Protocol）は、ネットワーク越しにディレクトリ情報サービスにアクセス・管理するための業界標準プロトコルです。もともとはDirectory Access Protocol（DAP）の簡易版として開発され、より小さなコードフットプリントでありながら強力なディレクトリサービス機能を維持しています。

LDAPを用いたディレクトリサービスは、以下の重要な組織データを格納・整理します：

ユーザーの資格情報と認証情報
グループメンバーシップと組織階層
メールアドレスと連絡先情報
プリンターやサーバー、デバイスなどのネットワークリソース
アクセス制御リスト（ACL）とセキュリティポリシー
アプリケーション設定と権限

Active Directory環境におけるLDAP

MicrosoftのActive Directory（AD）は、ディレクトリクエリや変更のための主要なプロトコルとしてLDAPに大きく依存しています。企業環境では、LDAPは次のような役割を果たします：

集中認証：複数のアプリケーションやサービス間でのシングルサインオン（SSO）
ユーザー管理：ユーザーアカウント、パスワード、属性の効率的な管理
リソース管理：ネットワークリソースとアクセス権の集中制御
権限管理：ロールベースアクセス制御（RBAC）とグループポリシーの適用

Active Directoryが企業ネットワークの中で圧倒的に普及しているため—推定で90%以上のFortune 1000企業が利用—LDAPインジェクションは高度な攻撃者にとって特に魅力的なターゲットとなっています。

LDAPインジェクションとは何か？

攻撃の仕組み

LDAPインジェクションは、ウェブアプリケーションが未検証のユーザー入力からLDAP文を構築する際に悪用されるコードインジェクション攻撃です。方法論はSQLインジェクションに似ていますが、ディレクトリサービスを対象としています。アプリケーションがLDAPクエリに特殊文字を適切に検証・エスケープせずに取り込むと、LDAPインジェクションが発生します。

この攻撃は、LDAPのクエリ構文（プレフィックス記法や特殊文字）を利用します。これには以下が含まれます：

グループ化用の括弧 ()
ワイルドカードのアスタリスク *
AND演算子のアンパサンド &
OR演算子のパイプ |
NOT演算子の感嘆符 !
比較のための等号 =

これらの文字が未検証の入力に現れると、攻撃者はLDAPクエリの論理構造を操作し、不正アクセスや情報漏洩を引き起こすことが可能です。

LDAPクエリの動作

典型的なLDAP認証クエリは次のパターンに従います：

(( uid=username)( password=userpassword ))

このクエリは、ユーザー名とパスワードが提供された値と一致するディレクトリエントリを検索します。アプリケーションは、成功した認証のために正確に1つの一致エントリを期待します。

一般的なLDAPインジェクションの攻撃ベクター

認証バイパス

最も一般的で危険なLDAPインジェクション攻撃は、認証メカニズムを完全に回避するものです。脆弱なログインフォームでは、ユーザー入力がLDAPフィルターに直接連結される例があります：

脆弱なコード例：

String filter = "(( uid=" + username + ")( password=" + password + "))";

攻撃者はadmin)(をユーザー名として入力し、任意の文字列をパスワードとして入力できます。結果のクエリは次のようになります：

(( uid=admin)())( password=anything))

LDAPサーバーは最初の完全なフィルター(( uid=admin)())だけを処理し、これはユーザー”admin”が存在するため常にtrueと評価されます。パスワードの検証は完全にスキップされ、不正な資格情報なしに不正アクセスが可能となります。

権限昇格

LDAPインジェクションは、さまざまな仕組みを通じて権限昇格を促進します：

グループメンバーシップの操作：攻撃者はクエリを作成して、自分自身をDomain AdminsやEnterprise Adminsのような特権グループに追加できます。例えば、LDAPを通じてグループオブジェクトの書き込み権限を悪用してmember属性を直接変更します。

パスワードリセット攻撃：設定ミスの環境では、攻撃者はLDAPインジェクションを利用して特権アカウントのパスワードをリセットし、ハイジャックします。

ACLの変更：高度な攻撃者は、LDAPインジェクションを利用してアクセス制御リスト（ACL）を変更し、Active Directory内の重要なオブジェクトに対してGenericWriteやWriteDacl、WriteOwnerの権限を付与します。

情報漏洩とユーザー列挙

LDAPインジェクションは、攻撃者にActive Directory環境の詳細情報を抽出させることも可能です：

ユーザーリストの抽出：ワイルドカードを検索クエリに挿入して、全ユーザーのディレクトリを取得します：

Payload: *)(uid=*))(|(uid=*
結果クエリ: (( uid=*)( uid=*))(|( uid=*)( password=anything ))

この修正されたクエリは、検索条件に関係なくすべてのユーザーオブジェクトを返します。

属性の発見：ブラインドLDAPインジェクション技術を用いて、特定のオブジェクトに存在する属性を列挙できます。例： - メールアドレス - 電話番号 - 部門情報 - マネージャーの関係 - セキュリティクリアランスレベル - サービスアカウントの資格情報

ネットワークの偵察：攻撃者はLDAPクエリを使ってActive Directory全体の構造をマッピングし、次のような情報を特定します： - ドメインコントローラーとその場所 - コンピューターアカウントとサーバー - ドメイン間の信頼関係 - グループポリシーオブジェクト - サービスプリンシパル名（SPN）

BloodHoundやPowerViewなどのツールは、この偵察を自動化し、Active Directory内の権限昇格経路の視覚的マップを作成します。

実際のLDAPインジェクション脆弱性例

企業環境における攻撃シナリオ

シナリオ1：ヘルプデスクアカウントの侵害

一般的な攻撃パターンは、特権を持つヘルプデスクアカウントの侵害です。LDAPインジェクションを用いて、次のことが可能です：

LDAPクエリを使った推移的グループメンバーシップの列挙
ネストされた管理グループの特定
WriteMembersやGenericAllの権限を悪用
侵害されたアカウントをDomain Adminsに追加
Golden Ticket攻撃による永続性の確立

シナリオ2：WebアプリケーションからDomain Adminへ

Active Directoryに認証するインターネット向けアプリケーションをターゲットにした攻撃者は、次のことが可能です：

エラーメッセージ解析によるLDAPインジェクションの脆弱性発見
アプリケーション層での認証バイパス
アプリケーションのLDAPバインドアカウントを使ったActive Directoryのクエリ
BloodHoundを用いた権限昇格経路のマッピング
LDAPリレー攻撃を利用した特権ユーザーのなりすまし
DCSync攻撃を実行し、全ドメイン資格情報を抽出

LDAPインジェクションが依然として蔓延する理由

忘れられたインジェクション攻撃

LDAPインジェクションは、いくつかの理由で依然として重大な脅威です：

認識不足：セキュリティトレーニングや開発慣行はSQLインジェクションの防止に重点を置いていますが、LDAPインジェクションはほとんど注目されていません。多くの開発者は、LDAPクエリもSQLと同じ厳格な入力検証が必要であることを認識していません。

レガシーシステム：10〜15年前に構築された多くの企業アプリケーションは、未だに運用中です。これらのシステムは、現代の安全なコーディング慣行よりも前に作られており、LDAP用のパラメータ化クエリサポートが欠如しています。

誤った安心感：SMB署名を実装してSMBリレー攻撃を防止している組織は、LDAP固有の保護を怠ることがあります。ネットワークレベルの制御だけで十分だと誤解しているのです。

複雑な対策：SQLインジェクションのようにパラメータ化クエリが簡単に保護を提供するわけではなく、LDAPインジェクションの防止には複数の防御層が必要です： - 適切な入力エスケープ（識別名や検索フィルター用） - フレームワーク固有のエンコーディング関数 - バインド認証の設定 - 最小権限のサービスアカウント - 包括的な入力検証

テストの課題

LDAPインジェクションの脆弱性を検出するのは難しいです：

ツールの制約：自動脆弱性スキャナーは、エラーメッセージやデータが返されないブラインド型のLDAPインジェクションを検出できないことがあります。手動テストにはLDAP構文やクエリ構造の深い知識が必要です。

環境の制約：本番のActive Directory環境でLDAPインジェクションをテストすることはリスクが伴います。誤ったクエリはパフォーマンス低下やサービス停止を引き起こし、数千人のユーザーに影響を及ぼす可能性があります。

ブラインドインジェクションの複雑さ：結果が見えないブラインドLDAPインジェクションでは、タイミング攻撃やブール値ベースの技術を用いて、1文字ずつ情報を抽出します。

高度な悪用技術

LDAPリレー攻撃

現代の攻撃者は、LDAPインジェクションとNTLMリレー技術を組み合わせて、巧妙な権限昇格を実現します：

初期アクセス：攻撃者はワークステーションを侵害またはフィッシングを通じて認証を誘導
NTLMリレー設定：NTLMRelayXなどのツールを使い、被害者の認証をドメインコントローラーのLDAPサービスにリレー
インタラクティブLDAPシェル：ImpacketのインタラクティブLDAP機能を利用して、
- コンピューターアカウントの追加
- 無効なユーザーアカウントの有効化
- Tier2アカウントのパスワードリセット
- リソースベースの制約付き委任（RBCD）の設定
- DACLの変更による管理者権限の付与
- LAPSパスワードの読み取り

ブラインドLDAPインジェクション

アプリケーションがクエリ結果を表示しない場合、攻撃者はブラインドインジェクション技術を用います：

ブール値ベースの列挙：真偽値条件を生成するクエリを作成し、差分解析を通じて情報を抽出します：

(( uid=admin)( password=A*)) - 応答時間：100ms（偽）
(( uid=admin)( password=B*)) - 応答時間：100ms（偽）
(( uid=admin)( password=M*)) - 応答時間：500ms（真）

応答時間の長さは、管理者パスワードの最初の文字が”M”であることを示しています。攻撃者はすべての文字を試し、パスワード全体を再構築します。

属性の発見：属性の存在を系統的にテストします：

(( uid=admin)( email=*)) - 結果を返す（属性が存在）
(( uid=admin)( ssn=*)) - 結果なし（属性が存在しない）

この技術は、ディレクトリオブジェクトのスキーマ全体を直接アクセスせずにマッピングします。

DCSyncとDCShadow攻撃

LDAPインジェクションと権限昇格に成功した後、攻撃者は次の操作を行うことが多いです：

DCSync：LDAP操作を通じて得たドメインレプリケーション権限を使い、すべてのドメインユーザーのパスワード情報をドメインコントローラーから取得し、全資格情報データベースをダンプします。

DCShadow：LDAPの改ざんを通じて偽のドメインコントローラーを登録し、Active Directoryのレプリケーショントラフィックに悪意のあるオブジェクトを注入し、検知されずに操作します。

検出と監視

Windowsイベントログの分析

LDAPの偵察やインジェクションの試行を検知するには、ログの詳細な監視が必要です：

イベントID 4662：Active Directoryオブジェクトに対して行われた操作を示します。セキュリティチームは次の点に注意します： - 異常なWrite Property操作 - Control Accessの変更 - DELETE、WRITE_DAC、WRITE_OWNERのアクセスタイプ

イベントID 1644：高負荷または非効率なLDAPクエリを記録します。これには次のような兆候があります： - 過剰なワイルドカード使用 - 異常な検索フィルタパターン - 単一ソースからの高頻度クエリ - 管理者グループを対象としたクエリ

SIEM検出ルール

セキュリティ情報・イベント管理（SIEM）システムには次のルールを実装します：

異常なLDAPトラフィックパターン： - ウェブアプリケーションからのLDAPクエリの急増 - 特殊文字を含むクエリの異常な位置 - 不正なユーザー名による認証失敗 - 複数の管理者アカウントを連続してターゲットとしたクエリ

権限変更： - グループメンバーシップの予期しない変更 - 特権アカウントのパスワードリセット - 重要オブジェクトのACL変更 - 新規コンピューターアカウントの追加

アプリケーション層での検出

早期警告を提供するために、アプリケーションレベルでの検出を実装します：

入力検証のログ記録：LDAPインジェクションに使われる文字（(), *, &, |, !, =, <, >, ~）を拒否した入力を記録します：

(), *, &, |, !, =, <, >, ~

クエリの監視：アプリケーションが生成するLDAPクエリを追跡し、異常なパターンを検出します： - 期待よりも多くの結果を返すクエリ - 複雑なフィルタを持つクエリ - 通常使われない属性にアクセスするクエリ

防止と対策

入力検証とサニタイズ

LDAPインジェクションに対する最も重要な防御策は、厳格な入力検証です：

特殊文字のエスケープ：フレームワークのエンコーディング関数を使ってLDAPの特殊文字をエスケープします：

Java例：

// パラメータ化クエリを使用
String filter = "(( uid={0})( objectClass=person ))";
NamingEnumeration<SearchResult> results = ctx.search(
    "ou=users,dc=example,dc=com",
    filter,
    new Object[]{userInput},
    controls
);

.NET例：

// Encoder.LdapFilterEncodeを使う
string safeInput = Encoder.LdapFilterEncode(userInput);
string filter = $"(( uid={safeInput})( objectClass=person ))";

// Encoder.LdapDistinguishedNameEncodeを使う
string safeDN = Encoder.LdapDistinguishedNameEncode(dnComponent);

Python例：

from ldap3 import Server, Connection
from ldap3.utils.conv import escape_filter_chars

# ユーザー入力をエスケープ
safe_input = escape_filter_chars(user_input)
search_filter = f"(( uid={safe_input})( objectClass=person ))"

文字の許可リスト：期待される入力タイプに基づき、許可される文字の厳格なリストを実装します： - ユーザー名：英数字、ハイフン、アンダースコア - メールアドレス：RFC準拠の文字セット - 電話番号：数字、スペース、括弧、ハイフン

パラメータ化LDAPクエリ

最新のLDAPライブラリは、エスケープ処理を自動的に行うパラメータ化クエリをサポートしています：

脆弱な例：

String filter = "(( uid=" + userInput + ")( objectClass=person ))";

安全な例：

String filter = "(( uid={0})( objectClass=person ))";
NamingEnumeration<SearchResult> results = ctx.search(
    baseDN, filter, new Object[]{userInput}, controls
);

バインド認証の設定

LDAPを匿名やシンプル認証ではなく、バインド認証を使用するよう設定します：

バインド認証のメリット： - 有効なユーザーアカウントと照合 - 各クエリで認証と認可を強制 - 匿名ディレクトリアクセスを防止 - インジェクションの影響を認証済みユーザーの権限に限定

設定手順： 1. すべてのドメインコントローラーで匿名LDAPバインドを無効化 2. 認証なしLDAPバインドを無効化 3. LDAPトラフィックに対してLDAP署名を必須化 4. LDAPS（LDAP over SSL/TLS）を導入し、通信を暗号化

最小権限の原則

LDAPインジェクションの潜在的な被害を最小化します：

サービスアカウントの制限： - 各アプリケーション用に専用のサービスアカウントを作成 - 必要最小限のLDAP権限のみ付与 - 可能な限り読み取り専用アクセス - グループメンバーシップやACLの変更を禁止 - 特権オブジェクトへのアクセス制限

クエリ範囲の制限： - アプリケーションの検索範囲を特定のOUに限定 - LDAP検索ベースの制限を実施 - LDAPコントロールを用いて結果のサイズを制御 - パスワードハッシュなどの敏感属性へのアクセスを禁止

ネットワークレベルの保護

LDAPインジェクションリスクを低減するためのネットワーク制御：

LDAP署名とチャネルバインディング： - すべてのドメインコントローラーでLDAP署名を強制 - LDAPS使用時にLDAPチャネルバインディングを有効化 - 署名なしのLDAP接続を拒否

ネットワークのセグメント化： - ドメインコントローラーを保護されたネットワークセグメントに隔離 - LDAPアクセスを必要なアプリケーションサーバーのみに制限 - ファイアウォールルールでLDAPをインターネット向けシステムからブロック - LDAPトラフィックを監視する侵入検知システム（IDS）の導入

コードレビューとセキュリティテスト

LDAPインジェクションのテストを開発パイプラインに組み込みます：

静的アプリケーションセキュリティテスト（SAST）： - SonarQubeなどのツールを用いてLDAPインジェクション検出ルールを設定 - LDAPクエリの文字列連結を検知するカスタムルールを作成 - 入力検証の欠如を検出する設定

動的アプリケーションセキュリティテスト（DAST）： - LDAPインジェクションペイロードを自動セキュリティテストに組み込む - 認証と検索機能の両方をテスト - 適切なエラーハンドリングがディレクトリ情報漏洩を防ぐことを確認

侵入テスト： - LDAPインジェクションを年次侵入テストの範囲に含める - 未認証・認証済みの両方の視点からテスト - 高度な技術（ブラインドインジェクションなど）を防止できているか検証

セキュアな開発の実践

フレームワークとライブラリの選択

LDAPのインジェクション防止機能を備えたライブラリを選びます：

推奨ライブラリ： - ldap3（Python）：自動エスケープとパラメータ化クエリを提供 - Spring LDAP（Java）：コンテキストソースとテンプレートパターンでインジェクション保護 - System.DirectoryServices.Protocols（.NET）：安全なLDAPクエリ構築をサポート - node-ldapauth-fork（Node.js）：入力サニタイズを標準搭載

開発者教育

開発者向けに次の内容を教育します：

LDAP構文とクエリの基本
一般的なLDAPインジェクションのパターンとペイロード
ディレクトリサービス連携の安全なコーディング慣行
フレームワーク固有のセキュリティ機能
LDAPインジェクション脆弱性のテスト方法

セキュリティ要件

LDAPインジェクション防止をセキュリティ要件に含めます：

認証システム： - すべてのユーザー入力はLDAPクエリ作成前にエスケープ - すべてのLDAP操作にパラメータ化クエリを使用 - LDAP特殊文字を除外する入力検証を徹底 - エラーメッセージはディレクトリ構造やクエリ構文を明示しない

コードレビューのチェックリスト： - [ ] LDAPクエリはパラメータ化/プリペアドステートメントを使用 - [ ] ユーザー入力は検証とサニタイズ済み - [ ] 特殊文字は適切にエスケープ - [ ] サービスアカウントは最小権限のみ付与 - [ ] エラーハンドリングはディレクトリ情報を漏らさない - [ ] ロギングはすべてのLDAPクエリ試行を記録

LDAPセキュリティの未来

新たなトレンド

Zero Trustアーキテクチャ：継続的な検証と最小権限アクセスを重視し、LDAPインジェクションの影響を低減します： - 多要素認証の導入 - マイクロセグメンテーションによる横展開の制限 - コンテキスト認識型アクセス制御の実施

クラウドベースのID管理への移行：オンプレミスのActive DirectoryからAzure ADや他のクラウドIDプラットフォームに移行する組織は、新たな課題に直面しています： - Azure ADのGraph APIは異なるインジェクションベクターを持つ - ハイブリッド環境は攻撃面を拡大 - OAuth 2.0やSAMLなどの最新認証プロトコルは新たな脆弱性をもたらす

AIによる防御：機械学習モデルは、インジェクションを示す異常なLDAPクエリパターンを検知します： - 正常なクエリパターンの振る舞い分析 - 不正なクエリのリアルタイム検知 - 疑わしい活動の自動対応と隔離

業界の取り組み

OWASP LDAP Injection Prevention Cheat Sheet：セキュリティ専門家がLDAPベースの認証を実装する際に参照すべき包括的ガイドラインです。

セキュリティ標準の進化：PCI DSS、ISO 27001、NISTなどの業界標準は、ディレクトリサービスのセキュリティとインジェクション防止をますます重視しています。

結論

LDAPインジェクションは、2025年においても企業認証システムにとって重要かつ過小評価されている脅威です。多くの組織はSQLインジェクションや他のよく知られた攻撃に対して堅牢な防御策を講じていますが、LDAPインジェクションは依然として攻撃者に直接的な突破口を提供し、認証を回避し、機密ディレクトリ情報を抽出し、Active Directory内での権限昇格を可能にしています。

この脆弱性が持続する理由は、開発者の認識不足、レガシーアプリケーションのコード、そして包括的な保護策の実装の複雑さにあります。最近の脆弱性例であるCVE-2024-37782やCVE-2025-29810は、現代のアプリケーションでも適切にユーザー入力をサニタイズしないとLDAPインジェクションに脆弱であることを示しています。

組織は、SQLインジェクションと同じ重みでLDAPインジェクションを扱い、防御の層を重ねる必要があります：

厳格な入力検証とパラメータ化クエリ
最小権限のサービスアカウント
包括的な監視と検知
定期的なセキュリティテストとコードレビュー
開発者への安全なLDAP統合に関する教育

Active DirectoryやLDAPを認証と認可に引き続き依存する企業にとって、この忘れられた攻撃を対処することは、セキュリティのベストプラクティスだけでなく、組織資産の保護と規制遵守のための重要な要件となっています。

問題は、あなたの組織がLDAPインジェクションに脆弱かどうかではなく、攻撃者がそれらの脆弱性を発見し修正する前に気付くかどうかです。エンタープライズセキュリティの猫と鼠のゲームにおいて、LDAPインジェクションを忘れることは、もはや許されない過ちです。

参考資料とさらなる情報

OWASP LDAP Injection Prevention Cheat Sheet
Microsoft Security Response Center - CVE-2025-29810
RFC 4515 - Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters
NIST Special Publication 800-63B - Digital Identity Guidelines
BloodHound: Six Degrees of Domain Admin
Impacket: Collection of Python classes for working with network protocols

著者について

この資料は、LDAPインジェクションの脆弱性についての教育資料であり、セキュリティ専門家や開発者がこれらのリスクを理解し、企業環境での対策を講じるためのものです。