Pesquisadores de cibersegurança estão alertando sobre os riscos de segurança na cadeia de suprimentos de software de machine learning (ML) após a descoberta de mais de 20 vulnerabilidades que poderiam ser exploradas para atacar plataformas de MLOps.
Essas vulnerabilidades, descritas como falhas inerentes e baseadas em implementação, podem ter consequências graves, variando desde a execução arbitrária de código até o carregamento de datasets maliciosos.
Plataformas de 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 versionar modelos de ML treinados.
Esses modelos podem então ser embutidos em uma aplicação ou permitir que outros clientes os consultem usando uma API (conhecida como model-as-a-service).
"Vulnerabilidades inerentes são vulnerabilidades causadas pelos formatos e processos subjacentes usados na tecnologia alvo", disseram pesquisadores da JFrog em um relatório detalhado.
Alguns exemplos de vulnerabilidades inerentes incluem abusar de modelos de ML para executar código da escolha do atacante, aproveitando-se do fato de que os modelos suportam execução automática de código ao serem carregados (por exemplo, arquivos de modelo Pickle).
Esse comportamento também se estende a certos formatos de dataset e bibliotecas, que permitem a execução automática de código, abrindo assim a porta para ataques de malware apenas ao carregar um dataset disponível publicamente.
Outro exemplo de vulnerabilidade inerente diz respeito ao JupyterLab (anteriormente 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 desconhecem é o tratamento de saídas 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á felizmente renderizado pelo seu navegador. O problema aqui é que o resultado do JavaScript, quando executado, não é isolado da aplicação web principal e a aplicação web principal pode executar automaticamente código Python arbitrário.
Em outras palavras, um atacante poderia emitir um código JavaScript malicioso de tal maneira que ele adiciona uma nova célula no notebook atual do JupyterLab, injeta código Python nela e, em seguida, executa-o.
Isso é particularmente verdadeiro em casos de exploração de uma vulnerabilidade de cross-site scripting (XSS).
Nesse sentido, a JFrog disse que identificou uma falha de XSS no MLFlow (
CVE-2024-27132
, pontuação CVSS: 7.5) que decorre da falta de sanitizaçã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 nossas principais conclusões desta pesquisa é que precisamos tratar todas as vulnerabilidades de XSS em bibliotecas de ML como execução arbitrária de código em potencial, já que cientistas de dados podem usar essas bibliotecas com o Jupyter Notebook", disseram os pesquisadores.
O segundo conjunto de falhas relaciona-se a fraquezas de implementação, como a falta de autenticação em plataformas de MLOps, permitindo potencialmente que um ator de ameaça com acesso à rede obtenha capacidades de execução de código ao abusar do recurso de Pipeline de ML.
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 container visando o Seldon Core que permite a atacantes ir além da execução de código para se mover lateralmente através do ambiente de nuvem e acessar modelos e datasets de outros usuários ao fazer upload de um modelo malicioso para o servidor de inferência.
O resultado líquido do encadeamento dessas vulnerabilidades é que elas poderiam não apenas ser armadas para infiltrar e se espalhar dentro de uma organização, mas também comprometer servidores.
"Se você está implantando uma plataforma que permite o serving de modelo, agora você deve saber que qualquer pessoa que possa servir um novo modelo também pode realmente executar código arbitrário nesse servidor", disseram os pesquisadores.
Certifique-se de que o ambiente que executa o modelo seja completamente isolado e reforçado contra um escape de container.
A divulgação ocorre enquanto a Palo Alto Networks Unit 42 detalhou duas vulnerabilidades agora corrigidas no framework de IA generativa LangChain de código aberto (
CVE-2023-46229
e
CVE-2023-44467
) que poderiam ter permitido aos atacantes executar código arbitrário e acessar dados sensíveis, respectivamente.
No mês passado, a Trail of Bits também revelou quatro problemas no Ask Astro, uma aplicação de chatbot de código aberto de geração augmentada de recuperação (RAG), que poderiam levar a envenenamento da saída do chatbot, ingestão imprecisa de documentos e potencial negação de serviço (DoS).
Assim como os problemas de segurança estão sendo expostos em aplicações movidas por inteligência artificial, técnicas também estão sendo desenvolvidas para envenenar datasets de treinamento com o objetivo final de enganar modelos de linguagem grandes (LLMs) a produzir código vulnerável.
"Ao contrário dos ataques recentes que embutem payloads maliciosos em seções detectáveis ou irrelevantes do código (por exemplo, comentários), o CodeBreaker aproveita LLMs (por exemplo, GPT-4) para transformação sofisticada de payload (sem afetar funcionalidades), garantindo que tanto os dados envenenados para o fine-tuning quanto o código gerado possam evitar a detecção de vulnerabilidade forte", disse um grupo de acadêmicos da Universidade de Connecticut.
.
Publicidade
Passe por todas as principais fases de um pentest, utilizando cenários, domínios e técnicas reais utilizados no dia a dia de um hacker ético. Conte ainda com certificado e suporte, tudo 100% gratuito. Saiba mais...