SAPwned: vulnerabilidades no SAP AI expõem ambientes de nuvem de clientes e artefatos privados de IA

• A Wiz Research confirmou que, por meio de uma cadeia de vulnerabilidades de isolamento de tenants no SAP AI Core, a execução de código iniciada a partir de uma tarefa legítima de treinamento de IA poderia levar ao controle do serviço e ao acesso a segredos de clientes
• O caminho de ataque combinava, em sequência, bypass das restrições de rede do Istio, exposição de tokens da AWS na configuração do Loki, compartilhamentos EFS sem autenticação e acesso sem autenticação ao Tiller do Helm v2
• Com os privilégios obtidos, era possível ler e modificar imagens e artefatos no Docker Registry interno da SAP, no Google Container Registry e no Artifactory interno, além de obter privilégios de cluster-admin no cluster Kubernetes
• Um possível atacante poderia acessar credenciais de AWS, Azure e SAP HANA Cloud dos clientes, além de artefatos privados de IA como modelos, datasets e código, ou contaminar artefatos internos
• A SAP corrigiu todas as vulnerabilidades relatadas e rotacionou os segredos relacionados; a Wiz afirmou que não houve violação de dados de clientes

---

Problema de isolamento de tenants revelado no SAP AI Core

• A Wiz Research vem investigando o isolamento de tenants em provedores de serviços de IA, e o SAP AI Core é o terceiro relatório, depois de Hugging Face e Replicate
• O SAP AI Core é um serviço gerenciado que permite aos usuários desenvolver, treinar e executar serviços de IA nos recursos de nuvem da SAP
• Serviços de treinamento de IA precisam acessar grandes volumes de dados sensíveis de clientes, e o SAP AI Core usa chaves de acesso à nuvem que acessam dados internos dos clientes para integração com o HANA e outros serviços de nuvem
• A pesquisa começou com a criação de um projeto de IA em uma conta de cliente SAP com permissões básicas e a criação de um Pod Kubernetes por meio de um arquivo Argo Workflow permitido pelo SAP AI Core
• Por design, o usuário podia executar código arbitrário dentro do Pod, mas, no ambiente inicial, o sidecar de proxy do Istio restringia o acesso à rede, dificultando a varredura da rede interna

Bug nº 1: bypass das restrições do Istio

• O admission controller da SAP bloqueava opções de segurança perigosas, e também impedia tentativas de executar contêineres como root
• Duas configurações não bloqueadas levaram ao bypass das restrições de rede
  • shareProcessNamespace permitia compartilhar o namespace de processos com o contêiner sidecar, possibilitando ver a configuração do proxy Istio e o token de acesso ao servidor central Istiod
  • runAsUser e runAsGroup permitiam UIDs diferentes de root, tornando possível executar como o UID do Istio, 1337
• Como o próprio Istio é excluído das regras iptables do Istio, um processo executado com o UID 1337 opera sem restrições de tráfego
• Em seguida, foi possível ler a configuração do servidor Istiod usando o token do Istio e obter informações sobre o ambiente interno

Bug nº 2: exposição de tokens da AWS na configuração do Loki

• Dentro do cluster, foi encontrada uma instância do Grafana Loki, e era possível ver toda a configuração por meio de uma solicitação ao endpoint /config
• A resposta continha segredos da AWS usados pelo Loki para acessar o S3
• Esses segredos concediam acesso ao bucket S3 do Loki, que continha muitos logs do serviço AI Core e logs de Pods de clientes
• A SAP considerou que esses logs não eram sensíveis

Bug nº 3: exposição de arquivos de usuários em compartilhamentos EFS sem autenticação

• Na rede interna, foram encontradas seis instâncias do AWS Elastic File System, ou EFS, escutando na porta 2049
• Essas instâncias EFS estavam em um estado no qual, bastando ter acesso de rede, era possível ver ou editar arquivos sem credenciais
• Era possível acessar livremente o conteúdo compartilhado usando apenas ferramentas NFS de código aberto
• O EFS armazenava grandes volumes de dados de IA, incluindo código e datasets de treinamento classificados por ID de cliente

Bug nº 4: Tiller do Helm sem autenticação expõe Registry interno e Artifactory

