Entornos de test públicos: un pequeño análisis de las (malas) prácticas en España

Todo entorno de programación serio requiere un entorno de prueba en el que poder verificar si el desarrollo de nuevas funcionalidades se ha realizado de forma correcta. Si nos ceñimos a la web, no es complicado encontrar ambientes de producción como podrían ser www.elevenpaths.com, y otro de desarrollo donde "experimentar", que bien podría ser test.elevenpaths.com. Imaginemos que estos subdominios no quedan bien restringidos por alguna razón, y se exponen públicamente. El riesgo es obvio: son entornos de desarrollo, pruebas... por definición, sujetos a fallos, errores o incluso a mostrar "las vergüenzas" de una página. Sin embargo, ¿existe alguna forma de detectar estos sub-dominios de pruebas? ¿Es común exponerlos? ¿Cuáles son los prefijos más comunes para identificar estos entornos de desarrollo en España? Vamos a averiguarlo.
Existen varias formas de identificar nombres de dominio: desde tratar de escanear directamente el supuesto activo para identificar los servicios abiertos, hasta preguntar por el dominio al servidor DNS, que es el encargado de proporcionar la relación entre nombre de dominio e IP.

Si la prioridad es no ser detectado por el propietario del dominio, la mejor opción es evitar escaneos directos contra el activo y consultar a un servidor DNS confiable si existe un nombre de dominio. Para ello, pueden utilizarse herramientas como 'nslookup' que pueden ser ejecutadas tanto en local como en remoto a través de servicios online gratuitos. Sin embargo, de cara a ocultar la actividad y no ser identificado como una amenaza de denegación de servicio frente al equipo de monitorización del servidor DNS, es importante no realizar demasiadas peticiones en poco tiempo. Por ello, si queremos descubrir los dominios de prueba disponibles en el menor número de peticiones posibles y con mayor probabilidad de éxito, un buen diccionario de sub-dominios de desarrollo será el mejor aliado.

Ejemplo de página en producción y de test
Para poder elaborar un diccionario acertado de subdominios de desarrollo que utilicen el TLD (Top Level Domain) .es, se puede localizar un buen número de dominios a través de listados de posicionamiento de sitios web como Alexa o Majestic. En esta ocasión, tras descargar un millón de registros, se han extraído aquellos dominios cuyo TLD sea .es. Hemos encontrando 7.454 sitios web con TLD español.

Para poder evaluar los más de 7.000 dominios .es, se ha diseñado un diccionario de 120 combinatorias que contiene términos como: backup, dev, prueba1, prueba2, test, testlogin, etc. A la hora de comprobar los dominios, se ha fraccionado el volumen de consultas para evitar ser identificado como actividad sospechosa; espaciando en un tiempo variable las casi 900.000 consultas necesarias. Además, es posible reducir el número de peticiones significativamente si se detecta que el dominio acepta cualquier subdominio como válido ( wilcard DNS record). Esto se puede comprobar solicitando la IP asociada a un subdominio que se sepa o sea muy improbable que exista.

Al finalizar las consultas, filtrar los datos y cuantificar los resultados, se puede determinar que un 18 % (1.387) de los sitios analizados contienen, al menos, un subdominio de desarrollo expuesto en Internet. Veamos en profundidad algunas de sus características.

El 71 % de estos subdominios de desarrollo apuntan a direcciones IP diferentes a la del dominio principal.


Respecto al diccionario de posibles entornos de desarrollo en dominios .es, se reduciría el número de posibles valores de 120 a 42 combinatorias. Los siguientes subdominios son los más utilizados:


Por supuesto, aclarar que no todas tienen por qué suponer un fallo de seguridad. Detengámonos en este asunto. Quisimos comprobar, no sólo cuales disponían de subdominio de prueba, sino además, cuántas están realmente protegidas. Para ello, realizamos consultas HTTP y HTTPS a estos subdominios y tuvimos en cuenta cuántos dominios se encuentran "correctamente protegidos".

Esto implicaba:

• Protección de ambos servicios (HTTP y HTTPS) en el subdominio concreto dedicado al testing.
• Protección por autenticación (la respuesta del servidor web es un 200 con panel de login, 403, 530, 3XX... etc).

