Draw A Fish! Postmortem
(aldenhallak.com)- El 3 de agosto de 2025, se produjo un incidente de seguridad a gran escala en el sitio web DrawAFish! durante aproximadamente 6 horas
- La fuga de la contraseña de administrador, una API sin autenticación y una debilidad en JWT quedaron expuestas de forma combinada y fueron explotadas en el ataque
- Como resultado, todos los nombres de usuario fueron cambiados a expresiones ofensivas, mientras se aprobaban dibujos inapropiados y se eliminaban imágenes seguras existentes
- Se resolvió el problema mediante recuperación manual, corrección de la lógica de autenticación y verificación de respaldos
- La principal lección es que el desarrollo rápido (“vibe-coding”) y la falta de pruebas y revisión de código pueden causar consecuencias de seguridad graves
Resumen de DrawAFish.com y del incidente del 3 de agosto de 2025
- DrawAFish.com es un sitio web donde los usuarios dibujan peces y los hacen nadar en un acuario junto a otros usuarios
- El 1 de agosto de 2025 llegó al primer puesto de Hacker News y atrajo mucha atención. El desarrollador adoptó un enfoque de “vibe-coding” para implementar funcionalidades con rapidez usando herramientas como Copilot
- Sin embargo, en la madrugada del 3 de agosto de 2025 ocurrió un incidente de seguridad grave
- Durante unas 6 horas, los nombres de usuario cambiaron a expresiones groseras y se aprobaron imágenes inapropiadas, generando una situación caótica
- Finalmente, el administrador realizó una restauración manual
Análisis detallado de vulnerabilidades
1. Contraseña antigua filtrada de 6 caracteres para administrador
- El desarrollador usó inicialmente su propio ID y contraseña de la infancia (de 6 caracteres) en la cuenta de administrador
- Esa contraseña ya había sido publicada en línea debido a filtraciones previas de datos en sitios como Neopets
- Luego el desarrollador pasó a usar Google Auth, pero como no eliminó esa contraseña quedó una vulnerabilidad expuesta para los atacantes
- El atacante aprovechó la información filtrada para autenticarse como administrador y realizó acciones maliciosas como aprobar dibujos ofensivos y eliminar dibujos normales
2. API de cambio de nombre de usuario sin autenticación
- Al desarrollar el backend de perfiles, se implementó una API para cambiar el nombre de usuario sin verificación de autenticación para priorizar la velocidad de desarrollo
- En la práctica, cualquiera podía cambiar nombres de usuario arbitrariamente
3. Validación insuficiente de JWT
- En la autenticación basada en tokens JWT, se permitió realizar acciones de administración sin validar que el token coincidiera con el userId/email
- Es decir, quien tuviera un token emitido con credenciales de administrador podía usarlo con privilegios de administrador para cualquier solicitud
- Curiosamente, un usuario de Hacker News utilizó esta vulnerabilidad para eliminar material inapropiado antes que el intruso, contribuyendo a la respuesta de emergencia
Proceso de recuperación
- El desarrollador detectó la situación alrededor de las 7:45 a. m. y comenzó la respuesta desde su escritorio de inmediato
- Como Firebase no tenía respaldos configurados, no pudo depender de ellos y modificó el código rápidamente para forzar la autenticación
- Revisó todos los registros de moderación y desarrolló un script para revertir las acciones maliciosas (también creado con “vibe-coding”)
- También bloqueó una cuenta de tercero con permisos de administrador (un usuario de Hacker News) usada durante la contingencia, contactó a esa persona, recibió retroalimentación sobre refactorización de seguridad en la base de código y aplicó parches adicionales
Cultura de desarrollo y lecciones
- El desarrollador comprobó que la “vibe-coding”, o sea el prototipado rápido con una cultura de revisión mínima, puede aportar diversión y alta productividad, pero también conducir a vulnerabilidades de seguridad graves
- Los LLM (como Copilot) son muy útiles para producir código rápidamente, pero refuerzan que la responsabilidad por la calidad y la seguridad del código recae en el propio desarrollador
- Este caso demuestra que omitir procesos de seguridad básicos como pruebas, lógica de autenticación y revisión de código puede hacer que incluso proyectos pequeños sean extremadamente vulnerables a ataques externos
Conclusión y aprendizajes
- El caso de DrawAFish.com muestra la importancia de las medidas de seguridad básicas que a menudo se pasan por alto en entornos de operación real
- Incluso al depender de herramientas open source y herramientas de desarrollo rápido, hay que validar siempre aspectos básicos como pruebas, autenticación, revisión de código y gestión de contraseñas
- Una atención masiva e inesperada (por ejemplo, un ranking alto en Hacker News) puede ampliar rápidamente la superficie de ataque y el riesgo
- Al documentar el postmortem de manera transparente, se comparte una lección de seguridad realista para futuros startups o desarrolladores independientes
3 comentarios
Opinión de Hacker News
A mí también me encanta trabajar rápido; disfruto cuando no hago revisión de código y solo hago push de inmediato, pero al ver este postmortem entendí por qué mis proyectos secundarios se detienen con frecuencia: siempre termino llegando a la parte real del trabajo, que es aburrida, y ahí es donde me quedo.
Me quedé con la duda de si se trata de Firebase, si estaban usando el tier gratis o si alguien lo atacó de manera maliciosa y al despertar en la mañana recibieron una factura de cinco dígitos.
Yo fui uno de los "afortunados" que pasó por el caso Slurfish. Como trabajo en seguridad, lo vi de forma tan evidente que me hizo sonreír, y supe que pronto aparecería en HN alguien que pudiera ayudar de verdad. Me gustó mucho que también estuviera disponible un postmortem tan bien documentado para un proyecto hecho con vibe-coding; últimamente, en mi trabajo de IR, veo mucho código de “vibes” en producción, y me impresiona ver que esté tan bien ordenado incluso en algo tan pequeño.
Este postmortem me pareció particularmente interesante por ser una app de vibe-coded. Me pregunté si estaría inspirado en la exhibición de hacer peces de Lego House; recientemente fui y era realmente adictivo ver a mi pez nadando junto a otros. video de Lego House Build-a-Fish en YouTube
Es sorprendente que alguien intentara usar una vulnerabilidad de seguridad para evitar un ataque real.
En "vibe-coded", la "S" viene de Security.
Es genial tener una idea totalmente nueva, crearla, aprender un montón y, aun así, avergonzarte de lo que falló de una manera profesional. Si no perdiste 100 mil dólares, no rompiste la red y no perdiste tu empleo, dentro de un año podrás recordar esto riéndote.
En ese sitio, actualmente, había un pez esvástica, y alguien lo metió dentro de la silueta de un pez para esquivar el filtro enlace de la imagen en cuestión; hoy ya fue eliminado.
Hoy es posible votar a cualquier pez sin autenticación (máximo 20 veces por minuto por IP) y usar POST en este endpoint enlace de la API de votos {"fishId":"xxxx","vote":"up"}
Me encantó que dejaran un postmortem sobre un sitio vibe-coded; mucha gente toma la tecnología demasiado en serio, y verlo con una mirada tan liviana y divertida se siente refrescante. Desde la perspectiva de un side project pequeño, se siente muy interesante y con mucho sentido.