Una etapa primordial en una prueba para encontrar vulnerabilidades en una aplicación web, es encontrar cuales aplicaciones web particulares están hospedadas sobre el servidor web. Muchas aplicaciones tienen vulnerabilidades conocidas, y estrategias de ataques conocidos pueden explotarse para ganar control remoto o explotar datos. Además muchas aplicaciones están frecuentemente mal configuradas o desactualizadas, debido a la percepción de únicamente se utilizan “internamente”,y por lo tanto no existen amenazas.

Con la profileración de servidores virtuales, la relación tradicional de tipo 1 a 1 entre una dirección IP y un servidor web, está perdiendo gran parte de su significado original. No es raro tener varios sitios webs o aplicaciones cuyos nombres simbólicos resuelven hacia la misma dirección IP. Este escenario no está limitado hacia entornos de hosting, sino también aplica hacia entornos corporativos ordinarios.

Los profesionales en seguridad algunas veces reciben un conjunto de direcciones IP como aquello lo cual evaluar. Se puede argumentar este escenario es el más parecido a un contrato de tipo prueba de penetración, pero en cualquier caso se espera tal asignación evalúe todas las aplicaciones web factibles de ser accedidas a través de aquello a evaluar. El problema es la dirección IP del host con un servicio HTTP en el puerto 80, es altamente probable devuelva un mensaje el cual verse sobre “Ningún servidor web ha sido configurado en esta dirección” o un mensaje similar. Pero el sistema podría “ocular” un número de aplicaciones web asociado hacia nombres (DNS) simbólicos sin relación. Obviamente la extensión del análisis afecta profundamente al profesional quien realiza las pruebas, pues deberá considerar evaluar todas las aplicaciones o únicamente aquellas conocidas.

Algunas veces la especificación de aquello a evaluar es amplia. Al profesional en pruebas de penetración se le proporciona una lista de direcciones IP, y sus correspondientes nombres simbólicos. Sin embargo esta lista podría transmitir información parcial, es decir podría omitir nombres simbólicos, y el cliente podría no ser consciente de esto (es más probable esto ocurra en grandes organizaciones).

