Enumeración y explotación web
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
Como se mencionó en la sección anterior, las aplicaciones web son donde solemos invertir la mayor parte del tiempo durante una Prueba de Penetración Externa (PPE). Suelen presentar una amplia superficie de ataque y pueden sufrir diversos tipos de vulnerabilidades que pueden provocar la ejecución remota de código o la exposición de datos confidenciales, por lo que debemos ser minuciosos con ellas.
Es importante recordar que existe una diferencia entre un Web Application Security Assessment (WASA) y un External Penetration Test. En una Prueba de Penetración Externa (WASA), normalmente nos encargamos de encontrar e informar todas las vulnerabilidades, sin importar su gravedad (por ejemplo, una versión del servidor web en los encabezados de respuesta HTTP, una cookie que no tenga el indicador Secure o HttpOnly, etc.). No queremos empantanarnos con este tipo de hallazgos durante una PPE, ya que normalmente tenemos mucho terreno por cubrir.
El documento de Scope of Work (SoW) debe diferenciar claramente entre los dos tipos de evaluación. Debe indicar explícitamente que durante una PPE se realizarán pruebas de aplicaciones web para buscar vulnerabilidades de alto riesgo. Si no tenemos muchos hallazgos, podemos analizar las aplicaciones web con mayor profundidad e incluir un hallazgo general Best Practice Recommendation que enumere varios problemas comunes de seguridad relacionados con los encabezados de respuesta HTTP que observamos con frecuencia, entre otros problemas menores. De esta forma, cumplimos con el contrato al abordar los problemas más importantes, como la inyección SQL, la carga de archivos sin restricciones, XSS, XXE, ataques Local File Inclusion, inyecciones de comandos, etc., pero nos cubrimos con el hallazgo informativo en caso de que el cliente vuelva a preguntar por qué no informamos de X.
La forma más rápida y eficiente de revisar varias aplicaciones web es usar una herramienta como para tomar capturas de pantalla de cada aplicación, como se explica en la sección . Esto es particularmente útil si tenemos un alcance masivo para nuestra evaluación y no es posible explorar cada aplicación web de una en una. En nuestro caso, tenemos 11 subdominios/vhosts (por ahora), así que vale la pena iniciar EyeWitness para que nos ayude, ya que queremos ser lo más eficientes posible para brindar al cliente la mejor evaluación posible. Esto significa acelerar cualquier tarea que se pueda realizar rápido y hacerlo de manera más eficiente sin posibilidad de perderse cosas. La automatización es excelente, pero si nos perdemos la mitad de lo que buscamos, entonces la automatización está haciendo más daño que bien. Asegúrate de comprender lo que hacen tus herramientas y verifica las cosas periódicamente para garantizar que tus herramientas y cualquier script personalizado funcionen como se espera.
Podemos enviar a EyeWitness un archivo .xml de Nmap o un escaneo de Nessus, lo cual resulta útil cuando tenemos un scope grande con muchos puertos abiertos, como suele ocurrir durante una prueba de penetración interna. En nuestro caso, simplemente usaremos la flag -f para proporcionarle la lista de subdominios en un archivo de texto que enumeramos anteriormente.
Los resultados de EyeWitness nos muestran varios hosts muy interesantes, cualquiera de los cuales podría aprovecharse para consolidarse en la red interna. Analicémoslos uno por uno.
Usando cURL, podemos ver que Drupal 9 está en uso.
En nuestro informe pudimos observar que esta instancia de Drupal parece no estar en uso y podría valer la pena eliminarla para reducir aún más la superficie de ataque externa general.
A continuación, el subdominio de carreras profesionales. Este tipo de sitios web suelen permitir al usuario registrar una cuenta, subir un CV y, potencialmente, una foto de perfil. Esta podría ser una vía de ataque interesante. Al acceder primero a la página de inicio de sesión http://careers.inlanefreight.local/login, podemos probar algunas evasiones de autenticación comunes y fuzzear el formulario de inicio de sesión para intentar eludir la autenticación o provocar algún tipo de mensaje de error o retraso que indique una inyección SQL. Como siempre, probamos algunas combinaciones de contraseñas débiles, como admin:admin. También deberíamos comprobar la enumeración de nombres de usuario en los formularios de inicio de sesión (y en los formularios de olvido de contraseña, si existen), pero no se observa ninguna en este caso.
La página http://careers.inlanefreight.local/apply nos permite solicitar un empleo y subir un CV. Al probar esta funcionalidad, se observa que permite subir cualquier tipo de archivo, pero la respuesta HTTP no muestra la ubicación del archivo una vez subido. La fuerza bruta de directorios no devuelve ningún directorio interesante, como /files o /uploads, que pueda albergar una webshell si logramos subir un archivo malicioso.
Una vez registrados, podemos iniciar sesión y explorar. Nos aparece nuestra página de perfil en http://careers.inlanefreight.local/profile?id=9. Intentar fuzzear el parámetro id para SQLi, inyección de comandos, inclusión de archivos, XSS, etc., no da resultado. El número de identificación en sí es interesante. Ajustarlo nos permite acceder a los perfiles de otros usuarios y ver a qué puestos se han postulado. Este es un ejemplo clásico de la vulnerabilidad Insecure Direct Object Reference (IDOR) y sin duda merecería la pena reportarlo debido a la posible exposición de datos confidenciales.
La aplicación web http://dev.inlanefreight.local es sencilla pero llamativa. Cualquier elemento que contenga devla URL o el nombre es interesante, ya que podría exponerse accidentalmente y estar plagado de fallos o no estar listo para producción. La aplicación presenta un formulario de inicio de sesión simple titulado Key Vault. Parece un gestor de contraseñas casero o similar y podría exponer considerablemente los datos si logramos acceder. Las combinaciones de contraseñas débiles y las cargas útiles para eludir la autenticación no nos llevan a ninguna parte, así que volvamos a lo básico y busquemos otras páginas y directorios. Probemos primero con la lista de palabras common.txt usando extensiones de archivo .php para la primera ejecución.
Recibimos algunos resultados interesantes. Los archivos con un código de error 403 forbidden suelen significar que existen, pero el servidor web no nos permite acceder a ellos de forma anónima. Las páginas uploads y upload.php llaman nuestra atención de inmediato. Si podemos cargar un webshell PHP, es probable que podamos acceder directamente a él en el directorio /uploads, que tiene habilitado el listado de directorios. Podemos registrar esto como un hallazgo válido Directory Listing Enabled de bajo riesgo y recopilar la evidencia necesaria para que la redacción del informe sea rápida y sencilla. Al acceder a /upload.php nos muestra un mensaje de error 403 Forbidden y nada más, lo cual es interesante porque el código de estado es un código de éxito 200 OK. Profundicemos en esto.
Experimentando un poco con la solicitud, añadiendo el encabezado X-Custom-IP-Authorization: 127.0.0.1 a la solicitud HTTP en Burp Repeater y luego solicitando la página con el método TRACK de nuevo, se obtiene un resultado interesante. Vemos lo que parece ser un formulario de carga de archivos en el cuerpo de la respuesta HTTP.
Si hacemos clic derecho en cualquier parte de la ventana Response, Repeater podemos seleccionar show response in browser copiar la URL resultante y solicitarla en el navegador que usemos con el proxy Burp. Se carga una plataforma de edición de fotos.
Podemos hacer clic en el botón Browse e intentar cargar un webshell simple con el siguiente contenido:
Guarde el archivo como 5351bf7271abaa2267e03c9ef6393f13.php o algo similar. Es recomendable crear nombres de archivo aleatorios al subir un shell web a un sitio web público para que un atacante no lo encuentre. En nuestro caso, usaríamos un nombre protegido por contraseña o restringido a nuestra dirección IP, ya que el listado de directorios está habilitado y cualquiera podría acceder al directorio /uploads. Intentar subir el archivo .php directamente genera un error: " JPG, JPEG, PNG & GIF files are allowed.", lo que indica que probablemente se esté implementando una validación débil del lado del cliente. Podemos obtener la solicitud POST, enviarla de nuevo a Repeater e intentar modificar el encabezado Content-Type: de la solicitud para ver si podemos engañar a la aplicación para que acepte nuestro archivo como válido. Intentaremos modificar el encabezado para Content-Type: image/png que haga pasar nuestro webshell como un archivo de imagen PNG válido. ¡Funciona! Obtenemos la siguiente respuesta: File uploaded /uploads/5351bf7271abaa2267e03c9ef6393f13.php.
Ahora podemos usar cURL para interactuar con este webshell y ejecutar comandos en el servidor web.
Al verificar la dirección IP del host, no parece que hayamos accedido a la red interna de Inlanefreight, ya que la dirección IP no está dentro del alcance de la red interna. Podría tratarse de un servidor web independiente, así que continuaremos.
Desde aquí, podemos enumerar más el host, buscar datos confidenciales, anotar otros dos hallazgos: HTTP Verb Tampering y Unrestricted File Upload, y pasar al siguiente host.
Del escaneo podemos deducir los siguientes datos:
La versión principal de WordPress es la más reciente (6.0 al momento de escribir este artículo).
El tema en uso escbusiness-investment
El plugin b2i-investor-tools está instalado
El plugin mail-masta está instalado
Podemos añadir otro hallazgo a nuestra lista: Local File Inclusion (LFI). A continuación, veamos si podemos enumerar usuarios de WordPress usando WPScan.
Encontramos varios usuarios:
ilfreightwp
Tom
James
John
Este sitio parece otro olvidado que no debería estar expuesto a internet. Parece ser una especie de aplicación interna para buscar en los registros. Al escribir una comilla simple ( '), se genera un mensaje de error de MySQL que indica la presencia de una vulnerabilidad de inyección SQL: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%'' at line 1. Podemos explotar esto manualmente con un payload como:
También podemos usar sqlmap para aprovechar esto. Primero, capture la solicitud POST con Burp, la guardamos en un archivo y marcamos el parámetro searchitem con un * para que sqlmap sepa dónde inyectar.
A continuación, ejecutamos esto a través de sqlmap de la siguiente manera:
A continuación, podemos enumerar las bases de datos disponibles y ver que la base de datos status es particularmente interesante:
Centrándonos en la base de datos status, encontramos que sólo tiene dos tablas:
A continuación, exploramos el http://support.inlanefreight.localsitio y vemos que se trata de un portal de soporte técnico. Los portales de tickets de soporte nos permiten interactuar con un usuario en vivo y, en ocasiones, pueden provocar un ataque del lado del cliente, donde podemos secuestrar la sesión de un usuario mediante una Cross-Site Scripting (XSS)vulnerabilidad. Al explorar la aplicación, encontramos la /ticket.phppágina donde podemos generar un ticket de soporte. Veamos si podemos activar algún tipo de interacción con el usuario. Complete todos los datos del ticket e incluya lo siguiente en el Messagecampo:
Código: javascript
Cambia la IP por la tuya e inicia un Netcatreceptor en el puerto 9000 (o el puerto que desees). Haz clic en el Sendbotón y comprueba si tu receptor recibe una llamada para confirmar la vulnerabilidad.
Enumeración y explotación web
Ahora necesitamos averiguar cómo podemos robar la cookie de un administrador para poder iniciar sesión y ver qué tipo de acceso podemos obtener. Podemos hacerlo creando los siguientes dos archivos:
índice.php
Código: php
script.js
Código: javascript
A continuación, inicie un servidor web PHP en su host de ataque de la siguiente manera:
Enumeración y explotación web
Por último, crea un nuevo ticket y envía lo siguiente en el campo de mensaje:
Código: javascript
Recibimos una devolución de llamada en nuestro servidor web con una cookie de sesión de administrador:
Enumeración y explotación web
El sitio http://tracking.inlanefreight.local/nos permite ingresar un número de seguimiento y recibir un PDF con el estado de nuestro pedido. La aplicación toma la información del usuario y genera un documento PDF. Al generar el PDF, podemos ver que el Tracking #:campo acepta cualquier información (no solo números) que especifiquemos en el cuadro de búsqueda antes de hacer clic en el Track Nowbotón. Si insertamos una carga útil JavaScript simple como <script>document.write('TESTING THIS')</script>and click Track Now, vemos que se genera el PDF y TESTING THISse muestra el mensaje, lo que parece indicar que el código JavaScript se ejecuta cuando el servidor web genera el documento.
Código: javascript
Pegamos la carga útil en el cuadro de búsqueda y presionamos el Track Nowbotón y el PDF recién generado nos muestra el contenido del archivo, ¡así que hemos leído el archivo local!
Experimenta con esta vulnerabilidad un poco más y descubre a qué más puedes acceder. Por ahora, anotaremos otro hallazgo de alto riesgo SSRF to Local File Ready seguiremos adelante.
Es común encontrar portales de VPN y otros portales de acceso remoto durante pruebas de penetración. Este parece ser un portal de inicio de sesión de VPN SSL de Fortinet. Durante las pruebas, confirmamos que la versión utilizada no era vulnerable a ningún exploit conocido. Podría ser un excelente candidato para la pulverización de contraseñas en una prueba real, siempre que adoptemos un enfoque cuidadoso y mesurado para evitar el bloqueo de cuentas.
Probamos algunos pares de credenciales comunes/débiles, pero recibimos el siguiente mensaje de error: Access denied., por lo que podemos pasar de aquí a la siguiente aplicación.
Requerir la aprobación del administrador para nuevos registros
Listas configuradas de dominios permitidos para registros
Configurar una lista de denegación
Ocasionalmente, nos encontraremos con una instancia de GitLab que no esté adecuadamente protegida. Si logramos acceder a una instancia de GitLab, vale la pena investigar para ver qué tipo de datos podemos encontrar. Podríamos descubrir archivos de configuración que contengan contraseñas, claves SSH u otra información que nos permita acceder aún más. Después de registrarnos, podemos explorar para /explorever a qué proyectos, si los hay, tenemos acceso. Vemos que podemos acceder al shopdev2.inlanefreight.localproyecto, lo que nos da una pista sobre otro subdominio que no descubrimos mediante la transferencia de zona DNS y que probablemente no pudimos encontrar mediante fuerza bruta de subdominios.
Antes de explorar el nuevo subdominio, podemos registrar otro hallazgo de alto riesgo: Misconfigured GitLab Instance.
Podemos probar la búsqueda de vulnerabilidades de inyección y buscar IDOR y otras fallas, pero no encontramos nada particularmente interesante. Probemos el flujo de compra, centrándonos en el proceso de pago del carrito y capturando las solicitudes en Burp Suite. Añada uno o dos artículos al carrito, busque /cart.phpy haga clic en el I AGREEbotón para analizar la solicitud en Burp. En Burp, vemos que POSTse realiza una solicitud XMLen el cuerpo, como se muestra a continuación:
Código: xml
Código: xml
Anotemos otro hallazgo de alto riesgo XML External Entity (XXE) Injection(¡tenemos una lista bastante larga hasta ahora!) y pasemos al último vhost/subdominio.
Descubrimos el monitoringvhost antes, así que no repetiremos el proceso. Usamos ffuf, pero esta enumeración también se puede realizar con otras herramientas. Pruébelo GoBusterpara familiarizarse con más herramientas. Navegar a http://monitoring.inlanefreight.localresulta en una redirección a /login.php. Podemos probar algunas cargas útiles para omitir la autenticación y pares de credenciales débiles comunes, pero no obtenemos resultados; solo recibimos el Invalid Credentials!error constantemente. Dado que se trata de un formulario de inicio de sesión, vale la pena explorarlo más a fondo para poder fuzzearlo un poco con Burp Intruder y ver si podemos generar un mensaje de error que indique una vulnerabilidad de inyección SQL, pero no lo logramos.
Configuraremos hydrael ataque de fuerza bruta, especificando el Invalid Credentials!mensaje de error para filtrar los intentos de inicio de sesión no válidos. Obtenemos una coincidencia para el par de credenciales admin:12qwaszx, una contraseña común de "recorrido por teclado" fácil de recordar, pero muy fácil de descifrar mediante fuerza bruta.
Enumeración y explotación web
Revisamos cada comando. Intentarlo cat /etc/passwdno funciona, así que parece que estamos en un entorno restringido. Nos whoamiproporciona dateinformación básica. No queremos acceder rebootal objetivo ni causar una interrupción del servicio. No podemos acceder cda otros directorios. Al escribir, lsse muestran algunos archivos que probablemente estén almacenados en el directorio al que estamos restringidos.
Hemos ganado la primera batalla, pero parece que hay otro tipo de filtro activado, ya que intentar algo como GET /ping.php?ip=127.0.0.1%0aidsigue generando un Invalid inputerror. A continuación, podemos experimentar con la sintaxis del comando y ver que podemos omitir el segundo filtro usando comillas simples. Cambiando a cURL, podemos ejecutar el idcomando de la siguiente manera:
Enumeración y explotación web
Hemos logrado ejecutar el comando como webdevusuario. Investigando un poco más, observamos que este host tiene varias direcciones IP, una de las cuales lo ubica dentro de la 172.16.8.0/23red que formaba parte del alcance inicial. Si logramos un acceso estable a este host, podríamos acceder a la red interna y comenzar a atacar el dominio de Active Directory.
Enumeración y explotación web
Si regresamos a Burp y realizamos la solicitud GET /ping.php?ip=127.0.0.1%0a'c'at${IFS}ping.php, o algo similar, obtenemos el contenido del archivo y podemos trabajar para superar el filtro y encontrar una forma de establecer un shell inverso.
Código: php
Ahora que finalmente hemos completado todos los servicios y aplicaciones web externos, tenemos una idea clara de los próximos pasos. En la siguiente sección, trabajaremos en establecer un shell inverso en el entorno interno y escalaremos nuestros privilegios para establecer algún tipo de persistencia en el host de destino.
Enumera los servicios accesibles y encuentra una flag. Envíe el valor de la flag como respuesta
A primera vista, parece prometedor. El sitio parece ser una instalación olvidada de Drupal o quizás un sitio de prueba que se configuró y nunca se hizo un hardening. Podemos consultar el módulo para obtener ideas.
Una búsqueda rápida en Google nos muestra que la versión estable actual de Drupal, prevista para producción, es , así que probablemente tendremos que tener suerte y encontrar algún error de configuración, como una contraseña de administrador débil para abusar de la funcionalidad integrada o un plugin vulnerable. Vulnerabilidades conocidas como Drupalgeddon 1-3 no afectan a la versión 9.x de Drupal, así que es un callejón sin salida. Intentar iniciar sesión con algunas combinaciones de contraseña débiles, como admin:admin, admin:Welcome1, etc., no da resultado. Intentar registrar un usuario también falla, así que pasamos a la siguiente aplicación.
Siempre es recomendable probar la funcionalidad de registro de usuarios en cualquier aplicación web que encontremos, ya que puede causar diversos problemas. En HTB Box , es posible registrarse en una aplicación web y modificar nuestro rol al de administrador al momento de registrarse. Esto se inspiró en un hallazgo real de una prueba de penetración externa, donde logré registrar hasta cinco roles de usuario diferentes en una aplicación web conectada a internet. Al iniciar sesión en la aplicación, se detectaron diversas vulnerabilidades de IDOR, lo que provocó errores de autorización en muchas páginas.
Vamos a seguir adelante y registrar una cuenta en http://careers.inlanefreight.local/registery mirar alrededor. Registramos una cuenta con detalles falsos: test@test.comy las credenciales pentester:Str0ngP@ssw0rd!. A veces necesitaremos usar una dirección de correo electrónico real para recibir un enlace de activación. Podemos usar un servicio de correo electrónico desechable como para no saturar nuestra bandeja de entrada o mantener una cuenta ficticia con el correo ProtonMail o similar solo para fines de prueba. Estarás contento de no haber usado tu dirección de correo electrónico real la primera vez que Burp Suite Active Scanner llega a un formulario y te envía más de 1000 correos electrónicos en rápida sucesión. Regístrate también con credenciales decentemente fuertes. No quieres introducir un problema de seguridad en la aplicación web que tienes la tarea de probar al registrarte con credenciales como test:test que podrían potencialmente permanecer en la aplicación mucho después de que la prueba haya terminado (aunque deberíamos, por supuesto, enumerar en un apéndice de nuestro informe cualquier modificación realizada durante la prueba, incluso el registro en un sitio web público).
Tras agotar todas las opciones, nos quedamos con una vulnerabilidad reportable que añadimos a nuestra lista de hallazgos y pasamos a la siguiente aplicación web. Podemos usar cualquier herramienta de fuerza bruta de directorios, pero optaremos por .
Necesitaremos Burp Suite para capturar la solicitud y ver si podemos averiguar qué sucede. Si capturamos la solicitud, la enviamos a Burp Repeater y luego volvemos a solicitar la página usando el método OPTIONS, vemos que se permiten varios métodos: GET,POST,PUT,TRACK,OPTIONS. Al recorrer las distintas opciones, cada una genera un error de servidor hasta que probamos el método TRACK y comprobamos que el encabezado X-Custom-IP-Authorization: está configurado en la respuesta HTTP. Podemos consultar la sección para repasar este tipo de ataque.
El siguiente objetivo de nuestra lista es http://ir.inlanefreight.localel portal de relaciones con inversores de la empresa, alojado en WordPress. Para ello, podemos consultar la sección . Iniciemos el módulo WPScan y veamos qué podemos enumerar usando la opción -ap para enumerar todos los plugins.
El plugin Mail Masta es antiguo y presenta varias vulnerabilidades conocidas. Podemos usar exploit para leer archivos en el sistema de archivos subyacente aprovechando una vulnerabilidad de Local File Inclusion (LFI).
Intentemos forzar la contraseña de una de las cuentas usando lista de palabras de SecLists. Al usar WPScande nuevo, obtenemos una coincidencia para la cuenta ilfreightwp.
Desde aquí, podemos acceder http://ir.inlanefreight.local/wp-login.phpe iniciar sesión con las credenciales ilfreightwp:password1. Una vez iniciada la sesión, se nos dirigirá a http://ir.inlanefreight.local/wp-admin/donde podemos http://ir.inlanefreight.local/wp-admin/theme-editor.php?file=404.php&theme=twentytwentyeditar el archivo 404.php del tema inactivo Twenty Twentyy agregar un shell web PHP para ejecutar código remoto. Tras editar esta página y lograr la ejecución de código siguiendo los pasos de la sección del Attacking Common Applicationsmódulo, podemos registrar otro hallazgo Weak WordPress Admin Credentialsy recomendar a nuestro cliente que implemente varias medidas de refuerzo si planea dejar este sitio de WordPress expuesto externamente.
Este es un ejemplo de un .
Desde aquí, podríamos intentar volcar todos los datos de la base de datos status y registrar otro hallazgo. SQL InjectionInténtelo manualmente usando el módulo como guía y consulte el módulo si necesita ayuda con el enfoque basado en herramientas.
Este es un ejemplo de un ataque de secuencias de comandos entre sitios (XSS) ciegas. Podemos revisar los métodos para la detección de XSS ciegas en el módulo .
A continuación, podemos utilizar un complemento de Firefox como para iniciar sesión utilizando la cookie de sesión del administrador.
Haga clic en el botón Guardar para guardar la cookie nombrada sessiony haga clic en Loginen la esquina superior derecha. Si todo funciona correctamente, seremos redirigidos a [nombre del archivo] http://support.inlanefreight.local/dashboard.php. Tómese un tiempo para registrar otro hallazgo, [ Cross-Site Scripting (XSS)nombre del archivo], teniendo en cuenta que este hallazgo es de alto riesgo, ya que puede usarse para robar la sesión de un administrador activo y acceder al sistema de cola de tickets. Consulte el módulo para repasar información sobre XSS y las diversas maneras en que se puede aprovechar este tipo de vulnerabilidades, incluido el secuestro de sesiones.
Observamos que también podemos inyectar HTML. Una carga útil simple como [ se necesita contexto para "payload <h1>test</h1>"] se renderizará en el Tracking #:campo al generar el PDF. Buscar algo como [se necesita contexto para "googlear"] pdf HTML injection vulnerabilityarroja varios resultados interesantes, como y que analizan el uso de la inyección HTML, XSS y SSRF para la lectura local de archivos. Si bien no se trata en [se necesita contexto para "the Penetration Tester Job Role Path, es importante tener en cuenta que a menudo encontraremos novedades durante nuestras evaluaciones].
Aquí es donde la mentalidad de un tester de penetración es clave. Debemos ser capaces de adaptarnos, investigar y explorar, y tomar la información que encontremos y aplicar nuestro proceso de pensamiento para determinar qué está sucediendo. Tras un breve sondeo, pudimos deducir que la aplicación web genera informes en PDF y que podemos controlar la entrada de un campo que, al parecer, solo debería aceptar números. Mediante una breve investigación, pudimos identificar una clase de vulnerabilidad con la que quizá aún no estemos familiarizados, pero sobre la que existe una considerable cantidad de investigación y documentación. Muchos investigadores publican estudios extremadamente detallados a partir de sus propias evaluaciones o recompensas por errores, y a menudo podemos usar esto como guía para intentar encontrar problemas similares. No hay dos evaluaciones iguales, pero el número de posibles pilas tecnológicas para aplicaciones web es limitado, por lo que es probable que veamos ciertas cosas una y otra vez, y pronto lo nuevo y difícil se convertirá en algo natural. Merece la pena consultar el módulo " para obtener más información sobre SSRF y otros ataques del lado del servidor.
Analicemos algunos de estos artículos para ver si podemos obtener un resultado similar y obtener la lectura local de archivos. Después de esta , probaremos la lectura local de archivos utilizando y también consultando esta sobre la lectura local de archivos mediante XSS en archivos PDF generados dinámicamente. Podemos usar esta carga útil para probar la lectura de archivos, primero probando el /etc/passwdarchivo, que es legible para todo el mundo y debería confirmar la existencia de la vulnerabilidad.
Vale la pena leer estas entradas del blog, analizar este hallazgo y su impacto, y familiarizarse con este tipo de vulnerabilidad. Si nos topamos con algo similar durante una prueba de penetración con el que no estamos familiarizados, pero que nos parece fuera de lugar, podríamos consultar el para analizar la situación. Si tras investigar no logramos descubrir la vulnerabilidad, deberíamos tomar notas detalladas de lo que hemos intentado y nuestro proceso de análisis, y pedir ayuda a nuestros compañeros y miembros más experimentados del equipo. Los equipos de pruebas de penetración suelen contar con personal especializado o con mayor experiencia en ciertas áreas, por lo que es probable que alguien del equipo haya visto esto o algo similar.
Muchas empresas alojan sus propias instancias de GitLab y, a veces, no las bloquean correctamente. Como se explica en la sección del Attacking Common Applicationsmódulo, un administrador puede implementar varios pasos para limitar el acceso a una instancia de GitLab, como:
Nuestra enumeración de la instancia de GitLab nos llevó a otro vhost, así que primero lo añadiremos a nuestro /etc/hostsarchivo para poder acceder a él. Al navegar a [nombre del host] http://shopdev2.inlanefreight.local, se nos redirige a una /login.phppágina de inicio de sesión. Las omisiones de autenticación típicas no nos llevan a ninguna parte, así que volvemos a lo básico según la sección del Attacking Common Applicationsmódulo y probamos algunos pares de credenciales débiles. A veces, lo más sencillo funciona (y sí, vemos este tipo de cosas en producción, tanto internas como externas) y podemos iniciar sesión con [nombre del admin:adminhost]. Una vez iniciada la sesión, vemos una especie de tienda online para comprar productos al por mayor. Cuando vemos dev[nombre del host] en una URL (sobre todo externa), podemos asumir que no está lista para producción y que vale la pena investigarla, sobre todo por el comentario Checkout Process not Implementedal final de la página.
Recordemos el contenido del módulo, concretamente el módulo ; parece ser una buena opción, XML External Entity (XXE) Injectionya que el formulario parece enviar datos al servidor en formato XML. Probamos varias cargas útiles y finalmente logramos la lectura local del archivo para ver su contenido /etc/passwdcon esta carga útil:
Un análisis de la solicitud y respuesta POST en Burp Suite no arroja resultados interesantes. En este punto, hemos agotado casi todos los posibles ataques web y volvemos al contenido del módulo, recordando el módulo de , que se centra en la herramienta hydra. Esta herramienta puede usarse para forzar formularios de inicio de sesión HTTP, así que vamos a probarla. Usaremos la misma del SecListsrepositorio de GitHub que antes.
Una vez iniciada la sesión, se nos presenta una especie de consola de monitorización. Si escribimos help, se nos presenta una lista de comandos. Esto parece un entorno de shell restringido para realizar tareas limitadas y algo muy peligroso que no debería exponerse externamente. La última clase de vulnerabilidades que se enseña en el artículo Penetration Tester Job Role Pathy que aún no hemos cubierto son .
Al revisar los archivos, encontramos un servicio de autenticación y que estamos dentro de un contenedor. La última opción de la lista es connection_test. Al escribirla, se obtiene un Successmensaje y nada más. Al regresar a Burp Suite y usar el proxy para la solicitud, vemos que GETse realiza una solicitud a /ping.phppara la IP del host local 127.0.0.1y la respuesta HTTP muestra un único ataque de ping exitoso. Podemos inferir que el /ping.phpscript está ejecutando un comando operativo mediante una función PHP como , shell_exec(ping -c 1 127.0.0.1)o similar, utilizando la función para ejecutar un comando. Si este script está mal codificado, podría fácilmente resultar en una vulnerabilidad de inyección de comandos, así que probemos algunas cargas útiles comunes.
Parece haber algún tipo de filtro implementado, ya que al intentar cargas útiles estándar como GET /ping.php?ip=%127.0.0.1;idy GET /ping.php?ip=%127.0.0.1|idse produce un Invalid inputerror, lo que significa que probablemente haya una lista negra de caracteres en juego. Podemos omitir este filtro usando un carácter de salto de línea %0A(o nueva línea) como operador de inyección, siguiendo la metodología descrita en la sección " . Podemos realizar una solicitud añadiendo el carácter de nueva línea como se indica a continuación GET /ping.php?ip=127.0.0.1%0a, y el ping sigue siendo exitoso, lo que significa que el carácter no está en la lista negra.
Nuestro próximo reto es encontrar una forma de acceder a una shell inversa. Podemos ejecutar comandos individuales, pero cualquier comando con un espacio no funciona. Volviendo a la sección del Command Injectionsmódulo, recordamos que podemos usar " ($IFS) Linux Environment Variablepara omitir las restricciones de espacio". Podemos combinar esto con la omisión del carácter de nueva línea y empezar a enumerar maneras de obtener una shell inversa. Para facilitarnos la tarea, revisemos el ping.phparchivo para comprender qué se está filtrando y así evitar las conjeturas.
Podemos ver que la mayoría de las opciones para obtener una shell inversa están filtradas, lo que dificulta las cosas; sin embargo, una que no lo está es [ socatnombre del archivo]. Socat es una herramienta versátil que permite capturar shells e incluso pivotar, como vimos en el módulo . Comprobemos si está disponible en el sistema. Al regresar a Burp y usar la solicitud, GET /ping.php?ip=127.0.0.1%0a'w'h'i'ch${IFS}socatvemos que está disponible en el sistema, en [nombre del archivo] /usr/bin/socat.
