Como se vulneran bases de datos y paneles de acceso

Las bases de datos mal configuradas o expuestas son una mina de oro para cualquier atacante. Muchas veces no hace falta ni técnicas avanzadas, solo pillar un panel mal cerrado o un backup suelto por ahi. Vamos a ver cómo se suelen romper estas cosas, paso a paso y sin humo.

Paneles de acceso mal puestos

• URLs como /phpmyadmin, /adminer o /db que están abiertas al mundo
• Accesibles desde cualquier IP sin ningún tipo de firewall o limitación
• Usuarios tipo admin, root y claves flojas o por defecto
• Servicios web montados en máquinas sin revisar ni endurecer

Fugas de backups o ficheros sensibles

• Archivos .sql, .bak, .gz olvidados en carpetas públicas
• URLs predecibles tipo /backup.sql o /db_dump_2023.sql
• Errores de permisos en buckets públicos (AWS S3, Azure, etc)
• Backup automáticos expuestos por scripts mal hechos o sin auth

Inyecciones SQL y errores en código

• Campos no filtrados que van directos a consultas SQL
• Consultas dinámicas con variables concatenadas a lo bestia
• ORMs mal usados que permiten filtrado arbitrario
• Fallos de lógica que dejan escapar datos (por ejemplo, debug activado en prod)

Bases de datos expuestas directamente

• Puertos abiertos de MySQL, PostgreSQL, MongoDB o Redis
• MongoDB sin contraseña en versiones viejas = acceso completo
• Redis expuesto sin contraseña = ejecución remota y persistencia
• ElasticSearch con datos abiertos por no poner reglas de red

Errores comunes que ayudan al atacante

• Mensajes de error detallados que dicen qué tabla falló o qué consulta se usó
• Paneles sin captcha, sin 2FA, ni límite de intentos
• Sesiones mal gestionadas que permiten secuestros
• Logs con datos sensibles visibles desde el navegador

Herramientas que se usan pa explotar esto

• sqlmap: automatiza casi cualquier inyección
• Burp Suite: ideal para modificar peticiones y buscar huecos
• Gobuster / Dirsearch: para descubrir rutas raras y ficheros sueltos
• Hydra: fuerza bruta de logins cuando no hay bloqueo
• nmap + scripts: para detectar servicios y versiones

Como evitar que pase todo esto

• Paneles y servicios solo accesibles por IPs permitidas o VPN
• Contraseñas fuertes, rotación periódica y 2FA siempre que se pueda
• Backup cifrados y nunca en rutas accesibles públicamente
• Filtros de entrada bien aplicados, escapes de variables y validaciones
• Logs protegidos, errores genéricos en producción y mínimo privilegio

Una base de datos no es solo donde se guarda todo, es lo que más valor tiene para quien quiera robar algo o romper cosas. Por eso lo primero que hacen algunos es buscar cómo acceder a eso antes que a nada. Si entiendes cómo se entra, puedes cerrarlo mejor.

← Volver al blog