Pesquisadores identificam mais de 20 vulnerabilidades da cadeia de suprimentos em plataformas MLOps

Pesquisadores de segurança cibernética estão alertando sobre os riscos de segurança na cadeia de suprimentos de software de aprendizado de máquina (ML) após a descoberta de mais de 20 vulnerabilidades que podem ser exploradas para atingir plataformas MLOps.

Essas vulnerabilidades, descritas como falhas inerentes e baseadas na implementação, podem ter consequências graves, que vão desde a execução de código arbitrário até o carregamento de conjuntos de dados maliciosos.

MLOps

As plataformas MLOps oferecem a capacidade de projetar e executar um pipeline de modelo de ML, com um registro de modelo atuando como um repositório usado para armazenar e treinar modelos de ML com versão. Esses modelos podem então ser incorporados em um aplicativo ou permitir que outros clientes os consultem usando uma API (também conhecida como modelo como serviço).

“Vulnerabilidades inerentes são vulnerabilidades causadas pelos formatos e processos subjacentes usados ​​na tecnologia alvo”, disseram os pesquisadores da JFrog em um relatório detalhado.

Alguns exemplos de vulnerabilidades inerentes incluem o abuso de modelos de ML para executar código escolhido pelo invasor, aproveitando o fato de que os modelos oferecem suporte à execução automática de código no carregamento (por exemplo, arquivos de modelo Pickle ).

Esse comportamento também se estende a certos formatos de conjuntos de dados e bibliotecas, que permitem a execução automática de código, abrindo potencialmente a porta para ataques de malware ao simplesmente carregar um conjunto de dados disponível publicamente.

Outro exemplo de vulnerabilidade inerente diz respeito ao JupyterLab (antigo Jupyter Notebook), um ambiente computacional interativo baseado na web que permite aos usuários executar blocos (ou células) de código e visualizar os resultados correspondentes.

“Um problema inerente que muitos não conhecem é o tratamento da saída HTML ao executar blocos de código no Jupyter”, apontaram os pesquisadores. “A saída do seu código Python pode emitir HTML e [JavaScript] que serão renderizados alegremente pelo seu navegador.”

O problema aqui é que o resultado do JavaScript, quando executado, não é isolado do aplicativo web pai e o aplicativo web pai pode executar automaticamente código Python arbitrário.

Em outras palavras, um invasor pode gerar um código JavaScript malicioso de modo que ele adicione uma nova célula no notebook JupyterLab atual, injete código Python nela e então a execute. Isso é particularmente verdadeiro em casos ao explorar uma vulnerabilidade de cross-site scripting (XSS).

Para isso, a JFrog disse ter identificado uma falha XSS no MLFlow ( CVE-2024-27132 , pontuação CVSS: 7,5) que decorre da falta de higienização suficiente ao executar uma receita não confiável , resultando na execução de código do lado do cliente no JupyterLab.

“Uma das principais conclusões desta pesquisa é que precisamos tratar todas as vulnerabilidades XSS em bibliotecas de ML como potencial execução de código arbitrário, já que os cientistas de dados podem usar essas bibliotecas de ML com o Jupyter Notebook”, disseram os pesquisadores.

O segundo conjunto de falhas está relacionado a fraquezas de implementação, como a falta de autenticação em plataformas MLOps, o que pode permitir que um agente de ameaça com acesso à rede obtenha recursos de execução de código abusando do recurso ML Pipeline.

Essas ameaças não são teóricas, com adversários motivados financeiramente abusando dessas brechas, como observado no caso do Anyscale Ray não corrigido ( CVE-2023-48022 , pontuação CVSS: 9,8), para implantar mineradores de criptomoedas.

Um segundo tipo de vulnerabilidade de implementação é um escape de contêiner direcionado ao Seldon Core, que permite que invasores vão além da execução de código para se moverem lateralmente pelo ambiente de nuvem e acessarem modelos e conjuntos de dados de outros usuários, enviando um modelo malicioso para o servidor de inferência.

O resultado líquido do encadeamento dessas vulnerabilidades é que elas não apenas podem ser usadas como armas para se infiltrar e se espalhar dentro de uma organização, mas também comprometer servidores.

“Se você estiver implantando uma plataforma que permite o serviço de modelo, agora você deve saber que qualquer um que possa servir um novo modelo também pode executar código arbitrário naquele servidor”, disseram os pesquisadores. “Certifique-se de que o ambiente que executa o modelo esteja completamente isolado e protegido contra um escape de contêiner.”

A divulgação ocorre no momento em que a Unidade 42 da Palo Alto Networks detalhou duas vulnerabilidades já corrigidas na estrutura de IA generativa LangChain de código aberto (CVE-2023-46229 e CVE-2023-44467) que poderiam ter permitido que invasores executassem código arbitrário e acessassem dados confidenciais, respectivamente.

No mês passado, a Trail of Bits também revelou quatro problemas no Ask Astro, um aplicativo de chatbot de código aberto de geração aumentada de recuperação (RAG), que poderia levar ao envenenamento da saída do chatbot, ingestão imprecisa de documentos e possível negação de serviço (DoS).

Assim como problemas de segurança estão sendo expostos em aplicativos com inteligência artificial, técnicas também estão sendo criadas para envenenar conjuntos de dados de treinamento com o objetivo final de enganar grandes modelos de linguagem (LLMs) para produzir código vulnerável.

“Ao contrário de ataques recentes que incorporam cargas maliciosas em seções detectáveis ​​ou irrelevantes do código (por exemplo, comentários), o CodeBreaker utiliza LLMs (por exemplo, GPT-4) para transformação sofisticada de cargas úteis (sem afetar funcionalidades), garantindo que tanto os dados envenenados para ajuste fino quanto o código gerado possam escapar da forte detecção de vulnerabilidades”, disse um grupo de acadêmicos da Universidade de Connecticut .

Fontes: The Hacker News