Unicode Injection

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)

Apoya a HackTricks

• Revisa los planes de suscripción!

• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repos de github.

Introducción

Dependiendo de cómo se comporte el back-end/front-end cuando recibe caracteres unicode extraños, un atacante podría eludir protecciones e inyectar caracteres arbitrarios que podrían ser utilizados para abusar de vulnerabilidades de inyección como XSS o SQLi.

Normalización de Unicode

La normalización de Unicode ocurre cuando los caracteres unicode se normalizan a caracteres ascii.

Un escenario común de este tipo de vulnerabilidad ocurre cuando el sistema está modificando de alguna manera la entrada del usuario después de haberla verificado. Por ejemplo, en algunos lenguajes, una simple llamada para hacer que la entrada esté en mayúsculas o minúsculas podría normalizar la entrada dada y el unicode se transformará en ASCII generando nuevos caracteres. Para más información, consulta:

Unicode Normalization

\u a %

Los caracteres unicode generalmente se representan con el prefijo \u. Por ejemplo, el carácter 㱋 es \u3c4b(ver aquí). Si un backend transforma el prefijo \u en %, la cadena resultante será %3c4b, que decodificada en URL es: <4b. Y, como puedes ver, se inyecta un carácter <. Podrías usar esta técnica para inyectar cualquier tipo de carácter si el backend es vulnerable. Consulta https://unicode-explorer.com/ para encontrar los caracteres que necesitas.

Esta vulnerabilidad proviene de una vulnerabilidad que un investigador encontró, para una explicación más detallada consulta https://www.youtube.com/watch?v=aUsAHb0E7Cg

Inyección de Emoji

Los back-ends a veces se comportan de manera extraña cuando reciben emojis. Eso es lo que sucedió en este informe donde el investigador logró conseguir un XSS con una carga útil como: 💋img src=x onerror=alert(document.domain)//💛

En este caso, el error fue que el servidor, después de eliminar los caracteres maliciosos, convirtió la cadena UTF-8 de Windows-1252 a UTF-8 (básicamente, la codificación de entrada y la conversión de codificación no coincidían). Entonces, esto no da un < adecuado, solo uno unicode extraño: ‹ ``Así que tomaron esta salida y convirtieron nuevamente ahora de UTF-8 a ASCII. Esto normalizó el ‹ a <, así es como el exploit pudo funcionar en ese sistema. Esto es lo que sucedió:

<?php

$str = isset($_GET["str"]) ? htmlspecialchars($_GET["str"]) : "";

$str = iconv("Windows-1252", "UTF-8", $str);
$str = iconv("UTF-8", "ASCII//TRANSLIT", $str);

echo "String: " . $str;

Listas de emojis:

• https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv

• https://unicode.org/emoji/charts-14.0/full-emoji-list.html

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)

Apoya a HackTricks

• Revisa los planes de suscripción!

• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.