• Na rede interna, foi encontrado o serviço Tiller, componente de servidor do Helm v2
• O Tiller se comunica por uma interface gRPC na porta 44134 e, por padrão, fica exposto sem autenticação
• Consultas ao Tiller expuseram segredos com altos privilégios para o SAP Docker Registry e servidores Artifactory
• Com permissões de leitura, era possível ler imagens internas e builds para extrair segredos comerciais e dados de clientes
• Com permissões de escrita, era possível contaminar imagens e builds e realizar um ataque à cadeia de suprimentos contra o serviço SAP AI Core

Bug nº 5: controle do cluster Kubernetes com permissões de escrita no Helm Tiller

• O Tiller permitia não apenas leitura, mas também operações de escrita
• Como o comando install recebe um pacote Helm e o implanta no cluster Kubernetes, a equipe de pesquisa criou e instalou um pacote Helm malicioso que criava um novo Pod com privilégios de cluster-admin
• Com esse processo, obteve controle total do cluster
• Esse nível de privilégio permitiria acessar diretamente Pods de outros clientes e roubar dados sensíveis, como modelos, datasets e código
• Também seria possível interferir nos Pods de clientes, contaminar dados de IA e manipular inferências de modelos
• Com os mesmos privilégios, também era possível consultar em texto claro segredos de clientes que extrapolavam o escopo do SAP AI Core
  • A conta do AI Core da equipe de pesquisa tinha segredos de uma conta AWS para acesso a dados no S3
  • Havia segredos de uma conta SAP HANA para acesso ao Data Lake
  • Havia segredos de uma conta Docker Hub para pull de imagens
• Na mesma consulta, também foi identificada uma chave de acesso da SAP para o Google Container Registry chamada sap-docker-registry-secret, que concedia permissões de leitura e escrita

Escopo de acesso confirmado e impacto potencial

• A cadeia de vulnerabilidades possibilitava as seguintes ações
  • Ler e modificar imagens Docker no Registry interno de contêineres da SAP
  • Ler e modificar imagens Docker da SAP no Google Container Registry
  • Ler e modificar artefatos no servidor Artifactory interno da SAP
  • Obter privilégios de cluster-admin no cluster Kubernetes do SAP AI Core
  • Acessar credenciais de nuvem de clientes e artefatos privados de IA
• Um possível atacante poderia acessar dados de clientes e contaminar artefatos internos, espalhando o impacto para serviços relacionados e ambientes de outros clientes
• Todas as vulnerabilidades foram relatadas à equipe de segurança da SAP e corrigidas pela SAP, que reconheceu o caso em sua página de créditos para pesquisadores de segurança
• Dados de clientes não foram violados

Problemas revelados do ponto de vista defensivo

• A principal linha de defesa era uma estrutura em que o Istio bloqueava o acesso à rede interna, mas, depois que essa barreira foi contornada, vários ativos internos não exigiam autenticação adicional
• Como a rede interna era tratada como uma zona confiável, um único bypass escalou para controle do serviço
• Se os serviços internos estivessem reforçados, o impacto do ataque poderia ter sido reduzido de controle completo do serviço para um incidente de segurança menor
• Serviços gerenciados baseados em Kubernetes podem criar armadilhas de isolamento de tenants, porque o plano de controle e a computação dos clientes são conectados logicamente por APIs, identidades, computação compartilhada e separação de rede baseada em software
• Como o treinamento de IA exige, por natureza, execução de código arbitrário, são necessários guardrails para separar adequadamente código não confiável de ativos internos e de outros tenants

Cronograma de divulgação

• 25 de janeiro de 2024: a Wiz Research relatou as descobertas de segurança à SAP
• 27 de janeiro de 2024: a SAP respondeu e atribuiu um número de caso
• 16 de fevereiro de 2024: a SAP corrigiu a primeira vulnerabilidade e rotacionou os segredos relacionados
• 28 de fevereiro de 2024: a Wiz Research contornou o patch com duas novas vulnerabilidades e as relatou à SAP
• 15 de maio de 2024: a SAP implantou correções para todas as vulnerabilidades relatadas
• 17 de julho de 2024: divulgação pública

