SSTエンジニアブログ

SSTのエンジニアによるWebセキュリティの技術を中心としたエンジニアブログです。

「CODE BLUE 2021」参加レポート(岩間編)

セキュリティ全般 イベント

はじめに

メトロイドヴァニアとBABAisYOUが楽しすぎて仕事する気が起きない岩間です。
10/19-20で開催されていたCODE BLUE 2021にオンラインで参加してきました。
私が聴講したセッションについて、簡単にですがレポートしたいと思います！

「サイバーセキュリティの万華鏡を揺らす - 人間行動とサイバーセキュリティへの没入型調査」

アラナ・モーリシャス氏による基調講演でした。 弊社黒木によるレポートが既に公開されているので、詳細を確認されたい方はそちらをご覧ください。

techblog.securesky-tech.com

いくつかの事例をあげて、人々の情報セキュリティの意識に対する危機や懸念、それに対する取り組みや活動実績について取り上げられていました。

講演の最後に「サイバーピース」というワードをあげて「サイバーピースを目指していきたい」と伝えていました。
サイバーピースについてサイバー空間における平和な状態と私は解釈しましたが、この言葉が非常に印象深かったです。
普段から診断業務を通してセキュリティについて考えていますが、業務の範囲だとどうしても具体性が強いため、サイバーピースのような平和な未来の形を思い描くことはあまり意識していませんでした。 この講演を聞いて、セキュリティに携わる者として自分なりのサイバーピースとは何かを考える良い機会になりました。

ProxyLogonは氷山の一角、Microsoft Exchange Serverの新たなアタック・サーフェス！

Orange Tsai氏によるMicrosoft Exchange Serverの複数の脆弱性(ProxyLogon, ProxyOracle, ProxyShell)の原因や仕組みについて解説された講演でした。

これらの脆弱性は脆弱性の危険度の高さや影響度の大きさ、実際に攻撃の観測や被害報告があったことから公表当時に国内でも注意喚起や対応の呼び掛けがありました。 当時の状況はpiyokango氏のブログが大変参考になります。

piyolog.hatenadiary.jp

それぞれの脆弱性について簡単に説明します。
詳細について知りたい方は、DEVCORE社(講演者の所属会社)のレポートが参考になります。各項目の最後にリンクを掲載しておきます。

ProxyLogon

ProxyLogonは、二つの脆弱性を連鎖的に組み合わせて未認証から任意コードの実行(RCE)まで実現させる脆弱性です。

一つ目のCVE-2021-26855は、SSRFを悪用した認証バイパスまで行う脆弱性です。 ユーザから渡されたCookie値を利用してバックエンドの宛先を変える挙動となっていたため、Server Side Request Forgery(SSRF)が可能な状態でした。

もともとはURLのHost部分しか操作できなかったようですが、バックエンドのURLを生成するのにC#のUriBuilderを利用していたため、任意のサーバ、ポート(およびパス?)へリクエストさせることが可能だったようです。
ほぼ全てのHTTPリクエストとレスポンスを制御できることから、Super SSRFと呼称していました。 URL正規化処理の複雑さを狙った攻撃手法は、Orange Tsai氏の得意分野であり非常に勉強になりました。
このSSRFを利用して、フロントエンドサーバ側で発行されるケロベロスチケットを生成し、認証バイパスを行うようです。

二つ目のCVE-2021-27065は、前述のCVE-2021-26855を利用して任意コードを実行させる脆弱性です。
バックエンドの内部API/ecp/proxylogon.ecpにアクセスして管理者に昇格し、ファイル書き込みのバグを利用して任意コード実行まで行うようです。 講演内ではスライド一枚で説明されておりましたが、DEVCORE社のレポートには詳細に記載されています。

devco.re

ProxyOracle

ProxyOracleも二つの脆弱性で構成されており、ユーザのパスワードをプレーンテキスト形式で復元できる脆弱性です。

一つ目のCVE-2021-31195は、反射型クロスサイトスクリプティング(XSS)の脆弱性です。
Outlook Web Access(OWA)は、フォームベース認証(FBA)と呼ばれる認証の仕組みが備わっているようです。 このFBAは暗号化された状態でクレデンシャル情報をCookieに保存するようですが、暗号化にAWSのCBCモードを採用しているため、パディングオラクル攻撃が有効のようでした。

パディングオラクル攻撃で暗号化されたCookieを復号化可能なことが確認できたので、次にどのようにしてユーザのCookieを盗むかを考えます。

