[レポート]クラウドサービスにおけるブラインド・メモリ破壊のエクスプロイト - CODE BLUE 2025 #codeblue_jp #codeblue2025

こんにちは、臼田です。

みなさん、セキュリティ対策してますか？(挨拶

今回はCODE BLUE 2025で行われた以下のセッションのレポートです。

クラウドサービスにおけるブラインド・メモリ破壊のエクスプロイト

メモリ破損は、クラウドセキュリティとはあまり関連付けられていません。真剣に受け止められてはいますが、悪用が成功したと報告されることは稀な理論的リスクです。これには複数の理由があると考えています。クラウドサービスは通常、メモリセーフな言語で記述されており、一般的なエクスプロイト技術を無効にする変動性をもたらすロードバランサーの背後で実行されます。最後に、攻撃者はROPチェーンのオフセットなど、標的とするバイナリに関する重要な情報が不足しています。

この講演では、クラウドサービスへの攻撃が従来のメモリ破損の標的とどう異なるか、そして攻撃者が克服する必要のある課題について説明します。次に、Google CloudのArtifact Analysisバックエンドでリモートコード実行を引き起こした、エンドツーエンドの脆弱性連鎖について詳しく掘り下げます。

この講演の目的は、メモリセーフな言語を使用し、攻撃者がバックエンドバイナリの知識を持たない場合でも、メモリ破損の脆弱性を悪用することが可能であることを示すことです。

Speakers
Anthony Weems アンソニー・ウィームズ
Stefan Schiller ステファン・シラー
Simon Scannell サイモン・スキャネル

レポート

• メモリ破損はクラウドのセキュリティとして考えにくいと言われる
  • しかし考えていく必要がある
  • 事例を報告する
  • 過小評価されている
  • GCPにおける実例を説明
• Google Cloud Vulnerability Researchチーム
• クラウド/古典的なメモリ破損
  • 古典的なメモリ破壊
    • ホストが1台
    • その上でのエクスプロイト
    • 攻撃者が攻撃に攻撃する
    • うまくいくとリモートコード実行
  • 何がクラウドだと違うか
    • バイナリが不明
    • ライブラリも不明
    • 環境もわからない
    • 環境を入手できない
    • ロードバランサーが使われている
    • 攻撃者はOSSが使われているかわからない
    • UIを見ても仕組みがわからない
    • しかしサービスについてわかれば憶測はできる
    • イメージライブラリが入っていることがわかるなど
    • Cで書かれたライブラリもしばらくは使われ続ける
    • ライブラリが特定できたとする
    • BOFしてRCEできる
  • LB配下だとやり取りしている間に違うワーカーに届く
    • ワーカーが少なければブルートフォースでもいいかもしれない
    • 上手く行かないのが別のワーカーだから七日不明
• どうやって解決するのか
  • Arbitrary file readの脆弱性を使う
    • 環境を理解する
    • JPEG 2000の問題
  • Arbitrary Memory Read primitives
  • Fingerprinting common ocker base images
    • libcなどがわかる
    • GoogleVRPではよく使う
  • ロードバランサをどうするか
    • 1回ですべてを実行できるなら問題ない
    • ASLRもある
    • 特別なバグが必要
    • ROPチェーンがないと難しいか
    • 対象のワーカーを特定する処理を入れる
    • エラーだけでも確認できる
• クラウド上でも攻撃でき、バグは必要だが利用できる
• つまり実際のリスクとして考える必要がある
• Artifact Analysis
  • いろんなサービスをフックしている
  • 自動的にArtifact Analysisで分析している
  • SCALIBRを実行している
  • コンテナイメージをスキャンする
  • すべてサンドボックスで起こる
  • Goで使われていてメモリセーフである
  • 本当にそうか？
  • RPM parserはsqliteでCGOを使っている
  • 攻撃ターゲットとなる
  • メモリセーフといえど安全ではないものもある
  • 攻撃
    • 攻撃者が悪意あるコンテナイメージを用意
    • SCALIBRでスキャンさせて破壊される
    • SCALIBRは攻撃者が使えるようになっているので試せる
    • ディレクトリトラバーサルがあるかも
      • path.Cleanが何を行うか
      • パストラバーサルできてしまう
    • これをRCEにどう利用するか
      • 通常minimal read-onlyファイルシステム
      • メモリ破壊には使える
    • なにかエクスプロイトできるかも
    • 悪意のあるイメージを作成してファイルの存在確認
    • あっていれば処理が成功する
• Exploit SQLite
  • 公開されているCVE
    • CVE-2024-0232
    • 3.43.2
  • Changelogを確認する
    • メモリエラーにつながるかもしれないと書いてあるログ
    • コードを確認してみる
      • i64キャスト
  • concat_ws
    • 指定したセパレータで文字列結合
    • サイズはi64
    • 文字列の長さの計算処理がどうなっているか
    • nはi64だがargcとnSepがint
    • integer overflowする
    • そしてnを使ってmallocに渡される
    • しかしoverflowがある
    • 追加の書き込みができる
    • コード実行もできる？
      • SEG Faultする
  • changelogの意味がわかった
  • ほかがalloatedなスペースになるのが望ましい
    • UNION SELECTでさらにallocできる
    • 途中にreadonlyのセグメントがある
    • allocを調整してたらいい
    • 小さいサイズで並べる
    • 同じ順番になるとは限らない
  • SELECT queryでallocate可能か
    • テキストサーチも可能
    • allocサイズをコントロールできる
    • xCloseは興味深い
    • sqlite3_moduleのxCloseをターゲットにしてfake structを格納する
    • goのheapをエクスプロイトする
    • そしてgo heapでsprayする
• 結論
  • パストラバーサルで条件付きの破壊に利用した
  • SQLiteでRCEした
• 教訓
  • E2Eメモリ破壊を実演
  • 1回だけのチェーンではなく反復される可能性がある
  • メモリ破壊はクラウドにおいて実際的なリスクと考えるべき

感想

クラウド環境でのセキュリティテストも大変そうですね。しっかりやってますね。