00:00:00Isso é sério e não é brincadeira, foram algumas horas difíceis, porque houve
00:00:06um enorme ataque de cadeia de suprimentos no Axios, sim, aquele Axios que tem mais de 80 milhões de downloads
00:00:14semanais.
00:00:15Agora, primeiro as coisas importantes.
00:00:18Para você verificar se foi afetado, anexei um link para um artigo, e
00:00:23compartilharei mais detalhes em um segundo, mas isso é importante, para você verificar se
00:00:27foi afetado, você deve seguir esse link abaixo e executar os comandos que vê lá
00:00:32para o seu sistema operacional, Mac OS, Linux, Windows, todos foram afetados.
00:00:37Você deve executar esses comandos se for afetado.
00:00:40E especialmente se esses passos aqui mostrarem que você foi comprometido, você precisará
00:00:49rotacionar seus segredos, alterar suas senhas, considere suas credenciais, as chaves de API no
00:00:55seu sistema, tudo o que está no seu sistema, como roubado.
00:01:00Considere sua senha roubada, mude tudo, desative as chaves de API, isso é muito importante.
00:01:07Agora, o que exatamente aconteceu?
00:01:09Axios, obviamente uma biblioteca JavaScript muito popular, uma biblioteca que pode ser usada para enviar requisições HTTP
00:01:17de, por exemplo, um app React para uma API de backend.
00:01:22Está sendo muito usada, como você pode ver, e algum código malicioso foi injetado nesta
00:01:28biblioteca.
00:01:29Agora, isso não significa que os sites que usam essa biblioteca foram afetados.
00:01:36Significa, em vez disso, que os sistemas onde você instalou essa biblioteca, seu MacBook, seu
00:01:41PC, ou talvez aquele VPS onde você construiu seu site, esses foram comprometidos.
00:01:50Se você executou npm install, bun install, npm update, bun update, algo assim nas últimas
00:01:57horas, há um alto perigo de você ter sido afetado.
00:02:00Novamente, compartilhei as verificações que você deve fazer para ver se foi afetado.
00:02:05Agora, como exatamente tudo isso aconteceu e o que exatamente é um ataque de cadeia de suprimentos?
00:02:10Eu também compartilharei, a propósito, como você pode se proteger contra ataques como este no futuro.
00:02:15Mas primeiro, vamos entender o que exatamente acontece e o que é um ataque de cadeia de suprimentos.
00:02:20Um ataque de cadeia de suprimentos é simplesmente um ataque que não visa o código da sua aplicação.
00:02:24O invasor não tenta infiltrar-se diretamente no seu sistema ou na sua base de código.
00:02:31Em vez disso, eles aproveitam o fato de que o código da sua aplicação normalmente tem dependências, que por sua vez
00:02:37têm dependências.
00:02:38Então você tem essa cadeia de dependências e o ataque visa essa cadeia.
00:02:45Portanto, ele acontece "upstream" (acima) do seu código.
00:02:48Assim, uma dessas dependências tem algum código malicioso devido a um ataque onde esse código foi
00:02:54injetado nela, não porque o mantenedor esteja tentando atacar você.
00:02:58Mas sim, por exemplo, como neste caso, a conta de um mantenedor é comprometida
00:03:03e o invasor usa isso para injetar código malicioso em alguma biblioteca, em algum pacote,
00:03:10que outro pacote pode estar usando e seu código pode estar usando esse pacote que
00:03:16usa o pacote malicioso, ou talvez o código da sua aplicação puxe diretamente a dependência maliciosa.
00:03:23De qualquer forma, uma das suas dependências agora, de repente, vem com algum código malicioso.
00:03:28E no momento em que você executa npm install ou algo assim, ou atualiza, aquele pacote é
00:03:36baixado para o seu sistema, aquele malicioso, aquele afetado, e então ele pode executar
00:03:41código malicioso no seu sistema, normalmente com a ajuda de scripts post-install.
00:03:47Caso você não saiba, o npm tem este mecanismo de scripts.
00:03:56Todos nós os usamos em nossos projetos, por exemplo, para iniciar um servidor de desenvolvimento, para buildar nosso projeto,
00:04:01para rodar testes, coisas assim.
00:04:04E existem especificamente os scripts post-install, que você pode não estar usando quando
00:04:11está construindo um app React, por exemplo, mas que as bibliotecas frequentemente usam ou podem não usar frequentemente,
00:04:17mas podem usar para rodar algum código no seu sistema após você instalar a biblioteca, normalmente não
00:04:23para fazer nada malicioso ou ruim, mas por exemplo, para compilar algum código, criar um binário que
00:04:31possa ser necessário por aquela biblioteca, preparar seu sistema de qualquer forma ou formato para que ele possa realmente
00:04:36usar a biblioteca que você acabou de baixar.
00:04:40Essa é a ideia por trás de um script post-install.
00:04:42Ele permite que um pacote defina algum código que deve ser executado após ter sido instalado
00:04:49através do npm install, por exemplo, e é exatamente isso que costuma ser aproveitado nesses
00:04:55ataques de cadeia de suprimentos.
00:04:57O invasor injeta algum código malicioso em um pacote que é essencialmente um script
00:05:04post-install que é executado automaticamente assim que o pacote infectado é instalado.
00:05:10Normalmente esse código é ofuscado para que não seja fácil de ler.
00:05:14Pode estar codificado em base64 para que scanners que buscam códigos maliciosos em pacotes possam
00:05:20não detectá-lo e/ou o código malicioso pode ser baixado.
00:05:24Portanto, o script post-install, como no caso do ataque ao Axios, na verdade não contém
00:05:30diretamente o código malicioso.
00:05:32Em vez disso, ele entra em contato com um servidor e baixa o código de lá.
00:05:36Foi o que aconteceu aqui.
00:05:37E temos um relatório detalhado sobre o que exatamente aconteceu durante esse ataque.
00:05:41Você encontrará isso anexo se quiser ler todos os detalhes, mas nele basicamente
00:05:45aprendemos que duas versões do pacote axios, 1.14.1 e 0.30.4, foram afetadas, foram comprometidas
00:05:57no final, e isso foi feito pelo invasor obtendo acesso à conta de um dos
00:06:02mantenedores do pacote axios e eles usaram essa conta para publicar uma nova versão do pacote axios
00:06:08que continha uma dependência que, por sua vez, continha aquele script post-install.
00:06:14Portanto, nem foi o pacote axios em si que continha o script post-install, mas
00:06:19sim outro pacote, o pacote plaincryptojs, que foi criado pelo invasor,
00:06:25cujo único propósito é ter um script post-install que baixa e executa algum código
00:06:31malicioso.
00:06:32Assim, o pacote axios foi comprometido ao adicionar o plaincryptojs como uma dependência do axios.
00:06:39Esse é um pacote malicioso.
00:06:40Ele não serve para outro propósito além de baixar aquele código malicioso e, apenas ao adicionar esta
00:06:46dependência ao Axios, o ataque estava essencialmente concluído.
00:06:52Este pacote não é importado no código-fonte do Axios em lugar nenhum.
00:06:56Ele apenas tem este script post-install e pronto.
00:06:59Como mencionado, ele é capaz de baixar e executar código no Mac OS, Windows e Linux para
00:07:05fazer o quê então?
00:07:06Bem, roubar um monte de coisas.
00:07:08Então, se o seu sistema for afetado, como mencionei inicialmente, credenciais, chaves de API, tokens de cripto,
00:07:14todas essas coisas divertidas estão sendo coletadas e exfiltradas por um trojan que é baixado por aquele script
00:07:21post-install.
00:07:22É assim que o ataque funcionou.
00:07:24É assim que ataques semelhantes funcionaram no passado.
00:07:29Agora, o que é meio interessante, bem, ah, a propósito, este ataque começou por volta da meia-noite,
00:07:36exatamente após a meia-noite UTC hoje, há algumas horas.
00:07:40Durou algumas horas e ambas as versões do Axios, 1.14.1 e 0.30.4, foram afetadas em
00:07:5040 minutos, essencialmente 39 minutos para ser preciso.
00:07:53Portanto, este foi um ataque muito orquestrado e planejado.
00:07:56Obviamente, a criação deste pacote extra aconteceu, eu acho, 18 horas antes do ataque
00:08:03começar.
00:08:04Foi muito orquestrado e planejado.
00:08:06Agora, o que é um pouco estranho aqui é que o NPM tem este mecanismo chamado "trusted publishing",
00:08:14que pode ser usado pelos mantenedores de pacotes.
00:08:17E a ideia aqui é que isso limita o processo de publicação de novas versões de um pacote a um processo
00:08:26claramente definido onde, especificamente, você tem que buildar e publicar uma nova versão através de
00:08:32um desses provedores de CI/CD suportados com uma certa configuração pela qual você tem que passar.
00:08:38E a ideia aqui é que mesmo que as credenciais da sua conta NPM sejam roubadas, em teoria,
00:08:46o invasor não pode publicar uma nova versão do seu pacote a partir de sua própria máquina porque ele
00:08:51precisa passar por aquele processo.
00:08:52Agora você pode argumentar que, se a conta do GitHub de um mantenedor for comprometida, então talvez
00:08:59uma versão maliciosa possa ser enviada para o GitHub, acionando esse fluxo de trabalho de deploy aqui e, portanto,
00:09:06o código malicioso é publicado através desse processo de "trusted publishing".
00:09:11Mas de acordo com o relatório de segurança aqui, não foi isso o que aconteceu.
00:09:16Porque a equipe do Axios está usando este processo de "trusted publishing" para a branch 1.x, não
00:09:21para a branch 0.30, mas para a branch 1.x.
00:09:26Mas, de acordo com este relatório, não há nenhum commit ou ataque no repositório GitHub do Axios.
00:09:33Portanto, não houve um push para o GitHub com aquela versão comprometida do Axios.
00:09:40Assim, o processo de "trusted publishing" não deveria ter sido acionado.
00:09:44Em vez disso, este relatório afirma que o invasor deve ter obtido um token de acesso NPM
00:09:50clássico de longa duração para publicar esta versão maliciosa ou comprometida do Axios porque
00:09:56o lançamento só existia no NPM, não no GitHub.
00:10:01Talvez isso esteja errado.
00:10:02Talvez o ataque tenha passado pelo GitHub.
00:10:05Se estiver correto, porém, não está claro para mim como exatamente funcionou porque, em teoria,
00:10:11esta forma de publicação não deveria ser possível quando o "trusted publishing" está ativado.
00:10:15Não tenho certeza se isso é alguma vulnerabilidade de segurança ou algum problema com o NPM aqui.
00:10:20Que alguns tokens existentes de longa duração ainda pudessem ser usados mesmo com o "trusted publishing"
00:10:26ativado.
00:10:27Isso é algo que não consegui descobrir como exatamente funcionou.
00:10:32E há uma thread aqui, uma issue no GitHub na biblioteca Axios onde este ataque foi
00:10:39reportado.
00:10:40A propósito, nota lateral, mais issues do tipo foram criadas e deletadas pelo mantenedor
00:10:45comprometido, pela conta do mantenedor comprometido.
00:10:48Esta thread, esta issue sobreviveu e o ataque foi finalmente interrompido.
00:10:52Eles recuperaram o acesso à conta daquele mantenedor que foi afetado.
00:10:56E naquela thread, naquela issue, o mantenedor posta e diz que eles estão usando o "trusted
00:11:03publishing" e não está claro como exatamente isso funcionou.
00:11:07Aqui está uma teoria que foi compartilhada.
00:11:09Mas meu entendimento é que essa teoria ainda exigiria uma nova versão maliciosa ou comprometida
00:11:16sendo enviada para o GitHub, mas, novamente, nada disso está claro.
00:11:20O que está claro é que versões comprometidas foram publicadas e acabaram no NPM e,
00:11:25portanto, puderam ser baixadas em sistemas e roubar coisas lá.
00:11:29E, claro, com mais de 80 milhões de downloads semanais, há muito estrago a ser feito em
00:11:35poucas horas.
00:11:37Obviamente, os downloads não são distribuídos uniformemente em todas as horas do dia, mas este é
00:11:44definitivamente um número enorme e podemos assumir que milhares, dezenas de milhares de sistemas
00:11:51foram afetados nessas poucas horas.
00:11:55Agora, é claro que este não foi o primeiro ataque de cadeia de suprimentos.
00:11:59Nos últimos meses, vimos vários ataques.
00:12:01Um grande ataque no final do ano passado, o ataque shy hulu, onde vários pacotes foram
00:12:08executados no NPM e isso teve um padrão semelhante, código malicioso sendo injetado e executado
00:12:16em sistemas que baixaram esses pacotes comprometidos e então credenciais e coisas sendo
00:12:21roubadas.
00:12:22Portanto, esse é um grande ataque.
00:12:25E então, apenas alguns dias atrás, tivemos um incidente semelhante no ecossistema Python.
00:12:31Portanto, não se limita ao JavaScript, onde o pacote lightllm foi afetado.
00:12:37Um pacote muito popular que, no fim das contas, facilita o uso de provedores de IA através de uma interface
00:12:43conveniente; este também sofreu um ataque semelhante e foi afetado.
00:12:49E, portanto, não é apenas o JavaScript, é claro.
00:12:52E eu acho que há algumas razões pelas quais vemos mais ataques desse tipo acontecendo.
00:12:57Porque, em teoria, esses tipos de ataques poderiam ter acontecido e provavelmente aconteceram no
00:13:03passado também, mas claramente eles estão se tornando mais frequentes agora e eu acho que há algumas
00:13:08razões para isso.
00:13:11Uma grande razão, claro, é que estamos em um momento em que mais código do que nunca
00:13:17está sendo escrito, gerado.
00:13:19Quero dizer, você pode olhar para várias métricas.
00:13:22Por exemplo, vi este gráfico recentemente mostrando que o número de novos repositórios GitHub sendo
00:13:27criados está em um nível recorde e, claro, isso é por causa da IA.
00:13:31Onde as pessoas estão trabalhando em projetos, estão gerando código.
00:13:35Temos mais produção de código do que nunca e, claro, isso significa que, com tantos outros programas
00:13:42sendo escritos, tanto mais código sendo gerado, a superfície de ataque é muito maior.
00:13:47Existem mais alvos.
00:13:48Há mais pessoas construindo ou escrevendo código e instalando pacotes.
00:13:52Então, é mais atraente do que nunca.
00:13:54Não que não fosse atraente no passado, mas agora há mais pessoas do que nunca que
00:13:59podem ser atacadas.
00:14:00Então, essa é, claro, uma grande razão.
00:14:03Simplesmente é mais interessante executar esses ataques, mas não é a única razão.
00:14:07Eu acho que outra razão também está relacionada à IA: primeiro, executar ataques como
00:14:15este com a ajuda da IA provavelmente ficou mais fácil, pois o código malicioso pode, claro,
00:14:21também ser gerado e escrito com a ajuda da IA, então as habilidades técnicas necessárias para executar tais
00:14:28ataques estão mais disponíveis do que no passado, eu diria, embora você também pudesse comprar scripts
00:14:33ou trojans como este na darknet, mas ainda assim pode estar mais acessível às pessoas.
00:14:40Não é apenas o lado bom da IA, que permite que mais pessoas construam softwares e transformem
00:14:46suas ideias em negócios ou o que quer que seja, mas também é o lado ruim.
00:14:50Mais pessoas podem fazer coisas ruins relacionadas ao código graças à IA, então essa é uma razão.
00:14:55Você também pode argumentar que, claro, os mantenedores de pacotes e de bibliotecas estão sobrecarregados
00:15:01com pull requests.
00:15:02Esse é outro grande problema que temos hoje em dia: se você é um mantenedor de código aberto, há
00:15:07mais pull requests chegando do que nunca, então você pode não ser super cuidadoso com o que
00:15:13você aceita (merge).
00:15:14Não foi o problema aqui, apenas para deixar claro.
00:15:16Neste ataque ao Axios, claramente foi uma conta comprometida, mas você poderia, em teoria,
00:15:22argumentar que seria possível que mantenedores aceitassem código malicioso ou código
00:15:29que instala dependências maliciosas em sua biblioteca porque eles simplesmente deixam passar ou talvez
00:15:34porque eles têm um processo de revisão de código totalmente automatizado que não detecta.
00:15:38Eles estão apenas confiando na IA.
00:15:40Novamente, não é o caso aqui, mas você pode pensar que isso poderia no futuro ser usado por invasores,
00:15:45que injetariam código malicioso em bases de código porque as pessoas simplesmente não olham.
00:15:51Além disso, quando você está usando o Cursor, o Claude, o que quer que seja em seu sistema para fazer
00:15:56todos os tipos de trabalho para você, não apenas ajudá-lo a trabalhar em software, mas talvez apenas gerenciar seu sistema
00:16:01como um todo, é claro que para certas tarefas essas ferramentas podem decidir
00:16:09escrever algum script e rodar algum código para fazer uma certa tarefa que você pediu, e esse
00:16:15código que elas geraram também pode depender de dependências como o axios.
00:16:20Então, novamente, a superfície de ataque está ficando maior, esse é meu primeiro argumento de novo, mas fora
00:16:24do desenvolvimento de software clássico e por todas essas razões e provavelmente muitas outras razões
00:16:30que não pensei aqui, esses ataques estão ficando mais lucrativos, fáceis de fazer e mais
00:16:37interessantes de fazer, e é por isso que estou certo de que veremos mais desses ataques no futuro.
00:16:43Agora, o que você pode fazer para prevenir tais ataques e se proteger?
00:16:47Um grande passo de segurança, uma coisa que você pode fazer é, em todos os seus projetos onde você está trabalhando
00:16:55em aplicações e assim por diante, quando você estiver usando ferramentas como pnpm em vez de npm para gerenciar
00:17:02suas dependências, você pode adicionar uma configuração de idade mínima de lançamento (minimum release age) ao seu arquivo pnpm-workspace.yaml.
00:17:09O bun tem um recurso semelhante; você pode adicionar um arquivo bunfig.toml se estiver usando o bun como gerenciador de pacotes
00:17:15e eles também têm uma configuração de idade mínima de lançamento que você pode adicionar nesse arquivo. O que isso faz?
00:17:21Isso simplesmente garante que, sempre que você instalar um pacote, ele apenas instale pacotes
00:17:27que tenham pelo menos aquela idade ou versões de pacotes que tenham pelo menos aquela idade.
00:17:34Portanto, se um pacote foi comprometido há cinco horas, mas você tem uma regra que só instala versões que
00:17:39têm pelo menos três dias de idade, você deve estar seguro. Essa é a ideia e, infelizmente, o próprio npm
00:17:46não tem isso agora. Só para ter certeza ou para que fique claro: ainda estamos falando de pacotes
00:17:51que estão hospedados no npm; esse não é o problema, estou falando do gerenciador de pacotes aqui.
00:17:56E você pode, claro, usar o bun ou pnpm para baixar esses pacotes do npm e, se você estiver usando-os
00:18:03em vez do próprio npm, a ferramenta em si, então você pode aproveitar configurações como esta,
00:18:08que simplesmente oferecem aquela camada extra de segurança porque, normalmente, no passado, esses ataques
00:18:14foram detectados em poucas horas; então, se você tiver, por exemplo, um limite de três dias,
00:18:20a maioria desses ataques já terá sido detectada e terá terminado. Não é 100%
00:18:25seguro, é claro, um ataque pode durar mais tempo, mas isso lhe dá uma vantagem clara e é
00:18:32definitivamente algo bom a se fazer agora. Para estar ainda mais seguro, você pode e deve considerar o uso de
00:18:39soluções como o Doppler, e isso não é patrocinado, é apenas um exemplo; existem alternativas.
00:18:44Eu construí minha própria alternativa, na verdade, que estou usando eu mesmo, que são serviços ou ferramentas que
00:18:49gerenciam seus segredos: então, algo como sua chave de API da OpenAI, você poderia colocá-la em um arquivo
00:18:55.env, mas é melhor armazená-la criptografada em ou com a ajuda de um serviço como o Doppler em
00:19:02seus servidores ou hospedada por você mesmo em um VPS seu, e então você a injeta no ambiente
00:19:08para que sua aplicação a conheça e a use quando necessário; de modo que, se você tivesse um
00:19:13trojan no seu sistema que talvez busque todos os seus arquivos .env e extraia as informações
00:19:20deles, ele não encontraria nenhum segredo ali; essa é a ideia. Portanto, armazenar esses segredos
00:19:25não em arquivos de texto no seu sistema — e um arquivo .env é apenas um arquivo de texto no final — mas sim
00:19:32criptografados em outro lugar é definitivamente algo que você também pode querer considerar fazer,
00:19:36e novamente, existem diferentes soluções aqui, mas é algo que você pode querer considerar.
00:19:40E para estar ainda mais seguro, claro, você poderia terceirizar seu ambiente de desenvolvimento e
00:19:45não tê-lo no seu MacBook, na sua máquina, no seu PC, mas sim em um VPS, em um Mac mini
00:19:50ao qual você se conecta via SSH ou algo assim, ou talvez em um container Docker para que,
00:19:56se algum código malicioso fosse executado ali, ele afetaria apenas aquele container Docker,
00:20:02aquele VPS, e não todo o seu sistema; assim, ele não poderia coletar todas as suas senhas de sistema e coisas
00:20:07desse tipo; em vez disso, ele estaria isolado, você teria um raio de explosão menor, porque esses ataques
00:20:13continuarão acontecendo, obviamente. Tenho certeza de que teremos mecanismos cada vez melhores
00:20:21para garantir a publicação segura de pacotes e assim por diante, mas nunca haverá uma garantia de 100% de que
00:20:27tais ataques não possam acontecer e, portanto, você, como usuário de tais pacotes, deve proteger
00:20:33seu sistema e ter múltiplas camadas de defesa para diminuir a chance de você
00:20:39baixar uma versão de pacote comprometida e, se baixar, o raio de explosão ser menor.
00:20:45Isso é o que você pode fazer, compartilharei mais sobre isso em vídeos futuros, também no meu outro canal,
00:20:50o canal da academia, mas sim, fiquem seguros por aí, verifiquem se vocês foram afetados por este
00:20:55ataque e, sim, foram algumas horas difíceis, como eu mencionei.