IIS - Internet Information Services
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Pruebe las extensiones de archivos ejecutables:
asp
aspx
config
php
En cualquier servidor IIS donde obtenga un 302, puede intentar eliminar el encabezado Host y usar HTTP/1.0 y dentro de la respuesta el encabezado Location podría señalarle la dirección IP interna:
Respuesta que revela la IP interna:
Puedes subir archivos .config y usarlos para ejecutar código. Una forma de hacerlo es añadiendo el código al final del archivo dentro de un comentario HTML: Descargar ejemplo aquí
Más información y técnicas para explotar esta vulnerabilidad aquí
Descarga la lista que he creado:
Fue creada fusionando los contenidos de las siguientes listas:
https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/IIS.fuzz.txt http://itdrafts.blogspot.com/2013/02/aspnetclient-folder-enumeration-and.html https://github.com/digination/dirbuster-ng/blob/master/wordlists/vulns/iis.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/aspx.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/asp.txt https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/vulns/iis.txt
Úsalo sin añadir ninguna extensión, los archivos que la necesitan ya la tienen.
Consulta el informe completo en: https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html
Como resumen, hay varios archivos web.config dentro de las carpetas de la aplicación con referencias a archivos "assemblyIdentity" y "namespaces". Con esta información es posible saber dónde están ubicados los ejecutables y descargarlos. De los Dlls descargados también es posible encontrar nuevos namespaces donde deberías intentar acceder y obtener el archivo web.config para encontrar nuevos namespaces y assemblyIdentity. Además, los archivos connectionstrings.config y global.asax pueden contener información interesante.\
En aplicaciones .Net MVC, el archivo web.config juega un papel crucial al especificar cada archivo binario del que depende la aplicación a través de etiquetas XML "assemblyIdentity".
Un ejemplo de acceso al archivo web.config se muestra a continuación:
Esta solicitud revela varias configuraciones y dependencias, tales como:
EntityFramework versión
AppSettings para páginas web, validación de clientes y JavaScript
Configuraciones de System.web para autenticación y tiempo de ejecución
Configuraciones de módulos de System.webServer
Vínculos de ensamblado de Runtime para numerosas bibliotecas como Microsoft.Owin, Newtonsoft.Json y System.Web.Mvc
Estas configuraciones indican que ciertos archivos, como /bin/WebGrease.dll, se encuentran dentro de la carpeta /bin de la aplicación.
Los archivos encontrados en el directorio raíz, como /global.asax y /connectionstrings.config (que contiene contraseñas sensibles), son esenciales para la configuración y operación de la aplicación.
Las aplicaciones MVC también definen archivos web.config adicionales para namespaces específicos para evitar declaraciones repetitivas en cada archivo, como se demuestra con una solicitud para descargar otro web.config:
La mención de un espacio de nombres personalizado sugiere la presencia de una DLL llamada "WebApplication1" en el directorio /bin. A continuación, se muestra una solicitud para descargar la WebApplication1.dll:
Esto sugiere la presencia de otros DLLs esenciales, como System.Web.Mvc.dll y System.Web.Optimization.dll, en el directorio /bin.
En un escenario donde un DLL importa un espacio de nombres llamado WebApplication1.Areas.Minded, un atacante podría inferir la existencia de otros archivos web.config en rutas predecibles, como /area-name/Views/, que contienen configuraciones específicas y referencias a otros DLLs en la carpeta /bin. Por ejemplo, una solicitud a /Minded/Views/web.config puede revelar configuraciones y espacios de nombres que indican la presencia de otro DLL, WebApplication1.AdditionalFeatures.dll.
Desde aquí
Si ves un error como el siguiente:
Significa que el servidor no recibió el nombre de dominio correcto dentro del encabezado Host. Para acceder a la página web, podrías echar un vistazo al Certificado SSL servido y tal vez puedas encontrar el nombre de dominio/subdominio allí. Si no está allí, es posible que necesites fuerza bruta VHosts hasta que encuentres el correcto.
Puedes intentar enumerar carpetas y archivos dentro de cada carpeta descubierta (incluso si requiere Autenticación Básica) usando esta técnica. La principal limitación de esta técnica si el servidor es vulnerable es que solo puede encontrar hasta las primeras 6 letras del nombre de cada archivo/carpeta y las primeras 3 letras de la extensión de los archivos.
Puedes usar https://github.com/irsdl/IIS-ShortName-Scanner para probar esta vulnerabilidad:java -jar iis_shortname_scanner.jar 2 20 http://10.13.38.11/dev/dca66d38fd916317687e1390a420c3fc/db/
Investigación original: https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf
También puedes usar metasploit: use scanner/http/iis_shortname_scanner
Una buena idea para encontrar el nombre final de los archivos descubiertos es preguntar a LLMs por opciones como se hace en el script https://github.com/Invicti-Security/brainstorm/blob/main/fuzzer_shortname.py
Bypass de una autenticación básica (IIS 7.5) intentando acceder a: /admin:$i30:$INDEX_ALLOCATION/admin.php o /admin::$INDEX_ALLOCATION/admin.php
Puedes intentar mezclar esta vulnerabilidad y la anterior para encontrar nuevas carpetas y eludir la autenticación.
ASP.NET incluye un modo de depuración y su archivo se llama trace.axd.
Mantiene un registro muy detallado de todas las solicitudes realizadas a una aplicación durante un período de tiempo.
Esta información incluye IPs de clientes remotos, IDs de sesión, todas las cookies de solicitud y respuesta, rutas físicas, información del código fuente y potencialmente incluso nombres de usuario y contraseñas.
https://www.rapid7.com/db/vulnerabilities/spider-asp-dot-net-trace-axd/
ASPXAUTH utiliza la siguiente información:
validationKey (cadena): clave codificada en hex para usar en la validación de firma.
decryptionMethod (cadena): (por defecto “AES”).
decryptionIV (cadena): vector de inicialización codificado en hex (por defecto un vector de ceros).
decryptionKey (cadena): clave codificada en hex para usar en la decripción.
Sin embargo, algunas personas usarán los valores predeterminados de estos parámetros y usarán como cookie el correo electrónico del usuario. Por lo tanto, si puedes encontrar una web que use la misma plataforma que está utilizando la cookie ASPXAUTH y creas un usuario con el correo electrónico del usuario que deseas suplantar en el servidor bajo ataque, podrías ser capaz de usar la cookie del segundo servidor en el primero y suplantar al usuario. Este ataque funcionó en este writeup.
Informe completo aquí: Un error en el código no verificó correctamente la contraseña proporcionada por el usuario, por lo que un atacante cuyo hash de contraseña coincide con una clave que ya está en la caché podrá iniciar sesión como ese usuario.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
