Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-30 00:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/unicode-injection/unicode-normalization.md

8.8 KiB
Raw Blame History

Normalización Unicode

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Antecedentes

La normalización asegura que dos cadenas que pueden usar una representación binaria diferente para sus caracteres tengan el mismo valor binario después de la normalización.

Hay dos tipos generales de equivalencia entre caracteres, “Equivalencia Canónica” y “Equivalencia de Compatibilidad”:
Los caracteres Canónicamente Equivalentes se asumen que tienen la misma apariencia y significado cuando se imprimen o se muestran. La Equivalencia de Compatibilidad es una equivalencia más débil, en la que dos valores pueden representar el mismo carácter abstracto pero pueden mostrarse de manera diferente. Hay 4 algoritmos de Normalización definidos por el estándar Unicode; NFC, NFD, NFKD y NFKD, cada uno aplica técnicas de normalización Canónica y de Compatibilidad de manera diferente. Puedes leer más sobre las diferentes técnicas en Unicode.org.

Codificación Unicode

Aunque Unicode fue diseñado en parte para resolver problemas de interoperabilidad, la evolución del estándar, la necesidad de soportar sistemas heredados y diferentes métodos de codificación aún pueden plantear un desafío.
Antes de adentrarnos en ataques Unicode, los siguientes son los puntos principales a entender sobre Unicode:

  • Cada carácter o símbolo está mapeado a un valor numérico que se conoce como “punto de código”.
  • El valor del punto de código (y por lo tanto el carácter en sí) está representado por 1 o más bytes en memoria. Los caracteres LATIN-1 como los utilizados en países de habla inglesa pueden representarse usando 1 byte. Otros idiomas tienen más caracteres y necesitan más bytes para representar todos los diferentes puntos de código (también porque no pueden usar los ya tomados por LATIN-1).
  • El término “codificación” significa el método en el que los caracteres se representan como una serie de bytes. El estándar de codificación más común es UTF-8, usando este esquema de codificación los caracteres ASCII pueden representarse usando 1 byte o hasta 4 bytes para otros caracteres.
  • Cuando un sistema procesa datos necesita saber la codificación utilizada para convertir la secuencia de bytes en caracteres.
  • Aunque UTF-8 es el más común, hay estándares de codificación similares llamados UTF-16 y UTF-32, la diferencia entre cada uno es el número de bytes utilizados para representar cada carácter. Por ejemplo, UTF-16 usa un mínimo de 2 bytes (pero hasta 4) y UTF-32 usa 4 bytes para todos los caracteres.

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

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

Descubrimiento

Si puedes encontrar dentro de una webapp un valor que se está reflejando, podrías intentar enviar ‘KELVIN SIGN’ (U+0212A) que se normaliza a "K" (puedes enviarlo como %e2%84%aa). Si se refleja una "K", entonces, se está realizando algún tipo de normalización 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:

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 sqlmap

{% embed url="https://github.com/carlospolop/sqlmap_to_unicode_template" %}

XSS (Cross Site Scripting)

Podrías usar uno de los siguientes caracteres para engañar a la aplicación web y explotar un XSS:

Observa que, por ejemplo, el primer carácter Unicode propuesto puede enviarse como: %e2%89%ae o como %u226e

Fuzzing de Regexes

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

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

Referencias

Toda la información de esta página fue tomada de: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/#

Otras referencias:

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: