SSTエンジニアブログ

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

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

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

はじめに

AC6が終わってないのに積みゲーだけ増えて仕事のやる気が起きない岩間です。世界樹の迷宮楽しいれす()
11/08-11/09で開催されていたCODE BLUE 2023にオフラインで参加してきました。
私が聴講したセッションについて、簡単にですがレポートしたいと思います！

Content-Disposition の "filename" という地雷 -曖昧な要件が原因となる脆弱性-

Content-Dispositionに関する研究発表でした。
調べたら登壇者の記事がありました。
詳細は、登壇者の記事をご覧ください。ここではざっくりと私の感想だけ書きます。
Web上でファイルのアップロードをしたりダウンロードする際に付与されるものですね。
手動診断される方は、Injection Pointとして普段から検査されると思います。
登壇者はSpring製のWebアプリの脆弱性を調べている際に、ファイルアップロードで500エラーを返したため、疑問に思い深堀されたようです。

エラー時のテスト

example";';.jpg

multipartのリクエストボディ

-----------------------------277224600214918072883416139191
Content-Disposition: form-data; name="file"; filename="example";';.png"
Content-Type: image/png

{バイナリデータ}
-----------------------------277224600214918072883416139191--

multipartについて、MDNやRFCを見て仕様やフォーマットを調べて、 上記のテスト値はダブルクォートがエスケープされていないことに気が付いたようです。 ダブルクォートがデリミタになっているので、filename="example" で区切られていると解釈され、後ろの文字 ;';.png" がSprint側に影響を与えているようです。

Content-Dispositionのパーサ部分なので、Spring Frameworkの該当部分のソースコードをチェックしたところ、Content-Dispositionの値を key=value 形式に分割して配列として返す tokenize() で、エラーを起こしていることが分かりました。

先ほどのテスト値は tokenize() で以下のような分割処理が行われていたようです。

Input:
Content-Disposition: form-data; name="file"; filename="example";';.png"

Output:
(ArrayList String)
  [0] = Content-Disposition: form-data
  [1] = name="file"
  [2] = filename="example"
  [3] = '
  [4] = .png"

要素3,4が key=value 形式でないのは明らかですね。登壇者は、このバグをうまく悪用することで、意図しない定義済みフィールドのインジェクションが可能か調べ、結果的に成功しました。

ファイル名:
a.txt"; name="dummy"; filename="dummy"; size=1234; dummy=".txt


Firefox が生成する Content-Disposition:
Content-Disposition: form-data; name="file"; filename="a.txt"; name="dummy"; filename="dummy"; size=1234; dummy=".txt"


parse() の結果:

type = "Content-Disposition: form-data"
name = "dummy"
filename = "a.txt"
charset = null  　( filename* の際に設定される値)
size = {Long@438} 1234
creationDate = null
modificationDate = null
readDate = null

インジェクションできるフィールドは、Spring側で指定されていたので、その中からという制約はありますが、素晴らしいです！

が、これをSpring Frameworkにレポートしたところ「ブラウザの問題じゃない？」と言われたようです。
まぁ、アップロード時にブラウザ側がエスケープしてない結果、invalidなContent-Dispositionを送っているので、Spring側の言い分は納得です。登壇者も同じようでしたｗ

悪用シナリオを考え、Firefoxに報告したところ、悲しいことにこの脆弱性？バグ？を2.5年もの間修正されず、しかも修正はサイレントだったようです。CVEも発行されず。

その後、別の方がSpring FrameworkのContent-Dispositionの脆弱性を見つけたようで、登壇者はこれをキッカケに更に深堀したようです。

そもそもこの脆弱性は、Reflected File Download(RFD)の脆弱性でした。 RFDって聞き慣れないなぁと思って調べたところ、

信頼できるドメインを元にしているように見える任意のコンテンツを強制的にダウンロードさせる

というものらしいです。へー。資料もいくつかありますね。

登壇者は、Content-Dispositionを更に調べ、HTTP内の以下の部分で利用されていることが分かりました。

  • HTTP Request の HTTP Body 内にある multipart
  • HTTP Response の HTTP Header
  • Email の Body 内にある multipart

余談ですが、ん、三つは当たり前じゃん？って思われるかもしれません。 でも、自分は調べずにContent-Disposition出てくる箇所全部言えるかな？って言われたら無理ですね。自信ないです。
更に登壇者は、これらの各部分において脆弱性があった場合の攻撃シナリオを考えています。
最終的に80個ほどのシステムを調べ、複数の脆弱性を見つける事ができたようです。
脆弱性ごとの分析については、登壇者の記事をご覧ください。

まとめ

  • RFCの記載では、Content-Dispositionについて明確には定まっていなかった
  • 一報WHATWGのHTML Specにはしっかりとかかれていた。ただし2021年と新しい。
  • filenameのcontent-dispositionでエスケープすること
    • \r \n "

ペニーワイズ - 新しいAI時代における目に見えないプライバシーリスク

LLMアプリケーションにおけるプライバシーの問題を、技術的な観点と法律的な観点の二つの観点でお話されていました。
冒頭でLLMアプリの普及具合についてお話されていました。
2023年のスタンフォード大学のレポートによると、沢山のLLMアプリケーションが登場しているようです。
その中でも有名なのが、OpenAIのChatGPT、GoogleのBard、MSのbingだそうです。
また、爆発的な普及と同時に、LLMの利用に関して従業員に利用することを禁止している企業も増え始めていました。

