Draw A Fish ! Pós-mortem
(aldenhallak.com)- Em 3 de agosto de 2025, ocorreu um incidente de segurança em larga escala no site DrawAFish! por cerca de 6 horas
- Vulnerabilidades críticas de segurança, como vazamento de senha de administrador, API sem autenticação e falha no JWT, ficaram expostas em conjunto durante o ataque
- Como resultado, todos os nomes de usuário foram alterados para expressões ofensivas, e desenhos inadequados foram aprovados enquanto desenhos seguros existentes eram excluídos ao mesmo tempo
- O incidente foi resolvido com recuperação manual, correção da lógica de autenticação e validação de backups
- A principal lição é que o desenvolvimento rápido (“vibe-coding”) e a falta de testes e revisão de código podem causar consequências de segurança graves
Visão geral do DrawAFish.com e resumo do incidente de 3 de agosto de 2025
- O DrawAFish.com é um site em que o usuário desenha peixes e os faz nadar em um aquário junto com outros usuários
- Em 1º de agosto de 2025, subiu para o 1º lugar do Hacker News e ganhou grande atenção. O desenvolvedor adotou a abordagem de “vibe-coding”, implementando funcionalidades rapidamente com ferramentas como o Copilot
- Porém, na madrugada de 3 de agosto de 2025, ocorreu um incidente de segurança grave
- Durante cerca de 6 horas, houve uma situação caótica com nomes de usuário alterados para termos ofensivos e aprovação de imagens impróprias
- Ao final, o administrador precisou fazer restauração manual
Detalhamento de vulnerabilidades
1. Senha de administrador de 6 dígitos vazada anteriormente
- O desenvolvedor usou inicialmente seu próprio ID e senha de 6 dígitos da infância na conta de administrador
- Essa senha já estava disponível publicamente devido ao vazamento de dados de sites anteriores, como o Neopets
- O desenvolvedor passou a usar o Google Auth depois, mas não removeu a senha antiga, deixando a fragilidade aberta para o atacante
- O atacante conseguiu autenticar com sucesso usando as informações vazadas e realizou ações maliciosas, como aprovar desenhos ofensivos e excluir desenhos normais
2. API de alteração de nome de usuário sem autenticação
- Durante o desenvolvimento do backend de perfil, foi implementada uma API de alteração de nome de usuário sem verificação de autenticação para ganhar velocidade no “desenvolvimento rápido”
- Na prática, qualquer pessoa podia alterar o nome de usuário livremente
3. Validação insuficiente de JWT
- No esquema de autenticação baseada em token JWT, as operações administrativas podiam ser feitas sem validar a correspondência entre token e userId/email
- Ou seja, se o invasor possuísse apenas um token emitido com credenciais administrativas, poderia usá-lo com privilégios de administrador em qualquer requisição
- Curiosamente, um usuário do Hacker News aproveitou essa falha para excluir materiais impróprios antes do invasor e ajudou na resposta de emergência
Processo de recuperação
- O desenvolvedor percebeu a situação em torno de 7h45 da manhã e começou a resposta imediatamente pelo computador
- Como o backup do Firebase não estava configurado, não foi possível contar com backup, e o código foi corrigido rapidamente para impor autenticação
- Rastreou todos os logs de moderação e desenvolveu um script para desfazer ações maliciosas (também escrito no formato vibe-coding)
- Em seguida, bloqueou e contatou também a conta de terceiros (usuário do Hacker News) que utilizara privilégios administrativos em emergência, recebendo feedback sobre refatoração de segurança da base de código e aplicando patches adicionais
Cultura de desenvolvimento e lições
- O desenvolvedor experimentou que o “vibe-coding”, ou seja, prototipagem rápida com revisão mínima, pode trazer diversão e alta produtividade, mas na prática pode levar a falhas de segurança graves
- O LLM (Copilot) é extremamente útil para produção rápida de código, mas a responsabilidade pela qualidade e pela segurança do código continua sendo do próprio desenvolvedor
- Este caso demonstra que, ao omitir testes, lógica de autenticação, revisão de código e outras rotinas básicas de segurança, até projetos pequenos podem se tornar extremamente vulneráveis a ataques externos
Conclusão e insights
- O caso DrawAFish.com mostra a importância de medidas básicas de segurança que são frequentemente negligenciadas na operação de serviços reais
- Mesmo dependente de ferramentas open source e ferramentas de desenvolvimento rápido, é essencial checar questões básicas como testes, autenticação, revisão de código e gestão de senhas
- A exposição repentina em grande escala (por exemplo, ficar entre os primeiros no ranking do Hacker News) pode ampliar rapidamente a superfície de ataque e o risco
- Ao documentar o pós-mortem de forma transparente, transmite lições práticas de segurança para futuras startups e desenvolvedores independentes de casos similares
3 comentários
Comentário do Hacker News
Também acho muito divertido trabalhar em ritmo acelerado; não fazer code review e ir dando push direto é prazeroso. Mas lendo esse pós-mortem, entendi por que meu side project foi interrompido tantas vezes: no fim, tudo acaba virando o trabalho real e chato, e é ali que eu paro.
Fiquei curioso se era Firebase: se continuaram usando o free tier ou se alguém atacou de propósito e eu acordei de manhã com uma fatura de cinco dígitos.
Eu fui uma das pessoas “sortudas” que passou pelo incidente do Slurfish. Por trabalhar com segurança, achei óbvio demais a ponto de rir, mas já sabia que alguém no HN logo teria tempo para ajudar de verdade. Também foi bom ver um post-mortem detalhado de um projeto vibe-coded. Hoje, no meu trabalho de Incident Response (IR), vejo muito código vibe-coded seguindo só a vibe em produção, então é marcante ver algo tão bem organizado em um projeto pequeno.
Esse pós-mortem foi ainda mais interessante por ser de um app vibe-coded. Fiquei curioso se se inspirou na exposição de construção de peixes do Lego House; visitei recentemente e foi viciante ver meus peixes nadando junto com outros peixes vídeo do Lego House Build-a-Fish no YouTube
É realmente surpreendente alguém usar uma vulnerabilidade de segurança para tentar impedir um ataque real.
O “S” no vibe-coded é de Security.
A pessoa que cria uma ideia totalmente nova, coloca a mão na massa, aprende muito e encara de forma humilde as falhas como profissional é quem é realmente profissional. Se você não perdeu US$100 mil, sua rede não caiu e não perdeu o emprego, daqui a um ano você vai rir disso com carinho.
Agora tem um peixe de suástica no site; alguém colocou algo no formato de peixe para burlar o filtro link da imagem em questão, atualmente removido.
Hoje dá para votar em qualquer peixe sem autenticação (até 20 vezes por minuto por IP), via POST para o endpoint abaixo link da API de voto {"fishId":"xxxx","vote":"up"}
Gostei muito de ver um pós-mortem de um site vibe-coded; muita gente trata tecnologia com excessiva seriedade, então esse olhar leve e divertido é refrescante, e para quem faz pequenos side projects foi bem interessante e significativo.