diff --git a/LLM01_PromptInjection.md b/LLM01_PromptInjection.md index 1089877..224a82f 100644 --- a/LLM01_PromptInjection.md +++ b/LLM01_PromptInjection.md @@ -1,73 +1,71 @@ -## LLM01:2025 Prompt Injection - -### Description - -A Prompt Injection Vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways. These inputs can affect the model even if they are imperceptible to humans, therefore prompt injections do not need to be human-visible/readable, as long as the content is parsed by the model. - -Prompt Injection vulnerabilities exist in how models process prompts, and how input may force the model to incorrectly pass prompt data to other parts of the model, potentially causing them to violate guidelines, generate harmful content, enable unauthorized access, or influence critical decisions. While techniques like Retrieval Augmented Generation (RAG) and fine-tuning aim to make LLM outputs more relevant and accurate, research shows that they do not fully mitigate prompt injection vulnerabilities. - -While prompt injection and jailbreaking are related concepts in LLM security, they are often used interchangeably. Prompt injection involves manipulating model responses through specific inputs to alter its behavior, which can include bypassing safety measures. Jailbreaking is a form of prompt injection where the attacker provides inputs that cause the model to disregard its safety protocols entirely. Developers can build safeguards into system prompts and input handling to help mitigate prompt injection attacks, but effective prevention of jailbreaking requires ongoing updates to the model's training and safety mechanisms. - -### Types of Prompt Injection Vulnerabilities - -#### Direct Prompt Injections - Direct prompt injections occur when a user's prompt input directly alters the behavior of the model in unintended or unexpected ways. The input can be either intentional (i.e., a malicious actor deliberately crafting a prompt to exploit the model) or unintentional (i.e., a user inadvertently providing input that triggers unexpected behavior). - -#### Indirect Prompt Injections - Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files. The content may have in the external content data that when interpreted by the model, alters the behavior of the model in unintended or unexpected ways. Like direct injections, indirect injections can be either intentional or unintentional. - -The severity and nature of the impact of a successful prompt injection attack can vary greatly and are largely dependent on both the business context the model operates in, and the agency with which the model is architected. Generally, however, prompt injection can lead to unintended outcomes, including but not limited to: - -- Disclosure of sensitive information -- Revealing sensitive information about AI system infrastructure or system prompts -- Content manipulation leading to incorrect or biased outputs -- Providing unauthorized access to functions available to the LLM -- Executing arbitrary commands in connected systems -- Manipulating critical decision-making processes - -The rise of multimodal AI, which processes multiple data types simultaneously, introduces unique prompt injection risks. Malicious actors could exploit interactions between modalities, such as hiding instructions in images that accompany benign text. The complexity of these systems expands the attack surface. Multimodal models may also be susceptible to novel cross-modal attacks that are difficult to detect and mitigate with current techniques. Robust multimodal-specific defenses are an important area for further research and development. - -### Prevention and Mitigation Strategies - -Prompt injection vulnerabilities are possible due to the nature of generative AI. Given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection. However, the following measures can mitigate the impact of prompt injections: - -#### 1. Constrain model behavior - Provide specific instructions about the model's role, capabilities, and limitations within the system prompt. Enforce strict context adherence, limit responses to specific tasks or topics, and instruct the model to ignore attempts to modify core instructions. -#### 2. Define and validate expected output formats - Specify clear output formats, request detailed reasoning and source citations, and use deterministic code to validate adherence to these formats. -#### 3. Implement input and output filtering - Define sensitive categories and construct rules for identifying and handling such content. Apply semantic filters and use string-checking to scan for non-allowed content. Evaluate responses using the RAG Triad: Assess context relevance, groundedness, and question/answer relevance to identify potentially malicious outputs. -#### 4. Enforce privilege control and least privilege access - Provide the application with its own API tokens for extensible functionality, and handle these functions in code rather than providing them to the model. Restrict the model's access privileges to the minimum necessary for its intended operations. -#### 5. Require human approval for high-risk actions - Implement human-in-the-loop controls for privileged operations to prevent unauthorized actions. -#### 6. Segregate and identify external content - Separate and clearly denote untrusted content to limit its influence on user prompts. -#### 7. Conduct adversarial testing and attack simulations - Perform regular penetration testing and breach simulations, treating the model as an untrusted user to test the effectiveness of trust boundaries and access controls. - -### Example Attack Scenarios - -#### Scenario #1: Direct Injection - An attacker injects a prompt into a customer support chatbot, instructing it to ignore previous guidelines, query private data stores, and send emails, leading to unauthorized access and privilege escalation. -#### Scenario #2: Indirect Injection - A user employs an LLM to summarize a webpage containing hidden instructions that cause the LLM to insert an image linking to a URL, leading to exfiltration of the the private conversation. -#### Scenario #3: Unintentional Injection - A company includes an instruction in a job description to identify AI-generated applications. An applicant, unaware of this instruction, uses an LLM to optimize their resume, inadvertently triggering the AI detection. -#### Scenario #4: Intentional Model Influence - An attacker modifies a document in a repository used by a Retrieval-Augmented Generation (RAG) application. When a user's query returns the modified content, the malicious instructions alter the LLM's output, generating misleading results. -#### Scenario #5: Code Injection - An attacker exploits a vulnerability (CVE-2024-5184) in an LLM-powered email assistant to inject malicious prompts, allowing access to sensitive information and manipulation of email content. -#### Scenario #6: Payload Splitting - An attacker uploads a resume with split malicious prompts. When an LLM is used to evaluate the candidate, the combined prompts manipulate the model's response, resulting in a positive recommendation despite the actual resume contents. -#### Scenario #7: Multimodal Injection - An attacker embeds a malicious prompt within an image that accompanies benign text. When a multimodal AI processes the image and text concurrently, the hidden prompt alters the model's behavior, potentially leading to unauthorized actions or disclosure of sensitive information. -#### Scenario #8: Adversarial Suffix - An attacker appends a seemingly meaningless string of characters to a prompt, which influences the LLM's output in a malicious way, bypassing safety measures. -#### Scenario #9: Multilingual/Obfuscated Attack - An attacker uses multiple languages or encodes malicious instructions (e.g., using Base64 or emojis) to evade filters and manipulate the LLM's behavior. - -### Reference Links +## LLM01:2025 プロンプトインジェクション + +### 説明 +プロンプトインジェクションの脆弱性とは、ユーザーが入力するプロンプトが、意図しない方法でLLM（大規模言語モデル）の動作や出力を変更してしまう場合に発生するものです。このような入力は、人間には認識できない場合でもモデルに影響を与える可能性があるため、プロンプトインジェクションが成立するために人間にとって可視的または読み取り可能である必要はありません。モデルがその内容を解析できれば十分となります。 + +プロンプトインジェクション脆弱性は、モデルがプロンプトを処理する方法や、入力がモデルに対してプロンプトデータを他の部分に誤って渡すよう強制する可能性がある場合に存在します。これにより、ガイドラインの違反、有害なコンテンツの生成、不正アクセスの許可、または重要な意思決定への影響が引き起こされる可能性があります。RAG（Retrieval Augmented Generation）やファインチューニングなどの技術は、LLMの出力をより適切かつ正確にすることを目的としていますが、研究によると、これらの手法はプロンプトインジェクションの脆弱性を完全には軽減できないことが示されています。 + +プロンプトインジェクションとジェイルブレイキングは、LLMセキュリティにおいて関連する概念ですが、しばしば同義として扱われます。プロンプトインジェクションは、特定の入力を通じてモデルの応答を操作し、その挙動を変化させるものであり、安全対策を回避することが含まれる場合があります。一方、ジェイルブレイキングは、プロンプトインジェクションの一形態であり、攻撃者がモデルに入力を提供し、それによってモデルが安全プロトコルを完全に無視するよう誘導するものです。開発者はシステムプロンプトや入力処理に安全対策を組み込むことでプロンプトインジェクション攻撃を軽減できますが、ジェイルブレイキングの効果的な防止には、モデルのトレーニングおよび安全メカニズムを継続的に更新する必要があります。 + +### プロンプトインジェクション脆弱性の種類 + +#### ダイレクトプロンプトインジェクション +プロンプトの直接入力は、ユーザーのプロンプト入力がモデルの動作を意図しないか予期しない方法で直接変更する場合に発生する。入力には、意図的なもの（悪意のある行為者が意図的にプロンプトを作成し、モデルを悪用する場合）と、意図的でないものユーザーが不注意に入力を行い、予期しない動作を引き起こす場合）がある。 + +#### インダイレクトプロンプトインジェクション +インダイレクトプロンプトインジェクションは、LLMがウェブサイトやファイルなどの外部ソースからの入力を受け入れるときに発生する。そのコンテンツは、外部コンテンツデータを持っている可能性があり、モデルの動作を意図しない、あるいは予期しない方法で変化させます。ダイレクトインジェクションと同様、インダイレクトインジェクションにも意図的なものと意図的でないものがあります。 + +プロンプトインジェクションが成功した場合の影響の重大性と性質は、ケースによって大きく異なる可能性があり、モデルに関連したビジネス的な文脈と、モデルが設計されたエージェンシーの両方に大きく依存します。しかし、一般的に、プロンプトインジェクションは、以下を含むがこれに限定されない、または予期せぬ結果につながる可能性があります： +- 機密情報の開示 +- AIシステムインフラやシステムプロンプトに関する機密情報の漏洩 +- 不正確または偏った出力につながるコンテンツ操作 +- LLMが利用可能な機能への不正アクセスを実施 +- 接続されたシステムで任意のコマンドを実行 +- 重要な意思決定プロセスを操作 + +複数のデータタイプを同時に処理するマルチモーダルAIの台頭は、独自のプロンプトインジェクションリスクをもたらす。悪意のある行為者は、良質のテキストに付随する画像に指示を隠すなど、モダリティ間の相互作用を悪用する可能性がある。このようなシステムの複雑さは、攻撃対象領域を拡大する。また、マルチモーダルモデルは、現在の技術では検出や軽減が困難な、新しいクロスモーダル攻撃の影響を受けやすい可能性がある。ロバストなマルチモーダル特有の防御は、さらなる研究開発のための重要な分野である。 + +### 防御と緩和の戦略 + +プロンプトインジェクションの脆弱性は、ジェネレーティブAIの性質上起こりうる。モデルの動作方法の中核に確率的な影響があることを考えると、プロンプト・インジェクションを防ぐ確実な方法があるかどうかは不明である。しかし、以下の対策はプロンプト・インジェクションの影響を軽減することができる： + +#### 1. モデルの動作を制約する +　システムプロンプト内でのモデルの役割、能力、制限について具体的な指示を与える。コンテキストの厳守を徹底し、特定のタスクやトピックに回答を限定し、中核となる指示を修正しようとする試みを無視するようモデルに指示する。 +#### 2. 期待される出力形式の定義と検証 +　明確な出力形式を指定し、詳細な理由とソースの引用を要求し、決定論的コードを使用してこれらの形式への準拠を検証する。 +#### 3. 入出力フィルタリングの実装 +　センシティブなカテゴリーを定義し、そのようなコンテンツを識別して処理するためのルールを構築する。セマンティックフィルタを適用し、文字列チェックを使用して許可されていないコンテンツをスキャンする。RAGトライアドを使用して回答を評価する：文脈の関連性、根拠、質問と回答の関連性を評価し、悪意のある可能性のある出力を特定する。 +#### 4. 権限制御と最小権限アクセスの強制 +　拡張可能な機能のためにアプリケーションに独自のAPIトークンを提供し、これらの機能をモデルに提供するのではなく、コードで処理する。モデルのアクセス権限を、意図した操作に必要な最小限のものに制限する。 +#### 5. リスクの高い行為には人間の承認が必要 +　権限のない操作を防止するために、特権操作に対してヒューマンインザループ・コントロールを導入する。 +#### 6. 外部コンテンツの分離と識別 +　信頼できないコンテンツを分離して明示し、ユーザーのプロンプトへの影響を制限する。 +#### 7. 敵対的テストと攻撃シミュレーションの実施 +　信頼境界とアクセス制御の有効性をテストするために、モデルを信頼されていないユーザーとして扱い、定期的な侵入テストと侵入シミュレーションを実施する。 + +### 攻撃シナリオの例 + +#### シナリオ #1: ダイレクトインジェクション +　攻撃者は、カスタマーサポートのチャットボットにプロンプトを注入し、以前のガイドラインを無視して個人データストアに問い合わせたり、電子メールを送信したりするよう指示し、不正アクセスや権限の昇格を引き起こす。 +#### シナリオ #2:インダイレクトインジェクション +　あるユーザーがLLMを使ってウェブページを要約すると、LLMがURLへのリンク画像を挿入し、プライベートな会話が流出する。 +#### シナリオ #3: 意図しないインジェクション +　ある企業が、AIが作成した応募書類を特定するための指示を職務経歴書に記載した。この指示を知らない応募者は、履歴書を最適化するためにLLMを使用し、不注意にもAIによる検出を引き起こしてしまう。 +#### シナリオ #4: 意図的なモデルの影響力 +　攻撃者は、RAG(Retrieval-Augmented Generation)アプリケーションで使用されるリポジトリ内の文書を改ざんする。ユーザーのクエリが変更されたコンテンツを返すと、悪意のある命令がLLMの出力を変更し、誤解を招く結果を生成する。 +#### シナリオ #5: コード・インジェクション +　攻撃者は、LLMを使用した電子メールアシスタントの脆弱性 (CVE-2024-5184) を悪用して悪意のあるプロンプトを挿入し、機密情報へのアクセスや電子メールコンテンツの操作を可能にします。 +#### シナリオ #6: ペイロードの分割 +　攻撃者は悪意のあるプロンプトを分割した履歴書をアップロードする。LLMが候補者の評価に使用された場合、プロンプトが組み合わされることでモデルの応答が操作され、実際の履歴書の内容とは裏腹に肯定的な推薦がなされる。 +#### シナリオ #7: マルチモーダル・インジェクション +　攻撃者は、悪意のあるプロンプトを、良性のテキストに付随する画像内に埋め込む。その際マルチモーダルAIが画像とテキストを同時に処理すると、隠されたプロンプトがモデルの行動を変化させ、不正な行動や機密情報の漏洩につながる可能性がある。 +#### シナリオ #8: 敵対的接尾辞 +　攻撃者は、一見無意味な文字列をプロンプトに追加し、LLMの出力に悪意のある影響を与え、安全対策を回避する。 +#### シナリオ #9: 多言語 / 難読化攻撃 +　攻撃者は、フィルターを回避し、LLMの動作を操作するために、複数の言語を使用したり、悪意のある命令をエンコードしたりする（Base64や絵文字を使用するなど）。 + +### 参考リンク 1. [ChatGPT Plugin Vulnerabilities - Chat with Code](https://embracethered.com/blog/posts/2023/chatgpt-plugin-vulns-chat-with-code/) **Embrace the Red** 2. [ChatGPT Cross Plugin Request Forgery and Prompt Injection](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./) **Embrace the Red** @@ -84,10 +82,12 @@ Prompt injection vulnerabilities are possible due to the nature of generative AI 14. [Universal and Transferable Adversarial Attacks on Aligned Language Models (arxiv.org)](https://arxiv.org/abs/2307.15043) 15. [From ChatGPT to ThreatGPT: Impact of Generative AI in Cybersecurity and Privacy (arxiv.org)](https://arxiv.org/abs/2307.00691) -### Related Frameworks and Taxonomies -Refer to this section for comprehensive information, scenarios strategies relating to infrastructure deployment, applied environment controls and other best practices. +### 関連フレームワークと分類 + +インフラ配備に関する包括的な情報、シナリオ戦略、適用される環境管理、その他の +ベストプラクティスについては、以下のセクションを参照してください。 - [AML.T0051.000 - LLM Prompt Injection: Direct](https://atlas.mitre.org/techniques/AML.T0051.000) **MITRE ATLAS** - [AML.T0051.001 - LLM Prompt Injection: Indirect](https://atlas.mitre.org/techniques/AML.T0051.001) **MITRE ATLAS** -- [AML.T0054 - LLM Jailbreak Injection: Direct](https://atlas.mitre.org/techniques/AML.T0054) **MITRE ATLAS** +- [AML.T0054 - LLM Jailbreak Injection: Direct](https://atlas.mitre.org/techniques/AML.T0054) **MITRE ATLAS**　 diff --git a/LLM02_SensitiveInformationDisclosure.md b/LLM02_SensitiveInformationDisclosure.md index f2260fb..5f6e93b 100644 --- a/LLM02_SensitiveInformationDisclosure.md +++ b/LLM02_SensitiveInformationDisclosure.md @@ -1,77 +1,77 @@ -## LLM02:2025 Sensitive Information Disclosure +## LLM02:2025 機密情報の開示 -### Description +### 説明 -Sensitive information can affect both the LLM and its application context. This includes personal identifiable information (PII), financial details, health records, confidential business data, security credentials, and legal documents. Proprietary models may also have unique training methods and source code considered sensitive, especially in closed or foundation models. +機密情報は、LLMとその申請状況の両方に影響を及ぼす可能性があります。これには、個人を特定できる情報（PII）、財務情報、健康記録、ビジネス上の機密データ、セキュリティ証明書、法的文書などが含まれます。専有モデルには、特にクローズドモデルやファウンデーションモデルにおいて、センシティブとみなされる独自のトレーニング方法やソースコードがある場合もあります。 -LLMs, especially when embedded in applications, risk exposing sensitive data, proprietary algorithms, or confidential details through their output. This can result in unauthorized data access, privacy violations, and intellectual property breaches. Consumers should be aware of how to interact safely with LLMs. They need to understand the risks of unintentionally providing sensitive data, which may later be disclosed in the model's output. +LLMは、特にアプリケーションに組み込まれた場合、その出力によって機密データ、独自のアルゴリズム、機密事項詳細が漏洩する危険性があります。これは、不正なデータアクセス、プライバシー侵害、知的財産侵害を引き起こす可能性があります。消費者は、LLMと安全にやりとりする方法を知っておく必要があります。消費者は、意図せずに機密データを提供し、それが後にモデルの出力で開示されるリスクを理解する必要があります。 -To reduce this risk, LLM applications should perform adequate data sanitization to prevent user data from entering the training model. Application owners should also provide clear Terms of Use policies, allowing users to opt out of having their data included in the training model. Adding restrictions within the system prompt about data types that the LLM should return can provide mitigation against sensitive information disclosure. However, such restrictions may not always be honored and could be bypassed via prompt injection or other methods. +このリスクを減らすために、LLMアプリケーションは適切なデータサニタイズを行い、ユーザーデータがトレーニングモデルに入るのを防ぐ必要があります。アプリケーションの所有者はまた、明確な利用規約を提供し、ユーザーが自分のデータがトレーニングモデルに含まれることを拒否できるようにする必要があります。LLMが返すべきデータ型に関する制限をシステムプロンプト内に追加することで、機密情報の漏洩を緩和することができます。しかし、そのような制限は常に守られるとは限らず、プロンプトインジェクションや他の方法によってバイパスされる可能性があります。 -### Common Examples of Vulnerability +### 脆弱性の一般的な例 -#### 1. PII Leakage - Personal identifiable information (PII) may be disclosed during interactions with the LLM. -#### 2. Proprietary Algorithm Exposure - Poorly configured model outputs can reveal proprietary algorithms or data. Revealing training data can expose models to inversion attacks, where attackers extract sensitive information or reconstruct inputs. For instance, as demonstrated in the 'Proof Pudding' attack (CVE-2019-20634), disclosed training data facilitated model extraction and inversion, allowing attackers to circumvent security controls in machine learning algorithms and bypass email filters. -#### 3. Sensitive Business Data Disclosure - Generated responses might inadvertently include confidential business information. +#### 1. 個人情報漏洩 +　個人を特定できる情報（PII）は、LLMとのやり取りの中で開示されることがある。 +#### 2. 独自のアルゴリズムによる露出 +　モデル出力の設定が不十分だと、独自のアルゴリズムやデータが漏洩する可能性がある。トレーニングデータの開示は、攻撃者が機密情報を抽出したり入力を再構築したりする反転攻撃にモデルをさらす可能性がある。例えば、「Proof Pudding」攻撃（CVE-2019- 20634）で実証されたように、開示されたトレーニングデータはモデルの抽出と反転を容易にし、攻撃者が機械学習アルゴリズムのセキュリティ制御を回避し、電子メールフィルターをバイパスすることを可能にする。 +#### 3. 機密業務データの開示 +　生成された回答には、不注意で企業機密情報が含まれる可能性がある。 -### Prevention and Mitigation Strategies +### 予防と緩和の戦略 -###@ Sanitization: +###@ サニタイゼーション: -#### 1. Integrate Data Sanitization Techniques - Implement data sanitization to prevent user data from entering the training model. This includes scrubbing or masking sensitive content before it is used in training. -#### 2. Robust Input Validation - Apply strict input validation methods to detect and filter out potentially harmful or sensitive data inputs, ensuring they do not compromise the model. +#### 1. データサニタイゼーション技術の統合 +　ユーザーデータがトレーニングモデルに入るのを防ぐために、データのサニタイゼーションを実施する。これには、トレーニングで使用する前に、機密性の高いコンテンツをスクラブまたはマスキングすることが含まれます。 +#### 2. ロバストな入力検証 +　厳密な入力検証方法を適用し、有害または機密の可能性があるデータ入力を検出してフィルタリングし、モデルを危険にさらすことがないようにする。 -###@ Access Controls: +###@ アクセスコントロール: -#### 1. Enforce Strict Access Controls - Limit access to sensitive data based on the principle of least privilege. Only grant access to data that is necessary for the specific user or process. -#### 2. Restrict Data Sources - Limit model access to external data sources, and ensure runtime data orchestration is securely managed to avoid unintended data leakage. +#### 1. 厳格なアクセス制御の実施 +　最小特権の原則に基づき、機密データへのアクセスを制限する。特定のユーザーまたはプロセスに必要なデータのみにアクセスを許可する。 +#### 2. データ利用の透明性の確保 +　データの保持、使用、削除に関する明確なポリシーを維持する。ユーザが自分のデータがトレーニングプロセスに含まれることをオプトアウトできるようにする。 -###@ Federated Learning and Privacy Techniques: +###@ 統合した学習とプライバシー技術: -#### 1. Utilize Federated Learning - Train models using decentralized data stored across multiple servers or devices. This approach minimizes the need for centralized data collection and reduces exposure risks. -#### 2. Incorporate Differential Privacy - Apply techniques that add noise to the data or outputs, making it difficult for attackers to reverse-engineer individual data points. +#### 1. 統合した学習の活用 +複数のサーバーやデバイスに分散して保存されたデータを使用してモデルをトレーニングする。このアプローチにより、中央集権的なデータ収集の必要性を最小限に抑え、暴露リスクを低減する。 +#### 2. 差別化されたプライバシー +データや出力にノイズを加え、攻撃者が個々のデータポイントをリバースエンジニアリングすることを困難にする技術を適用する。 -###@ User Education and Transparency: +###@ ユーザー教育と透明性: -#### 1. Educate Users on Safe LLM Usage - Provide guidance on avoiding the input of sensitive information. Offer training on best practices for interacting with LLMs securely. -#### 2. Ensure Transparency in Data Usage - Maintain clear policies about data retention, usage, and deletion. Allow users to opt out of having their data included in training processes. +#### 1.LLMの安全な使用についてユーザーを教育する +機密情報の入力を避けるためのガイダンスを提供する。LLMと安全にやりとりするためのベストプラクティスに関する研修を提供する。 +#### 2. データ利用の透明性の確保 +データの保持、使用、削除に関する明確なポリシーを維持する。ユーザが自分のデータがトレーニングプロセスに含まれることをオプトアウトできるようにする。 -###@ Secure System Configuration: +###@ 安全なシステム構成: -#### 1. Conceal System Preamble - Limit the ability for users to override or access the system's initial settings, reducing the risk of exposure to internal configurations. -#### 2. Reference Security Misconfiguration Best Practices - Follow guidelines like "OWASP API8:2023 Security Misconfiguration" to prevent leaking sensitive information through error messages or configuration details. - (Ref. link:[OWASP API8:2023 Security Misconfiguration](https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/)) +#### 1. コンシールシステム 前文 +　ユーザーがシステムの初期設定を上書きしたり、アクセスしたりすることを制限し、内部設定にさらされるリスクを低減する。 +#### 2. 参考 セキュリティの誤設定のベストプラクティス +　「OWASP API8:2023 Security Misconfiguration」のようなガイドラインに従って、エラーメッセージや設定の詳細から機密情報が漏れるのを防いでください。 + (参考リンク:[OWASP API8:2023 Security Misconfiguration](https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/)) -###@ Advanced Techniques: +###@ 高度なテクニック: -#### 1. Homomorphic Encryption - Use homomorphic encryption to enable secure data analysis and privacy-preserving machine learning. This ensures data remains confidential while being processed by the model. -#### 2. Tokenization and Redaction - Implement tokenization to preprocess and sanitize sensitive information. Techniques like pattern matching can detect and redact confidential content before processing. +#### 1. 同じ形の暗号 +　セキュアなデータ分析とプライバシー保護された機械学習を可能にするために、同じ形の暗号化を使用します。これにより、モデルによって処理されている間、データの機密性が保たれる。 +#### 2. トークン化と再編集 +トークン化を導入し、機密情報を前処理してサニタイズする。パターンマッチングのような技術は、処理前に機密コンテンツを検出し、再編集することができます。 -### Example Attack Scenarios +### 攻撃シナリオの例 -#### Scenario #1: Unintentional Data Exposure - A user receives a response containing another user's personal data due to inadequate data sanitization. -#### Scenario #2: Targeted Prompt Injection - An attacker bypasses input filters to extract sensitive information. -#### Scenario #3: Data Leak via Training Data - Negligent data inclusion in training leads to sensitive information disclosure. +#### シナリオ #1: 意図しないデータ露出 +　データのサニタイズが不十分なため、他のユーザーの個人データを含む応答をユーザーが受信する。 +#### シナリオ #2: 狙い撃ちのプロンプトインジェクション +　攻撃者は入力フィルタを迂回して機密情報を引き出す。 +#### シナリオ #3: トレーニングデータによるデータ漏洩 +　トレーニングへのデータ組み込みを怠ると、機密情報の漏洩につながる。 -### Reference Links +### 参考リンク 1. [Lessons learned from ChatGPT’s Samsung leak](https://cybernews.com/security/chatgpt-samsung-leak-explained-lessons/): **Cybernews** 2. [AI data leak crisis: New tool prevents company secrets from being fed to ChatGPT](https://www.foxbusiness.com/politics/ai-data-leak-crisis-prevent-company-secrets-chatgpt): **Fox Business** @@ -79,9 +79,9 @@ To reduce this risk, LLM applications should perform adequate data sanitization 4. [Using Differential Privacy to Build Secure Models](https://neptune.ai/blog/using-differential-privacy-to-build-secure-models-tools-methods-best-practices): **Neptune Blog** 5. [Proof Pudding (CVE-2019-20634)](https://avidml.org/database/avid-2023-v009/) **AVID** (`moohax` & `monoxgas`) -### Related Frameworks and Taxonomies +### 関連フレームワークと分類 -Refer to this section for comprehensive information, scenarios strategies relating to infrastructure deployment, applied environment controls and other best practices. +インフラ配備に関する包括的な情報、シナリオ戦略、適用される環境管理、その他のベストプラクティスについては、以下のセクションを参照してください。 - [AML.T0024.000 - Infer Training Data Membership](https://atlas.mitre.org/techniques/AML.T0024.000) **MITRE ATLAS** - [AML.T0024.001 - Invert ML Model](https://atlas.mitre.org/techniques/AML.T0024.001) **MITRE ATLAS** diff --git a/LLM03_SupplyChain.md b/LLM03_SupplyChain.md index 3b9e739..e2ee122 100644 --- a/LLM03_SupplyChain.md +++ b/LLM03_SupplyChain.md @@ -1,84 +1,83 @@ -## LLM03:2025 Supply Chain - -### Description - -LLM supply chains are susceptible to various vulnerabilities, which can affect the integrity of training data, models, and deployment platforms. These risks can result in biased outputs, security breaches, or system failures. While traditional software vulnerabilities focus on issues like code flaws and dependencies, in ML the risks also extend to third-party pre-trained models and data. - -These external elements can be manipulated through tampering or poisoning attacks. - -Creating LLMs is a specialized task that often depends on third-party models. The rise of open-access LLMs and new fine-tuning methods like "LoRA" (Low-Rank Adaptation) and "PEFT" (Parameter-Efficient Fine-Tuning), especially on platforms like Hugging Face, introduce new supply-chain risks. Finally, the emergence of on-device LLMs increase the attack surface and supply-chain risks for LLM applications. - -Some of the risks discussed here are also discussed in "LLM04 Data and Model Poisoning." This entry focuses on the supply-chain aspect of the risks. -A simple threat model can be found [here](https://github.com/jsotiro/ThreatModels/blob/main/LLM%20Threats-LLM%20Supply%20Chain.png). - -### Common Examples of Risks - -#### 1. Traditional Third-party Package Vulnerabilities - Such as outdated or deprecated components, which attackers can exploit to compromise LLM applications. This is similar to "A06:2021 – Vulnerable and Outdated Components" with increased risks when components are used during model development or finetuning. - (Ref. link: [A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)) -#### 2. Licensing Risks - AI development often involves diverse software and dataset licenses, creating risks if not properly managed. Different open-source and proprietary licenses impose varying legal requirements. Dataset licenses may restrict usage, distribution, or commercialization. -#### 3. Outdated or Deprecated Models - Using outdated or deprecated models that are no longer maintained leads to security issues. -#### 4. Vulnerable Pre-Trained Model - Models are binary black boxes and unlike open source, static inspection can offer little to security assurances. Vulnerable pre-trained models can contain hidden biases, backdoors, or other malicious features that have not been identified through the safety evaluations of model repository. Vulnerable models can be created by both poisoned datasets and direct model tampering using tehcniques such as ROME also known as lobotomisation. -#### 5. Weak Model Provenance - Currently there are no strong provenance assurances in published models. Model Cards and associated documentation provide model information and relied upon users, but they offer no guarantees on the origin of the model. An attacker can compromise supplier account on a model repo or create a similar one and combine it with social engineering techniques to compromise the supply-chain of an LLM application. -#### 6. Vulnerable LoRA adapters - LoRA is a popular fine-tuning technique that enhances modularity by allowing pre-trained layers to be bolted onto an existing LLM. The method increases efficiency but create new risks, where a malicious LorA adapter compromises the integrity and security of the pre-trained base model. This can happen both in collaborative model merge environments but also exploiting the support for LoRA from popular inference deployment platforms such as vLMM and OpenLLM where adapters can be downloaded and applied to a deployed model. -#### 7. Exploit Collaborative Development Processes - Collaborative model merge and model handling services (e.g. conversions) hosted in shared environments can be exploited to introduce vulnerabilities in shared models. Model merging is is very popular on Hugging Face with model-merged models topping the OpenLLM leaderboard and can be exploited to bypass reviews. Similarly, services such as conversation bot have been proved to be vulnerable to maniputalion and introduce malicious code in models. -#### 8. LLM Model on Device supply-chain vulnerabilities - LLM models on device increase the supply attack surface with compromised manufactured processes and exploitation of device OS or fimware vulnerabilities to compromise models. Attackers can reverse engineer and re-package applications with tampered models. -#### 9. Unclear T&Cs and Data Privacy Policies - Unclear T&Cs and data privacy policies of the model operators lead to the application's sensitive data being used for model training and subsequent sensitive information exposure. This may also apply to risks from using copyrighted material by the model supplier. - -### Prevention and Mitigation Strategies - -1. Carefully vet data sources and suppliers, including T&Cs and their privacy policies, only using trusted suppliers. Regularly review and audit supplier Security and Access, ensuring no changes in their security posture or T&Cs. -2. Understand and apply the mitigations found in the OWASP Top Ten's "A06:2021 – Vulnerable and Outdated Components." This includes vulnerability scanning, management, and patching components. For development environments with access to sensitive data, apply these controls in those environments, too. - (Ref. link: [A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)) -3. Apply comprehensive AI Red Teaming and Evaluations when selecting a third party model. Decoding Trust is an example of a Trustworthy AI benchmark for LLMs but models can finetuned to by pass published benchmarks. Use extensive AI Red Teaming to evaluate the model, especially in the use cases you are planning to use the model for. -4. Maintain an up-to-date inventory of components using a Software Bill of Materials (SBOM) to ensure you have an up-to-date, accurate, and signed inventory, preventing tampering with deployed packages. SBOMs can be used to detect and alert for new, zero-date vulnerabilities quickly. AI BOMs and ML SBOMs are an emerging area and you should evaluate options starting with OWASP CycloneDX -5. To mitigate AI licensing risks, create an inventory of all types of licenses involved using BOMs and conduct regular audits of all software, tools, and datasets, ensuring compliance and transparency through BOMs. Use automated license management tools for real-time monitoring and train teams on licensing models. Maintain detailed licensing documentation in BOMs. -6. Only use models from verifiable sources and use third-party model integrity checks with signing and file hashes to compensate for the lack of strong model provenance. Similarly, use code signing for externally supplied code. -7. Implement strict monitoring and auditing practices for collaborative model development environments to prevent and quickly detect any abuse. "HuggingFace SF_Convertbot Scanner" is an example of automated scripts to use. - (Ref. link: [HuggingFace SF_Convertbot Scanner](https://gist.github.com/rossja/d84a93e5c6b8dd2d4a538aa010b29163)) -8. Anomaly detection and adversarial robustness tests on supplied models and data can help detect tampering and poisoning as discussed in "LLM04 Data and Model Poisoning; ideally, this should be part of MLOps and LLM pipelines; however, these are emerging techniques and may be easier to implement as part of red teaming exercises. -9. Implement a patching policy to mitigate vulnerable or outdated components. Ensure the application relies on a maintained version of APIs and underlying model. -10. Encrypt models deployed at AI edge with integrity checks and use vendor attestation APIs to prevent tampered apps and models and terminate applications of unrecognized firmware. - -### Sample Attack Scenarios - -#### Scenario #1: Vulnerable Python Library - An attacker exploits a vulnerable Python library to compromise an LLM app. This happened in the first Open AI data breach. Attacks on the PyPi package registry tricked model developers into downloading a compromised PyTorch dependency with malware in a model development environment. A more sophisticated example of this type of attack is Shadow Ray attack on the Ray AI framework used by many vendors to manage AI infrastructure. In this attack, five vulnerabilities are believed to have been exploited in the wild affecting many servers. -#### Scenario #2: Direct Tampering - Direct Tampering and publishing a model to spread misinformation. This is an actual attack with PoisonGPT bypassing Hugging Face safety features by directly changing model parameters. -#### Scenario #3: Finetuning Popular Model - An attacker finetunes a popular open access model to remove key safety features and perform high in a specific domain (insurance). The model is finetuned to score highly on safety benchmarks but has very targeted triggers. They deploy it on Hugging Face for victims to use it exploiting their trust on benchmark assurances. -#### Scenario #4: Pre-Trained Models - An LLM system deploys pre-trained models from a widely used repository without thorough verification. A compromised model introduces malicious code, causing biased outputs in certain contexts and leading to harmful or manipulated outcomes -#### Scenario #5: Compromised Third-Party Supplier - A compromised third-party supplier provides a vulnerable LorA adapter that is being merged to an LLM using model merge on Hugging Face. -#### Scenario #6: Supplier Infiltration - An attacker infiltrates a third-party supplier and compromises the production of a LoRA (Low-Rank Adaptation) adapter intended for integration with an on-device LLM deployed using frameworks like vLLM or OpenLLM. The compromised LoRA adapter is subtly altered to include hidden vulnerabilities and malicious code. Once this adapter is merged with the LLM, it provides the attacker with a covert entry point into the system. The malicious code can activate during model operations, allowing the attacker to manipulate the LLM’s outputs. -#### Scenario #7: CloudBorne and CloudJacking Attacks - These attacks target cloud infrastructures, leveraging shared resources and vulnerabilities in the virtualization layers. CloudBorne involves exploiting firmware vulnerabilities in shared cloud environments, compromising the physical servers hosting virtual instances. CloudJacking refers to malicious control or misuse of cloud instances, potentially leading to unauthorized access to critical LLM deployment platforms. Both attacks represent significant risks for supply chains reliant on cloud-based ML models, as compromised environments could expose sensitive data or facilitate further attacks. -#### Scenario #8: LeftOvers (CVE-2023-4969) - LeftOvers exploitation of leaked GPU local memory to recover sensitive data. An attacker can use this attack to exfiltrate sensitive data in production servers and development workstations or laptops. -#### Scenario #9: WizardLM - Following the removal of WizardLM, an attacker exploits the interest in this model and publish a fake version of the model with the same name but containing malware and backdoors. -#### Scenario #10: Model Merge/Format Conversion Service - An attacker stages an attack with a model merge or format conversation service to compromise a publicly available access model to inject malware. This is an actual attack published by vendor HiddenLayer. -#### Scenario #11: Reverse-Engineer Mobile App - An attacker reverse-engineers an mobile app to replace the model with a tampered version that leads the user to scam sites. Users are encouraged to dowload the app directly via social engineering techniques. This is a "real attack on predictive AI" that affected 116 Google Play apps including popular security and safety-critical applications used for as cash recognition, parental control, face authentication, and financial service. - (Ref. link: [real attack on predictive AI](https://arxiv.org/abs/2006.08131)) -#### Scenario #12: Dataset Poisoning - An attacker poisons publicly available datasets to help create a back door when fine-tuning models. The back door subtly favors certain companies in different markets. -#### Scenario #13: T&Cs and Privacy Policy - An LLM operator changes its T&Cs and Privacy Policy to require an explicit opt out from using application data for model training, leading to the memorization of sensitive data. - -### Reference Links +## LLM03:2025 サプライチェーン + +### 説明 + +LLMのサプライチェーンは様々な脆弱性の影響を受けやすく、トレーニングデータ、モデル、展開プラットフォームの完全性に影響を与える可能性があります。これらのリスクは、偏った出力、セキュリティ侵害、システム障害を引き起こす可能性があります。従来のソフトウェアの脆弱性は、コードの欠陥や依存性のような問題に焦点を当てているが、MLでは、リスクはサードパーティの事前訓練されたモデルやデータにも及びます。 + +これらの外部要素は、改ざんやポイズニング攻撃によって操作される可能性があります。 + +LLMの作成は専門的な作業であり、サードパーティのモデルに依存することが多くなります。オープンアクセスLLMの台頭や、「LoRA」（ Low-Rank Adaptation） や「PEFT 」（Parameter-Efficient Fine-Tuning）のような新しい微調整手法、特にHugging Faceのようなプラットフォームでは、新たなサプライチェーンリスクをもたらしています。最後に、オンデバイスLLMの出現は、LLMアプリケーションの攻撃対象とサプライチェーンリスクを増加させます。 + +ここで論じられているリスクのいくつかは、「LLM04 データとモデルポイズニング 」でも論じられています。このエントリーでは、リスクのサプライチェーンの側面に焦点を当てている。簡単な脅威のモデルはこちらで見ることができます。(https://github.com/jsotiro/ThreatModels/blob/main/LLM%20Threats-LLM%20Supply%20Chain.png) + +### よくあるリスクの例 + +#### 1. 従来のサードパーティ製パッケージの脆弱性 +例えば、攻撃者がLLMアプリケーションを侵害するために悪用することができる、古いコンポーネントや非推奨のコンポーネントなどです。これは "A06:2021 - 脆弱で時代遅れのコンポーネント "と類似しており、モデルの開発中や微調整中にコンポーネントが使用された場合にリスクが高まる。 +(参考リンク：A06:2021 - 脆弱で時代遅れの部品(https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)) +#### 2. ライセンスのリスク +AI開発には多様なソフトウェアやデータセットのライセンスが含まれることが多く、適切に管理されなければリスクが生じる。オープンソースやプロプライエタリ・ライセンスによって、法的要件は異なる。データセット・ライセンスは、使用、配布、商業化を制限する場合がある。 +#### 3. 旧式または非推奨モデル +もはや保守されていない古いモデルや非推奨のモデルを使うことは、セキュリティ上の問題を引き起こす。 +#### 4. 脆弱な事前訓練モデル +モデルはバイナリー・ブラックボックスであり、オープンソースとは異なり、静的検査ではセキュリティの保証はほとんどできない。脆弱な事前学習済みモデルには、モデルリポジトリの安全性評価では特定されなかった、隠れたバイアス、バックドア、その他の悪意のある機能が含まれている可能性がある。脆弱なモデルは、汚染されたデータセットと、ロボトミゼーションとしても知られるROMEのような技術を使った直接的なモデル改ざんの両方によって作成される可能性がある。 +#### 5. 弱いモデル証明 +現在、公表されているモデルには、出所を保証する強力なものはない。モデルカードと関連文書はモデル情報を提供し、ユーザーに依存しているが、モデルの出所を保証するものではない。攻撃者は、モデルレポのサプライヤアカウントを侵害したり、類似のアカウントを作成し、ソーシャルエンジニアリング技術と組み合わせることで、LLM アプリケーションのサプライチェーンを侵害することができる。 +#### 6. 脆弱なLoRAアダプタ +LoRAは、既存のLLMに事前に訓練されたレイヤーをボルトで固定することで、モジュール性を強化する一般的な微調整技術である。この方法は効率を高めるが、悪意のあるLorAアダプターが事前に訓練されたベースモデルの完全性とセキュリティを損なうという新たなリスクを生み出す。このような事態は、協調モデルマージ環境でも起こりうるが、vLMMやOpenLLMのような一般的な推論デプロイメントプラットフォームがLoRAをサポートしており、アダプタをダウンロードしてデプロイされたモデルに適用できることを悪用することもできる。 +#### 7. 共同開発プロセスの活用 +共有環境でホストされている協調的なモデルマージやモデル処理サービス（変換など）は、共有モデルに脆弱性を導入するために悪用される可能性がある。モデルマージはHugging Faceで非常に人気があり、モデルマージされたモデルはOpenLLMリーダーボードの上位を占めている。同様に、会話ボットのようなサービスは、マニピュタリオンに対して脆弱であり、モデルに悪意のあるコードを導入することが証明されている。 +#### 8. デバイスのサプライチェーンの脆弱性に関するLLMモデル +デバイス上のLLMモデルは、侵害された製造プロセスや、デバイスOSやFimwareの脆弱性を悪用してモデルを侵害することで、攻撃対象領域を拡大する。攻撃者はリバースエンジニアリングを行い、改ざんされたモデルでアプリケーションを再パッケージ化することができる。 +#### 9. 不明瞭なT&Cとデータ・プライバシー・ポリシー +モデル運営者のT&Cやデータプライバシーポリシーが不明確なため、アプリケーションの機密データがモデルのトレーニングに使用され、機密情報が暴露される。これは、モデル供給者が著作権で保護された素材を使用することによるリスクにも当てはまる。 + +### 予防と緩和の戦略 + +1. 信頼できるサプライヤーのみを使用し、T&C やプライバシ ーポリシーを含め、データソースやサプライヤーを注意深く吟味する。サプライヤーのセキュリティとアクセスを定期的に見直し、監査し、セキュリティ態勢やT&Cに変更がないことを確認する。 +2. OWASP TOP10の「A06:2021 - 脆弱性および時代遅れのコンポーネント」にある緩和策を理解し、適用する。これには、脆弱性スキャン、管理、パッチ適用コンポーネントが含まれる。機密データにアクセスできる開発環境についても、これらの管理を適用する。 + (参考リンク: [A06:2021 – 脆弱性および時代遅れのコンポーネント](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)) +3. サードパーティのモデルを選択する際には、包括的なAIのレッドチームと評価を適用する。Decoding TrustはLLMのための信頼できるAIベンチマークの一例ですが、モデルは公表されているベンチマークをパスするように微調整することができます。特にモデルを使用する予定のユースケースにおいて、モデルを評価するために広範なAIレッドチーミングを使用する。 +4. ソフトウェア部品表（SBOM）を使用してコンポーネントの最新インベントリを管理することで、配備済みパッケージの改ざんを防止し、最新かつ正確な署名付きインベントリを確保できます。SBOMは、新しいゼロデイ脆弱性を迅速に検出し、警告するために使用できる。AI BOMとML SBOMは新しい分野であり、OWASP CycloneDXを始めとするオプションを評価する必要がある。 +5. AI ライセンスのリスクを軽減するには、BOM を使用して関係するすべてのタイプのライセンスのインベントリを作成し、すべてのソフトウェア、ツール、およびデータセットの定期的な監査を実施して、BOM によるコンプライアンスと透明性を確保する。リアルタイムのモニタリングに自動ライセンス管理ツールを使用し、ライセンスモデルについてチームをトレーニングする。BOM で詳細なライセンス文書を維持する。 +6. 検証可能なソースからのモデルのみを使用し、強力なモデルの出所の欠如を補うために、署名とファイル・ハッシュによるサード・パーティのモデル完全性チェックを使用する。同様に、外部から提供されたコードにはコード署名を使用する。 +7. 共同モデル開発環境に対して厳格な監視と監査を実施し、不正使用を防止し、迅速に検出する。"HuggingFace SF_Convertbot Scanner "は、使用する自動化スクリプトの一例です。 +(参考リンク： [HuggingFace SF_Convertbot Scanner](https://gist.github.com/rossja/d84a93e5c6b8dd2d4a538aa010b29163)) +8. 理想的には、これはMLOpsとLLMパイプラインの一部であるべきだが、これらは新しい技術であり、レッドチーム演習の一部として実施する方が簡単かもしれない。 +9. 脆弱なコンポーネントや古くなったコンポーネントを緩和するためのパッチ適用ポリシーを導入する。アプリケーションが、維持されているバージョンの API と基礎モデルに依存していることを確認する。 +10. AI エッジにデプロイされたモデルを完全性チェックで暗号化し、ベンダー認証 API を使用して、改ざんされたアプリやモデルを防止し、認識できないファームウェアのアプリケーショ ンを終了させる。 + +### 攻撃シナリオ例 + +#### シナリオ #1: 脆弱なPythonライブラリ +攻撃者が脆弱なPythonライブラリを悪用してLLMアプリを侵害。これは最初のOpen AIデータ侵害で起きた。PyPiパッケージのレジストリに対する攻撃により、モデル開発者はマルウェアを含む危険なPyTorchの依存関係をモデル開発環境にダウンロードさせられた。この種の攻撃のより洗練された例として、Shadowがある。AIインフラを管理するために多くのベンダーが使用しているRay AIフレームワークに対するRay攻撃。この攻撃では、5つの脆弱性が悪用され、多くのサーバーに影響を与えたと考えられている。 +#### シナリオ #2: 直接的な改ざん +直接的な改ざんと、誤った情報を広めるためのモデルの公開。これは、PoisonGPTがモデルのパラメータを直接変更することで、Hugging Faceの安全機能をバイパスする実際の攻撃。 +#### シナリオ #3: 一般的なモデルの微調整 +攻撃者は、主要な安全機能を削除し、特定の領域（保険）で高い性能を発揮するよう、一般的なオープンアクセスモデルを微調整する。このモデルは安全性ベンチマークで高得点を取るように微調整されているが、非常に標的を絞ったトリガーを持っています。攻撃者はそれをHugging Faceに展開し、被害者がベンチマークの保証に対する信頼を悪用して使用するように仕向ける。 +#### シナリオ #4: 事前に訓練されたモデル +LLMシステムは、徹底的に検証することなく、広く使われているリポジトリから事前に訓練されたモデルを導入する。侵害されたモデルは悪意のあるコードを導入し、特定のコンテキストで偏った出力を引き起こし、有害な結果や操作された結果につながる。 +#### シナリオ #5: 危殆化した第三者サプライヤー +危殆化したサードパーティサプライヤが脆弱なLorAアダプタを提供し、それがHugging Faceのモデルマージを使用してLLMにマージされている。 +#### シナリオ #6: サプライヤーの浸透 +攻撃者はサードパーティのサプライヤに侵入し、vLLMやOpenLLMのようなフレームワークを使用して展開されるオンデバイスLLMとの統合を目的としたLoRA（Low-Rank Adaptation）アダプタの製造を侵害する。侵害されたLoRAアダプターは、隠された脆弱性と悪意のあるコードを含むように微妙に変更されている。このアダプタがLLMにマージされると、攻撃者にシステムへの秘密のエントリーポイントを提供する。悪意のあるコードはモデル動作中に起動し、攻撃者はLLMの出力を操作することができる。 +#### シナリオ #7: クラウドボーン攻撃とクラウドジャッキング攻撃 +これらの攻撃はクラウド・インフラを標的とし、共有リソースや仮想化レイヤーの脆弱性を活用する。CloudBorneは、共有クラウド環境のファームウェアの脆弱性を悪用し、仮想インスタンスをホストする物理サーバーを侵害する。クラウドジャッキングは、クラウドインスタンスの悪意ある制御や悪用を指し、重要なLLM展開プラットフォームへの不正アクセスにつながる可能性がある。どちらの攻撃も、クラウドベースのMLモデルに依存しているサプライチェーンにとっては重大なリスクであり、侵害された環境が機密データを暴露したり、さらなる攻撃を容易にしたりする可能性がある。 +#### シナリオ #8 :LeftOvers（CVE-2023-4969） +LeftOversは、リークしたGPUローカルメモリを悪用して機密データを復元する。攻撃者はこの攻撃を利用して、本番用サーバーや開発用ワークステーション、ノートパソコン内の機密データを流出させることができる。 +#### シナリオ #9: WizardLM +WizardLMの削除後、攻撃者はこのモデルへの関心を悪用し、同じ名前でマルウェアやバックドアを含む偽バージョンを公開する。 +#### シナリオ #10: モデルマージ/フォーマット変換サービス +攻撃者は、マルウェアを注入するために一般に公開されているアクセスモデルを侵害するために、モデルマージやフォーマット会話サービスを使って攻撃を仕掛ける。これは、ベンダーであるHiddenLayerが公開している実際の攻撃。 +#### シナリオ #11: リバースエンジニア・モバイルアプリ +攻撃者はモバイルアプリをリバースエンジニアリングし、ユーザーを詐欺サイトへ誘導する改ざんされたバージョンに置き換える。ユーザーはソーシャル・エンジニアリングの手法でアプリを直接ダウンロードするよう促される。これは「予測AIに対する本物の攻撃」であり、現金認識、ペアレンタルコントロール、顔認証、金融サービスなどに使用される人気のセキュリティおよびセーフティ・クリティカルなアプリケーションを含む116のGoogle Playアプリに影響を与えた。 + (参考リンク: [予測AIへの真の攻撃](https://arxiv.org/abs/2006.08131)) +#### シナリオb#12: データセット・ポイズニング +攻撃者は、モデルを微調整する際にバックドアを作成するために、一般に入手可能なデータセットを汚染する。バックドアは、異なる市場において特定の企業を微妙に優遇する。 +#### シナリオ #13: 利用規約とプライバシーポリシー +あるLLM事業者がT&Cとプライバシーポリシーを変更し、モデルトレーニングにアプリケーションデータを使用しないよう明示的なオプトアウトを要求したため、機密データが記憶されることになった。 + +### 参考リンク 1. [PoisonGPT: How we hid a lobotomized LLM on Hugging Face to spread fake news](https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news) 2. [Large Language Models On-Device with MediaPipe and TensorFlow Lite](https://developers.googleblog.com/en/large-language-models-on-device-with-mediapipe-and-tensorflow-lite/) @@ -91,8 +90,9 @@ A simple threat model can be found [here](https://github.com/jsotiro/ThreatModel 9. [Thousands of servers hacked due to insecurely deployed Ray AI framework](https://www.csoonline.com/article/2075540/thousands-of-servers-hacked-due-to-insecurely-deployed-ray-ai-framework.html) 10. [LeftoverLocals: Listening to LLM responses through leaked GPU local memory](https://blog.trailofbits.com/2024/01/16/leftoverlocals-listening-to-llm-responses-through-leaked-gpu-local-memory/) -### Related Frameworks and Taxonomies +### 関連フレームワークと分類 -Refer to this section for comprehensive information, scenarios strategies relating to infrastructure deployment, applied environment controls and other best practices. +インフラ配備に関する包括的な情報、シナリオ戦略、適用される環境管理、その他の +ベストプラクティスについては、以下のセクションを参照してください。 -- [ML Supply Chain Compromise](https://atlas.mitre.org/techniques/AML.T0010) - **MITRE ATLAS** +- [ML サプライチェーンの危機](https://atlas.mitre.org/techniques/AML.T0010) - **MITRE ATLAS** diff --git a/LLM04_DataModelPoisoning.md b/LLM04_DataModelPoisoning.md index 6ad9182..45845c8 100644 --- a/LLM04_DataModelPoisoning.md +++ b/LLM04_DataModelPoisoning.md @@ -1,50 +1,51 @@ -## LLM04:2025 Data and Model Poisoning +## LLM04:2025 データとモデルポイズニング -### Description +### 説明 -Data poisoning occurs when pre-training, fine-tuning, or embedding data is manipulated to introduce vulnerabilities, backdoors, or biases. This manipulation can compromise model security, performance, or ethical behavior, leading to harmful outputs or impaired capabilities. Common risks include degraded model performance, biased or toxic content, and exploitation of downstream systems. +データポイズニングは、事前学習、微調整、または埋め込みデータが、脆弱性、バックドア、またはバイアスを導入するために操作された場合に発生します。このような操作は、モデルのセキュリティ、性能、または倫理的な動作を危険にさらし、有害な出力や能力の低下につながります。一般的なリスクには、モデル性能の低下、偏った内容や有害な内容、下流システムの悪用などがあります。 -Data poisoning can target different stages of the LLM lifecycle, including pre-training (learning from general data), fine-tuning (adapting models to specific tasks), and embedding (converting text into numerical vectors). Understanding these stages helps identify where vulnerabilities may originate. Data poisoning is considered an integrity attack since tampering with training data impacts the model's ability to make accurate predictions. The risks are particularly high with external data sources, which may contain unverified or malicious content. +データポイズニングは、プリトレーニング（一般的なデータからの学習）、ファインチュ +ーニング（特定のタスクへのモデルの適応）、エンベッディング（テキストから数値ベクトルへの変換）など、LLMライフサイクルのさまざまな段階をターゲットにすることができます。これらの段階を理解することは、脆弱性がどこから発生するかを特定するのに役立ちます。学習データの改ざんは、モデルが正確な予測を行う能力に影響を与えるため、データポイズニングは完全性攻撃とみなされます。検証されていない、あるいは悪意のあるコンテンツが含まれている可能性のある外部データソースでは、リスクが特に高くなります。 -Moreover, models distributed through shared repositories or open-source platforms can carry risks beyond data poisoning, such as malware embedded through techniques like malicious pickling, which can execute harmful code when the model is loaded. Also, consider that poisoning may allow for the implementation of a backdoor. Such backdoors may leave the model's behavior untouched until a certain trigger causes it to change. This may make such changes hard to test for and detect, in effect creating the opportunity for a model to become a sleeper agent. +さらに、共有リポジトリやオープンソースプラットフォームを通じて配布されるモデルは、悪意のあるピックリングのような技術によって埋め込まれたマルウェアのような、データポイズニング以外のリスクを伴う可能性があります。また、ポイズニングはバックドアの実装を許す可能性があることも考慮してください。このようなバックドアは、あるトリガーがそれを変更させるまで、モデルの動作をそのままにしておくかもしれません。これにより、そのような変更をテストしたり検出したりすることが難しくなり、事実上、モデルがスリーパーエージェントになる機会を作ってしまうかもしれません。 -### Common Examples of Vulnerability +### 脆弱性の一般的な例 -1. Malicious actors introduce harmful data during training, leading to biased outputs. Techniques like "Split-View Data Poisoning" or "Frontrunning Poisoning" exploit model training dynamics to achieve this. - (Ref. link: [Split-View Data Poisoning](https://github.com/GangGreenTemperTatum/speaking/blob/main/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%201%20Split-View%20Data%20Poisoning.jpeg)) - (Ref. link: [Frontrunning Poisoning](https://github.com/GangGreenTemperTatum/speaking/blob/main/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%202%20Frontrunning%20Data%20Poisoning.jpeg)) -2. Attackers can inject harmful content directly into the training process, compromising the model’s output quality. -3. Users unknowingly inject sensitive or proprietary information during interactions, which could be exposed in subsequent outputs. -4. Unverified training data increases the risk of biased or erroneous outputs. -5. Lack of resource access restrictions may allow the ingestion of unsafe data, resulting in biased outputs. +1. 悪意のある行為者は、トレーニング中に有害なデータを導入し、偏った出力を導く。「Split-View Data Poisoning」や「Frontrunning Poisoning」のようなテクニックは、モデルのトレーニングダイナミクスを悪用してこれを実現する。 + (参考リンク: [スプリット・ビュー・データ・ポイズニング](https://github.com/GangGreenTemperTatum/speaking/blob/main/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%201%20Split-View%20Data%20Poisoning.jpeg)) + (参考リンク: [フロントランニング・ポイズニング](https://github.com/GangGreenTemperTatum/speaking/blob/main/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%202%20Frontrunning%20Data%20Poisoning.jpeg)) +2. 攻撃者は、有害なコンテンツを学習プロセスに直接注入し、モデルの出力品質を損なうことができる。 +3. ユーザーは、対話中に機密情報や専有情報を無意識のうちに注入し、それが後続の出力で暴露される可能性がある。 +4. 未検証のトレーニングデータは、偏った出力や誤った出力のリスクを高める。 +5. リソースへのアクセス制限がないため、安全でないデータの取り込みが可能になり、結果として偏った出力になる可能性がある。 -### Prevention and Mitigation Strategies +### 予防と緩和の戦略 -1. Track data origins and transformations using tools like OWASP CycloneDX or ML-BOM. Verify data legitimacy during all model development stages. -2. Vet data vendors rigorously, and validate model outputs against trusted sources to detect signs of poisoning. -3. Implement strict sandboxing to limit model exposure to unverified data sources. Use anomaly detection techniques to filter out adversarial data. -4. Tailor models for different use cases by using specific datasets for fine-tuning. This helps produce more accurate outputs based on defined goals. -5. Ensure sufficient infrastructure controls to prevent the model from accessing unintended data sources. -6. Use data version control (DVC) to track changes in datasets and detect manipulation. Versioning is crucial for maintaining model integrity. -7. Store user-supplied information in a vector database, allowing adjustments without re-training the entire model. -8. Test model robustness with red team campaigns and adversarial techniques, such as federated learning, to minimize the impact of data perturbations. -9. Monitor training loss and analyze model behavior for signs of poisoning. Use thresholds to detect anomalous outputs. -10. During inference, integrate Retrieval-Augmented Generation (RAG) and grounding techniques to reduce risks of hallucinations. +1. OWASP CycloneDX や ML-BOM のようなツールを使用して、データの起源と変換を追跡する。すべてのモデル開発段階において、データの正当性を検証する。 +2. データベンダーを厳しく吟味し、モデル出力を信頼できるソースと照らし合わせて検証し、毒の兆候を検出する。 +3. 厳密なサンドボックスを実装し、検証されていないデータソースにモデルがさらされるのを制限する。異常検知技術を使用して、敵対的なデータをフィルタリングする。 +4. 微調整のために特定のデータセットを使用することで、さまざまなユースケースに合わせてモデルを調整します。これにより、定義された目標に基づき、より正確なアウトプットを生成することができます。 +5. モデルが意図しないデータソースにアクセスするのを防ぐために、十分なインフラストラクチャ制御を確保する。 +6. データ・バージョン管理（DVC）を使用して、データセットの変更を追跡し、操作を検出する。バージョン管理は、モデルの完全性を維持するために非常に重要です。 +7. ユーザーから提供された情報をベクトルデータベースに保存し、モデル全体を再トレーニングすることなく調整が可能。 +8. レッドチームによるキャンペーンや、連合学習などの敵対的手法を用いてモデルの頑健性をテストし、データ摂動の影響を最小限に抑える。 +9. トレーニングの損失を監視し、中毒の兆候についてモデルの動作を分析する。閾値を使用して異常出力を検出する。 +10. 推論の際には、RAG（ Retrieval-Augmented Generation）とグラウンディング技術を統合し、幻覚のリスクを減らす。 -### Example Attack Scenarios +### 攻撃シナリオの例 -#### Scenario #1 - An attacker biases the model's outputs by manipulating training data or using prompt injection techniques, spreading misinformation. -#### Scenario #2 - Toxic data without proper filtering can lead to harmful or biased outputs, propagating dangerous information. -#### Scenario # 3 - A malicious actor or competitor creates falsified documents for training, resulting in model outputs that reflect these inaccuracies. -#### Scenario #4 - Inadequate filtering allows an attacker to insert misleading data via prompt injection, leading to compromised outputs. -#### Scenario #5 - An attacker uses poisoning techniques to insert a backdoor trigger into the model. This could leave you open to authentication bypass, data exfiltration or hidden command execution. +#### シナリオ #1 +攻撃者は、学習データを操作したり、プロンプト・インジェクションのテクニックを使ったりして、モデルの出力に偏りを与え、誤った情報を広める。 +#### シナリオ #2 +適切なフィルタリングを行わない有害なデータは、有害または偏った出力につながり、危険な情報を伝播する。 +#### シナリオ # 3 +悪意のある行為者や競合他社がトレーニング用に改ざんされた文書を作成し、その結果、モデルの出力に不正確さが反映される。 +#### シナリオ #4 +不適切なフィルタリングにより、攻撃者はプロンプト・インジェクションを介して誤解を招くデータを挿入し、危険な出力に導くことができる。 +#### シナリオ #5 +攻撃者はポイズニング技術を使用して、モデルにバックドア・トリガーを挿入します。これにより、認証のバイパス、データの流出、隠しコマンドの実行を許してしまう可能性があります。 -### Reference Links +### 参考リンク 1. [How data poisoning attacks corrupt machine learning models](https://www.csoonline.com/article/3613932/how-data-poisoning-attacks-corrupt-machine-learning-models.html): **CSO Online** 2. [MITRE ATLAS (framework) Tay Poisoning](https://atlas.mitre.org/studies/AML.CS0009/): **MITRE ATLAS** @@ -58,9 +59,9 @@ Moreover, models distributed through shared repositories or open-source platform 10. [arXiv:2401.05566 Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training](https://www.anthropic.com/news/sleeper-agents-training-deceptive-llms-that-persist-through-safety-training) **Anthropic (arXiv)** 11. [Backdoor Attacks on AI Models](https://www.cobalt.io/blog/backdoor-attacks-on-ai-models) **Cobalt** -### Related Frameworks and Taxonomies +### 関連フレームワークと分類 -Refer to this section for comprehensive information, scenarios strategies relating to infrastructure deployment, applied environment controls and other best practices. +インフラ配備に関する包括的な情報、シナリオ戦略、適用される環境管理、その他のベストプラクティスについては、以下のセクションを参照してください。 -- [AML.T0018 | Backdoor ML Model](https://atlas.mitre.org/techniques/AML.T0018) **MITRE ATLAS** -- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework): Strategies for ensuring AI integrity. **NIST** +- [AML.T0018 | バックドアMLモデル](https://atlas.mitre.org/techniques/AML.T0018) **MITRE ATLAS** +- [NIST AIリスク管理フレームワーク](https://www.nist.gov/itl/ai-risk-management-framework): Strategies for ensuring AI integrity. **NIST** diff --git a/LLM05_ImproperOutputHandling.md b/LLM05_ImproperOutputHandling.md index 734e408..c8748f4 100644 --- a/LLM05_ImproperOutputHandling.md +++ b/LLM05_ImproperOutputHandling.md @@ -1,52 +1,52 @@ -## LLM05:2025 Improper Output Handling - -### Description - -Improper Output Handling refers specifically to insufficient validation, sanitization, and handling of the outputs generated by large language models before they are passed downstream to other components and systems. Since LLM-generated content can be controlled by prompt input, this behavior is similar to providing users indirect access to additional functionality. -Improper Output Handling differs from Overreliance in that it deals with LLM-generated outputs before they are passed downstream whereas Overreliance focuses on broader concerns around overdependence on the accuracy and appropriateness of LLM outputs. -Successful exploitation of an Improper Output Handling vulnerability can result in XSS and CSRF in web browsers as well as SSRF, privilege escalation, or remote code execution on backend systems. -The following conditions can increase the impact of this vulnerability: -- The application grants the LLM privileges beyond what is intended for end users, enabling escalation of privileges or remote code execution. -- The application is vulnerable to indirect prompt injection attacks, which could allow an attacker to gain privileged access to a target user's environment. -- 3rd party extensions do not adequately validate inputs. -- Lack of proper output encoding for different contexts (e.g., HTML, JavaScript, SQL) -- Insufficient monitoring and logging of LLM outputs -- Absence of rate limiting or anomaly detection for LLM usage - -### Common Examples of Vulnerability - -1. LLM output is entered directly into a system shell or similar function such as exec or eval, resulting in remote code execution. -2. JavaScript or Markdown is generated by the LLM and returned to a user. The code is then interpreted by the browser, resulting in XSS. -3. LLM-generated SQL queries are executed without proper parameterization, leading to SQL injection. -4. LLM output is used to construct file paths without proper sanitization, potentially resulting in path traversal vulnerabilities. -5. LLM-generated content is used in email templates without proper escaping, potentially leading to phishing attacks. - -### Prevention and Mitigation Strategies - -1. Treat the model as any other user, adopting a zero-trust approach, and apply proper input validation on responses coming from the model to backend functions. -2. Follow the OWASP ASVS (Application Security Verification Standard) guidelines to ensure effective input validation and sanitization. -3. Encode model output back to users to mitigate undesired code execution by JavaScript or Markdown. OWASP ASVS provides detailed guidance on output encoding. -4. Implement context-aware output encoding based on where the LLM output will be used (e.g., HTML encoding for web content, SQL escaping for database queries). -5. Use parameterized queries or prepared statements for all database operations involving LLM output. -6. Employ strict Content Security Policies (CSP) to mitigate the risk of XSS attacks from LLM-generated content. -7. Implement robust logging and monitoring systems to detect unusual patterns in LLM outputs that might indicate exploitation attempts. - -### Example Attack Scenarios - -#### Scenario #1 - An application utilizes an LLM extension to generate responses for a chatbot feature. The extension also offers a number of administrative functions accessible to another privileged LLM. The general purpose LLM directly passes its response, without proper output validation, to the extension causing the extension to shut down for maintenance. -#### Scenario #2 - A user utilizes a website summarizer tool powered by an LLM to generate a concise summary of an article. The website includes a prompt injection instructing the LLM to capture sensitive content from either the website or from the user's conversation. From there the LLM can encode the sensitive data and send it, without any output validation or filtering, to an attacker-controlled server. -#### Scenario #3 - An LLM allows users to craft SQL queries for a backend database through a chat-like feature. A user requests a query to delete all database tables. If the crafted query from the LLM is not scrutinized, then all database tables will be deleted. -#### Scenario #4 - A web app uses an LLM to generate content from user text prompts without output sanitization. An attacker could submit a crafted prompt causing the LLM to return an unsanitized JavaScript payload, leading to XSS when rendered on a victim's browser. Insufficient validation of prompts enabled this attack. -#### Scenario # 5 - An LLM is used to generate dynamic email templates for a marketing campaign. An attacker manipulates the LLM to include malicious JavaScript within the email content. If the application doesn't properly sanitize the LLM output, this could lead to XSS attacks on recipients who view the email in vulnerable email clients. -#### Scenario #6 - An LLM is used to generate code from natural language inputs in a software company, aiming to streamline development tasks. While efficient, this approach risks exposing sensitive information, creating insecure data handling methods, or introducing vulnerabilities like SQL injection. The AI may also hallucinate non-existent software packages, potentially leading developers to download malware-infected resources. Thorough code review and verification of suggested packages are crucial to prevent security breaches, unauthorized access, and system compromises. - -### Reference Links +## LLM05:2025 不適切な出力処理 + +### 説明 + +不適切な出力処理とは、特に、大規模な言語モデルによって生成された出力が、他のコンポーネントやシステムに渡される前に、十分に検証、サニタイズ、処理されないことを指します。LLMが生成するコンテンツはプロンプト入力によって制御できるため、この動作はユーザーに追加機能への間接的なアクセスを提供しているのと同じです。 +不適切な出力処理は、LLMが生成した出力が下流に渡される前に対処するという点で、過度の信頼とは異なります。一方、過度の信頼は、LLMの出力の正確さと適切さへの過度の依存に関するより広範な懸念に焦点を当てています。 +不適切な出力処理の脆弱性が悪用されるとウェブブラウザではXSSやCSRFが、バックエンドシステムではSSRFや権限昇格、リモートコード実行が発生する可能性があります。 +この脆弱性の影響を増大させる可能性があるのは、以下の条件です： +- アプリケーションは LLM にエンドユーザが意図する以上の特権を与え、特権の昇格やリモートでのコード実行を可能にします。 +- このアプリケーションは、間接的なプロンプトインジェクション攻撃に対して脆弱であり、攻撃者にターゲットユーザーの環境への特権アクセスを許してしまう可能性があります。 +- サードパーティの拡張機能は、入力を適切に検証しません。 +- 異なるコンテキスト（HTML、JavaScript、SQLなど）に対する適切な出力エンコーディングの欠如 +- LLMアウトプットの不十分なモニタリングと記録 +- LLM使用時のレート制限や異常検知の不在 + +### 脆弱性の一般的な例 + +1. LLMの出力がシステムシェルやexecやevalのような類似関数に直接入力され、リモートでコードが実行される。 +2. JavaScriptやMarkdownはLLMによって生成され、ユーザーに返されます。そのコードはブラウザによって解釈され、XSSになります。 +3. LLMが生成したSQLクエリが適切なパラメータ化なしに実行され、SQLインジェクションにつながる。 +4. LLMの出力が適切なサニタイズなしにファイルパスを構築するために使用され、パストラバーサル脆弱性を引き起こす可能性がある。 +5. LLMで生成されたコンテンツが適切なエスケープを施されずにEメールテンプレートで使用される。 + +### 予防と緩和の戦略 + +1. モデルを他のユーザーと同じように扱い、信頼ゼロのアプローチを採用し、モデルからバックエンド機能への応答に適切な入力検証を適用する。 +2. OWASP ASVS（Application Security Verification Standard）ガイドラインに従い、効果的な入力検証とサニタイズを確実に行う。 +3. JavaScriptやMarkdownによる望ましくないコード実行を緩和するために、モデル出力をエンコードしてユーザに返します。OWASP ASVS は、出力エンコードに関する詳細なガイダンスを提供しています。 +4. LLMの出力が使用される場所に基づいて、コンテキストを考慮した出力エンコーディングを実装する（例えば、ウェブコンテンツのHTMLエンコーディング、データベースクエリのSQLエスケーピング）。 +5. LLM出力を含むすべてのデータベース操作には、パラメータ化されたクエリまたはプリペアド・ステートメントを使用してください。 +6. 厳格なコンテンツ・セキュリティ・ポリシー（CSP）を採用し、LLMが生成したコンテンツからのXSS攻撃のリスクを軽減する。 +7. 搾取の試みを示す可能性のあるLLM出力の異常なパターンを検出するために、堅牢なロギングと監視システムを導入する。 + +### 攻撃シナリオの例 + +#### シナリオ #1 +あるアプリケーションは、チャットボット機能の応答を生成するためにLLM拡張機能を利用している。この拡張機能は、別の特権 LLM がアクセスできる多くの管理機能も提供している。汎用の LLM は、適切な出力検証を行うことなく、レスポンスを直接拡張機能に渡し、拡張機能がメンテナンスのためにシャットダウンする原因となる。 +#### シナリオ #2 +ユーザーはLLMを搭載したウェブサイト要約ツールを利用し、記事の簡潔な要約を生成する。このウェブサイトには、LLMにウェブサイトまたはユーザーの会話から機密コンテンツをキャプチャするよう指示するインジェクションが含まれている。そこからLLMは機密データをエンコードし、出力の検証やフィルタリングを行うことなく、攻撃者がコントロールするサーバーに送信することができる。 +#### シナリオ #3 +LLMでは、ユーザーがチャットのような機能を使ってバックエンドデータベースに対するSQLクエリを作成することができます。ユーザはデータベースの全テーブルを削除するクエリを要求する。LLMが作成したクエリが精査されなければ、すべてのデータベーステーブルが削除される。 +#### シナリオ #4 +あるウェブアプリケーションは、LLM を使用して、出力がサニタイズされていないテキストプロンプトからコンテンツを生成します。攻撃者は細工したプロンプトを送信することで、LLMがサニタイズされていないJavaScriptペイロードを返し、被害者のブラウザでレンダリングされた際にXSSを引き起こす可能性がある。プロンプトの不十分な検証により、この攻撃が可能にした。 +#### シナリオ # 5 +LLMは、マーケティングキャンペーン用の動的な電子メールテンプレートを生成するために使用される。攻撃者は LLM を操作して、悪意のある JavaScript をメールコンテンツに含めます。アプリケーションが LLM の出力を適切にサニタイズしていない場合、脆弱なメールクライアントでメールを閲覧した受信者に XSS 攻撃を仕掛ける可能性がある。 +#### シナリオ #6 +LLMは、ソフトウェア会社で自然言語入力からコードを生成するために使用され、開発作業を効率化することを目的としている。効率的ではあるが、このアプローチには機密情報を暴露したり、安全でないデータ処理方法を作成したり、SQLインジェクションのような脆弱性を導入したりするリスクがある。また、AIは存在しないソフトウェア・パッケージを幻視し、開発者をマルウェアに感染したリソースのダウンロードに導く可能性もある。セキュリティ侵害、不正アクセス、システム侵害を防ぐには、提案されたパッケージの徹底したコードレビューと検証が極めて重要である。 + +### 参考リンク 1. [Proof Pudding (CVE-2019-20634)](https://avidml.org/database/avid-2023-v009/) **AVID** (`moohax` & `monoxgas`) 2. [Arbitrary Code Execution](https://security.snyk.io/vuln/SNYK-PYTHON-LANGCHAIN-5411357): **Snyk Security Blog** @@ -56,4 +56,3 @@ The following conditions can increase the impact of this vulnerability: 6. [Threat Modeling LLM Applications](https://aivillage.org/large%20language%20models/threat-modeling-llm/): **AI Village** 7. [OWASP ASVS - 5 Validation, Sanitization and Encoding](https://owasp-aasvs4.readthedocs.io/en/latest/V5.html#validation-sanitization-and-encoding): **OWASP AASVS** 8. [AI hallucinates software packages and devs download them – even if potentially poisoned with malware](https://www.theregister.com/2024/03/28/ai_bots_hallucinate_software_packages/) **Theregiste** -