[GN⁺]

Opiniões no Hacker News

• Entendo que seja um produto de IA, mas a vulnerabilidade aqui está na configuração do k8s
  Ela não tem muita relação com o produto de IA em si, nem com treinamento de IA, machine learning ou IA generativa; está mais próxima de uma segurança de plataforma em nuvem malfeita

  • Talvez seja até pior. Uma empresa tão grande e que lida com tantas informações importantes quanto a SAP ter errado em segurança básica de nuvem soa como um erro comum, não como algo novo feito de forma errada
  • O texto não diz que o problema é do produto em si. Pelo contrário, explica bem que é uma questão de isolamento dos modelos de treinamento de IA
    O fato de “um invasor ter conseguido executar um modelo de IA malicioso e procedimentos de treinamento” é a causa raiz, e isso é essencialmente execução de código
    Entendo que isso foi pesquisado e investigado porque produtos de IA estão se espalhando amplamente e é preciso ter cuidado com essa infraestrutura
  • A marca vendida deve assumir a responsabilidade
    Aplicar segurança, saber que segurança é necessária, testar ou não lançar até estar seguro são todas coisas que essa marca, como vendedora, deve fazer

• Eu gostaria que a SAP fizesse uma retrospectiva rigorosa sobre por que a pesquisa da Wiz não foi bloqueada antes de chegar a privilégios totais de administrador do cluster
  Gostaria de saber se a SAP recebeu alertas sobre essa atividade e se investigou adequadamente. Também fico curioso se há regulamentações que obriguem a SAP a ter mecanismos de alerta suficientes para atividades de rede suspeitas, e se esta pesquisa poderia servir como evidência de que eles não cumpriram isso

  • Regras e regulamentações certamente existem. Basta ver a página de certificações: https://www.sap.com/about/trust-center/certification-complia...
    A questão é se elas são realmente seguidas ou se ficam só em um fichário na prateleira
  • Normalmente, um pesquisador de segurança deve entrar em contato com o alvo antes de se aprofundar mais no sistema e pedir permissão para continuar
    Programas de bug bounty também costumam exigir regras assim dentro do escopo-alvo. Como os pesquisadores pertencem a uma empresa de segurança, imagino que tenha sido assim aqui também
    Pesquisadores normalmente escrevem no artigo em que ponto pediram autorização adicional, mas nem sempre fazem isso
  • Se de fato não detectaram, fica a dúvida de como sabem que dados de clientes não foram comprometidos
  • A SAP carece de competência em segurança de nuvem. Há uma longa lista de problemas de segurança nos serviços de nuvem da SAP, e isso contando apenas os conhecidos
  • Seria bom ver um artigo mostrando como detectar esse tipo de coisa em IA

• É chocante que uma instância do tiller estivesse rodando. Ele está sem suporte desde 2020: https://helm.sh/blog/helm-v2-deprecation-timeline/

  • Você ficaria horrorizado se soubesse quanto software anterior a 2020, e até anterior a 2010, ainda roda em ambientes de produção
    Aqui se trata de uma grande empresa e há uma migração um tanto complexa para sair do tiller, mas software antigo é encontrado facilmente mesmo sem essas circunstâncias atenuantes
  • Pela minha experiência, “sem suporte” muitas vezes é entendido como “ainda não foi removido, então pode continuar usando”, o que às vezes é bastante desanimador
  • O Microsoft Dynamics tem uma quantidade enorme de código legado antigo, inseguro e sem patches