Cookie情報を盗聴する手法としてはXSSがオーソドックスですが、重要情報が格納されたCookieは全てHttpOnly属性が設定されているようでした。
HttpOnly属性が設定されたCookieはJavascriptからアクセスすることが出来ないため、XSSを緩和させます。
攻撃者がユーザのCookieを取得するのは一見出来ないように思えますが、先のProxyLogonのSSRFを利用することで、Cookie情報を攻撃者のサーバまで送ることが可能のようです。
この辺りの一連の説明は講演内ではあまり触れていなかったため、改めて調べて理解したいと思います・・・。

誤解の無いように補足すると、HttpOnly属性のCookieがJavascriptからアクセスできたという話ではありません。XSSだけでなく先のSSRFも利用した攻撃であるため、これまで通りHttpOnly属性がXSSの緩和策になることは変わりません。

devco.re

ProxyShell

ProxyShellは、三つの脆弱性を組み合わせて、未認証の状態から任意コマンドの実行が可能な脆弱性です。
URLパスの正規化処理に問題があり、任意のバックエンドURLにアクセスさせることができるようです。

一つ目のCVE-2021-34473は、URLパス正規化の不備を突いてSSRFを行い、ACLをバイパスして任意のバックエンドにアクセスさせる脆弱性でした。

二つ目のCVE-2021-34523は、特権昇格の脆弱性でした。
Exchange PowerShell Remotingと呼ばれる機能を調べた結果、URLからアクセストークンを抽出する処理が見つかり、X-CommonAccessTokenヘッダがない場合はX-Rps-CATパラメータからトークンのデシリアライズを行うことが分かったようです。
この挙動を利用してSYSTEMからExchange管理者にダウングレードするようです。

三つ目のCVE-2021-31207では任意ファイルの書き込み（および実行も？）についてでした。
Exchange PowerShellのNew-MailboxExportRequestコマンドを利用して任意のファイルパスにファイルを作成できるようで、ペイロードを送ってシェル取得まで至るようですが、疲れてしまい殆ど聞けず(-_-;)

devco.re

www.zerodayinitiative.com

対策

  • Excahnge Serverを最新にし、インターネットに直接公開しないようにすること(特にweb部分)
  • Microsoftから2021年4月にCASフロントエンドを強化したため、パッチを適用すること
  • office 365 Exchangeに変えること（冗談）

MUSHIKAGO: ゲームAIを利用したIT/OT自動化ペネトレーションテストツール

Powder Keg Technologies合同会社によるMUSHIKAGOと呼ばれるペネトレーションテストツールの紹介でした。
ペネトレーションテストを自動化するツールのようで、ラズベリーパイやラップトップPCでも動く軽量なソフトウェアのようです。
ハードウェアもあるようです。キラキラして間接照明みたいで素敵でした。枕元に置いておきたい。

MUSHIKAGOは大きく4つのコンポーネント(Game AI, GUI, Arsenal, Database)に分かれているようです。 Game AIはDBから現在の状況を取得し、最適なテストプランを作成します。 テストプランが決まるとペネトレーションテストに必要なツールをArsernalから実行し、実行した結果をDBに格納します。 GUIからはDBから情報を取得して、テスト結果を確認することができます。

このGame AIで使用されているアルゴリズムがGOAP(Goal-Oriented Action Planning)と呼ばれるもので本ツールの特徴でもあるようです。
GOAPはゲーム中のNPC(non player character)の動きを決定する際に用いられるアルゴリズムのうちの一つです。 実際のゲームの例だと、FPSゲーム「F.E.A.R」や「CHOMEHOUNDS」で使われています。

GOAPに関する仕組みについても説明がありましたが、まとめると以下のような理由からペネトレーションテストとの相性が良いため、GOAPを採用したようです。

  • 様々なシチュエーションや環境でも自動化に使用できる
  • モジュール拡張が容易(シンボルとアクションを変更するだけで、モジュールを拡張できる)

また、GOAPは他のAIのような事前学習や学習データを必要とせず、複数のツールと適用することができるようです。

テスト計画や実施からレポートまでの全体の管理にゲームAI(GOAP)アルゴリズムを利用するのはユニークなアイデアだと思いました。
まだまだ発展途上のツールのようですので、今後に期待したいです。

ラストマイル問題： ウェブマーケターが追加するサードパーティスクリプトという盲点

冒頭部分を聞きそびれてしまったのですが、株式会社UBSecureのアレクサンドル・メルシエ氏によるWebマーケティング用に追加されるサードパーティのスクリプトに関する発表でした。

Webマーケティングの位置づけ

Webマーケティングの位置づけは、本番環境に以降後の関わってくるものであり、セキュリティの文脈で語られるDebOpsとは少し異なる場所にいます。 マーケティング目的で追加されたスクリプトによってアプリが変わることもあり、これを講演内ではラストマイル問題と呼称しておりました。

タグマネージャシステム

Webマーケティングで利用されるものとしてタグマネージャと呼ばれるシステムがあります。
タグマネージャーとは、Webサイト等に含まれる「タグ」を素早く簡単に更新できる管理システムのことで、タグマネージャーのコードをプロジェクトに追加することで、ユーザ分析や測定などが可能になります。
代表的なサービスだと、Google Tag managerやYahoo!タグマネージャー、Adobeのタグマネージャーあるようです。

どのような機能が使えるかについて、以下のような例を挙げておりました。

  • トラフィックの分析・レポート
  • 広告トラフィック
  • ソーシャルメディアのオーディエンス分析
  • A/Bテスト、ユーザビリティテスト、行動トラッキング
  • ヒートマップ
  • イベント駆動型ポップアップやその他のメール収集

などなど。

中には強力なタグもあるようで、セッションリプレイと呼ばれるタグではユーザが見ている画面でどのような操作をしたのかを動画で再生できるようです。

マーケティングにおいて強力なツールであると同時に危険なスクリプトにも成り得るため、起こりうる危険性について以下のような例を挙げていました。

  • 設定ミス
    • 設定ミスにより、ユーザのクレカ情報を収集してしまう等
  • 未確認の脆弱性の導入
    • タグを追加することで増える機能（例えばメルマガ登録フォーム）に脆弱性が潜む場合、開発やテスト工程では見つけられない。
  • 悪意あるスクリプトの追加
    • タグはサンドボックス化されておらず、Googleはマルウェア配布の確認を行うのみ。保護機能は提供されていないので、キーストロークを記録するといったスクリプトを追加したとき、それはUXの改善なのかキーロガーなのか(タグマネージャ側は)判断できない。
    • スクリプトに知識が無く誰かに言われた通りにスクリプトを追加された場合、危険なスクリプトが動いてしまう。
  • ドメイン乗っ取り
    • スクリプトのドメインが失効して、第三者に乗っ取られるケース。 実際にニュースサイトにアダルトビデオのサイトが表示されるケースがあったようですが、それ以外にもデータスキミングといった被害にあう可能性も考えられます。

マーティング部との連携

先にあげたような危険性を考えると、Webマーケティングのためのスクリプトもセキュリティを意識しなければなりませんが、マーケティングの方々と対話するときはマーケティングの方々の視点に立って説明することが重要です。

例えば、「このスクリプトは安全じゃないので使用しないでほしい」と言った提案ではなくマーケティング界隈の言葉で提案します。

  • 「お客様のブラウザに『保護されていない通信』と表示され、怖がられる可能性があります。CVR(コンバージョン率)にも影響が出る恐れがあります」
  • 「スクリプトのせいで、ウェブサイトが遅くなっています。直帰率にも影響している可能性があるため、新しいバージョンに置き換えられますか」

当然のようなお話ですが、違う職種の視点に立って説明することは容易ではありません。勉強や経験なしではマーケティングの方が、私たちセキュリティ界隈の人と同じような温度感でセキュリティについて考えることが難しい一方で、セキュリティ界隈の人もマーケティングについては知らない事や意識できていないことが多いと思います。

リスクの軽減

  • タグマネージャの運用を見直すこと。
    • 特にカスタムHTMLなどはなるべく使用しないようにする
  • 自身が顧客なら、(マーケティングの)ベンダにセキュリティコントロールの見直しやチェックを要求する
  • 技術的な面では、CSP(Content Security Policy)を導入する
  • センシティブなページではスクリプトを動かさないようにdataLayerの制限をかけ、セーフティネットを用意する

技術的に対応できる部分と運用や連携で対応できる両面があり、セキュリティは一人ではなくチームで行っていくということを再認識しました。 連携部分では、相手のナラティブを理解し歩み寄る対話が必要だと感じました。セキュリティの話というより組織論のお話になりましたが重要なことです。

おわりに

今年のセッションもどれも面白く非常に勉強になりました。
今回は初のオンラインとオフラインのハイブリッド開催のようで、オフラインチケットも会社にて用意頂いていたのですが、個人的なコロナ感染の懸念からオンラインでの参加にいたしました。
コロナ禍が落ち着いたら、オフライン参加もしたいと思いました。