Depois de ler o relatório de investigação da Binance, confesso que fiquei um pouco assustado.
Um engenheiro queria instalar uma ferramenta popular de programação com IA e encontrou um instalador do Homebrew adulterado. Outra pessoa recebeu um convite numa plataforma legítima de empregos, fez primeiro uma videochamada com alguém de verdade do RH e depois uma entrevista com o “CEO”. A conta da outra pessoa nas redes sociais tinha até fotos e vídeos do dia a dia. Só no fim pediram que baixasse uma “tarefa de entrevista” com código malicioso.
Se fosse só um link de um desconhecido ou um instalador suspeito, acredito que todos ficariam alertas. Mas, depois de toda essa preparação, não posso dizer que teria certeza de perceber o golpe.
Em vez de me perguntar como os funcionários puderam ser enganados tão facilmente, quero saber: depois de comprometer o computador de um funcionário, até onde os invasores conseguem chegar?
No relatório, dois caminhos de ataque distintos acabaram convergindo nos sistemas internos. Os invasores usaram ferramentas internas de IA para assumir o controle de dispositivos de outros engenheiros, obtiveram tokens de implantação e, por fim, chegaram à etapa de autorização de transações da carteira.
Como o comprometimento de um único dispositivo pode se transformar numa perda de controle de permissões em tão larga escala? É isso que dá medo.
Pensando na forma como costumo trabalhar, percebo que também faço muitas coisas por praticidade. Deixo chaves de API guardadas por aí, mantenho credenciais de servidores válidas por muito tempo e nem sempre me lembro de revogar as permissões temporárias que concedi quando já não são mais necessárias.
Quando se trata de ferramentas de IA, é ainda mais fácil se identificar. Peço que leiam arquivos, executem comandos, se conectem a servidores, façam implantações automaticamente… Sempre há um motivo para conceder mais permissões e, depois que as concedo, a ferramenta realmente trabalha mais rápido. Depois de passar horas tentando fazer algo funcionar, aparece mais uma solicitação de permissão, e é muito fácil clicar em “Permitir” sem pensar.
O relatório da Binance menciona que uma ferramenta interna de IA foi usada como trampolim para novas invasões, mas o mecanismo exato ainda não foi divulgado. Mesmo assim, ao chegar a esse ponto, já fiquei com vontade de verificar: a quais arquivos minha IA tem acesso? Quais credenciais ela pode usar? Quando testo um projeto novo, será que acabo expondo também os dados de outros projetos?
Queremos sempre que a IA faça menos perguntas e consiga avançar mais por conta própria. Mas, para poupar algumas confirmações, podemos acabar concedendo permissões muito além do necessário para a tarefa em questão.
Não posso garantir que nunca vou ser enganado. Mas pelo menos posso tomar algumas precauções: separar o ambiente de trabalho do ambiente de testes, manter carteiras e chaves em locais separados e revogar as permissões temporárias assim que terminar de usá-las.
Não deixe que uma única autorização se transforme em confiança permanente.
$BNB #币安10·30安全事件调查报告
Um engenheiro queria instalar uma ferramenta popular de programação com IA e encontrou um instalador do Homebrew adulterado. Outra pessoa recebeu um convite numa plataforma legítima de empregos, fez primeiro uma videochamada com alguém de verdade do RH e depois uma entrevista com o “CEO”. A conta da outra pessoa nas redes sociais tinha até fotos e vídeos do dia a dia. Só no fim pediram que baixasse uma “tarefa de entrevista” com código malicioso.
Se fosse só um link de um desconhecido ou um instalador suspeito, acredito que todos ficariam alertas. Mas, depois de toda essa preparação, não posso dizer que teria certeza de perceber o golpe.
Em vez de me perguntar como os funcionários puderam ser enganados tão facilmente, quero saber: depois de comprometer o computador de um funcionário, até onde os invasores conseguem chegar?
No relatório, dois caminhos de ataque distintos acabaram convergindo nos sistemas internos. Os invasores usaram ferramentas internas de IA para assumir o controle de dispositivos de outros engenheiros, obtiveram tokens de implantação e, por fim, chegaram à etapa de autorização de transações da carteira.
Como o comprometimento de um único dispositivo pode se transformar numa perda de controle de permissões em tão larga escala? É isso que dá medo.
Pensando na forma como costumo trabalhar, percebo que também faço muitas coisas por praticidade. Deixo chaves de API guardadas por aí, mantenho credenciais de servidores válidas por muito tempo e nem sempre me lembro de revogar as permissões temporárias que concedi quando já não são mais necessárias.
Quando se trata de ferramentas de IA, é ainda mais fácil se identificar. Peço que leiam arquivos, executem comandos, se conectem a servidores, façam implantações automaticamente… Sempre há um motivo para conceder mais permissões e, depois que as concedo, a ferramenta realmente trabalha mais rápido. Depois de passar horas tentando fazer algo funcionar, aparece mais uma solicitação de permissão, e é muito fácil clicar em “Permitir” sem pensar.
O relatório da Binance menciona que uma ferramenta interna de IA foi usada como trampolim para novas invasões, mas o mecanismo exato ainda não foi divulgado. Mesmo assim, ao chegar a esse ponto, já fiquei com vontade de verificar: a quais arquivos minha IA tem acesso? Quais credenciais ela pode usar? Quando testo um projeto novo, será que acabo expondo também os dados de outros projetos?
Queremos sempre que a IA faça menos perguntas e consiga avançar mais por conta própria. Mas, para poupar algumas confirmações, podemos acabar concedendo permissões muito além do necessário para a tarefa em questão.
Não posso garantir que nunca vou ser enganado. Mas pelo menos posso tomar algumas precauções: separar o ambiente de trabalho do ambiente de testes, manter carteiras e chaves em locais separados e revogar as permissões temporárias assim que terminar de usá-las.
Não deixe que uma única autorização se transforme em confiança permanente.
$BNB #币安10·30安全事件调查报告
