• 香港ハイディフェンスサーバー：期間限定スペシャルオファー, 月額 $800取る
使い始める

高防御CDN環境におけるDNSケルベロスリレー攻撃の解析と防止策

私たちは今、その過程にいる。Kerberos認証の基本プロセス（クライアントがTGTやサービスチケットを取得するなど）Kerberos Relayに関連するコンセプトは、「Kerberos Relay」で大まかに紹介されているので、用語の記憶があいまいな場合は、戻ってご覧ください。この記事では、Kerberos Relayテクノロジーについてさらに詳しく紹介する。

1、DNSベースのケルベロス

DNSは、効率的なKerberosインフラを構築する上で不可欠な役割を果たす。しかし、AD環境では、DNSはそれ以上のものである。

また、主にセキュアダイナミックアップデートメカニズムで具現化された機能である、Kerberosによる認証操作も可能である。

簡単に言えば、セキュアダイナミックアップデートの目的は、動的IPアドレスを持つネットワーククライアントが、現在のIPアドレスをDNSレコードと自動的に同期できるようにすることであり、これによってIP変更によるサービスの中断を回避することである。

このプロセスは、ネットワークの柔軟性を向上させるだけでなく、Kerberos認証メカニズムによってセキュリティを強化し、権限のないクライアントによるDNSレコードの改ざんを防止します。以下の図に、動的更新プロセスに関わるステップの詳細を示します。 このメカニズムがどのように機能するかを理解することで、DNS Kerberosリレーを一から理解することができます。

上から下へとステップを踏んでいく。 ウィンドウズ10 サーバーはDNSの役割を持つDCである。

  1. クライアントはStart Of Authority (SOA)レコードを照会し、その名前を取得する。SOAレコードは、どのサーバがクライアントの所在するドメインの権威であるかを示す。
  2. サーバーは認証されたDNSサーバー（この場合はDC）を使用して応答する。 アイコープ・ディーシー.
  3. クライアントはレコードAのダイナミック・アップデートを試みる。 社内カンパニー 真ん中だ。
  4. 認証が提供されていないため、サーバーはこの動的更新を拒否しました。
  5. クライアントの利用 TKEY クエリを使用して、認証済みクエリのキーをネゴシエートする。
  6. サーバー使用状況 TKEY リソースレコードに応答することで、認証が完了する。
  7. クライアントは再度ダイナミックアップデートを送信するが、今度は添付された TSIG これは、ステップ5と6で確立されたキーを使った署名である。
  8. サーバーが動的更新を確認。新しいDNSレコードが配置されました。
ステップ5と6では、TKEYクエリはUDPで許可される最大512バイトよりもはるかに大きいため、実際にはTCPで送信される。これは主に、TKEYのアペンド・レコードが非常に大きく、よく目にするKerberos認証構造が含まれているためである：
このクエリは、完全なGSSAPI(Generic Security Service Application Programming Interface)とSPNEGO(Simple and Protected GSSAPI Negotiation Mechanism)構造を含み、その中にKerberosのAP-REQ(Request for Authentication)が埋め込まれている。
これは実際には標準的なKerberosサービスの認証プロセスである。また、サーバーは応答としてGSSAPIとSPNEGO構造体を返し、これは認証の成功を確認するために使用され、AP-REP(Authentication Reply)で応答する。
このAP-REPには新しいセッション・キークライアントはこの鍵を使ってDNSクエリ、特にTSIG（トランザクショ ン署名）レコードに署名できる。
重要なのはencAPRepPart(AP-REPの暗号化部分)は通常、クライアントとサーバーだけで共有されるセッショ ン鍵を使用して暗号化されるため、通常の状況では直接復号化することはできない。

このプロセスの核となる概念は比較的単純である（実際にはもっと複雑である）。
クライアントはまず、Kerberosによる認証を完了し、セッション鍵を安全に交換する。その後、クライアントはこのセッション鍵を使用して後続の更新クエリに署名し、通信のセキュリティと完全性を確保する。サーバーは、この鍵と、認証されたユーザーまたはコンピュータの情報を保存して、更新要求を安全に処理することができる。

