Normalização Unicode

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

Você trabalha em uma empresa de segurança cibernética? Você quer ver sua empresa anunciada no HackTricks? ou você quer ter acesso à última versão do PEASS ou baixar o HackTricks em PDF? Confira os PLANOS DE ASSINATURA!
Descubra A Família PEASS, nossa coleção exclusiva de NFTs
Adquira o swag oficial do PEASS & HackTricks
Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-me no Twitter 🐦@carlospolopm.
Compartilhe suas técnicas de hacking enviando PRs para o repositório hacktricks e para o repositório hacktricks-cloud.

Contexto

A normalização garante que duas strings que podem usar uma representação binária diferente para seus caracteres tenham o mesmo valor binário após a normalização.

Existem dois tipos gerais de equivalência entre caracteres, "Equivalência Canônica" e "Equivalência de Compatibilidade":
Caracteres "Equivalente Canônico" são assumidos como tendo a mesma aparência e significado quando impressos ou exibidos. A "Equivalência de Compatibilidade" é uma equivalência mais fraca, na qual dois valores podem representar o mesmo caractere abstrato, mas podem ser exibidos de maneira diferente. Existem 4 algoritmos de normalização definidos pelo padrão Unicode; NFC, NFD, NFKD e NFKD, cada um aplica técnicas de normalização canônica e de compatibilidade de maneira diferente. Você pode ler mais sobre as diferentes técnicas em Unicode.org.

Codificação Unicode

Embora o Unicode tenha sido em parte projetado para resolver problemas de interoperabilidade, a evolução do padrão, a necessidade de suportar sistemas legados e diferentes métodos de codificação ainda podem representar um desafio.
Antes de mergulharmos nos ataques Unicode, os seguintes são os principais pontos a entender sobre o Unicode:

Cada caractere ou símbolo é mapeado para um valor numérico que é referido como um "ponto de código".
O valor do ponto de código (e, portanto, o próprio caractere) é representado por 1 ou mais bytes na memória. Caracteres LATIN-1 como os usados em países de língua inglesa podem ser representados usando 1 byte. Outros idiomas têm mais caracteres e precisam de mais bytes para representar todos os diferentes pontos de código (também porque não podem usar os já usados pelo LATIN-1).
O termo "codificação" significa o método pelo qual os caracteres são representados como uma série de bytes. O padrão de codificação mais comum é o UTF-8, usando esse esquema de codificação, caracteres ASCII podem ser representados usando 1 byte ou até 4 bytes para outros caracteres.
Quando um sistema processa dados, ele precisa saber a codificação usada para converter o fluxo de bytes em caracteres.
Embora o UTF-8 seja o mais comum, existem padrões de codificação semelhantes chamados UTF-16 e UTF-32, a diferença entre cada um é o número de bytes usados para representar cada caractere. ou seja, UTF-16 usa um mínimo de 2 bytes (mas até 4) e UTF-32 usa 4 bytes para todos os caracteres.

Um exemplo de como o Unicode normaliza dois bytes diferentes que representam o mesmo caractere:

Uma lista de caracteres Unicode equivalentes pode ser encontrada aqui: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html e https://0xacb.com/normalization_table

Descoberta

Se você encontrar em um aplicativo da web um valor que está sendo ecoado de volta, você pode tentar enviar 'KELVIN SIGN' (U+0212A) que normaliza para "K" (você pode enviá-lo como %e2%84%aa). Se um "K" for ecoado de volta, então, algum tipo de normalização Unicode está sendo realizada.

Outro exemplo: %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 após a normalização Unicode é Leonishan.

Exemplos vulneráveis

Bypass de filtro de injeção SQL

Imagine uma página da web que está usando o caractere ' para criar consultas SQL com a entrada do usuário. Esta página da web, como medida de segurança, deleta todas as ocorrências do caractere ' da entrada do usuário, mas após essa exclusão e antes da criação da consulta, ela normaliza usando Unicode a entrada do usuário.

Então, um usuário mal-intencionado poderia inserir um caractere Unicode diferente equivalente a ' (0x27) como %ef%bc%87, quando a entrada é normalizada, uma única aspa é criada e uma vulnerabilidade de injeção SQL aparece:

Alguns caracteres Unicode interessantes

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

Modelo sqlmap

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

XSS (Cross Site Scripting)

Você pode usar um dos seguintes caracteres para enganar o aplicativo da web e explorar um XSS:

Observe que, por exemplo, o primeiro caractere Unicode proposto pode ser enviado como: %e2%89%ae ou como %u226e

Fuzzing Regexes

Quando o backend está verificando a entrada do usuário com um regex, pode ser possível que a entrada esteja sendo normalizada para o regex mas não para onde ele está sendo usado. Por exemplo, em um Open Redirect ou SSRF, o regex pode estar normalizando o URL enviado mas depois acessando-o como está.

A ferramenta recollapse permite gerar variações da entrada para fuzz o backend. Para mais informações, verifique o github e este post.

Referências

Todas as informações desta página foram retiradas de: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/#

Outras referências: