はじめに
こんにちは。基礎技術研究部の中川です。5 月に、シンガポールのマリーナベイサンズで行われた Black Hat Asia 2023 に登壇してきました。また、11 月に東京で行われた CODE BLUE 2023 にも登壇してきました。色々ありまして発表してからかなり時間が経ってしまいましたが、簡単ながらこの記事で登壇に至るまでの経緯を報告します。
今年の Black Hat と CODE BLUE について
まず Black Hat と CODE BLUE について簡単に説明します。
Black Hat は世界トップレベルのサイバーセキュリティの産業系の国際会議で、最新のセキュリティに関する研究や技術について議論する場です。夏に開催される Black Hat USA が一番有名ですが、他の地域、例えば Europe、Asia、MEA でも開催されています。Black Hat は Briefings と Arsenal の 2 つのプログラムから構成されます。Briefings では最新のセキュリティに関する研究が発表され、Arsenal ではツールの展示・デモが行われます。今回は Briefings の方で登壇しました。
CODE BLUE は日本発の世界トップレベルのサイバーセキュリティの産業系の国際会議です。日本における Black Hat の位置づけとなる会議と言えるでしょう。実際、Black Hat の登壇者が CODE BLUE で登壇する事例も多くあります (例えば Orange Tsai さんなど)。
私は Black Hat への参加は 2020 年の EU 以来の 2 回目で、CODE BLUE の参加も 2021 年以来の 2 回目でした。ただ、双方ともコロナ禍の中での開催ということがあり、オンラインやハイブリッド開催のイベントへの参加だったため、オンサイトで登壇するのはこれが初めてでした。
発表した内容について
まずそれぞれのカンファレンスで発表した内容の概略を説明します。
Black Hat Asia では Rosetta 2 のコードインジェクション手法 (AOT poisoning) の詳細について発表しました。
Rosetta 2 について簡単に説明すると、これは Apple Silicon Mac 上で x86 のコード実行を可能とする仕組みです。Rosetta 2 は実行前 (AOT) と実行中 (JIT) の 2 つの変換メカニズムを提供しています。基本的には AOT 変換を利用しますが、動的にコードを生成するアプリについては JIT 変換も利用します。AOT 変換の結果は AOT ファイルという Mach-O ファイルとして保存されます。同じアプリが 2 回目に実行されるタイミングでこの結果を使いまわすことで、何度も同じ変換をする無駄を減らすような仕組みになっています。
この同じアプリであるのかの判定において、Rosetta 2 は専用のハッシュを計算します。これを AOT lookup hash と私は呼んでいます。このハッシュ値を衝突させることにより、汚染した AOT ファイルを使い回させることが出来ます。これを悪用したコードインジェクションが AOT poisoning です。この AOT poisoning は TCC bypass や XProtect などのアンチウイルスのバイパス手法として利用できます。
さらに、AOT poisoning と同等のコードインジェクション手法を Arm 版 Windows の x86/x64 emulation 機能にも発見しました。発表ではこの XTA cache poisoning という手法についても触れ、こうしたアーキテクチャ間の変換メカニズムに広く存在する脆弱性であることを示しました。
CODE BLUE では macOS のセキュリティとプライバシー機構のバイパス手法について発表をしました。私は Gatekeeper, App Sandbox, TCC, XProtect, SIP をそれぞれバイパスする 0-day 脆弱性を 1 年間かけて自力で発見しました。この発見した脆弱性の詳細を紹介しつつ、あまりまとまった情報のない macOS のセキュリティの全体像を攻撃者目線で紹介することを目的とした講演をしました。
各発表の詳細については、発表スライドや動画を見ていただくとして、この記事では発表に至るまでの経緯について説明します。
Black Hat Asia 向けの研究のきっかけ
私は以前 Black Hat EU 2020 で XTA cache file を改ざんすることによるコードインジェクション手法 (XTA cache hijacking) を発表しました。*1XTA cache file とは Arm 版 Windows の x86/x64 エミュレーションで用いられるファイルのことで、大雑把には Rosetta 2 での AOT ファイルに対応します。
Black Hat EU 2020 での発表に至るまでの経緯については以下の記事にまとめているのでよろしければご参照ください。
この研究を終えた後の自然な流れとして「macOS の Rosetta 2 で同じコードインジェクション手法は使えるのか、仮に使えるとしてどのような状況で使える手法なのか」という疑問に至りました。
そこで M1 Mac の発売後、早速端末を入手し、Rosetta 2 の解析を開始しました。Activity Monitor から、Rosetta 2 を介して実行されているプロセスにだけ、/var/db/oah ディレクトリ配下の拡張子が aot のファイルがマップされていることに気づきました。
このファイルに変換結果が含まれていると思い、調べてみると、なんと root でもアクセスできないことがわかりました。
# ls /var/db/oah Operation not permitted
研究を始めた時点では macOS セキュリティについて無知だったため、原因がよく分かリませんでした。その後、調べてみると macOS では SIP と呼ばれる仕組みにより、一部のシステムファイルは root であっても閲覧・書き換えが制限されていることがわかりました。
SIP を無効化すれば AOT ファイルの書き換えはできます。しかし、SIP の無効化には標的の端末への物理的なアクセスが必要となります。もちろん SIP bypass や Kernel でのコード実行の脆弱性を見つければ物理的なアクセスがなくとも可能ですが、すでにそういった権限を得ている攻撃者が AOT ファイルを書き換えるモチベーションは低いでしょう。そのため、SIP が有効な環境下で AOT ファイルに何かしらコードをインジェクトする手法を見つける必要がありました。
しかし、そもそもこの脆弱性探しを始める前に、仮に見つかったとしてどれくらいのインパクトがあるのか、を調べる必要がありました。といいますのも macOS と Windows ではセキュリティモデルが違うため、Windows で有効な手法が macOS でも同じ様に有効とは限らないためです。
その調査の過程で以下のブログ記事を発見しました。
In the past 2 years I started to dig into macOS security research, and along the way it became pretty clear that beyond memory corruption issues the alpha and omega of macOS exploits is to run code in the context of other applications.
翻訳: この2年間、私はmacOSのセキュリティ・リサーチを掘り下げてきたが、その過程で、メモリ破壊の問題を超えて、macOSのエクスプロイトのアルファとオメガ(訳注：最も大事な部分、主要素)は、他のアプリケーションのコンテキストでコードを実行することであることが明らかになった。
このブログポストにも書いていますが、macOS には様々なセキュリティ機構が備わっています。これらはコード署名とエンタイトルメントをベースに機能しています。もし、コード署名のついたバイナリに対してコードインジェクションができる場合、様々なセキュリティ機構のバイパスに悪用可能です。
この記事を見つけ、「もし AOT ファイルに何かしらコードの注入を可能とする脆弱性が見つかり、それが署名付きの実行ファイルに対しても適用できるのであればインパクトがある」ことがわかりました。そこで SIP による制約をバイパスして AOT ファイルの書き換えを可能とする手段がないか深掘りすることにしました。この深掘りを通して開発した手法が AOT poisoning になります。
詳細は Black Hat Asia のスライドにありますが、Apple Silicon Mac 特有の様々なセキュリティ機構のバイパスが必要で、AOT ファイルの汚染は一筋縄では行きませんでした。試行錯誤の時間を合わせるとこの手法を開発するのに 3--4 ヶ月はかかりました。電車に乗っている時に「別のファイルシステムを経由すれば AOT lookup hash の衝突を引き起こせるのでは」とひらめいた時のことは今でも鮮明に覚えています。
Black Hat Asia への投稿、そして登壇
Rosetta 2 の解析結果やそれを悪用するコードインジェクション手法は新規性の高い内容だと考えていましたので、Black Hat Asia に自信を持って投稿しました。かなり早い段階で採択のメールを受け取り、シンガポール行きが決まりました。発表スライドは CFP を投稿した時点でほぼ出来ており、発表練習と PoC コードを整理する程度で、スムーズにシンガポールへ渡航後、登壇できるはずでした。
ですが、その後が大変で、渡航の 1 週間前に娘から風邪をもらい、ほぼ 1 週間まるまる寝込むというアクシデントに見舞われました。検査の結果、幸いコロナではなかったのですが、体調が本調子ではない状態のままの、しんどい海外渡航となりました。また、家庭の事情により長期間の海外渡航が難しくなり、全日程参加ができなくなった点も残念な点です。ほぼ自分の当該セッションに参加するのみであり、少々物足りなさを感じました。
発表についてはいくつか質問ももらい好意的なコメントをもらえたのは良かったですが、少し不完全燃焼感がありました。
CODE BLUE 向け研究のきっかけと採択されるまで
Black Hat Asia の準備をしつつ、空いた時間を利用して macOS のバグハンティング活動も並行して行っていました。これは普段の研究とは別に空いた時間を利用して行っていたものです。macOS のセキュリティ研究者 (@theevilbit, @_r3ggi, @patrickwardle, @patch1t など) による脆弱性の write-up を参考にしつつ、脆弱性のありそうな箇所を掘り下げ、SIP、Gatekeeper、App Sandbox をバイパスする脆弱性を複数発見しました。Black Hat Asia に投稿していた脆弱性が TCC をバイパスするものであったので、新規に発見したものと合わせて、macOS のほぼすべてのセキュリティ機構をバイパスする脆弱性を見つけた事になりました。
この事実に気づき、macOS の脆弱性を一通り概観し、macOS のセキュリティの全体像を攻撃者目線で紹介する発表ができれば面白いかもと思い、投稿したのが CODE BLUE で話した内容になります。macOS 向けセキュリティの情報でまとまっているものがあまりなく、そのことが功を奏したのか、無事採択されました *2。
投稿に当たり意識していること
最後に、Black Hat EU, Asia, CODE BLUE (2 回) に採択されている身として、私なりに CFP 投稿に当たり気をつけている点を挙げます。
CFP ガイドラインをちゃんと読んで、書かれている内容を遵守すること
様々なセキュリティカンファレンスの CFP ガイドラインで "submit early" と書かれている中、守っている方はどの程度いるでしょうか。
私は Black Hat Asia, CODE BLUE の両方について締め切りの 1 ヶ月以上前には投稿しています。例年の傾向などからどのカンファレンスの締め切りがいつ頃であるのかはわかります。それを確認し、余裕をもって投稿できるところにしか私は投稿していません。
その他、ガイドラインにはどういうことを書くべきかが事細かにかかれています。私は CFP を提出する前に書くべき内容が一通り揃っていることを必ず確認しています。
カンファレンスの趣旨に合う投稿をすること
Black Hat に限らず、CODE BLUE や JSAC などでは、どういった投稿が高く評価されるのかについての情報が公開されています。この情報を参考にそのカンファレンスの趣旨に合う CFP を作成することも通すために重要なポイントだと考えています。
- Black Hat: 弊社鵜飼による Black Hat USA CFP 応募必勝攻略法, Black Hat の CFP ページにまとめられているリンク など
- CODE BLUE: All Your REJECT Are Belong To Us － リジェクトする側から など
- JSAC: After JSAC 2021 のビデオで言及されている CFP に通すコツなど
例えば Black Hat の場合、新規性が非常に重視されます。特に、以前に他のカンファレンス等で発表されておらず、Black Hat の場で最初に発表されることを重視する傾向にあります。
https://i.blackhat.com/Black-Hat-General/How-to-become-a-Black-Hat-Speaker-by-Sheila-Berta.pdf
Other tips ‐ 100% new material: We (reviewers, at least at Black Hat) prioritize talks that have never been presented elsewhere before. Having 100% new research is important to us. If you will disclose your research before Black Hat’s date(s), your proposal will have a lower priority
したがって、既存手法を改良しただけのようなインクリメンタルな研究や、他のカンファレンスで発表済みの内容は当然ながら採択されにくくなります。
ここでは Black Hat を例に出しましたが、これが別のカンファレンスとなれば重視されるポイントが変わってきます。そのため、あるカンファレンス向けに準備した CFP をそのまま変更せずに別のカンファレンスに投稿するのは基本的に NG で、そういう投稿の場合採択される可能性は低くなるでしょう。
おわりに
Black Hat Asia と CODE BLUE という 2 つの国際会議での登壇という貴重な機会をいただけたことを本当に感謝しています。運営の皆様には本当に感謝しています。
今回、CFP を Black Hat Asia に通し、以前は Black Hat EU に通しました。Black Hat も残るは USA だけとなりました。USA は Black Hat の中でも最も難易度が高いと言われるもので、採択率が 10% をきる非常に狭き門です。いつになるかはわかりませんが、将来的には USA にも通して Black Hat グランドスラム (?) を達成したいと思っています。