2、DNS認証の悪用

DNSクエリーの傍受に成功すれば、被害者のクライアントを騙して、本当のDNSクエリーを送信させることができる。DNSサーバーWindowsのデフォルト設定では、同じ（仮想）ローカルエリアネットワーク（VLAN）内のどのシステムでも、mitm6ツールを使ってこの傍受を行うことができる。デフォルトのWindowsコンフィギュレーションでは、同じ（仮想）ローカルエリアネットワーク（VLAN）内のどのシステムでも、mitm6ツールを使ってこの傍受を実現できます。mitm6はDNSサーバーになりすますので、被害者はSOA（Starting Authorities）クエリを偽サーバーに送信します。動的更新要求を拒否すると、クライアントはKerberosで認証を試みます。

しかし、現実にはそれほど単純ではない。通常、DNSサーバーの役割はドメインコントローラー(DC)上で実行される。その結果、DNSサービス用のKerberosチケットは、DC上で実行されている他のサービスにもすでに適用されている。これは、LDAPなどの他のサービスにチケットをリレーするために、チケットのサービス名を変更できることを意味します。

しかし、TKEYクエリのバリデータをよく見てみると、リクエストの完全性 (署名)フラグがすでに設定されていることがわかる。これは、たとえチケットを傍受して中継できたとしても、クライアントとサーバは署名によってデータの完全性と真正性を保証するので、署名の検証メカニズムをバイパスできないことを意味する。したがって、この攻撃は理論的には実現可能であるが、特にターゲット・システムが厳密なセキュリティ・メカニズム（例えば署名検証）を有効にしている場合、実用化にはより大きな技術的課題に直面することになる。

これは自動的にLDAP署名をトリガーし、攻撃全体を失敗させる。各メッセージに有効な暗号署名を与えなければ、その後LDAPとやりとりできないからだ。私たちは認証を中継しており、サービスチケットを解読してセッションキーを抽出するのに必要なKerberosキーを実際には持っていないので、この署名を生成できない。

幸いなことに、私たちは巨人の肩の上に立つことができ、ディルクヤン・モレマはすでにこれらの問題を解決する手助けをしてくれている。

  • AD CS 環境では、コード実行の可能性を被害者に提供することができる。(https://dirkjanm.io/ntlm-relaying-to-ad-certificate-services/)
  • 多くのサービスクラスは実際にはHOSTクラスに暗黙的にマップされ、またDNSにもマップされる。 従って、被害者がDNSサービスのチケットを要求すると、実際にはHOST SPNを持つ全てのアカウントに適用される。デフォルトでは、これはドメイン内のすべてのコンピュータアカウントに設定されているので、これらのアカウントで実行されているサービスはすべて標的にされる可能性がある。(https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html)

この2点に対処するため、Dirk-jan Mollemaはkrbrelayxとmitm6ツールを最適化した。

krbrelayx は Kerberos 認証のリレーに使用できるようになりましたが、HTTP と LDAP へのリレーしかサポートしていません。

mitm6では、被害者がSOAレコードのクエリを要求したときに、権威ネームサーバーの応答でホスト名となるリレーターゲットを指定するオプションを追加しました。これにより、被害者は正規のDNSサーバーではなく、標的としているサービスのKerberosサービスチケットを要求することができるようになります。

3, Kerberosリレー攻撃の例

まず、AD CS ホスト(adscert.internal.corp)が宛先として指定され、DNSサーバーをバインドするインターフェイスとしてインターフェイスのIPv4アドレスが指定される。これにより、Ubuntuで通常ループバックアダプターをリッスンするDNSサーバーとの競合を防ぐことができます。

sudo krbrelayx.py --target http:୧/͈ᴗ-͈.内部.corp/certsrv/ -ip 192.168.111.80 --被害者icorp-W10。内部.corp --adcs ---テンプレート マシン

次に、AD CS ホスト名をリレーターゲットとして mitm6 をセットアップします：

sudo mitm6 --domain 内部.corp --host-allowlist icorp-w10.内部.corp --relay adscert.内部.corp -v

被害者がIPv6アドレスを取得し、悪意のあるサーバーに接続するのを待つ：

スクリーンショットからわかるように、被害者はDNSレコードを更新しようとしますが、有効な認証がないため、偽のDNSサーバーはリクエストを拒否します。その後、被害者はKerberos認証情報をTCPコネクションを介して私たちの実行中の krbrelayx DNSサーバー.このサーバはこの認証データを受け取り、さらに処理するために AD CS に転送する。

フローでは、予想される流れを見ることができる：

  • 被害者たち192.168.111.73) ホスト名のSOAレコードを問い合わせる。
  • 我々は、悪意のあるDNSサーバーが、被害者が動的更新クエリーを送信する権威ネームサーバーであることを示す。
  • このクエリはmitm6によって拒否され、被害者にクエリを検証する必要があることが示される。
  • クライアントはKDCと通信し、指示したサービスのKerberosチケットを取得する。
  • クライアントはkrbrelayxとのTCP接続を確立し、Kerberosチケットを含むTKEYクエリを送信する。
  • チケットはAD CSホストに転送され、認証が成功し、証明書が発行される。
