Descubrimiento y enumeración de aplicaciones
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
Como Pentesters, necesitamos tener fuertes habilidades de enumeración y ser capaces de obtener una "imagen general" de cualquier red comenzando con muy poca o ninguna información (descubrimiento de caja negra o simplemente un conjunto de rangos CIDR). Normalmente, cuando nos conectamos a una red, comenzaremos con un barrido de ping para identificar "hosts activos". A partir de ahí, generalmente comenzaremos con un escaneo de puertos específico y, eventualmente, un escaneo de puertos más profundo para identificar servicios en ejecución. En una red con cientos o miles de hosts, estos datos de enumeración pueden volverse difíciles de manejar. Supongamos que realizamos un escaneo de puertos de Nmap para identificar servicios web comunes como:
Podemos encontrar una enorme cantidad de hosts con servicios ejecutándose únicamente en los puertos 80 y 443. ¿Qué hacemos con estos datos? Examinar los datos de enumeración manualmente en un entorno grande consumiría demasiado tiempo, especialmente porque la mayoría de las evaluaciones están sujetas a estrictas restricciones de tiempo. Navegar por cada IP/nombre de host + puerto también sería muy ineficiente.
Afortunadamente, existen varias herramientas excelentes que pueden ayudarnos mucho en este proceso. Dos herramientas fenomenales que todo evaluador debería tener en su arsenal son y . Ambas herramientas pueden recibir una salida de escaneo XML sin procesar de Nmap (Aquatone también puede recibir XML de Masscan; EyeWitness puede recibir una salida XML de Nessus) y usarse para inspeccionar rápidamente todos los hosts que ejecutan aplicaciones web y tomar capturas de pantalla de cada uno. Luego, las capturas de pantalla se reúnen en un informe que podemos revisar en el navegador web para evaluar la superficie de ataque web.
Estas capturas de pantalla pueden ayudarnos a reducir la lista de posibles cientos de hosts y crear una lista más específica de aplicaciones a las que deberíamos dedicar más tiempo para enumerar y atacar. Estas herramientas están disponibles tanto para Windows como para Linux, por lo que podemos utilizarlas en cualquier entorno que elijamos para nuestro cuadro de ataque. Repasemos algunos ejemplos de cada una para crear un inventario de las aplicaciones presentes en el INLANEFREIGHT.LOCALdominio de destino.
Aunque cubriremos la toma de notas, la elaboración de informes y la documentación en un módulo aparte, vale la pena aprovechar la oportunidad para seleccionar una aplicación de toma de notas si aún no lo hemos hecho y comenzar a configurarla para registrar mejor los datos que estamos recopilando en esta fase.
El módulo analiza varias aplicaciones de toma de notas. Si aún no ha elegido una, sería un excelente momento para comenzar. Herramientas como OneNote, GitBook, Notion, Cherrytree, etc., son todas buenas opciones y todo depende de las preferencias personales. Independientemente de la herramienta que elija, en este momento deberíamos estar trabajando en nuestra metodología de toma de notas y creando plantillas que podamos usar en nuestra herramienta de elección configurada para cada tipo de evaluación.
Supongamos que nuestro cliente nos proporcionó el siguiente alcance:
Podemos comenzar con un escaneo de Nmap de los puertos web más comunes. Normalmente, hago un escaneo inicial con los puertos 80,443,8000,8080,8180,8888,10000 y luego ejecuto EyeWitness o Aquatone (o ambos, dependiendo de los resultados del primero) en relación con este escaneo inicial. Mientras reviso el informe de captura de pantalla de los puertos más comunes, puedo ejecutar un escaneo de Nmap más exhaustivo en relación con los 10 000 puertos principales o todos los puertos TCP, dependiendo del tamaño del alcance. Dado que la enumeración es un proceso iterativo, ejecutaremos una herramienta de captura de pantalla web en relación con cualquier escaneo de Nmap posterior que realicemos para garantizar la máxima cobertura.
Todos los análisis que realizamos durante una interacción no invasiva tienen como objetivo recopilar datos como entrada para nuestro proceso de validación y prueba manual. No deberíamos depender únicamente de los escáneres, ya que el elemento humano en las pruebas de penetración es esencial. A menudo, encontramos las vulnerabilidades y configuraciones erróneas más singulares y graves solo mediante pruebas manuales exhaustivas.
Analicemos en profundidad la lista de alcance mencionada anteriormente con un análisis de Nmap que normalmente descubrirá la mayoría de las aplicaciones web en un entorno. Por supuesto, realizaremos análisis más profundos más adelante, pero esto nos dará un buen punto de partida.
Como podemos ver, identificamos varios hosts que ejecutan servidores web en varios puertos. A partir de los resultados, podemos inferir que uno de los hosts es Windows y el resto son Linux (pero no podemos estar 100% seguros en esta etapa). Preste especial atención a los nombres de host también. En este laboratorio, estamos utilizando Vhosts para simular los subdominios de una empresa. Vale la pena anotar los hosts dev como parte del FQDN ya que pueden estar ejecutando funciones no probadas o tener cosas como el modo de depuración habilitado. A veces, los nombres de host no nos dirán demasiado, como app.inlanefreight.local. Podemos inferir que es un servidor de aplicaciones, pero necesitaríamos realizar una enumeración adicional para identificar qué aplicación(es) se están ejecutando en él.
También nos gustaría agregar gitlab-dev.inlanefreight.local a nuestra lista de "hosts interesantes" para investigar una vez que completemos la fase de descubrimiento. Es posible que podamos acceder a repositorios públicos de Git que podrían contener información confidencial, como credenciales o pistas que pueden llevarnos a otros subdominios/Vhosts. No es raro encontrar instancias de Gitlab que nos permitan registrar un usuario sin requerir la aprobación del administrador para activar la cuenta. Es posible que encontremos repositorios adicionales después de iniciar sesión. También valdría la pena verificar las confirmaciones anteriores para obtener datos como las credenciales, que cubriremos con más detalle más adelante en este módulo cuando profundicemos en Gitlab.
Enumerar uno de los hosts más a fondo mediante un escaneo de servicio Nmap (-sV) contra los 1000 puertos principales predeterminados puede brindarnos más información sobre lo que se está ejecutando en el servidor web.
En el resultado anterior, podemos ver que un servidor web IIS se está ejecutando en el puerto predeterminado 80 y parece que Splunkse está ejecutando en el puerto 8000/8089, mientras que PRTG Network Monitorestá presente en el puerto 8080. Si estuviéramos en un entorno de tamaño mediano a grande, este tipo de enumeración sería ineficiente. Podría hacer que nos perdiéramos una aplicación web que podría resultar fundamental para el éxito del compromiso.
En primer lugar, tenemos EyeWitness. Como ya se ha mencionado, EyeWitness puede tomar la salida XML tanto de Nmap como de Nessus y crear un informe con capturas de pantalla de cada aplicación web presente en los distintos puertos mediante Selenium. También irá un paso más allá y categorizará las aplicaciones cuando sea posible, las identificará y sugerirá credenciales predeterminadas en función de la aplicación. También se le puede proporcionar una lista de direcciones IP y URL y se le puede indicar que anteponga http:// y https:// al principio de cada una. Realizará la resolución DNS para las IP y se le puede proporcionar un conjunto específico de puertos a los que intentar conectarse y realizar una captura de pantalla.
Podemos instalar EyeWitness a través de apt:
Al ejecutar eyewitness -h nos mostrará las opciones que tenemos disponibles:
Ejecutemos la opción predeterminada --web para tomar capturas de pantalla usando la salida XML de Nmap del escaneo de descubrimiento como entrada.
Podemos moverlo a una ubicación en nuestro $PATHdirectorio para /usr/local/binpoder llamar a la herramienta desde cualquier lugar o simplemente colocar el binario en nuestro directorio de trabajo (por ejemplo, escaneos). Es una cuestión de preferencia personal, pero normalmente es más eficiente construir nuestras máquinas virtuales de ataque con la mayoría de las herramientas disponibles para usar sin tener que cambiar directorios constantemente o llamarlas desde otros directorios.
En este ejemplo, proporcionamos a la herramienta la misma salida de Nmap web_discovery.xml especificando el indicador -nmap y comenzamos:
Incluso con los 26 hosts anteriores, este informe nos ahorrará tiempo. ¡Ahora imagine un entorno con 500 o 5000 hosts! Después de abrir el informe, vemos que está organizado en categorías, siendo High Value Targetslos primeros y, por lo general, los hosts más "jugosos" los que hay que analizar. He ejecutado EyeWitness en entornos muy grandes y he generado informes con cientos de páginas que llevan horas revisar. A menudo, los informes muy grandes tendrán hosts interesantes enterrados en lo profundo de ellos, por lo que vale la pena revisar todo y buscar/investigar cualquier aplicación con la que no estemos familiarizados. Encontré la ManageEngine OpManageraplicación mencionada en la sección de introducción enterrada en lo profundo de un informe muy grande durante una prueba de penetración externa. Esta instancia se dejó configurada con las credenciales predeterminadas admin:adminy se dejó abierta a Internet. Pude iniciar sesión y lograr la ejecución del código ejecutando un script de PowerShell. La aplicación OpManager se estaba ejecutando en el contexto de una cuenta de administrador de dominio, lo que provocó un compromiso total de la red interna.
Durante una evaluación, seguiría revisando el informe, anotando los hosts interesantes, incluida la URL y el nombre/versión de la aplicación para más adelante. Es importante en este punto recordar que todavía estamos en la fase de recopilación de información y cada pequeño detalle podría determinar el éxito o el fracaso de nuestra evaluación. No debemos descuidarnos y comenzar a atacar a los hosts de inmediato, ya que podemos terminar en un agujero de conejo y pasar por alto algo crucial más adelante en el informe. Durante una prueba de penetración externa, esperaría ver una combinación de aplicaciones personalizadas, algunos CMS, tal vez aplicaciones como Tomcat, Jenkins y Splunk, portales de acceso remoto como Remote Desktop Services (RDS), puntos finales de VPN SSL, Outlook Web Access (OWA), O365, tal vez algún tipo de página de inicio de sesión del dispositivo de red perimetral, etc.
Tus resultados pueden variar y, a veces, nos encontraremos con aplicaciones que no deberían exponerse, como una sola página con un botón de carga de archivos que encontré una vez con un mensaje que decía: "Cargue solo archivos .zip y .tar.gz". Por supuesto, no presté atención a esta advertencia (ya que esto estaba dentro del alcance durante una prueba de penetración autorizada por el cliente) y procedí a cargar un .aspxarchivo de prueba. Para mi sorpresa, no hubo ningún tipo de validación del lado del cliente o del backend, y el archivo pareció cargarse. Haciendo una rápida fuerza bruta de directorios, pude localizar un /filesdirectorio que tenía habilitado el listado de directorios, y mi test.aspxarchivo estaba allí. Desde aquí, procedí a cargar un .aspxshell web y me afiancé en el entorno interno. Este ejemplo demuestra que no debemos dejar piedra sin mover y que puede haber un tesoro absoluto de datos para nosotros en nuestros datos de descubrimiento de aplicaciones.
Durante una prueba de penetración interna, veremos mucho de lo mismo, pero a menudo también veremos muchas páginas de inicio de sesión de impresoras (que a veces podemos aprovechar para obtener credenciales LDAP de texto sin formato), portales de inicio de sesión de ESXi y vCenter, páginas de inicio de sesión de iLO e iDRAC, una gran cantidad de dispositivos de red, dispositivos IoT, teléfonos IP, repositorios de código interno, SharePoint y portales de intranet personalizados, dispositivos de seguridad y mucho más.
Ahora que hemos trabajado con nuestra metodología de descubrimiento de aplicaciones y hemos configurado nuestra estructura de toma de notas, analicemos en profundidad algunas de las aplicaciones más comunes con las que nos encontraremos una y otra vez. Tenga en cuenta que este módulo no puede cubrir todas las aplicaciones con las que nos encontraremos. En cambio, nuestro objetivo es cubrir las más frecuentes y aprender sobre vulnerabilidades comunes, configuraciones incorrectas y abuso de su funcionalidad integrada.
Puedo garantizar que se enfrentará al menos a algunas de estas aplicaciones, si no a todas, durante su carrera como evaluador de penetración. La metodología y la mentalidad para explorar estas aplicaciones son aún más importantes, las desarrollaremos y mejoraremos a lo largo de este módulo y las probaremos durante las evaluaciones de habilidades al final. Muchos evaluadores tienen grandes habilidades técnicas, pero las habilidades blandas, como una metodología sólida y repetible, junto con la organización, la atención al detalle, una buena comunicación y una toma de notas/documentación y presentación de informes minuciosos, pueden diferenciarnos y ayudar a generar confianza en nuestras habilidades tanto de parte de nuestros empleadores como de nuestros clientes.
o clonar el , navegar hasta el Python/setupdirectorio y ejecutar el script de instalación setup.sh. EyeWitness también se puede ejecutar desde un contenedor Docker y hay una versión para Windows disponible que se puede compilar con Visual Studio.
, como ya hemos dicho, es similar a EyeWitness y puede tomar capturas de pantalla si se le proporciona un archivo de hosts .txt o un archivo Nmap .xml con la flag -nmap. Podemos compilar Aquatone por nuestra cuenta o descargar un binario precompilado. Después de descargar el binario, solo tenemos que extraerlo y ya estamos listos.
Nota: Aquatoneactualmente se encuentra en desarrollo activo en una nueva , que se centra en mejoras y mejoras de funciones. Consulta la guía de instalación que se proporciona en el repositorio.
En el siguiente informe, me entusiasmaría ver a Tomcat en cualquier evaluación (pero especialmente durante una prueba de penetración externa) y probaría las credenciales predeterminadas en los puntos finales /managery /host-manager. Si podemos acceder a cualquiera de ellos, podemos cargar un archivo WAR malicioso y lograr la ejecución remota de código en el host subyacente mediante . Más sobre esto más adelante en el módulo.
Continuando con el informe, parece que el http://inlanefreight.localsitio web principal es el siguiente. Siempre vale la pena probar las aplicaciones web personalizadas, ya que pueden contener una amplia variedad de vulnerabilidades. Aquí también me interesaría ver si el sitio web estaba ejecutando un CMS popular como WordPress, Joomla o Drupal. La siguiente aplicación, http://support-dev.inlanefreight.locales interesante porque parece estar ejecutando , que ha sufrido varias vulnerabilidades graves a lo largo de los años. Los sistemas de tickets de soporte son de particular interés porque podemos iniciar sesión y obtener acceso a información confidencial. Si la ingeniería social está en el ámbito, podemos interactuar con el personal de soporte al cliente o incluso manipular el sistema para registrar una dirección de correo electrónico válida para el dominio de la empresa que podemos aprovechar para obtener acceso a otros servicios.
Esta última pieza se demostró en el cuadro de lanzamiento semanal de HTB de . Vale la pena estudiar este cuadro en particular, ya que muestra lo que es posible al explorar la funcionalidad incorporada de ciertas aplicaciones comunes. Trataremos osTicket con más profundidad más adelante en este módulo.