Bajo estos criterios , 473 dominios cumplían las condiciones. O lo que es lo mismo, aproximadamente un 34 % de los dominios que cuentan con algún subdominio expuesto del tipo "testing", protege estos entornos tanto con TLS como por redirección/autenticación de manera adecuada. Si relajamos un poco las condiciones, y "obviamos" la coherencia HTTP/HTTPS, el número asciende a 838.

Durante la investigación ha sido posible encontrar algunos casos que no tenían una explicación lógica a priori, pero que han resultado ser interesantes de cara al estudio de estos entornos de desarrollo.

En concreto, 35 de los subdominios detectados están asociados a una IP privada como, por ejemplo, 192.168.63.1. Esta actividad puede ser útil (aunque no sabemos si lo más acertado) para el desarrollador. En ocasiones, de cara a realizar pruebas, es más cómodo poder hacer peticiones a un nombre de dominio concreto y redirigir la petición al servidor interno de la red privada que aloja el servicio web. Si en el futuro cambia la IP del servidor interno, sólo hay que cambiar el registro DNS, no hace falta modificar ningún desarrollo de prueba.

Aunque lo cierto es que no parece ser lo más adecuado publicar este registro en servidores DNS públicos. Se expone información sobre direccionamiento interno de la compañía. Además este tipo de prueba se podría realizar igualmente con mínimo esfuerzo desde la red privada.

Podría llegar a ser discutible si estos dominios deberían estar o no expuestos en Internet. En algunos casos puede intentar estar justificada para realizar pruebas de acceso externas (aunque no parece que pueda estar nunca justificada una exhibición masiva y pública, existiendo sencillos métodos de restricción de acceso) y en otros casos tratarse de un descuido que puede salirle caro a una compañía.

Algunos de los riesgos identificados al mostrar estos dominios en Internet n o distan mucho de los riesgos habituales de una web, solo que con el potencial agravante de encontrarse en un entorno precisamente caracterizado por situarse en una etapa de desarrollo anterior y, por definición, menos madura que la de producción.

• Acceso a datos confidenciales: Si el dominio de prueba obtiene datos de la misma base de datos que el dominio de producción y presenta vulnerabilidades (tipo SQLi) que fueron corregidas en el servidor web de producción pero no en el de desarrollo, podría suponer un vector de ataque para el robo de datos sensibles.
• Acceso a red corporativa: Si el dominio de desarrollo no ha sido asegurado correctamente y presenta vulnerabilidades que permitan la ejecución arbitraria de código remoto, un atacante podría tomar el control de la máquina y, entre otras opciones, servir como punto de acceso a la red corporativa o infectar otros equipos en la misma subred.
• Daños contra la reputación de la compañía: Sobre todo en el caso de grandes empresas con alta reputación y cotización en bolsa, la noticia sobre un defacement, aunque sea sobre un dominio de prueba, puede virilizarse en poco tiempo y ser perjudicial para la confianza de sus inversores o clientes.

Por tanto, si es necesario exponer un dominio de este tipo a Internet debería hacerse siguiendo unas recomendaciones:

• No utilizar nunca datos reales para realizar las pruebas.
• Aislar el dominio de pruebas de cualquier otro activo que permita el acceso a datos reales.
• Determinar la temporalidad de las pruebas, filtrar el acceso a usuarios autenticados y bloquear el acceso al subdominio de desarrollo cuando se hayan finalizado las pruebas.
• Incluir el subdominio en el parque de activos de la compañía y aplicar, siempre que sea posible, las mismas medidas de seguridad que a un servidor de producción o mitigando el riesgo de exposición frente a nuevas vulnerabilidades que sean descubiertas en las tecnologías utilizadas por el servidor de desarrollo.
• Monitorizar de manera constante la posible aparición de subdominios de este tipo sin el consentimiento de la compañía. Sobre todo, si no se ha incluido un registro DNS Wildcard (*.elevenpaths.com) que impida la detección de subdominios de desarrollo a través de consultas por diccionario de términos comunes al registro de nombres de dominio.