この証明書があれば、PKINITtoolsやRubeusを使ってKerberosで認証し、ドメイン管理者になりすまして被害者（この場合は アイコープW10)
python gettgtpkinit.py -pfx-base64 MIIRFQIBA.....lODSghScECP5hGFE3PXoz internal.corp/icorp-w10$ icorp-w10.ccache

管理者アクセスを証明するためにC$ドライブをリストアップする：

4、防御策

このテクニックが成功する主な理由は、WindowsがIPv6やAD CSを好むなど、WindowsやADのいくつかの安全でないデフォルト設定を利用するからである。 これらの問題に対する防御は、いくつかの方法で行うことができる：

1.ミティゲーション mitm6

mitm6は、WindowsがIPv4のみの環境でもIPv6アドレスを検索することを悪用します。社内でIPv6を使用していない場合、mitm6を防ぐ最も安全な方法は、グループポリシーを使ってWindowsファイアウォールでブロックすることです。 ディーエイチシーピーブイ6 トラフィックとルーターのアナウンスメントを受信します。IPv6を完全に無効にすると、望ましくない副作用が発生する可能性があります。以下の定義済みルールを［許可］ではなく［ブロック］に設定すると、攻撃が有効になるのを防ぐことができます：

  • (インバウンド）コアネットワーク - IPv6動的ホスト構成プロトコル（DHCPV6-In）
  • (インバウンド）コアネットワーク - ルーター広告（ICMPv6-In）
  • (アウトバウンド）コアネットワーク - IPv6動的ホスト構成プロトコル（DHCPV6-Out）

2.ADCSへのミティゲーション・リレー

デフォルト CertSrv TLSを使用しないサイトは、さらなる保護を有効にする前にTLSを実施する必要がある。有効な証明書で TLS を有効にした後、IIS で認証の拡張保護を有効にすると、リレー攻撃を防 止できる。これは、AD CS のすべての Web ベースの登録機能で、このサービスを提供するすべての個別の CA サーバで有効にする必要がある。

この記事で紹介したツールはすべて、すでにGitHubでオープンソースツールとして公開されている。

mitm6：https://github.com/dirkjanm/mitm6

krbrelayx：https://github.com/dirkjanm/krbrelayx

PKINITtools：https://github.com/dirkjanm/PKINITtools

この技術についてもっと知りたい方は、ディルク＝ヤン・モレマの英語版オリジナル記事をお読みください：https://dirkjanm.io/relaying-kerberos-over-dns-with-krbrelayx-and-mitm6/

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です