Explotacion de XSS reflejado

Cross-Site Scripting (XSS)

¿Qué es el XSS (Cross-Site Scripting)?

El Cross-Site Scripting (XSS) es una vulnerabilidad que permite a un atacante inyectar código malicioso, generalmente en forma de JavaScript, en el contexto de una página web que es visitada por otros usuarios. Este ataque se aprovecha de una validación y escape inadecuados de los datos de entrada proporcionados por el usuario, lo que permite ejecutar scripts maliciosos en el navegador de la víctima.

Existen varios tipos de ataques XSS, siendo los más comunes:

1. XSS Reflejado (Reflected XSS): Ocurre cuando el script malicioso se incluye en una URL y se refleja inmediatamente en la respuesta del servidor. El ataque se ejecuta cuando un usuario desprevenido hace clic en un enlace malicioso.

2. XSS Persistente (Stored XSS): Se presenta cuando el código malicioso se almacena permanentemente en el servidor (por ejemplo, en una base de datos) y se ejecuta cuando un usuario accede a la página comprometida.

3. XSS Basado en DOM: Ocurre cuando el código JavaScript malicioso es ejecutado en el navegador del usuario debido a una manipulación insegura del Document Object Model (DOM) en el lado del cliente.

¿Por qué el servicio en la URL es susceptible a ataques XSS?

La URL proporcionada, http://44.199.19.36:4000/links/open?url=123, presenta un posible caso de XSS reflejado, ya que lo que se ingresa como parámetro en url es directamente reflejado en la respuesta HTML, sin una validación o sanitización adecuada.

Veamos cómo responde el servicio cuando se envía el parámetro url=123:

<h1>Welcome to API en desarrollo..</h1>
<h2>Error renderizando la URL proporcionada: <font color="red">123</font> for you</h2><br><br>

Aquí, el valor proporcionado en el parámetro url (en este caso, 123) es insertado directamente en la respuesta HTML, dentro de una etiqueta <font>. Esto indica que el servicio refleja la entrada del usuario sin ningún tipo de filtrado o escape, lo que significa que, si en lugar de proporcionar un valor benigno como "123", un atacante proporciona un script malicioso, este se podría ejecutar en el navegador de un usuario que visite esa URL.

Ejemplo de cómo se podría explotar este XSS

Si el atacante modifica la URL para incluir código JavaScript, como por ejemplo:

http://44.199.19.36:4000/links/open?url=<script>alert('XSS')</script>

El servidor reflejaría este código en la respuesta de esta manera:

• La siguiente pagina nos ayudara a verificar si es vulnerable a XSS insertando los comandos y viendo como responde la pagina.

Page not found - HackTricksbook.hacktricks.xyz

Verificación del Lenguaje de la Página Mientras probamos la vulnerabilidad a XSS mediante comandos específicos, también debemos identificar el lenguaje en el que está desarrollada la página. Conocer el lenguaje puede darnos pistas sobre cómo maneja las entradas y salidas, y ajustar nuestras pruebas en consecuencia.

Algunos posibles lenguajes en los que podría estar desarrollada la página incluyen:

1. PHP:

   • Común en aplicaciones web.

   • Vulnerable si las entradas no son correctamente sanitizadas antes de ser mostradas en la salida (ejemplo: echo $_GET['input'];).

2. JavaScript (Node.js):

   • Popular en frameworks como Express.js.

   • Vulnerable si las entradas del usuario no se escapan adecuadamente en las respuestas.

3. Python (Django, Flask):

   • Utiliza plantillas HTML renderizadas del lado del servidor.

   • Las vulnerabilidades XSS suelen surgir al insertar variables no escapadas en las plantillas.

4. Ruby (Rails):

   • Ofrece protección predeterminada contra XSS, pero puede ser vulnerable si se desactivan o manipulan las configuraciones de seguridad.

5. ASP.NET:

   • Común en aplicaciones empresariales.

   • Vulnerable si las páginas no utilizan correctamente los controles de validación.

6. Java (Spring, JSP):

   • Si no se gestionan correctamente las variables en las vistas, puede permitir la inyección de scripts.

7. Perl, CGI u otros lenguajes menos comunes:

   • Aunque menos utilizados hoy en día, estas páginas también pueden ser vulnerables si no implementan controles adecuados.

Para determinar el lenguaje:

• Analiza las extensiones de las URLs (por ejemplo, .php, .jsp, .asp).

• Inspecciona los encabezados HTTP que pueden contener pistas sobre el servidor (como X-Powered-By).

• Prueba comandos específicos que podrían revelar errores del lenguaje, como inyectar caracteres especiales o funciones específicas de un entorno.

Des esta manera comprobemos name=

Encontramos los parametros adecuados:

Ahora tenemos que hacer una revershell:

Con ngrok

copiamos ese parametro

• nc -nvl123

y tenemos shell 🎉

• ls -la

• which python3 > preguntando si tiene python

tenemos consola integrada a nuestro linux

• cat .bash_history > comando para ver el historial de comandos.

+ Ahora adentro encontremos mas interfaces conectadas a ella

1. Lo primero verificar si tenemos nmap instalado en la maquina victima

pero antes hay q tener la interfaz amigable:

• Instalando nmap:

static-binaries/binaries/linux/x86_64/nmap at master · andrew-d/static-binariesGitHub

verificar los permisos de nmap si no tiene lo necesario agregar con chmod +x

• Verificamos los vecinos que tenemos con nmap:

./nmap -sP 172.16.1.11/24