Otros problemas afectando el alcance de la evaluación, está representada por las aplicaciones web publicadas en URLs no obvias (ejemplo: http://www.example.com /f3woj1), la cual no se referencia en ningún lugar. Esto puede ocurrir ya sea por error (debido a inadecuadas configuraciones), o intencionalmente (por ejemplo, interfaces administrativas sin anunciar).

Para solucionar estos inconvenientes es necesario realizar un descubrimiento de la aplicación web.

Objetivos de la Prueba

Enumerar las aplicaciones web dentro del alcance existente en el servidor web.

Como Evaluar

Prueba de Caja Negra

El descubrimiento de las aplicaciones web es un proceso dirigido a identificar aplicaciones web sobre una infraestructura definida. Esto último es usualmente especificado como un conjunto de direcciones IP (podría ser un bloque de red), pero puede consistir de un conjunto de nombres simbólicos DNS o una mezcla de los dos. Esta información se entrega antes de la ejecución de la evaluación, ya sea un prueba de penetración al estilo clásico, o una evaluación enfocada a la aplicación. En ambos casos, a menos las reglas del contrato especifiquen lo contrario (por ejemplo probar únicamente la aplicación ubicada en http://www.example.com ), la evaluación debe abarcar el alcance más completo, es decir, debe identificar todas las aplicaciones factibles de ser accedidas a través de aquello a evaluar. Los siguientes ejemplos examinan algunas técnicas a emplearse para lograr este objetivo.

Nota: Algunas de las siguientes técnicas aplican a servidores web de cara hacia Internet, como servicios de búsqueda basados en web para nombres DNS e IP inversa, y el uso de motores de búsqueda. Ejemplo de utilizar una dirección IP privada (como 192.168. 1.100), la cual a menos se indique lo contrario representa direcciones IP genéricas, y son utilizadas únicamente para propósito de anonimato.

Existen tres factores influyendo en como muchas aplicaciones están relacionadas hacia un nombre DNS determinado (o una dirección IP):

1. URL base diferentes

El punto de entrada más obvio para una aplicación web es “www.example.com”, es decir con esta notación corta se piensa la aplicación web se origina en “www.example.com” (lo mismo se aplica para https). Sin embargo aunque esta es una situación común, no hay nada lo cual fuerce la aplicación inicie en “/”

Por ejemplo, el mismo nombre simbólico puede estar asociado hacia tres aplicaciones web, como http://www.example.com/url, http://www.example.com/url2, http://www.example.com/url3.

En este caso la URL http://www.example.com/ podría no estar asociada con una página significativa, y las tres aplicaciones podrían estar “ocultas” a menos el profesional en pruebas de penetración conozca como alcanzar cada una de estas, es decir conozca url1, url2, y url3. Usualmente no se necesita publicar las aplicaciones web de esta manera, a menos el propietario no requiera sean factibles de ser accedidas de manera estándar, y esté preparado para informar a los usuarios sobre su ubicación exacta. Esto no significa estas aplicaciones sean secretas, solo su existencia y ubicación no ha sido anunciada explícitamente.

2. Puertos no estándar

Mientras las aplicaciones web usualmente viven en el puerto 80 (http) o 443 (https), no existe ninguna magia en estos números de puerto. De hecho las aplicaciones web pueden estar asociadas con puertos TCP arbitrarios, y pueden ser referidos especificando el número de puerto como sigue: http://www.example.com:2000/

3. Hosts virtuales

DNS permite a una única dirección IP estar asociada con uno o más nombres simbólicos. Por ejemplo la dirección IP 192.168. 1.100 podría estar asociada hacia los nombres DNS www.example.com, helpdesk.example.com y webmail.example.com. No siendo necesario todos los nombres correspondan al mismo dominio DNS. Esta relación 1 a N puede relejarse para servir contenido diferente utilizando los así llamados hosts virtuales. La información especificando el host virtual referido esta incorporada en la cabecera “Host:” de HTTP 1.1

No se sospecharía la existencia de otras aplicaciones web además del obvio www.example.com, a menos se conozca helpdesk.example.com y webmail.example.com.

Perspectivas para abordar el inconveniente 1. URLs no estándar

No hay manera de determinar completamente la existencia de aplicaciones nombradas no estándar. Al ser no estándar, no hay un criterio fijo el cual gobierne la convención de nombramiento, sin embargo existen diferentes técnicas factibles de utilizar para ganar información adicional.

Primero, si el servidor web está inadecuadamente configurado y permite navegación de directorios, puede ser posible detectar estas aplicaciones. Los escáneres de vulnerabilidades pueden ayudar en este punto.

Segundo, estas aplicaciones pueden ser referidas por otras páginas webs, existiendo la probabilidad de haber sido rastreadas o indexadas por los motores de búsqueda web. Si el profesional en pruebas de penetración sospecha la existencia de tales aplicaciones “ocultas” sobre www.example.com, se podría buscar utilizando el operador “site:”, y examinando el resultado de la consulta “site:www.example.com”. Entre las URLs devueltas podría estar una apuntando hacia tal aplicación no obvia.

Otra opción es probar por URLs las cuales podrían ser probables candidatos para aplicaciones no publicadas. Por ejemplo un correo electrónico web podría ser factible de ser accedido desde URLs como https://www.example.com/webmail, https://webmail.example.com o https://mail.example.com. Lo mismo se aplica para interfaces administrador, las cuales podrían ser publicadas en URLs ocultas (por ejemplo, una interfaz administrativa Tomcat), y no estar referida en ninguna parte. Por lo tanto hacer una búsqueda al estilo diccionario (o “adivinación inteligente”) podría dar algunos resultados. Los escáneres de vulnerabilidades pueden ayudar en este punto.

Perspectivas para abordar el inconveniente 2. Puertos no estándar

Es fácil verificar la existencia de aplicaciones web en puertos no estándar. Un escáner de puertos como “nmap” es capaz de realizar un reconocimiento de servicios, lo cual se realiza utilizando la opción “-sV”, y podría identificar servicios http[s] en puertos arbitrarios. Lo requerido es un escaneo completo de los 65,535 puertos TCP.

Por ejemplo, el siguiente comando un escaneo de tipo “TCP Connect” contra todos los puertos abiertos en la dirección IP 192.168 .0.88, e intentará determinar cuales servicios están enlazados en estos (únicamente las opciones esenciales son mostradas, pues Nmap incluye una amplia diversidad de opciones).

# nmap -Pn -sT -sV -p- 192.168.0.88

Es suficiente examinar el resultados para buscar por http o servicios relacionados con SSL/TLS (lo cual debe ser probado para confirmar son https). Por ejemplo la salida del anterior comando se expone en la siguiente imagen.

Del ejemplo se puede ver:

• Existe un servidor Apache httpd ejecutándose en el puerto TCP 80
• Existe un servicio SSL/HTTPS ejecutándose en el puerto TCP 443, el cual Nmap no puede identificar.
• Existe un servicio Apache Tomcat/Coyote ejecutándose en el puerto TCP 8080
• Existe un servicio Jetty ejecutándose en el puerto TC 8081

La misma tarea puede ser realizada por los escáneres de vulnerabilidades, pero primero verificar el escáner elegido es capaz de identificar servicios http[s] ejecutándose en puertos no estándar. Por ejemplo Nessus es capaz de identificarlos en puertos arbitrarios (siempre se le instruya a escanear todos los puertos), y podría proporcionar con respecto a Nmap, un número de pruebas sobre vulnerabilidades conocidas para el servidor web, como también la configuración SSL de servicios https. Como se mencionó anteriormente Nessus es capaz de detectar aplicaciones populares o interfaces web, lo cuales de otra manera pasarían desapercibidas (por ejemplo una interfaz administrativa de Tomcat).

Perspectivas para abordar el inconveniente 3. Host virtuales

Existen diversas técnicas las cuales pueden ser utilizadas para identificar nombres DNS asociados hacia una dirección IP definida w.x.y.z.

Transferencia de Zona

Esta técnica tiene un uso limitado en la actualidad, de hecho las transferencia de zona son improbables de encontrar en servidores DNS. Sin embargo es necesario intentarlo. Primero, los profesionales en pruebas de penetración deben determinar los servidores de nombres sirviendo w.x.y.z. Si el nombre simbólico es conocido para w.x.y.z (digamos www.example.com), sus servidores de nombres pueden ser determinados mediante herramientas como “nslookup”, “host”, o “dig”, mediante peticiones a los registros NS del DNS.

Si no se conocen nombres simbólicos para w.x.y.z, pero la definición de aquello a evaluar contiene al menos un nombre simbólico, se debe intentar aplicar el mismo proceso y consultar el servidor de nombre (con la esperanza w.x.y.z de ese servidor también sirva para w.x.y.z). Por ejemplo, si aquello a evaluar consiste de una dirección IP w.x.y.z, y el nombre mail.example.com, determinar los servidores de nombre para el dominio example.com.

El siguiente ejemplo muestra como identificar los servidores de nombre para owasp.org, utilizando el comando host.

# host -t NS owasp.org

Una transferencia de zona podría ahora ser solicitada hacia los servidores de nombres para el dominio example.com. Si el profesional en pruebas de penetración es afortunado, podría obtener un listado de las entradas DNS para este dominio. Esto podría incluir el nombre obvio www.example.com, y host no tan obvios como helpdesk.example.com, y webmail.example.com (y posiblemente otros). Verificar todos los nombres devueltos por la transferencia de zona, y considerar todos aquellos los cuales se relacionan con los sistemas en evaluación.

Se intenta realizar una transferencia de zona contra www.owasp.org contra los dos servidores de nombres.

# host -l owasp.org dns1.stabletransit.com.
# host -l owasp.org dns2.stabletransit.com.

Consultas DNS inversas

Este proceso es similar a los anteriores, pero se basa en el registro (PTR) de los registros DNS. En lugar de solicitar una transferencia de zona, intentar configurar el tipo de registro PTR para realizar una consulta en una dirección IP definida. Si se es afortunado, se puede recuperar una entrada de nombre DNS. Esta técnica se basa en la existencia del mapeo de IP a nombre simbólico, lo cual no está garantizado.

Búsquedas DNS basadas en web

Este tipo de búsqueda es similar a la transferencia de zona DNS, pero se basa en servicios basados en web, lo cual permite búsquedas basadas en nombres sobre DNS. Uno de tales servicios es proporcionado por Netcraft. Pudiendo consultar por una lista de nombres correspondientes a un dominio elegido, como example.com. Luego se verifican si los nombres obtenidos son pertinentes a aquello lo cual se está examinando.

Servicios IP inverso

Servicios IP inversos son similares a las consultas inversas DNS, con la diferencia de se consulta una aplicación basada en web en lugar de un servidor de nombres. Existen diversos servicios disponibles. Dado el hecho tienden a retornar resultados parciales (y frecuentemente diferentes), es mejor utilizar múltiples servicios para obtener un análisis más completo.

El siguiente ejemplo muestra el resultado de consultar uno de los servicios reversos disponibles para la dirección IP correspondiente a www.owasp.org.

Buscar en Google

Siguiendo la captura de información desde las técnicas previas, se debe utilizar motores de búsqueda para posiblemente refinar o incrementar el análisis. Esto puede proporcionar evidencia de nombres simbólicos adicionales correspondientes a aquello en evaluación, o aplicaciones factibles de ser accedidas mediante URLs no obvias.

Por ejemplo considerar el ejemplo previo relacionado con www.owasp.org, pues se podría consultar a Google y otros motores de búsqueda, en busca de información (nombres DNS) relacionado a los dominios recién descubiertos.

Pruebas de Caja Gris

No aplica. La metodología permanece igual como en lo detallado en las pruebas de caja negra, no importando con cuanta información se inicie.

Fuentes:

https://www.owasp.org/index.php/Enumerate_Applications_on_Webserver_(OTG-INFO-004)
https://nmap.org/
https://www.tenable.com/products/nessus/nessus-essentials
http://reverseip.domaintools.com/
https://www.dnsstuff.com/
https://www.net-square.com/mspawn.html
https://searchdns.netcraft.com/