Incidente de US$ 6,3 bilhões da Binance: o que aconteceu e como reduzir o risco

As conclusões preliminares da Binance descrevem o comprometimento de funcionários em junho e setembro, seguido por uma invasão mais ampla por meio de ferramentas internas de IA em 20 de outubro. Os invasores acessaram os computadores de dois colegas e encontraram um token para implantar contêineres. Em 29 de outubro, usaram esse token para implantar código malicioso que alcançou os sistemas de assinatura de carteiras e iniciou transferências não autorizadas.

Os invasores também usaram o serviço de assinatura para criar uma delegação EIP-7702: uma permissão para que código sob seu controle agisse em nome de uma carteira Ethereum. Essa permissão existia na blockchain, independentemente dos sistemas de saque da Binance. Suspender os saques não a removia. A Binance precisou de uma revogação separada na própria blockchain.

A distinção importante é entre interromper uma atividade e remover a autoridade que a permite. Substituir um dispositivo, revogar uma credencial de implantação e cancelar uma permissão em outro sistema tratam de partes diferentes de uma invasão.

Um notebook, um sistema de implantação e um serviço sensível têm funções diferentes. O risco aumenta quando o acesso a um abre automaticamente o seguinte. Um token roubado pode permitir que um invasor substitua software. Esse software pode então agir com permissões que o funcionário nunca teve diretamente.

Quatro perguntas ajudam a identificar onde interromper essa progressão:

1. Exposição de credenciais. Que acesso à produção um invasor pode obter a partir do dispositivo de um funcionário?
2. Privilégios de implantação. Quem pode alterar o código executado com esse acesso?
3. Autorização do serviço. Quais ações um serviço sensível aceitará desse código?
4. Acesso persistente. Quais novas permissões podem permanecer depois que a conta original for desativada?

O objetivo é limitar como a autoridade passa entre sistemas e identificar e revogar qualquer acesso adicional criado durante uma invasão. As próximas seções examinam quatro controles que apoiam esse objetivo.

Controle 1. Reduza as credenciais que um notebook pode expor

Uma credencial é útil para um invasor porque outro sistema a aceita como prova de autoridade. Manter menos credenciais de produção nos dispositivos dos funcionários reduz o que pode ser roubado quando uma ferramenta, um repositório ou uma sessão do navegador é comprometido.

No trabalho de rotina, um funcionário muitas vezes precisa de permissão para solicitar uma operação, como reiniciar um serviço. A credencial que a executa pode ficar com uma identidade de execução separada. Reduzir a exposição envolve remover cópias desnecessárias e gerenciar as credenciais que permanecem:

• Substitua o acesso direto de rotina por operações bem delimitadas sempre que possível.
• Use identidades separadas para responsabilidades diferentes e limite seu escopo e sua duração.
• Mantenha um inventário de credenciais, de seus responsáveis e de como revogá-las.

Isso aplica o princípio das orientações da OWASP para gerenciamento de segredos: reduza o manuseio humano de segredos e conceda apenas o acesso necessário a cada identidade. Assim, uma estação de trabalho roubada expõe menos credenciais reutilizáveis, e a equipe de resposta sabe quem é responsável pelas que ainda precisam ser revogadas.

Controle 2. Trate os direitos de implantação como privilégios de produção

Um segredo pode estar oculto para uma pessoa, mas disponível para o código que ela implanta. Quem pode alterar esse código talvez consiga ler o segredo, chamar uma API interna ou agir como a conta de serviço da aplicação. Por isso, o acesso de implantação deve ser avaliado de acordo com as permissões da carga de trabalho resultante.

As orientações da OWASP para segurança de CI/CD tratam alterações de repositório, configuração de pipelines e hosts de execução como partes do mesmo problema de segurança. A proteção precisa abranger o código antes da implantação e suas permissões depois dela:

• Exija revisão do código de produção e proteja a branch do repositório executada pela automação.
• Controle alterações nas definições de tarefas, nas dependências e nas entradas fornecidas na execução, além do script principal.
• Conceda às cargas de trabalho apenas as credenciais e o acesso à rede necessários à sua função.

Dois conjuntos de controles precisam funcionar juntos. As permissões de repositório e de implantação determinam quem pode alterar o código. Políticas separadas de identidade, host e rede limitam o que esse código pode fazer ao ser executado. O armazenamento central de segredos reduz a exposição, enquanto essas políticas restringem o programa que usa o segredo.

Controle 3. Autorize a operação, não apenas o chamador

Um serviço de assinatura pode manter sua chave privada oculta e ainda aceitar uma solicitação de assinatura prejudicial. A mesma distinção vale para um banco de dados ou uma API de nuvem: autenticar uma carga de trabalho identifica o chamador, enquanto a autorização decide o que ele pode fazer.

A OWASP recomenda verificar a autorização em cada solicitação e negar o acesso quando ele não for explicitamente permitido. No serviço que recebe a solicitação, isso significa verificar a ação e seu destino: destinatários e valores de pagamento permitidos, operações de banco de dados ou alterações de infraestrutura.

O resultado deve ser um serviço que avalia a ação solicitada mesmo quando o chamador já é confiável. A automação controla como o trabalho é solicitado. O serviço de destino controla quais operações aceitará.

Controle 4. Revogue o acesso criado durante a invasão

