こんにちは。新卒13thのn01e0です。11/8~11/9にかけて開催されたCODE BLUE 2023に参加してきました。
このブログでは、特に印象に残っている発表やブース、ワークショップをいくつかピックアップして紹介します。
CODE BLUEとの出会いは高校時代で、学生スタッフとして参加したのが最初でした。2018, 2019, 2021と学生スタッフでの参加をさせてもらいましたが、今回は社会人としての参加です。
セキュリティエンジニアになる決意をした場に改めて参加できたことを嬉しく思います。
ブース
CODE BLUEでは、発表の他に、スポンサーによるブース展示やコンテスト・ワークショップも行われています。
GMOインターネットグループはトップスポンサーになっているため、入り口からほど近いところにはイエラエのブースがありました。
水をもらって場内巡りをします
ブースの中でも個人的に一番グッと来たのはHex-Raysです。自分はIDAではなくradare2を使っているんですが、マントノン侯爵夫人はひときわ目立っていました。
拙い英語で「記念にブースの写真を撮ってもいいですか?」と聞いたら「撮ってあげるよ」と言われたので記念撮影。ありがとうございました。
ワークショップ
Webハッキングチャレンジforビギナーズ
初日はイエラエの開催するWebハッキングチャレンジforビギナーズに参加しました。
シナリオベースのペンテストライクなCTFで、全問正解するとイエラエのパートナーが執筆した本がもらえます。
朝早い時間に参加し、全問解いたため、初日はずっと1位としてスコアボードに載っていました。
賞品は物理セキュリティの実践を頂きました。ありがとうございます。
Flatt Security Speedrun CTF
2日目はFlatt Securityの開催するFlatt Security Speedrun CTFに参加しました。
タイムアタック形式で、全問解くまでにかかった時間を競い、上位5名はノベルティが貰えるというコンテストでした。
結果、自分は5問中3問しか解くことができず、7位でした。Dart問が解けず悔しい。
発表
CODE BLUEの発表にはいくつかの種類があり、メインのトラック以外にも、主にツールの発表を行うBlueBox、アイデアを発表するCyberTAMAGO、CommunityとしてのBSides Tokyoなどがあります。
以下、自分が参加したものの中から、特に印象に残っている発表です。
macOSのセキュリティとプライバシーの機構をバイパスする手法について: Gatekeeper から System Integrity Protection まで by Koh Nakagawa
macOSにはSIP(System Integrity Protection)を始めとして、GatekeeperやApp Sandbox、TCC(Transparency, Consent and Controll)、XProtectなどの様々な防御機構があり、それぞれの役割を持ち、多層防御を行っている。
SIPはrootを含むユーザに対して一部のファイルやディレクトリの変更を制限、Gatekeeperは署名の検証、App Sandboxは一部のアプリケーションに対する隔離、TCCはユーザのデータまたはカメラやマイクなどへのアクセスに対する制御、XProtectはダウンロードしたファイルに対するマルウェアの検出をそれぞれ行っている。
App Store外からダウンロードしたアプリケーションにはcom.apple.quarantineというattributeがついており、このattributeがついているアプリケーションを実行しようとするとポップアップが表示されるようになっている。
これがGatekeeperであり、まずはここのバイパス手法から。
標準のアーカイブユーティリティでは、圧縮されたアプリケーションの解凍時にもこのattributeを伝播するような仕組みがあるが、ここに問題があり、uchg flagのついたファイルに対して、アーカイブユーティリティの使っているライブラリはquarantine attributeを付けていなかった。
zipではuchgを保持できないが、tar.gzではuchgがついたまま圧縮が可能なため、
- アプリケーションを含むディレクトリを作成
- uchgフラグをアプリケーションにつける
- tar.gzでそのディレクトリを圧縮
この手順でGateKeeperをバイパスできてしまった。というもの。
また、quarantine attributeのついていないアプリケーションがDropする別のアプリケーションは、Sandbox環境下ではなく、通常の環境で動くため、同時にApp Sandboxのバイパスも行えた。
次はTCCのバイパス。TCCは主にユーザのセンシティブな情報を保護している。Zoomを開いたときに出るカメラの使用を許可しますか?みたいなやつ。
TCCはrootとログインユーザの2つの権限で2つのtccdと呼ばれるデーモンが動いており、それぞれ
/Library/Application Support/com.apple.TCC/TCC.db(SIP protected)~/Library/Application Support/com.apple.TCC/TCC.db(TCC protected)
のデータベースで管理されている。
今回はこのデータベースを改ざんするために、別のアプリケーションに対してcode injectionを行う。
そのために用いるのが、CODE BLUE 2021の発表でも言及のあった、Rosetta 2のAOTと呼ばれるキャッシュ機構の改ざん。
(前回の発表内容がここで出てくるの、めちゃくちゃアツくないですか? 中川さんは冷静に発表されてましたが、自分は心の中でｳｵｰつってました)
AOTのlookupに使われるハッシュの計算には、
- Mach-O headerとload commands
- ctime, mtime, crtime
- file path
- uid, gid
が用いられるが、バイナリの内容そのものは使われていない。そのため、これらの要素を保持したままバイナリを書き換えると、汚染されたバイナリが実行されてしまう。ということだ。
APFSではmtimeを改ざんするとctimeも書き換わってしまうが、FAT32にはctimeが存在しないため、これを活用する。
- TCCで許可されたアプリケーションを探す
- FAT32のディスクイメージを作成、マウント
- 許可されたアプリケーションをマウントしたディレクトリに移動
- シェルコードを書き込む
translate_toolでAOTファイルを作成させる- アプリケーションを元の状態に復元
- タイムスタンプを改ざん
- 実行
- シェルコードを含んだアプリケーションが実行される
また、AOTファイルの生成時にはスキャンが行われていなかったため、このバイパス手法によって、同時にXProtectもバイパスできた。
最後にSIPのバイパス。SIPをバイパスは常にTCCのバイパスでもある(SIPで保護されたTCCのdbを書き換えられる)上、SIPをバイパスすると、SIPで保護されたマルウェアの展開も可能なため、非常に重要。
SIPのバイパスを行うためにはcom.apple.rootless.install及びcom.apple.rootless.install.heritableが重要。これらはSIPのバイパスをしたり、その権限を与えるのに使われる権限
system_installdはcom.apple.rootless.install.heritableをもっており、システムパッケージのインストール時に、SIPのバイパス権限を与えるのに使われている。
.pkgファイルにはインストール前後に実行されるスクリプトが入っており、そのスクリプトに脆弱性があると、system_installdの権限で操作が可能になるため、SIPをバイパスできる。
InstallAssistant.pkgのpost install scriptには脆弱性があり、CVE-2023-23533として報告されている。
このような脆弱性は他にもあり、その原因はAppleが過剰な権限を与えているからだとしている。いくつかのパッケージについては、system_installdではなく、installdで十分だとのこと。
MacOSのセキュリティに関して、ここまで詳しくわかりやすい発表は初めてだった。公開されている情報が少ない分野なので、非常にありがたく、面白かったです。
stelftools: クロスアーキテクチャに対応した静的結合されたライブラリ関数の特定ツール by Shu akabane, Takeshi Okamoto, Yuhei Kawakoya
BlueBox(ツールの発表を行うカテゴリ)の発表。ELF中に静的にリンクされたライブラリのシンボルを特定しようという試みと、その結果として生まれたツール。
以前からこのツールと関連研究については軽く追いかけており、個人的に普段使用しているツールから使えるようにするスクリプトの開発などもしていた(ref)ため、楽しみにしていた発表の一つです。
stelftoolsはstatic linkされたバイナリの関数を特定するツールです。
多くのIoT向けマルウェアでは、ライブラリを静的にリンクしており、バイナリの解析時に開発者が定義した関数なのか、ライブラリの提供している関数なのかが特定しづらくなっています。
一般的に、解析を行いたいのは開発者が定義した関数の方で、ライブラリの提供する関数ではありません。これらを特定することで、区別が簡単になり、より効率的に解析が行なえます。
しかし、IoTデバイスは様々な命令セットで動いており、そのファームウェアや、ビルド時のツール郡もバラバラです。
stelftoolsではこれらに対し、網羅的にパターンを作成することで、IDA FLIRTなどの他のツールよりも優れた特定率を誇っています。
stelftoolsは、まず様々なツールチェインでコンパイルされたライブラリ関数に対し、yaraルールを作成します。
しかし、例えばrand(3)のように、内部で別の関数をそのままcallするだけの関数に関してはシンボルが非常に小さく、大量のマッチが発生してしまいます。
そのため、stelftoolsではyaraルールによるパターンマッチングに加え、いくつかの方法で絞り込みを行っています
- Branch target analytics
- 遷移先アドレスの絞り込み
- Call-dependency filtering
- ライブラリとバイナリの依存関係を比較
- Linking order filtering
- 絞り込めない関数を含んだソースコードを用意し、実際にコンパイルして比較
また、発表内ではstelftoolsの他に、Generic UnpackerであるXUnpackなど、他のツール郡についても紹介されていました。
非常に優れた研究・ツールだと思うので、今後も楽しみにしています。
カーネル空間への宝探し: Linuxカーネルでの攻撃可能な構造体の探索 by Yudai Fujiwara
日本の著名なCTFプレイヤー 藤原 裕大氏による発表です
Linuxカーネルの脆弱性は、その攻撃可能性がわからないものが多くある。「potentially remote code Execution」みたいなのよく見る。
カーネルにおけるHeapベースの脆弱性があったときに、実際に攻撃につながるかどうかは、Heapにallocateされている構造体の種類によって求められる。
関数ポインタを持った構造体や、コントロール可能なメンバ、Blobデータなど
そういった構造体を、ユーザ空間から簡単にallocateできると攻撃に繋げやすい。例えばtty_structやsetxattr、msg_msgなど
今回の研究では、Ghidra Scriptを用いて、それらの構造体を自動で探し出した。
debug info付きでビルドしたLinux KernelをMALTIES(Malloc Tracer for Identifing Exploitable Struct)と名付けられたGhidra Scriptに読ませると、それらの構造体を特定してくれる。
この手法は、動的なものや、他の静的な手法と比べて基本的に優れているが、「ユーザ空間からのallocateのしやすさ」という点では動的手法の方が優れていることもある。
実際のLinux Kernelを対象に検証したところ、1133の構造体を見つけることができた。
まとめ
CODE BLUEの発表を見ていると、トレンドがなんとなく見えてきます。
今回は生成AIのセキュリティに加え、TeslaやPwn2Ownなどの低レイヤーに関するセキュリティの話が多く、非常に楽しむことができました。