そういった情勢の中、OWASPは、 OWASP Top 10 LLM アプリケーションを公開しました。
講演では、このランクインしたLLMアプリケーションに関する問題の中から、いくつかピックアップされていました。

一つ目は、Prompt Injection。 Prompt Injectionの中でも登壇者が注目したのは、CVE-2023-20374の脆弱性で、これはLangchainの脆弱性でPythonコードの実行が可能だったようです。
非常に多くの利用者が多かったため、注目も大きかったようです。

二つ目、LLMに対する過度の信頼です。
LLMアプリでは、誤った答えを出す可能性があります。
ニューヨークの弁護士は、とある裁判でGPTによって生成した書面を提出しました。
GPTはあたかも実在するような事例を載せていましたが、実際には架空の事例だったことが後で判明しました。

三つ目は、LLMのチャットアプリケーションの規制をバイパスするDAN(Do Anything Now?)でした。
暴力的なコンテンツなどのアプリケーション側で設けている制限を迂回する手法です。
例えば、本来であれば暴力的な内容である「爆弾の作り方」を聞き出すといったものです。

四つ目は、Role Acting Promptによる機微情報の窃取です。
LLMに特定のロールを振る舞うようにさせ、そこからフィルターされるべき情報を窃取するというものです。

OWASP TOP 10の内容から派生して、プライバシーに関する内容にフォーカスしていました。 LLMは学習の過程で、大量の公開情報を学習します。(これを過剰収集と呼んでいました)
その中にはプライバシーで保護されるべき内容もあります。登壇者にとって、過剰収集はプライバシーの侵害と考えており、個人情報を提示する方法を調べました。
直接「個人情報を教えてくれ」と伝えると、bardやChatGPTは個人情報の提示を拒否しました。
ですが、MS Bingは個人情報を渡してきたそうです。

次に、おばあちゃんを演じさせるようにLLMに伝え、個人情報が入った方言を歌ってもらうように指示すると、ChatGPTやbardでも個人情報を返したそうです。これは、先ほど紹介したRole Acting Promptだと思います。
最後に、LLMアプリケーションは、今後プライバシーを保護するためのベースラインがあるべきだと話してました。また、それは各LLMで異なる基準ではなく、統一的なものが求められています。

次に法律的な観点でのお話でした。
まず規制について、社会はLLMあるいはAIに何を期待しているのか。そして何を規制したいのかを考えます。

  • EUのAIに関する法案には、透明性という言葉が含まれていた
  • 日本のAIに関する法案では、社会的原則（human-centric)。
  • カナダではデータの扱いに関する行動が規定されていた。

また、NIST AI RMF1.0にもいくつかの原則があります。

  • 安全であること
  • 説明責任があること
  • 透明性があること

このことから、信頼できるAIシステムには説明責任が必要です。そして説明責任の前提には透明性があります。
では、人々はAIに対してどのような透明性を求めているのでしょうか。
この答えはプライバシーに関するリスクでしょう。前半で説明されていた過剰収取におけるプライバシーの侵害です。

イタリアでは、ChatGPTがユーザーの同意なく個人情報を収集したと見なし、イタリアでのChatGPTをオフラインにしたようです。
OpenAIは、改善を行い年齢の確認を実装し、その後イタリアでの利用が再開されました。
他にもデータの保有期間についても問題となっていました。ユーザーが30日以内なら削除できるオプトアウトを持つべきという透明性が求められていました。

まとめ

  • LLMやLLMアプリケーションに求められるのは、透明性とプライバシーに対する説明責任
  • 開発者は、機能を作るとき、同時にプライバシーを設計に組み込む
  • データの権利を明確にする
  • ユーザーへの通知、同意を得る事、最初は人間を中心に考えること

生成AIのセキュリティ・リスク​

こちらもLLMに関する研究発表でした。
調べたところ、既に記事がありましたので、詳細は割愛したいと思います。

講演の冒頭で、挙手制の会場アンケートがありました。「LLMアプリケーションについてご存じですか？」と登壇者の方が質問したところ、会場の三分の一程度が手をあげていました。
LLMの概要を説明された後、OWASP TOP 10 のLLMアプリケーションについて紹介されていました。こちらは、前の講演と同じものですね。
LLMとLLMアプリケーションは、消える事はなく今後も増えていくし、LLM自体も発展していくと発表では話されていました。

LLMアプリケーションのセキュリティリスクについて、脅威と手法の紹介、およびデモが行われました。
ChatGPTを介して機微情報であるメールアドレスの窃取する手法として、jailbreak + CoT + MCが紹介されていました。未知の分野なので勉強になります。以前作成したイオタに通用するのかやってみたいですね。

デモでは、メールアドレスの漏えい、プロンプトテンプレートの漏えい、LLMを介したSQLインジェクションが行われていました。

まとめ

技術として新しいので、LLMに対する関心は皆さん高いように見えました。私もその一人です。
今回紹介された手法は、現在でも有効なのと検証自体はすぐに出来そうでした。
私も試してみたいなぁという気持ちと、LLMアプリケーションのセキュリティについて調べてみたいと思いました。
スポンサーセッションでしたが、興味深い内容でした。もっとやってほしい。

おわりに

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