← Volver al inicio Caso real
Auditoría #001

Account takeover
sin credenciales.

Plataforma SaaS multi-tenant del sector logística internacional. Ocho empresas afectadas en cuatro países. Dos críticos, tres altos, un medio.

Datos anonimizados · Cliente y plataforma bajo NDA · Reportado bajo divulgación responsable

Sector
Logística
internacional
Arquitectura
SaaS
multi-tenant
Alcance
8 empresas
4 países
Operación
Sector
regulado
Timeline

Cómo se desplegó la auditoría.

Día 0 · Reconocimiento pasivo

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.

Día 1 · Análisis de bundles JS

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.

Día 3 · Hallazgo crítico #1 · CVSS 9.8

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.

POST /api/v1/account/[id]/reset
Authorization: [ausente]

{ "email": "atacante@evil.com" }
→ 200 OK
Día 5 · Hallazgo crítico #2 · CVSS 9.1

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 fiscales (CUIT), operaciones financieras.

Día 7 · Hallazgos altos

Contraseñas en texto plano · enumeración de CUIT

El schema confirmó almacenamiento de contraseñas sin hash. Adicionalmente: oracle de respuesta HTTP permitía enumerar CUIT/DNI válidos del padrón de la plataforma sin autenticación.

Día 10 · Reporte entregado

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.

Impacto potencial

Qué hubiera pasado
si lo encontraban otros.

Exposición de bases completas

Datos fiscales (CUIT), credenciales, operaciones financieras de las ocho empresas tenant en cuatro jurisdicciones.

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 equivalentes en las tres jurisdicciones restantes. Multas regulatorias acumulativas.

Parálisis operativa

Sector regulado. Una brecha pública obligaría a suspender operaciones hasta auditoría completa de control interno.

Cómo se manejó

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.

Pedí tu cotización →