• Isso é realmente ruim. Eles operavam um único cluster K8s e esperavam garantias fortes de multitenancy?
  As principais nuvens usam limites de máquinas virtuais e clusters K8s separados entre clientes. A Microsoft também sofreu algo parecido alguns anos atrás em um de seus produtos de funções, no qual esperava que o K8s fosse um limite de segurança principal

  • Posso ter deixado passar a parte em que o texto diz que eles esperavam garantias fortes, mas onde isso aparece?
    Por exemplo, em uma situação de execução de código arbitrário, como treinamento de modelos, não sei bem que papel a multitenancy do K8s desempenha
    Pelo que vejo, o problema principal foi confiar em toda a comunicação da rede interna depois que se entrava por trás do Istio, que é um proxy/firewall. Mas talvez eu simplesmente não entenda clusters k8s o suficiente
  • Multitenancy forte dentro do mesmo cluster K8s lógico é, na prática, difícil de alcançar
    É um alvo que muda o tempo todo, então planos de torná-la segura com admission controllers também não são muito bons
    Se você quer considerar multitenancy forte presumindo tenants hostis, deveria começar olhando coisas como VirtualClusters (https://github.com/kubernetes-sigs/cluster-api-provider-nest...). E isso trata apenas do plano de controle, nem toca no plano de dados
    Mesmo com essa camada adicional, não sei o quão seguro seria. Até no mundo das máquinas virtuais houve, ao longo dos anos, vulnerabilidades absurdas de escape de VM
  • Um K8S configurado corretamente foi literalmente projetado para multitenancy
    Manter um cluster separado para cada cliente é absurdamente caro e ruim para o planeta. Pode ser possível para um produto premium em que segurança é a prioridade máxima, mas clusters separados por cliente são, na prática, queimar dinheiro

• Acho que empresas que invadem redes sem permissão para encontrar vulnerabilidades e produzir conteúdo de blog deveriam ser processadas
  Este texto, em especial, soa como um texto ofensivo finamente disfarçado de divulgação de vulnerabilidade. A frase “agradeceram pela cooperação” também soa um pouco como extorsão

  • Isso pode ser reformulado como “empresas que coletam descuidadamente dados sensíveis de usuários e os armazenam de forma insegura não deveriam ser examinadas de perto, e deveriam ser deixadas continuar expondo dados de usuários inocentes a cibercriminosos mal-intencionados”
    Visto por esse ângulo, não parece bem diferente?
  • Tentar invadir uma grande empresa sem ser convidado é crime e, normalmente, seria algo processado com seriedade
    Mas, como diz a prática jurídica, acaba virando algo como “quando se tem bilhões de dólares, a lei deixa de se aplicar”

• Alguém aqui já usou o Wiz?
  Talvez seja o foguete mais rápido entre as empresas de software corporativo. Chegou a US$ 100 milhões de ARR em 1,5 ano e a US$ 350 milhões no fim do terceiro ano
  https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...

  • Uso e estou muito satisfeito. Mesmo deixando de lado o aspecto de segurança, foi a melhor ferramenta que já usei para fazer gestão de ativos multicloud direito
    Com o recurso de grafo, dá para consultar praticamente qualquer coisa em todas as contas, se você quiser
  • O Google também está tentando comprá-la por US$ 23 bilhões

• Ainda bem que consegui convencer o pessoal da empresa a rodar o teste de invasão anual do produto no ambiente de produção e incluir toda a infraestrutura de produção no escopo
  O foco pode ser um produto ou sistema específico, mas tudo está dentro do escopo. O primeiro teste está em andamento e, como ninguém gritou ainda, espero que dê certo

  • Quando você diz anual, posso entender que vocês não fazem testes de invasão internos regulares?
    Também queria saber se você pode recomendar alguma empresa de pentest que faça um trabalho de verdade, além de passar por cima com Metasploit de qualquer jeito

• Se eu li direito, os dados das contas dos clientes foram expostos para esses mesmos clientes? Parece que só parte dos logs foi exceção

  • Não foi só parte dos logs: também foram expostos dados de treinamento e código de outros clientes, além do repositório interno de imagens Docker da SAP. E com permissão de leitura e escrita!

• Um pesquisador de segurança deveria saber que pixelizar texto para ocultá-lo não é uma boa escolha
  https://www.bleepingcomputer.com/news/security/researcher-re...

  • Todos os bugs reportados foram corrigidos, e os segredos que podem ter sido comprometidos provavelmente também foram rotacionados
    Desfoque ou pixelização parecem praticamente desnecessários, independentemente de funcionarem ou não. Os dados ocultados parecem ser nomes de host locais e partes de hashes de imagens
  • Para mim, parecia desfoque, não pixelização
    Edit: olhando de novo, parece que em alguns lugares foi desfoque e em outros, pixelização