Um invasor pode usar uma identidade legítima para adicionar outra credencial ou conceder novas permissões. O MITRE ATT&CK documenta a manipulação de contas como forma de manter ou ampliar o acesso, inclusive adicionando credenciais de nuvem e chaves SSH. Desativar a sessão original não remove necessariamente essas alterações.

A delegação na blockchain da Binance mostra por que a equipe de resposta precisa inspecionar as permissões no próprio sistema afetado. A contenção deve abranger o ponto de entrada inicial e a autoridade criada por meio dele:

• Limite quais identidades de automação podem criar outras credenciais ou conceder permissões.
• Inclua contas, sessões e delegações recém-criadas no plano de resposta.
• Verifique a revogação no sistema que aplica a permissão, em vez de considerar uma tarefa interrompida como prova de contenção.

Essas etapas dão à equipe de resposta um conjunto definido de identidades e permissões para investigar e revogar. Também tornam a contenção verificável: a equipe pode conferir se cada caminho conhecido até o serviço afetado foi realmente fechado.

Esses controles atuam em camadas diferentes: o dispositivo do funcionário, o sistema de implantação, o serviço de destino e o processo de resposta. Cada camada precisa de um responsável e de uma forma de verificar se suas restrições continuam válidas quando outra camada é comprometida.

As plataformas de gerenciamento de automação tratam da parte desse problema entre a solicitação de um funcionário e a execução em produção. No Semaphore UI, a equipe pode preparar uma tarefa definida, controlar quem pode executá-la ou alterá-la e executá-la com uma identidade separada. A autorização dentro do serviço de destino e a revogação de permissões criadas em outros locais continuam sendo responsabilidade desses sistemas e da equipe de resposta.

Considere um engenheiro de plantão que precisa reiniciar um serviço de API. Um mantenedor prepara um playbook e um Task Template que fixam os hosts de destino e como o reinício será feito. O engenheiro inicia a tarefa e lê o resultado, sem abrir uma sessão SSH em produção. Os dois caminhos abaixo fazem o mesmo reinício, mas deixam a credencial de execução em mãos diferentes.

Construir o fluxo de reinício exige quatro etapas conectadas: criar uma identidade de execução restrita, definir o que os usuários podem executar ou alterar, escolher o ambiente de execução e tornar o resultado visível. Depois dessas etapas, a mesma abordagem pode ser estendida às implantações.

Uma sessão de operador roubada ainda pode solicitar as operações permitidas àquela conta. Até um reinício autorizado pode interromper um serviço se for acionado repetidamente. Teste o fluxo configurado com uma conta de operador realista em homologação, cobrindo tanto o que ela pode fazer quanto como a equipe responderia ao uso indevido:

• Permissões de tarefas e entradas. Teste as funções e opções de execução reais, incluindo branches, inventários e argumentos alternativos.
• Acesso além da operação pretendida. Verifique o acesso a outros templates, credenciais e sistemas de produção, incluindo o que o processo do runner pode alcançar.
• Detecção e impacto operacional. Confirme quem recebe os resultados, quem investiga atividades inesperadas e se execuções repetidas podem causar interrupções inaceitáveis.
• Revogação. Teste a revogação de sessões e tokens e identifique quaisquer permissões que a identidade de execução possa criar em outros locais.

Documente o acesso que a conta de teste mantém e feche qualquer caminho que exceda a finalidade da operação. Ao concluir o exercício, a equipe deve saber tanto o que uma sessão roubada poderia fazer quanto como detectar e conter esse uso indevido.

Os controles de acesso funcionam junto com a proteção de endpoints e uma equipe que sabe como responder. Torne o fluxo preparado conveniente o bastante para que as pessoas possam usá-lo sem recorrer a chaves compartilhadas e atalhos não documentados. Apoie-o com algumas práticas diárias:

• Execute instaladores desconhecidos e tarefas de entrevistas em ambientes descartáveis e isolados, sem credenciais corporativas, diretórios do host montados ou acesso às redes internas.
• Facilite a comunicação precoce de atividades suspeitas, sem culpabilização. Ofereça um contato claro e um caminho de resposta a incidentes.
• Revise os acessos quando as responsabilidades mudarem, mantenha um procedimento controlado de acesso emergencial e ensaie a revogação antes de um incidente.

Essas práticas conectam prevenção, detecção e recuperação ao trabalho diário. Ajudam a manter o modelo de acesso correto conforme as responsabilidades mudam e dão à equipe uma resposta conhecida quando ocorre um evento suspeito.

A principal lição é limitar quanta autoridade uma identidade comprometida pode acumular. Menos credenciais em notebooks, automação revisada, hosts de execução restritos e autorização dentro dos serviços de produção reduzem os caminhos que um invasor pode seguir.

O Semaphore incorpora vários desses controles em um fluxo repetível: tarefas preparadas, permissões separadas para executar e editar, credenciais fornecidas centralmente e registros de execução visíveis. Os operadores recebem as ações necessárias ao seu trabalho, enquanto os mantenedores mantêm o controle do código e das credenciais por trás delas.

Comece por uma operação de produção usada com frequência: prepare seu template de tarefa, atribua as permissões de operador necessárias e teste o acesso resultante antes de desativar a conexão direta que ele substitui. Uma medida útil de progresso é o pouco que um invasor consegue fazer com a próxima conta que comprometer.