Unicode Normalization

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

Este es un resumen de: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Consulta para más detalles (imágenes tomadas de allí).

Entendiendo Unicode y Normalización

La normalización de Unicode es un proceso que asegura que diferentes representaciones binarias de caracteres se estandaricen al mismo valor binario. Este proceso es crucial al tratar con cadenas en programación y procesamiento de datos. El estándar Unicode define dos tipos de equivalencia de caracteres:

  1. Equivalencia Canónica: Los caracteres se consideran canónicamente equivalentes si tienen la misma apariencia y significado cuando se imprimen o se muestran.

  2. Equivalencia de Compatibilidad: Una forma más débil de equivalencia donde los caracteres pueden representar el mismo carácter abstracto pero pueden mostrarse de manera diferente.

Hay cuatro algoritmos de normalización de Unicode: NFC, NFD, NFKC y NFKD. Cada algoritmo emplea técnicas de normalización canónica y de compatibilidad de manera diferente. Para una comprensión más profunda, puedes explorar estas técnicas en Unicode.org.

Puntos Clave sobre la Codificación Unicode

Entender la codificación Unicode es fundamental, especialmente al tratar con problemas de interoperabilidad entre diferentes sistemas o lenguajes. Aquí están los puntos principales:

  • Puntos de Código y Caracteres: En Unicode, a cada carácter o símbolo se le asigna un valor numérico conocido como "punto de código".

  • Representación en Bytes: El punto de código (o carácter) se representa por uno o más bytes en memoria. Por ejemplo, los caracteres LATIN-1 (comunes en países de habla inglesa) se representan utilizando un byte. Sin embargo, los idiomas con un conjunto más grande de caracteres necesitan más bytes para su representación.

  • Codificación: Este término se refiere a cómo los caracteres se transforman en una serie de bytes. UTF-8 es un estándar de codificación prevalente donde los caracteres ASCII se representan utilizando un byte, y hasta cuatro bytes para otros caracteres.

  • Procesamiento de Datos: Los sistemas que procesan datos deben ser conscientes de la codificación utilizada para convertir correctamente el flujo de bytes en caracteres.

  • Variantes de UTF: Además de UTF-8, hay otros estándares de codificación como UTF-16 (que utiliza un mínimo de 2 bytes, hasta 4) y UTF-32 (que utiliza 4 bytes para todos los caracteres).

Es crucial comprender estos conceptos para manejar y mitigar eficazmente los problemas potenciales que surgen de la complejidad de Unicode y sus diversos métodos de codificación.

Un ejemplo de cómo Unicode normaliza dos bytes diferentes que representan el mismo carácter:

unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")

Una lista de caracteres equivalentes en Unicode se puede encontrar aquí: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html y https://0xacb.com/normalization_table

Descubriendo

Si puedes encontrar dentro de una webapp un valor que se está devolviendo, podrías intentar enviar ‘KELVIN SIGN’ (U+0212A) que se normaliza a "K" (puedes enviarlo como %e2%84%aa). Si se devuelve una "K", entonces, se está realizando algún tipo de normalización de Unicode.

Otro ejemplo: %F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83 después de unicode es Leonishan.

Ejemplos Vulnerables

Bypass de filtro de inyección SQL

Imagina una página web que está utilizando el carácter ' para crear consultas SQL con la entrada del usuario. Esta web, como medida de seguridad, elimina todas las ocurrencias del carácter ' de la entrada del usuario, pero después de esa eliminación y antes de la creación de la consulta, normaliza usando Unicode la entrada del usuario.

Entonces, un usuario malicioso podría insertar un carácter Unicode diferente equivalente a ' (0x27) como %ef%bc%87, cuando la entrada se normaliza, se crea una comilla simple y aparece una vulnerabilidad de SQLInjection:

https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/

Algunos caracteres Unicode interesantes

  • o -- %e1%b4%bc

  • r -- %e1%b4%bf

  • 1 -- %c2%b9

  • = -- %e2%81%bc

  • / -- %ef%bc%8f

  • --- %ef%b9%a3

  • #-- %ef%b9%9f

  • *-- %ef%b9%a1

  • ' -- %ef%bc%87

  • " -- %ef%bc%82

  • | -- %ef%bd%9c

' or 1=1-- -
%ef%bc%87+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

" or 1=1-- -
%ef%bc%82+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

' || 1==1//
%ef%bc%87+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

" || 1==1//
%ef%bc%82+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

plantilla de sqlmap

XSS (Cross Site Scripting)

Puedes usar uno de los siguientes caracteres para engañar a la webapp y explotar un XSS:

https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/

Ten en cuenta que, por ejemplo, el primer carácter Unicode propuesto se puede enviar como: %e2%89%ae o como %u226e

https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/

Fuzzing Regexes

Cuando el backend está verificando la entrada del usuario con una regex, puede ser posible que la entrada esté siendo normalizada para la regex pero no para donde se está usando. Por ejemplo, en un Open Redirect o SSRF, la regex podría estar normalizando la URL enviada pero luego accediendo a ella tal como está.

La herramienta recollapse **** permite generar variaciones de la entrada para fuzzear el backend. Para más información, consulta el github y este post.

Referencias

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

Last updated