この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
今回はCODE BLUE 2021で行われた以下のセッションのレポートです。
ProxyLogonは氷山の一角、Microsoft Exchange Serverの新たなアタック・サーフェス！
Microsoft Exchange Serverは、政府機関や企業に広く導入されている電子メールソリューションであり、日々の業務とセキュリティの両方において不可欠な存在である。言うまでもなく、Exchangeに存在する脆弱性は攻撃者にとって長年の聖杯であり、それゆえにわれわれはExchangeに関するセキュリティリサーチを行っている。驚いたことに、私たちはProxyLogonのような重要な脆弱性だけでなく、Exchangeの全く新しいアタック・サーフェス（攻撃可能領域）を発見した。
この新たなアタック・サーフェスは、Exchange Server 2013の大きな変更に基づいている。それは、基本的なプロトコルハンドラーであるクライアント・アクセス・サービス（CAS）がフロントエンドとバックエンドに分割されたという点だ。このアーキテクチャの根本的な変更により、かなりの量の設計上の不備が発生した。さらに悪いことに、コンテキスト間の不整合が発生したために、今回の新たなアタック・サーフェスが発見されることとなった。
このアタック・サーフェスの美しさとわれわれの独創的な攻撃手法を明らかにするため、講演では、このアーキテクチャを分析することから始め、次いで7つの脆弱性を紹介する。これらは、サーバー側のバグ、クライアント側のバグ、暗号のバグによって構成されており、アタック・サーフェスを通じて発見されたものである。最終的に、これらの脆弱性は3つのアタック・ベクター（攻撃方法・経路）へと繋がる。それぞれが異なる見事な攻撃シナリオの「ProxyLogon」、「ProxyShell」、「ProxyOracle」だ。これらのアタック・ベクターによって、認証されていない攻撃者であってもプレーンテキストのパスワードを発見し、ポート443を介してMicrosoft Exchange Server上で任意のコードを実行することさえ可能になる。そして、このポートをインターネットに公開するExchange Serverが最大で40万台存在している。
このアタック・サーフェスには、以下の理由から比類のないインパクトがある。セキュリティ研究者は、メモリバグ、インジェクション、ロジックの欠陥を掘り下げるなど、特定の視点から脆弱性を発見する傾向がある。しかし、われわれは別のアプローチを採用した。それは、Exchangeを高レベルのアーキテクチャの観点から見て、このアーキテクチャレベルのアタック・サーフェスを捉えたもので、これにより複数の脆弱性を発見することができた。この研究が脆弱性調査に新たなパラダイムをもたらし、より多くのセキュリティ研究者がExchange Serverを調査するようになることを願っている。最後になるが、Exchangeでこのようなタイプのゼロデイを緩和するための強化策についても紹介する予定だ。
Presented by : オレンジ・ツァイ - Orange Tsai
レポート
- 今回はMicrosoft Exchange のAttack Surfaceについて話す
- ProxyLogonについて
- 新しいAttack Surfaceであり、さらなる問題がでてくる可能性がある
- これを理解することでなぜZero Dayが起きたか理解できる
- 自己紹介
- なぜExchangeがターゲットになっているか
- 重要なメールソリューション
- 企業で使われている
- トップターゲットになっていた
- 何をしたか
- アーキテクチャからレビューした
- 新しいAttack Surfaceを見つけた
- 8つの脆弱性
- 4つのAttackにつながっている
- 一番大きいのはProxyLogon
- ProxyOracle
- ProxyShell
- ProxyRelay
- ロジックのバグ
- メモリを壊すより悪用がかんたん
- すべてがProxyのプレフィックスがある
- 新しいAttack Surfaceから来ている
- Exchange Architecture
- 新しいバージョンが3年ごとリリースされている
- リリース毎にアーキテクチャが変わる
- アップデートが難しくなっている
- 新旧の担保をするためにAttack Surfaceが生まれている
- Client Access Service(CAS)
- すべてのプロトコルで受けられるProxy
- Exchangeのプロセッシングの早い段階に入っている
- 殆どの仕組みの手前に入っているためほとんどProxyできる
- 仕組み
- どこから来てもCASがProxyする
- POP3/IMAP/モバイルデバイスなど
- Webについてフォーカスする
- IISに構築されている
- Frontは80/443
- Backendは81/444
- すべてのポートがさらされている
- 危ないのではないか
- CASはいくつかのIISモジュールで成り立っている
- すべての入ってくるリクエストをパスする
- RehydrationModule
- フロントエンドとバックエンドがどうやって情報を交換しているか
- まずフロントエンドでハンドルされる
- Filterやバリデーションなどを使う
- そしてProxyModuleも
- バックエンドがリクエストを受け取るとRehydrationModureで受け取る
- 考え方はシンプル
- 意図的にバックエンドにアクセスできるか
- 殆どのアクセス制御がフロントエンドで行われている
- バックエンドに制約なしでアクセスできれば悪用できるかも
- フロントエンドはうまく実装されている
- フロントエンドとバックエンドが操作できればいい
- ProxyModuleがどうやって動いているか
- ProxyRequestHandler.cs
- どのようにヘッダを処理するか・Proxyするかなど
- Request Section
- Proxy Section
- Response Section
- 3つのセクション
- このハンドラは重要
- 1. Request Section
- CopyHeadersToServerRequest
- ヘッダをでっち上げて混乱させることができるか
- 残念ながらブラックリストがある
- 意図的に使われたヘッダがブロックされる
- CopyCookiesToServerRequest
- 同じものだけどCookie
- AddProtocolSpecificHeadersToServerRequest
- 情報をヘッダにインサートする
- UserIdentityを新しいヘッダで作る
- フロントエンドとバックエンドが同期され、共通のトークンとなる
- CopyHeadersToServerRequest
- 2. Proxy Section
- GetTargetBackEndServerUrl
- 脆弱性がたくさんある
- 後ほど説明
- CreateServerRequest
- あらゆる人にオープンになっている
- これを防ごうとする
- バックエンドではどのコネクションがValidなのか認証する
- AuthorizationとX-CommonAccessTokenヘッダがある
- フロントエンドのValidとIdentityの確認
- GetServerResponse
- GetTargetBackEndServerUrl
- 3. Response Section
- CopyHeadersToClientResponse
- CopyCookiesToClientResponse
- Requestと同じような動き
- どのようにバックエンドが処理するか
- Backend Rehydration Module
- 入ってきたリクエストが検証されているか確認
- フロントエンドで作成したCookieを活用
- 共通のアクセストークンを作る
- HTTPコンテキストを取っておく
- アイデンティティは確認しない
- 通常ユーザーとして認証することができればアクセストークンを確認できる
- もう1つチェックすることがある
- 例外がある
- 正しいクレデンシャルでなかったとしてもExchangeなら可能
- フローまとめ
- X-CommonAccessTokenをヘッダに入れる
- KerberosでAuthorizationヘッダに入れる
- リクエストをバックエンドに送る
- Tokenシリアライズを確認
- X-CommonAccessTokenを使って復旧
- ProxyLogon
- Exchangeの歴史の中で最も深刻な脆弱性
- 2つある
- フロントのSSRF
- 認証後の任意ファイル書き込みによるRCE
- Proxy SectionのGetTargetのところにある
- バックエンドのターゲットをCookieから選ぶ
- 非常に単純
- これがバックエンドで利用される
- Super SSRF
- 新しいリリースのために下位互換性を保つ設計になっている
- ほとんどすべてのリクエストを入手しコントロールできるようになってしまっている
- Kerberosチケットを生成する
- 保護されたシステムを使っていてもExchangeを使ってハッキングできる
- インターナルAPIを活用してコントロールパネルにアクセスできる
- APIというのがProxyLogonとよんでいる理由
- 説明は今回は割愛する
- Demoに関心があれば探してみてくれ
- ProxyOracle
- ProxyLogonと比べると面白いバグ
- プレーンテキストのパスワードの取得ができる
- XSSとパディングオラクル
- OWA/ECPがどうやって認証するか
- プロンプトでパスワード入力が求められる
- ExchangeがクレデンシャルとCookieを変換している
- どのようにしているか
- IISのアーキテクチャ
- FBAはフロントの認証マネージャ
- Cookieをコンバートしている
- 逆もやる
- ユーザーIDとパスワードはCookieにある
- Cookieは暗号化される
- フックを慎重に読むと複数のCookieがユーザー情報を持っている
- 5つの重要なCookieがありプレフィックスがある
- 暗号ロジックではIVとkeyはクライアント側で保持される
- IVとkeyの暗号化にRSAを使う
- パディングオラクルできる
- ログインがFailするとエラーコードを付けてリダイレクト
- 戻されることでオラクルになる
- Encryptionが失敗することで0になる
- ログイン失敗でエラーコードが2になる
- どのようにして被害者からCookieを取得するか
- XSSからチェーニングする
- ExchangeはcookeはHTTPOnly
- ブラウザにCookieを追加したらどうか
- 悪意のあるリンクを送る
- SSRF Cookieを挿入
- プロキシになる
- HTTPOnlyをバイパス
- デモはブログにあるよ
- ProxyShell
- Pwn2Own 2021でデモした
- 認証されていない攻撃者が任意のコマンドを実行できる
- ProxyShellはGetTargetBackEndServerUrlにある
- Explicit Logon featureがある
- 公開許可の設定をする
- 単一のGetにするためにはシンプルにする必要がある
- Exchangeは特別なURLをノーマライズする
- メールボックスアドレスを指定する唯一の指定方法ではない
- アドレスを取得してURLを正常化しようとしている
- メールボックスアドレスを除去することにチェックがあまりない
- URLのどの部分でも消すことができる
- クエリストリングを使ってアドレスが削除され不正なURLがバックエンドに送られる
- SSRFにあるがパワフルではない
- 自分たちの権利を特定する
- 新しいアプローチをするひつようがある
- PowerShell Remoting
- PowerShell APIに基づいている
- WinRMに基づく
- URLも作ることができる
- IISのバックエンド認証の後、Rehydrationの前に使う
- CommonAccessTokenFromUrl
- X-Rps-CATを取り出す
- 特権を取得できる
- EOPで任意のパワーシェルコマンドをAdminとして実行できる
- すべてを紐付ける
- New-MailBoxExportRequestから攻撃
- パスを混乱させアクセストークンを抽出する
- PowerShellを利用する
- 緩和
- アーキテクチャの問題でAttack Surfaceの緩和は難しい
- Exchangeのアップデートをしておく
- インターネットに直面しないようにする
- MSはCASを強化した
- パッチを適用する
- Office 365への移行も検討(冗談だけど)
感想
毎度ながらオレンジ氏の内容は密度が濃くて、そして1割ぐらいしか理解できませんでしたｗ
詳細はオレンジ氏のブログをチェックしてください。
Exchangeの仕組みや新しいAttack Surfaceであることは理解できました。最後のOffice 365の話は冗談ですが冗談ではないかもですね。
32
