diff --git a/2_0_vulns/translations/pt-BR/LLM03_CadeiadeSuprimentos.md b/2_0_vulns/translations/pt-BR/LLM03_CadeiadeSuprimentos.md new file mode 100644 index 00000000..6d209364 --- /dev/null +++ b/2_0_vulns/translations/pt-BR/LLM03_CadeiadeSuprimentos.md @@ -0,0 +1,95 @@ +## LLM03:2025 Cadeia de Suprimentos + +### Descrição + +As cadeias de suprimentos de LLMs são suscetíveis a várias vulnerabilidades, que podem afetar a integridade dos dados de treinamento, dos modelos e das plataformas de implantação. Esses riscos podem resultar em saídas tendenciosas, violações de segurança ou falhas no sistema. Enquanto as vulnerabilidades tradicionais de software focam em questões como falhas de código e dependências, em aprendizado de máquina, os riscos também se estendem a modelos pré-treinados e dados de terceiros. + +Esses elementos externos podem ser manipulados por meio de ataques de adulteração ou envenenamento. + +A criação de LLMs é uma tarefa especializada que frequentemente depende de modelos de terceiros. O surgimento de LLMs de acesso aberto e novos métodos de ajuste fino, como "LoRA" (Adaptação de Baixa Dimensão) e "PEFT" (Ajuste Fino com Eficiência de Parâmetros), especialmente em plataformas como Hugging Face, introduzem novos riscos à cadeia de suprimentos. Finalmente, o surgimento de LLMs em dispositivos aumenta a superfície de ataque e os riscos na cadeia de suprimentos para aplicações de LLM. + +Alguns dos riscos discutidos aqui também são abordados em "LLM04 Data and Model Poisoning". Esta entrada foca no aspecto da cadeia de suprimentos desses riscos. Um modelo de ameaça simples pode ser encontrado [aqui](https://github.com/jsotiro/ThreatModels/blob/main/LLM%20Threats-LLM%20Supply%20Chain.png). + +### Exemplos Comuns de Riscos + +#### 1. Vulnerabilidades Tradicionais de Pacotes de Terceiros + Como componentes desatualizados ou obsoletos, que os atacantes podem explorar para comprometer aplicações de LLM. Isso é semelhante a "A06:2021 – Componentes Vulneráveis e Desatualizados," com riscos aumentados quando os componentes são usados durante o desenvolvimento ou ajuste fino do modelo. + (Ref. link: [A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)) +#### 2. Riscos de Licenciamento + O desenvolvimento de IA frequentemente envolve diferentes licenças de software e conjuntos de dados, criando riscos se não forem gerenciados adequadamente. Licenças abertas e proprietárias impõem diferentes requisitos legais. Licenças de conjuntos de dados podem restringir uso, distribuição ou comercialização. +#### 3. Modelos Desatualizados ou Obsoletos + Usar modelos desatualizados ou obsoletos que não são mais mantidos leva a problemas de segurança. +#### 4. Modelo Pré-treinado Vulnerável + Modelos são caixas-pretas binárias e, ao contrário de código aberto, a inspeção estática oferece poucas garantias de segurança. Modelos pré-treinados vulneráveis podem conter vieses ocultos, backdoors ou outras funcionalidades maliciosas que não foram identificadas nas avaliações de segurança dos repositórios de modelos. Modelos vulneráveis podem ser criados tanto por conjuntos de dados envenenados quanto por adulteração direta do modelo usando técnicas como ROME, também conhecida como "lobotomização." +#### 5. Proveniência Fraca do Modelo + Atualmente, não há garantias fortes de proveniência em modelos publicados. Cartões de Modelo e documentação associada fornecem informações sobre os modelos e são confiáveis pelos usuários, mas não oferecem garantias sobre a origem do modelo. Um atacante pode comprometer a conta de um fornecedor em um repositório de modelos ou criar uma conta semelhante e usar técnicas de engenharia social para comprometer a cadeia de suprimentos de uma aplicação de LLM. +#### 6. Adaptadores LoRA Vulneráveis + LoRA é uma técnica popular de ajuste fino que aumenta a modularidade permitindo que camadas pré-treinadas sejam acopladas a um LLM existente. Embora eficiente, essa abordagem cria novos riscos, onde um adaptador LoRA malicioso compromete a integridade e a segurança do modelo base pré-treinado. Isso pode ocorrer tanto em ambientes colaborativos quanto explorando plataformas populares de implantação de inferência, como vLLM e OpenLLM, que suportam adaptadores LoRA. +#### 7. Exploração de Processos de Desenvolvimento Colaborativo + O desenvolvimento colaborativo de modelos e os serviços de manipulação de modelos (e.g., conversões) hospedados em ambientes compartilhados podem ser explorados para introduzir vulnerabilidades em modelos compartilhados. Por exemplo, a fusão de modelos é popular no Hugging Face, com modelos combinados liderando o ranking do OpenLLM, mas pode ser explorada para burlar revisões. +#### 8. Vulnerabilidades na Cadeia de Suprimentos de Modelos em Dispositivos + Modelos de LLM em dispositivos aumentam a superfície de ataque com processos de fabricação comprometidos e exploração de vulnerabilidades no sistema operacional ou firmware do dispositivo para comprometer os modelos. Atacantes podem fazer engenharia reversa e reempacotar aplicações com modelos adulterados. +#### 9. Termos e Condições e Políticas de Privacidade Ambíguos + Termos e Condições (T&Cs) e políticas de privacidade pouco claros dos operadores de modelos podem levar à utilização de dados sensíveis da aplicação para treinamento do modelo, expondo informações confidenciais. + +### Estratégias de Prevenção e Mitigação + +1. Avalie cuidadosamente fontes de dados e fornecedores, incluindo T&Cs e suas políticas de privacidade, usando apenas fornecedores confiáveis. Revise e audite regularmente a segurança e o acesso do fornecedor, garantindo que não haja mudanças em sua postura de segurança ou T&Cs. +2. Entenda e aplique as mitigações encontradas no "OWASP Top Ten's A06:2021 – Componentes Vulneráveis e Desatualizados." Isso inclui varreduras de vulnerabilidade, gerenciamento e correção de componentes. Para ambientes de desenvolvimento com acesso a dados sensíveis, aplique esses controles também nesses ambientes. + (Ref. link: [A06:2021 – Vulnerable and Outdated Components](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)) +3. Realize avaliações extensivas com equipes vermelhas de IA ao selecionar um modelo de terceiros. Use benchmarks confiáveis de IA, como o Decoding Trust, para avaliar a confiabilidade dos modelos. +4. Mantenha um inventário atualizado de componentes usando um Software Bill of Materials (SBOM) para garantir uma lista precisa e assinada, prevenindo adulterações em pacotes implantados. SBOMs podem detectar e alertar rapidamente sobre novas vulnerabilidades de dia zero. +5. Para mitigar riscos de licenciamento, crie um inventário de todos os tipos de licenças envolvidos usando SBOMs e conduza auditorias regulares, garantindo conformidade e transparência. +6. Use modelos de fontes verificáveis e realize verificações de integridade de modelos com assinatura e hashes de arquivos para compensar a falta de proveniência robusta. Da mesma forma, use assinatura de código para códigos fornecidos externamente. +7. Implemente práticas rigorosas de monitoramento e auditoria para ambientes colaborativos de desenvolvimento de modelos. +8. Testes de robustez contra adversários e detecção de anomalias em modelos e dados fornecidos podem ajudar a detectar adulterações e envenenamentos, como discutido em "LLM04 Data and Model Poisoning." +9. Implemente uma política de correção para mitigar componentes vulneráveis ou desatualizados. Certifique-se de que a aplicação depende de uma versão mantida de APIs e modelos subjacentes. +10. Encripte modelos implantados na borda de IA com verificações de integridade e use APIs de atestação de fornecedores para prevenir aplicativos adulterados e modelos não reconhecidos. + +### Cenários de Ataques Exemplares + +#### Cenário #1: Biblioteca Python Vulnerável + Um atacante explora uma biblioteca Python vulnerável para comprometer um aplicativo LLM. Isso aconteceu na primeira violação de dados da OpenAI. +#### Cenário #2: Adulteração Direta + Um atacante adultera diretamente um modelo para disseminar desinformação. Este ataque real é exemplificado pelo PoisonGPT. +#### Cenário #3: Ajuste Fino de Modelo Popular + Um atacante ajusta fino um modelo popular de acesso aberto para remover recursos de segurança importantes, implantando-o em plataformas confiáveis. +#### Cenário #4: Modelos Pré-Treinados + Um sistema LLM implanta modelos pré-treinados de um repositório amplamente usado sem verificação detalhada, introduzindo vieses e resultados manipulados. +#### Cenário #5: Fornecedor Comprometido + Um fornecedor comprometido fornece um adaptador LoRA vulnerável que é integrado a um modelo LLM. +#### Cenário #6: Infiltração de Fornecedor + Um atacante compromete a produção de um adaptador LoRA integrado a um LLM implantado em dispositivos. +#### Cenário #7: Ataques CloudBorne e CloudJacking + Esses ataques visam infraestruturas em nuvem, comprometendo instâncias virtuais e ambientes compartilhados. +#### Cenário #8: LeftOvers (CVE-2023-4969) + Um ataque que explora memória local de GPUs para recuperar dados sensíveis. +#### Cenário #9: WizardLM + Um modelo falso com o mesmo nome é publicado contendo malware e backdoors. +#### Cenário #10: Serviço de Conversão de Formato de Modelo + Um atacante usa serviços de manipulação de modelos para comprometer um modelo disponível publicamente. +#### Cenário #11: Engenharia Reversa de Aplicativos Móveis + Um atacante substitui o modelo de um aplicativo por uma versão adulterada, conduzindo usuários a sites fraudulentos. +#### Cenário #12: Envenenamento de Conjuntos de Dados + Um atacante adultera conjuntos de dados públicos para criar backdoors em modelos ajustados finos. +#### Cenário #13: Termos e Condições e Política de Privacidade + Alterações nos T&Cs e políticas de privacidade levam ao uso de dados sensíveis da aplicação no treinamento do modelo. + +### Links de Referência + +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/) +3. [Hijacking Safetensors Conversion on Hugging Face](https://hiddenlayer.com/research/silent-sabotage/) +4. [ML Supply Chain Compromise](https://atlas.mitre.org/techniques/AML.T0010) +5. [Using LoRA Adapters with vLLM](https://docs.vllm.ai/en/latest/models/lora.html) +6. [Removing RLHF Protections in GPT-4 via Fine-Tuning](https://arxiv.org/pdf/2311.05553) +7. [Model Merging with PEFT](https://huggingface.co/blog/peft_merging) +8. [HuggingFace SF_Convertbot Scanner](https://gist.github.com/rossja/d84a93e5c6b8dd2d4a538aa010b29163) +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/) + +### Frameworks e Taxonomias Relacionados + +Consulte esta seção para informações abrangentes, cenários e estratégias relacionados à implantação de infraestrutura, controles no ambiente aplicado e outras melhores práticas. + +- [ML Supply Chain Compromise](https://atlas.mitre.org/techniques/AML.T0010) - **MITRE ATLAS** diff --git a/2_0_vulns/translations/pt-BR/LLM03_SupplyChain.md b/2_0_vulns/translations/pt-BR/LLM03_SupplyChain.md deleted file mode 100644 index 3b9e739c..00000000 --- a/2_0_vulns/translations/pt-BR/LLM03_SupplyChain.md +++ /dev/null @@ -1,98 +0,0 @@ -## 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 - -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/) -3. [Hijacking Safetensors Conversion on Hugging Face](https://hiddenlayer.com/research/silent-sabotage/) -4. [ML Supply Chain Compromise](https://atlas.mitre.org/techniques/AML.T0010) -5. [Using LoRA Adapters with vLLM](https://docs.vllm.ai/en/latest/models/lora.html) -6. [Removing RLHF Protections in GPT-4 via Fine-Tuning](https://arxiv.org/pdf/2311.05553) -7. [Model Merging with PEFT](https://huggingface.co/blog/peft_merging) -8. [HuggingFace SF_Convertbot Scanner](https://gist.github.com/rossja/d84a93e5c6b8dd2d4a538aa010b29163) -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**