Account takeover
sin credenciales.
Plataforma SaaS B2B multi-tenant. Encadenamiento de vulnerabilidades que permitía acceso administrativo sin autenticación. Dos críticos, tres altos, un medio.
Datos anonimizados · Cliente y plataforma bajo NDA · Reportado bajo divulgación responsable
B2B
multi-tenant
tenant
B2B
Cómo se desplegó la auditoría.
Subdominios expuestos vía CT logs
Certificate Transparency (crt.sh) reveló un panel administrativo en un subdominio no indexado. Sin tocar la infraestructura del cliente — solo información pública.
Endpoints de API documentados en el frontend
El bundle JavaScript público contenía referencias a rutas de la API que no estaban documentadas. Mapeo de la superficie de ataque desde el cliente, sin interacción con el backend.
IDOR sin autenticación → account takeover
Un endpoint aceptaba modificación de cuenta con solo un identificador numérico predecible. Sin token, sin sesión, sin verificación. Reseteo de credenciales de cualquier cuenta — incluidas las administrativas — desde un navegador en modo incógnito.
Authorization: [ausente]
{ "email": "atacante@evil.com" }
→ 200 OK
SQL injection error-based + boolean-blind
Parámetro de búsqueda sin sanitización. Extracción carácter a carácter de la base usando majority-vote sobre el tamaño de respuesta HTTP. Acceso a la estructura completa del schema: usuarios, hashes, datos de clientes, pedidos y métodos de pago.
Contraseñas en texto plano · enumeración de usuarios
El schema confirmó almacenamiento de contraseñas sin hash. Adicionalmente: oracle de respuesta HTTP permitía enumerar emails y datos de clientes válidos del padrón de la plataforma sin autenticación.
Informe ejecutivo + técnico con remediación
Reporte de 40 páginas con CVSS scoring, vectores reproducibles, impacto cuantificado y plan de remediación priorizado. Reunión de presentación con el equipo técnico bajo NDA.
Qué hubiera pasado
si lo encontraban otros.
Exposición de bases completas
Credenciales, datos de clientes, historial de pedidos y métodos de pago de las 12 marcas tenant.
Account takeover masivo
Cualquier cuenta administrativa comprometible desde un navegador. Sin necesidad de phishing, sin necesidad de ingeniería social.
Obligación de notificación
Ley 25.326 (Argentina) y normativas similares de protección de datos en los mercados donde opera la plataforma. Multas regulatorias acumulativas.
Fuga reputacional
Filtración pública del incidente afectaría la confianza simultánea de las 12 marcas tenant. Daño en cascada difícil de contener una vez publicado.
Ningún dato real fue extraído.
Toda la investigación se hizo con PoC mínima: confirmar la existencia del vector sin acceder a datos de usuarios reales. La SQLi se validó extrayendo metadata del schema (SELECT VERSION(), DATABASE()) — nunca contenido de tablas con información personal.
El reporte se entregó bajo ISO/IEC 29147 (responsible disclosure). Plazo de 90 días para remediación antes de cualquier publicación. Reunión con el equipo técnico bajo NDA. Cliente y plataforma no se identifican en este caso público.
Si encontrás algo así en tu plataforma, esto es lo que vas a recibir: un proceso documentado, ético, y enfocado en resolver — no en presionar.
¿Tu plataforma
tiene algo así?
Probablemente sí. La mayoría de los SaaS multi-tenant tiene al menos un IDOR. Mejor encontrarlo conmigo que con alguien que no firme NDA.