サイバー脅威
ChatGPTにも繋がるCodexとサイバー攻撃①：データ収集におけるセキュリティリスク
2020年6月、人工知能を研究する非営利団体「OpenAI」は、その後の「ChatGPT」にも繋がる自然言語処理モデル「Generative Pre-trained Transformer」の第3バージョン（GPT-3）をリリースしました。この自然言語処理モデルは、人が書いたかのように思えるほど優れた文章を生成する能力を持つことから、世の中の技術業界を大いに驚かせました。
[公開日] 2022年6月16日、[更新日]2023年3月16日
このブログシリーズでは、その後の「ChatGPT」にも繋がる「Codex」についてさまざまな視点を交えて解説し、開発者だけでなく、攻撃者への影響も含めたセキュリティの観点にもとづき、その機能やリスクについて評価します。全4シリーズで構成されており、今回のブログはシリーズ第1回目となります（第2回目、第3回目、第4回目もご参照ください）。
- GPT-3、GPT-4：自然言語を理解し生成する文章生成モデル、GPT-3は後にGPT-3.5をリリース
- Codex：GPT-3をベースにしたコード生成モデル
- ChatGPT：GPT-3.5、GPT4をベースにした「対話型」文章生成モデル、Codexが自然言語を入力してコードを出力することに対して、文章による対話型でコードを生成することも可能
また、「ChatGPTがもたらすサイバーセキュリティ業界への影響」のブログについてもご参照ください。
2020年6月、人工知能を研究する非営利団体「OpenAI」は、自然言語処理モデル「Generative Pre-trained Transformer」の第3バージョン（GPT-3）をリリースしました。この自然言語処理モデルは、人が書いたかのように思えるほど優れた文章を生成する能力を持つことから、世の中の技術業界を大いに驚かせました。また、GPT-3は、自然言語だけでなくコンピュータ言語を学習することも可能です。そのため、OpenAIは最近、プログラミング言語に特化した「Codex」もリリースしました。Codexは、プログラマのコーディング作業を支援することを意図したものですが、場合によっては、プログラマに取って代わる存在になると考えられます。この新しいシステムは、汎用言語モデルであるため、自然言語のコメント文も入力として受け取ることが可能であり、ユーザが選択したプログラミング言語に対応するプログラミングコードを「補完」します。
GPT-3がプログラミング言語を扱えるであろうことは、Codexがリリースされる以前からも、先行利用者による多彩な概念実証を通して示されていました。例えば、Webページレイアウトを説明した英語の文章からHTMLを生成するものや、入力文章に応じたデータセットを選択してグラフを描画するものなどが挙げられます。この他にも、先行利用者によってさまざまな注目に値する機能をわずかな労力で実装できることが示されていました。
GPT-3が人間の言葉だけでなく、多岐にわたるプログラミング用語まで扱えるのは、その独特で膨大な学習データから来るものです。GPT-3の最も高機能なエンジンは、1,750億個以上のパラメータでチューニングされたニューラルネットワークです。学習用のコーパス（言語データベース）として、人間が書いた文書（Wikipedia、公表されている文書、クローリングしたWebサイトなど）とコードリポジトリの双方を含み、全体として800億以上の言語トークンで構成されています。
Codexに自然言語処理機能を供給するGPT-3は、最近一般公開されましたが、Codex自体はまだ技術レビュー段階であり、限られたユーザのみに公開されています。また、Codexは、すでに開発用プログラミングエディタ「Visual Studio Code」上では、AIによるコード補完と変換をリアルタイムで行うプログラミング支援のプラグインとして「GitHub Copilot」に機能を提供しています。
現時点でその性能はまだ粗削りですが、将来的にプログラマやコンピュータエンジニアに対してだけではなく、悪意を持ったユーザに対しても、どのような恩恵がもたらされるのか予測することはできるでしょう。
もしCodexのようなシステムがコンピュータエンジニアの日常業務に劇的な変化をもたらすのであれならば、それと同様に、サイバー攻撃者の活動にはどのような変化をもたらすのかという疑問も自然とあがってくるでしょう。この点を踏まえ、今回の調査では、サイバー攻撃の主軸である「偵察」「ソーシャルエンジニアリング」「脆弱性の利用」という3つの観点からCodexの持つ機能の可能性を分析しました。
このブログシリーズでは、Codexの現時点における機能が、攻撃者の活動に与える影響、開発者や一般ユーザが実施できるセキュリティ対策、そしてCodexが今後どのように進化していくかの３つのテーマから取り上げます。今回のブログはその第1回目となります。
機密情報の収集
言語処理モデルは、公開されているテキストやソースコードから構築された膨大な言語データベースによって精度が向上されます。それでは、GPT-3のニューラルネットワーク内に取り込まれた公開データは、どのような形で保存され扱われるのでしょうか。こうした疑問は、誰しも抱くことでしょう。この観点から、プラグイン「GitHub Copilot」が、著作権保護されているソースコードの断片を提示してしまう問題は既に指摘されていました。では、機密情報の場合はどうでしょうか。GPT-3が機密情報を内部のナレッジベースに保存しているかどうか、そしてそれをCodexのコード生成機能を経由して抽出できるかどうか、という視点からの調査が必要です。
コードからの個人情報、機密情報漏えい
公開リポジトリは、攻撃者から見ると、未発見の機密情報が眠っている宝の山のようにも見えるかも知れません。実際、今回行った調査では、Codexに対して意図的に公開リポジトリ内の機密情報にアクセスさせ、それをコード生成結果に含めて出力させることができました。
上図では、「特定の機密データを取得し、その結果を含めた文字列によってコードを補完」するよう意図的にCodexに要求しました。結果として、確かに、求めていた機密情報に繋がるURLが補完後のコード内に含まれていました。今回、これらのURLからさらなる機密情報を探索することはできませんが、これはURLが偽物やダミーであったということではなく、情報が古かっただけで、機密情報が取得されたという点は意図したとおりであった言えます。
上述の補完された情報が古すぎる課題については、将来的にはある程度解消されることを留意する必要があります。というのも、GPT-3のような言語モデルでは、最新の学習データによる恩恵をできる限り享受するため、再学習が頻繁に行われるからです。
Codexが意図せず露出させる機密情報はURLだけではありません。コードの特定部分を実装した担当者情報、従業員情報、あるいは暗号資産ウォレット番号さえも、露出させる可能性があります。上図の例では、調査のために無線ファームウェアのSIM番号を探っていたところ、現在は該当のプロジェクトに従事してはいないことは明らかですが、実際に存在する開発者の名前が偶然発見されました。
その他、既知の脆弱性を実装するという要求をCodexに行った場合では、脆弱性に関する調査担当者の名前がコードスニペットのコメントに表示されました。実際に検索したところ、確かにその名前の担当者が存在していました。無論、こうした氏名などは、もともと公開されている情報でもあり、名前を知っていればその人物のGitHubリポジトリを検索することも可能ではありますが、GPT-3内にその名前が保持された形でコード内に露出する場合は、セキュリティ上のリスクになってしまう可能性が危惧されます。
クレデンシャルスタッフィング攻撃
個人情報だけでなく、認証情報やAPIのエントリポイントを自動補完させる要求をCodexに行うことも可能です。下図の例では、FedExとDHLの認証情報が露出されています。これらの認証情報は、実際のところはテスト用、有効期限切れ、または単純なランダムな文字列かも知れません。あるいは、言語モデルが「妥当」と判断できる文字列を自動生成したとも考えられます。しかし、事前調査を行う攻撃者からすれば、これらのライブラリ名や変数名に触発されて、攻撃に向けたさらなる調査へ繋げる可能性もあります。
余談ですが、Codexは、質問応答システムではなく、自己主張の強い自動補完システムとして振る舞う点が興味深いところです。実際、Codexは、時折リクエスト文自体を補完することがあります。例えば、上図3段目にあるPayPalリクエスト文中のPayPalアカウント情報は、Codex自身が補完したものです。同様に、下図のコマンド「psql」の例についても、初期のリクエスト文は単純に「psql」の文字列だけでした。
結論
これまでの多くの調査と研究から、リポジトリ内のコードの扱いに関しては、適切なデータクレンジングの重要性が示されてきました。特にインターネット上のリポジトリには、公開されているかを問わず、認証情報や個人情報など未確認の機密情報が多く存在することから、セキュリティ上の懸念点として指摘されています。
今回の調査で提起したセキュリティ上の懸念点は、決して軽視されるものではなく、むしろこれから先、開発者にとってはますます深刻な影響を及ぼすでしょう。学習に使用されるコーパスの規模がかつてない勢いで肥大化している状況を鑑みると、今後、AIエンジンは、機密情報を正確に排除する十分な機構を持たないまま、性能拡充を目指して隅々までコードを掻き集めようとするでしょう。
開発チームと運用チームのエンジニアは、こうした機密情報を継続的に選別する専用機能を実装し、さらに、認証情報を安全に管理する技術や枠組みを確立することが強く求められます。安全に管理する技術や枠組みとして、機密情報を必要に応じていつでも暗号化できるようにし、復号キーをセキュアな記憶媒体にのみ保管することが挙げられます。また、安全に保管できないデータについては、一定時間が経過して機密情報としての有効期限が切れたデータのみを学習対象として取り込む時間的サイクル方式を導入することも有効な対策として考えられます。
本ブログシリーズは、全4シリーズで構成されており、今回のブログはシリーズ第1回目となります。第2回目、第3回目、第4回目もご参照ください。
また、「ChatGPTがもたらすサイバーセキュリティ業界への影響」のブログについてもご参照ください。
参考記事：
• 「"Codex Exposed: Exploring the Capabilities and Risks of OpenAI’s Code Generator"」
By: Forward-Looking Threat Research Team
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）