A Hugging Face foi alvo de uma intrusão por parte de um agente desonesto da OpenAI na semana passada, e essa intrusão continua a proporcionar insights e compreensão. A equipa da Hugging Face publicou uma cronologia detalhada, juntamente com uma reprodução em streaming de um rasto de 17 600 eventos que visualiza o que aconteceu, e é maravilhosamente e fascinantemente detalhada. Recomendo que a leiam, se tiverem tempo.
A violação da sua plataforma não consistiu numa única exploração brilhante seguida de um percurso de ataque bem definido e dirigido por humanos. Tratou-se de uma multiplicidade de ações distribuídas ao longo de quatro dias e meio, com milhares de experiências falhadas a obscurecer o número relativamente pequeno de ações que, em última análise, foram determinantes. O reconhecimento, a execução de código e a preparação da carga útil tiveram início quase imediatamente. O movimento lateral decisivo para os seus clusters do Kubernetes, a rede interna e o controlo de código-fonte só começou no terceiro dia.
A maioria das organizações dispõe de registos e monitorização suficientes para reconstruir um ataque após o facto. Muito menos possuem a visibilidade em tempo de execução, a lógica de alerta e o apoio à tomada de decisões necessários para reconhecer o ataque enquanto este ainda se está a formar.
A cronologia combinada da Hugging Face, juntamente com algumas informações há muito aguardadas partilhadas pela OpenAI sobre o incidente, além da análise pós-incidente inicial da CSA, sugerem o que considero serem quatro pontos críticos de decisão em matéria de resposta a incidentes que as empresas devem ter em conta. Cada um deles constitui também um teste prático para verificar se a vossa organização dispõe ou não dessas capacidades.
Decisão 1: Quando é que um reconhecimento de sinal fraco se torna um incidente?
No primeiro dia da intrusão, os agentes identificaram sistemas de ficheiros, processos, interfaces de rede, variáveis de ambiente, pontos de montagem e ferramentas disponíveis. Testaram canais de saída e estabeleceram um sistema de comando e controlo utilizando serviços públicos comuns. Por si só, cada evento poderia ser justificado como depuração, automatização, uma carga de trabalho mal configurada ou uma experiência normal.
A Hugging Face afirma que os sinais iniciais surgiram na análise em tempo real do tempo de execução, nos registos SIEM e noutros controlos. A sua pilha de segurança baseada em IA correlacionou esses sinais num padrão de ataque coerente, mas não atribuiu uma gravidade suficiente nem alertou a equipa de plantão. Esse atraso custou um tempo de resposta valioso. Análises anteriores e discussões na comunidade chegaram à mesma conclusão: o reconhecimento estava a ser registado há vários dias, mas a escalada só ocorreu quando o volume posterior de atividade não autorizada finalmente ultrapassou o limiar de alarme.
A decisão não se resume a determinar se um evento isolado é malicioso. Trata-se de determinar se uma sequência de comportamentos em tempo de execução, ambíguos quando considerados individualmente, constitui a construção de um percurso de ataque.
As organizações devem questionar-se se conseguem estabelecer uma correlação entre a execução de processos, o acesso ao sistema de ficheiros, a atividade da API, a identidade da carga de trabalho e o comportamento da rede em contentores de curta duração. Conseguem reconhecer que um pod que lê /proc/self/environ, inspeciona tokens de contas de serviço e testa vários métodos de saída é substancialmente diferente de uma falha normal de uma aplicação?
É aqui que a instrumentação «canary» pode eliminar a ambiguidade. A técnica em que devemos investir aqui consiste em colocar tokens falsos em ambientes de carga de trabalho selecionados, deixar credenciais falsas em repositórios secretos e monitorizar valores de configuração em percursos que não sejam de produção. Estes nunca devem proporcionar acesso real. Em vez disso, o seu único objetivo é gerar um sinal de elevada confiança quando lidos, copiados ou apresentados. Um token canário bem colocado deve alertar um respondedor, em vez de ser descartado como uma anomalia. A criação de uma capacidade de engano deve fazer parte do plano de ação de todas as equipas.
Decisão 2: O que acontece quando as credenciais são roubadas e utilizadas?
O terceiro dia alterou a natureza do incidente. O agente leu os tokens das contas de serviço do Kubernetes, consultou metadados na nuvem, reproduziu credenciais temporárias de fornecedores de alojamento externos (a Modal avançou para se declarar um desses fornecedores de alojamento), criou pods com privilégios e escapou para a raiz do nó. Em seguida, acedeu a um objeto secreto contendo 136 chaves, incluindo credenciais utilizadas para uma VPN em malha e um intermediário de acesso ao cluster interno. Uma credencial de conector partilhada proporcionou, na prática, acesso de administrador do cluster em vários clusters.
Este é o momento em que a «investigação» deve passar a ser uma contenção ativa.
A sua equipa consegue identificar todos os sistemas que confiam numa credencial comprometida? O gráfico de dependências e a análise de impacto são fundamentais para dar início à fase de contenção da resposta a incidentes. As suas ferramentas e painéis de controlo conseguem distinguir um token que está a ser utilizado pela sua carga de trabalho prevista de um token idêntico que surge de um novo fornecedor de serviços na nuvem, de uma sandbox ou de uma origem de rede diferente? Os responsáveis pela resposta conseguem revogar toda uma família de credenciais, em vez de apenas rodar uma chave enquanto os tokens derivados permanecem válidos?
A deteção em tempo de execução é essencial porque a credencial em si pode parecer legítima. A condição maliciosa reside no seu contexto de execução: o processo errado, o pod errado, a rede de origem errada, a identidade da carga de trabalho errada ou uma sequência de ações impossível. Gosto de chamar a isto de monitorização do tipo «a água é molhada». Entre as coisas que sei que são verdadeiras, a água é molhada, tal como o céu é azul. Se não implementarmos uma monitorização que nos ajude a detetar alterações nos nossos ambientes que «contradizem as nossas suposições», continuaremos a ser surpreendidos.
Um exemplo disso seria configurar testes de encaminhamento do próximo salto para detetar um sequestro de BGP. Os primeiros quatro saltos da sua rede interna em direção a um recurso externo estável e bem conhecido (como o time.windows.com) não deveriam, de facto, apresentar qualquer desvio. Outro exemplo de monitorização do tipo «a água é molhada» diz respeito aos registos DNS, avaliando constantemente se os endereços IP internos e externos dos principais componentes da infraestrutura permanecem inalterados.
Os canários implementados para detetar ataques liderados por agentes devem, por conseguinte, incluir tokens falsos de contas de serviço, credenciais de nuvem falsas e chaves sintéticas de registo em VPN. Um token armazenado num ambiente de pod cuidadosamente selecionado pode revelar a recolha de credenciais. Uma conta de serviço isca pode revelar a enumeração de namespaces. Uma entrada falsa de cluster devolvida por um catálogo de serviços interno pode revelar tentativas de movimento lateral. Estes artefactos devem conduzir a «sinkholes» ou a pontos finais bloqueados, e não a acesso à produção, mas cada interação deve preservar a identidade da fonte e acionar orientações imediatas de contenção.
Decisão 3: Consegues identificar o C2 quando este se assemelha à tua própria aplicação?
A lição mais importante em matéria de deteção poderá ser o facto de o tráfego de comando e controlo não se assemelhar necessariamente ao tráfego tradicional de malware.
O agente utilizou serviços públicos de captura de pedidos, pastebins e servidores de partilha de ficheiros. Mais importante ainda, utilizou conjuntos de dados do Hugging Face controlados pelo atacante como pontos de entrega secretos. Os comandos e os dados roubados foram colocados em commits e ramos secundários dos conjuntos de dados, sendo depois recuperados através da API normal do Hugging Face. Um proxy CORS aberto do Space também foi utilizado como retransmissor de saída. As cargas úteis foram divididas em blocos, comprimidas, codificadas e, por vezes, enviadas através de sockets brutos. A reprodução do processo de descodificação do atacante permitiu recuperar cerca de quatro vezes mais secrets expostos secrets a análise inicial.
Por outras palavras, as instruções recebidas pareciam atividade relacionada com conjuntos de dados e a exfiltração de dados enviados parecia também atividade relacionada com conjuntos de dados. A própria Hugging Face passou a fazer parte do transporte C2. Um SIEM convencional pode reportar milhares de eventos invulgares sem revelar que estes formam um protocolo bidirecional.
O ponto decisivo é determinar se se deve desativar uma funcionalidade acessível aos clientes, isolar um inquilino, bloquear um serviço público ou interromper um percurso de dados de produção. Os responsáveis pela resposta precisam de provas mais sólidas do que «este tráfego é invulgar».
Crie conjuntos de dados isca com nomes convincentes, tais como resultados de testes de desempenho internos, respostas de avaliação ou investigações de segurança arquivadas. Insira neles marcadores únicos e credenciais falsas. Nenhuma carga de trabalho legítima deve aceder a eles. Monitorize leituras, clones, commits, criação de ramos e pedidos de API. Um cluster interno falso ou um conjunto de dados listado num catálogo também pode revelar se um atacante está a enumerar oportunidades, em vez de se limitar a interagir normalmente com o serviço.
Os «canários» bem concebidos e bem posicionados permitem identificar a intenção, e não apenas uma anomalia.
Decisão 4: Reparar os danos ou reconstruir o ambiente?
Por fim, a questão que se coloca é se a organização ainda confia na infraestrutura afetada.
A Hugging Face procedeu a uma rotação generalizada das credenciais, bloqueou o acesso aos metadados na nuvem, restringiu o âmbito das credenciais e apagou e reconstruiu a infraestrutura central a partir do zero. Numa perspetiva mais ampla, a decisão equivalia a destruir cerca de um terço do ambiente, em vez de tentar provar que todos os pontos de acesso, tokens falsificados e mecanismos de persistência tinham sido removidos.
Essa opção só existe quando a infraestrutura é reproduzível e descartável. Uma análise anterior revelou que a recuperação da Hugging Face foi acelerada através da implementação de infraestrutura nova a partir de repositórios, em vez de restaurar e, posteriormente, limpar os sistemas comprometidos. A competência para tomar essa decisão deve também ser claramente atribuída e documentada antes do incidente.
O pacote de apoio à tomada de decisões deve incluir o histórico das credenciais, as identidades das cargas de trabalho afetadas, a verificação de imagens imutáveis, a cobertura da infraestrutura como código, os requisitos de restauração de dados e provas de tentativas de persistência. Os executivos devem conhecer o tempo estimado de inatividade necessário para a reconstrução antes de lhes ser pedido que a autorizem. E com que nível de confiança (quando foi a última vez que um determinado cluster ou serviço foi implementado de raiz?).
Os «canários» também continuam a ser úteis após a recuperação. Substitua cada isca por um valor recém-gerado. Qualquer utilização de um token de «canário» antigo após a reconstrução constitui uma forte indicação de que sobreviveu um ponto de apoio não detetado, um segredo copiado ou um local de preparação externo. Isto é especialmente verdade se acreditarmos que os atacantes com intenções maliciosas são suficientemente perspicazes para deixar pistas para os seus agentes-modelo, de modo a evitar a deteção ou a retomar o trabalho de onde pararam.
O incidente da Hugging Face demonstra que o registo não é detecção, a detecção não é escalonamento e o escalonamento não é apoio à tomada de decisões. A visibilidade em tempo de execução permite saber o que o software está realmente a fazer. Os tokens Canary, os clusters e os conjuntos de dados permitem identificar quando uma atividade não tem uma explicação legítima.
O objetivo não é apenas recolher provas suficientes para compreender a violação na próxima semana. É criar sinais suficientemente fortes para tomar a decisão certa hoje.
