SSTエンジニアブログ

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

「CODE BLUE 2023」参加レポート(1日目)

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

はじめに

スーパーマリオブラザーズワンダーが驚きの連続！で話題だったので、買って遊んで仕事のやる気が起きない岩間です。
11/08-11/09で開催されていたCODE BLUE 2023にオフラインで参加してきました。
私が聴講したセッションについて、簡単にですがレポートしたいと思います！

AI主導のIDアタックサーフェスの可視化でIDの誤設定をあぶり出す

株式会社CyCraft Japan様の発表でした。

冒頭では、ASM(Attack Surface Management)についての説明でした。
国内で知られているASMは、外部からのアタックサーフェスを可視化・管理するEASMと呼ばれるものを指すケースが多いですが、今回の講演ではEASMではなく、Identityを管理するIdentity Attack Surface Managementについての紹介でした。 組織のID管理、IDの把握、リスクの調査、(リスクがあった場合の)緩和措置を行うための管理ソリューション、それがIASMだそうです。

多くの企業はIDを管理するうえで、Active DirectoryやAzure Entra IDを使用しますが、これらは複雑でしばしばアタックサーフェスにおける盲点になりやすいです。 IASMでは、ID管理の弱点を探索します。

  • 設定ミス
  • 過剰な権限
  • シャドーアドミン(※)

※ 見かけ上は一般ユーザに見えるが、実際の権限は特権ユーザーと同等であったり、特権グループに入ってないように見えるが実際には特権グループに参加が可能なユーザなど

アタックサーフェスの分析・可視化には、アタックサーフェスだけでなくアタックベクターやアタックパスも評価するようです。

  • Attack Vector: 攻撃者が行う攻撃手段のこと
  • Attack Path: 攻撃から目的のポイントまでの攻撃経路
  • Attack Surface: Attack Path上のシステムとシステムの境界にある面

IASMでは、どのような攻撃手段をつかってどのようなルートを辿り、弱点となる境界を知っていくことが重要のようです。 CyCraftのIASM製品「XCockpit」は、LLMやAIを使ったIDの管理やリスク分析や、人間の言葉で理解できる緩和措置を提供してくれるようです。

Xcockpitのアプローチ

  • Identity Collection: ツールによって自動的にID情報を収集する
  • Relationship Mapping: ID情報のデータを関連付けしていき分析する
  • Attack Simulation: AIを活用して、潜在的な脅威をシミュレーションする
  • Overall Landscape: 脆弱性やリスクの説明をLLMによって生成された人の言葉で理解できやすい内容で提供する。

Overrall Landscapeで説明されたLLMは、CyCraftGPTという機能？名前？らしいですが、これは、CyCraftの社内で開発されたクローズドなLLMとのことです。日本語による生成もデモでは出来ているように見えましたが、現在開発中とのことです。 また、対策内容だけでなく、対策するためのスクリプト生成もAIを使用して自動生成できる機能もあるようで、こちらも開発中とのことです。

Pwn2Ownのターゲットをハッキングした3年間の物語：攻撃、ベンダーの進化、そして教訓

恒例のOrange Tsai氏による講演です。今回は特定の脆弱性に関する研究発表ではなく、Pwn2Ownで3年連続して同じ製品をターゲットにした挑戦と教訓についての発表でした。

内容の前に、Pwn2Ownについて軽く紹介します。Pwn2Ownは、毎年開催されるセキュリティカンファレンス+ハッキングコンテストです。CTFのような出題者による想定解がある問題を解くコンテストではなく、実際の製品をハッキングし、ゼロデイの脆弱性を探すことがコンテストの目的です。また、高額な賞金が用意されているのも特徴的です。
年齢制限や主催企業の従業員は参加できないなどの参加資格はありますが、基本的には誰でも参加でき、参加する際にどのカテゴリーに参加したいか選ぶ必要があります。
2023年のルールでは、8つのカテゴリー（スマートフォン、プリンターなど）に分かれており、さらにカテゴリの中でも製品ごとに分かれているそうです。Orange Tsai氏はスマートスピーカーカテゴリのSonosに3年連続してエントリーしており、今回その中で挑戦した経緯や教訓について発表されていました。

2020年、初めてSonosを選んだ理由は、これまで違うものを対象にしたかったとのことで、コンテスト登録2週間前に、調査を開始されたようです。（！）
Web Interfaceに対するアプローチは、デバッキング用の機能の解析と、UPnPで使われるSOAPコマンドの調査でした。残念ながらコマンドインジェクションのような脆弱性は見つからなかったようです。

次のアプローチは、SonosスピーカーをCLI経由で操作するためのOSS「socos」が用意されており、これに注目しました。
コードの中でBeginSoftwareUpdateメソッドを見つけ、これを実行させたところ、Sonosから送られてきたリクエストのUAからwgetが使われていることが分かりました。
ブラックボックスによる調査は、時間の浪費になることが多いためFirmwareの調査に切り替えたものの、ネット上には古いFirmwareしかなかったようです。
それでもバイナリを手に入れることはできたので、調査を開始したようです。

SSRFを試みましたが駄目だったようで、wgetの脆弱性を調べてみても一つも該当するものはなかったようです。firemwareのバックドアやダウングレード攻撃といったことも試してみたもののいずれも失敗に終わりました。

次にFirmware Parserに注目し、古いFirmwareではエクスプロイトが成功したようです。ただし最新版のFirmwareでは成功できませんでした。

2020年のコンテストで、次のような内省をしていました * 2週間の調査の中では良くやった * リバースエンジニアリングのスピードをあげるべきだった。特にC++

