Las mejores vulnerabilidades que he encontrado nunca estuvieron en el dominio principal.
Todo el mundo está machacando formularios de login y probando XSS en la página de inicio. Lo entiendo. Ahí es donde vive la aplicación, ahí es donde están las funcionalidades, y ahí es donde apunta cualquier escáner por defecto.
Pero ahí es también donde está buscando cualquier otro hunter.
Yo prefiero estar en otro sitio. Subdominios olvidados. Entornos de staging. Herramientas internas que alguien expuso hace dos años y nunca quitó. Cosas que no aparecen en la navegación de la aplicación principal pero que sí aparecen en los registros DNS.
Las empresas protegen lo que ven. El dominio principal recibe el WAF, el hardening, las revisiones de seguridad trimestrales, el pentest anual. ¿Todo lo demás? Eso depende de si alguien recuerda que existe.
Exactamente por eso prefiero los alcances wildcard y a nivel de empresa frente a los limitados. Un alcance limitado mete a todos los hunters en la misma superficie de ataque. Todos probáis el mismo formulario de login, la misma API, el mismo puñado de endpoints. La competencia es brutal y los hallazgos fáciles desaparecen a las pocas horas de que se lance un programa.
Los alcances wildcard cambian esa ecuación. En vez de competir con cientos de hunters en las mismas cinco páginas, vas a donde nadie más está mirando. Y lo que encuentras ahí fuera es casi siempre peor que lo que hay en la aplicación principal.
Cosas que he encontrado simplemente yendo a lo ancho:
- Inyección SQL en herramientas internas legacy todavía conectadas a bases de datos de producción
- Entornos de staging replicando producción con controles de acceso rotos
- APIs internas filtrando registros completos de usuarios sin ninguna autenticación
- Mensajes de error verbosos exponiendo stack traces y credenciales de base de datos
- Frameworks desactualizados con CVEs conocidos que nadie se molestó en parchear
¿La aplicación principal? Sólida. Fortificada. Probada por cientos de hunters antes de que siquiera abrieses la página del programa. El equipo de seguridad la conoce. A los desarrolladores les importa. Recibe atención.
¿Ese subdominio de 2019 que nadie recuerda? Intacto. Ejecutando una versión de framework que dejó de recibir parches de seguridad hace tres años. Conectado a la misma base de datos que producción. Sin WAF. Sin monitorización. Sin rate limiting. Nada.
He visto este patrón las suficientes veces como para convertirlo en una parte fundamental de mi forma de trabajar. Cuando me uno a un programa nuevo, no empiezo por la aplicación principal. Empiezo por el reconocimiento. Reconocimiento amplio. Quiero conocer cada subdominio, cada rango de IPs, cada servicio ejecutándose en un puerto no estándar. Quiero encontrar las cosas que el equipo de seguridad olvidó, porque esas son las que no han sido probadas.
El trabajo aburrido de reconocimiento es lo que separa a los hunters que encuentran duplicados de los que encuentran críticos.
Esto no significa que la aplicación principal no valga la pena. Los bugs de lógica de negocio complejos, las race conditions y los fallos de autorización siguen viviendo ahí. Pero si buscas victorias rápidas de alta severidad, ampliar tu superficie de ataque es la forma más rápida de encontrarlas.
Mi consejo es sencillo. Si un programa ofrece un alcance wildcard, aprovéchalo. No te limites al dominio principal. Ve a lo ancho primero. Mapéalo todo. Encuentra los activos olvidados. Luego profundiza en los que parezcan descuidados.
El servidor de staging abandonado con una contraseña de admin por defecto siempre será más fácil de explotar que el login de producción fortificado que ha sido probado por todos los escáneres automatizados del planeta.
Id a lo ancho antes de ir a lo profundo.