2021年のコンテストでは、再びSonosでエントリーされたようです。
synactivのチームがSonosでエントリーしており、別の攻撃に関する記事を公開していたため、希望が見えたようです。
多分これかな？ www.synacktiv.com

今回はコンテスト3ヵ月前から調査を開始しました。 USB3380 エバレーションボードを購入したものの、ハードウェアの専門ではなかったためうまく動作せず、動くまでに一週間かかったようです。 動くようになってから、簡単な調査（スライドではno-brainと表現）をしました。

  • Webデバッグルートの実装の調査
  • system(3) / exec*(3)の呼び出し部分の調査
  • ecv(3) / recvfrom(3) / recvmsg(3)部分の調査
  • unsafe string operationの調査(後に、見落としがあった)
  • 簡単なオーバーフローがないか調査

バグは見つからなかったため、オーディオフォーマットのパーサー部分に注目し、sonosがパーサーを介してどのようなメタデータをオーディオから抽出するのか調べました。
結果的に、バッファオーバーフローが可能なポイントを見つけることができたようですが、残念ながらBOFには至らなかったようです。 その後、ID3v2タグの調査を行い、バグ？脆弱性？は見つけられたようです。

2年目は次のように振り返っていました。

  • よいアタックサーフェスを見つける事は時間の節約につながる
  • 入口としてハンドメイドのパサーを見つけられた
  • ハードウェアの構築に時間を掛け過ぎた
  • 盲目的な試行をするのではなく、基本を理解すること
  • ファジングを早くに諦めたこと（別チームでバグが発見された）
  • すぐにマニュアルを読むべきだったこと

3年目の挑戦では、Sonosが全てのバイナリ保護機能をONにしており、これまでのバグが通用しなくなっていました。 gethostbyname_r(3)が呼び出されている/nslookupの実装に注目しました。
カスタマイズしたDNSと遅延レスポンスによるPIE、ASLRのバイパスに成功、スタックポインタをリークすることができたようですが、翌日修正されていたようです。

次に、XMLパーサーに注目しました。 XMLライブラリ(libexpot)を使用していたため、コールバック処理を調査したところ、OOB-Writeにつながる脆弱性を見つけることができました。が、これも翌日修正されていたようです。（翌日というより当日？）

その後全てのアイデアを使い切ったものの、脆弱性は発見できず、これまで見つかったバグのレビューをしたところ、オーディオフォーマットのパーサー部分で発見されたBOFできそうだったバグじゃない部分が、これまでのパッチ適用により脆弱なコードにデグレされていることが分かりました。

これまでの脆弱性発見からの翌日修正の結果から、開発側はクラッシュレポートを見て鬼速の修正をするのは明らかだったので、今度はオフラインで検証したようですｗ

3年目では次のように振り返っていました。 * バイナリ関連のバグのカバレッジに関して、自身のメソドロジーを見直す * SMBライブラリのバグを他チームが探していた。複雑な処理だと思い怖かったので、 libsmb2F のレビューをしなかったこと * ネットを遮断すること(良いラボ環境をセットアップすること）

まとめ

  • 粘り強さが大事
  • 同じことにどれだけ長く取り組めるか
  • 粘り強さは鍵ではあるが、正しい道筋を見つけることも重要

最後にCeleste（ゲーム）が紹介されていました。Celeste、癖になりますよね…。

開けゴマ！スマートロック開錠の全容

Day1の最終トラックの講演でした。
スマートロックに関するハッキング調査発表で、2021年から2023年に発売された中国製の新しいスマートロックをターゲットにしていました。

スマートロックの最初のハッキングは、中にある基盤にアクセスすることです。
一台目のスマートロックは、ファームウェアとメモリが守られていなかったため、抽出するのは簡単だったようです。 信号から通信内容を解析し、ヘッダー、コミュニケーションID、インデックスやコマンドなどが判明しました。 リバースエンジニアリングを行い、EasyFlashリンクなども見つかったようです。 パスワードのリークに成功し、結果的に開錠することができました。

二台目のスマートロックは、一台目と同じメーカーのものを購入。全体の設計は一台目と同じでした。 ただし、二台目にはNFCの機能が搭載されていたようです。 こちらも同様に開錠できました。

この結果をメーカーに伝えましたが、メーカーは意見を全く聞かずにやりとりは終わったようです。
やりとりのスクショを見ましたが、普通のカスタマーサポートが対応してるだけのような気もしました。技術チームへのエスカレーションはできなかったのか、エスカレーションした結果の回答だったのでしょうか・・・。

次のスマートロックは、スマートフォンとBLE通信で開錠するタイプのものでした。スマートフォンとスマートロック間のBLE通信には暗号化がされていないため、スニファーすることは容易でした。 こちらも通信内容を解析した結果、データはおそらくAESで暗号されていることが分かりました。 スマートフォン側のアプリ（APK）をfridaなどを使ってリバースエンジニアリングしたところ、弱い暗号強度だということが分かりました。 6 hex程度の長さなので、20分ぐらいで総当たりが可能でした。 こちらのメーカーも対応は良くなかったようです。

講演では、その他のスマートロックに関する調査と開錠のデモが行われていました。

まとめ

  • 暗号化や開発はベストプラクティスに則って行うこと
  • セキュリティリサーチャーには、耳を傾けるべき
  • よい信頼関係を構築できる
  • エンドユーザーに、完璧なソリューションはない

おわりに

今年のセッションもどれも面白く非常に勉強になりました。（前回と同じこと言ってる） 前回の参加が2021年なので2年ぶりです。(あれ、なんで去年参加しなかったんだろ・・・？）
オフラインは2018年以来行ってないので、実に5年ぶりですね！
今年は社内での参加は自分だけでしたが、来年は他のメンバーと行けるといいなぁと思いました。