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

8.7 KiB
Raw Blame History

Normalização Unicode

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

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 Canonicamente Equivalentes são considerados com a mesma aparência e significado quando impressos ou exibidos. 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 projetado em parte 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 explorarmos ataques Unicode, os seguintes são os principais pontos a entender sobre Unicode:

  • Cada caractere ou símbolo é mapeado para um valor numérico referido como “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. Outras línguas 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á ocupados pela LATIN-1).
  • O termo “codificação” significa o método no qual os caracteres são representados como uma série de bytes. O padrão de codificação mais comum é 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 a sequência de bytes em caracteres.
  • Embora 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. Por exemplo, 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 representando 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

Descobrindo

Se você encontrar dentro de um webapp um valor que está sendo ecoado de volta, você poderia tentar enviar ‘SINAL DE KELVIN’ (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 executado.

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 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 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 malicioso poderia inserir um caractere Unicode diferente equivalente a ' (0x27) como %ef%bc%87, quando a entrada é normalizada, uma aspa simples é criada e uma vulnerabilidade de SQLInjection 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

sqlmap template

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

XSS (Cross Site Scripting)

Você pode usar um dos seguintes caracteres para enganar o webapp 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 uma regex, pode ser possível que a entrada esteja sendo normalizada para a regex, mas não para onde está sendo usada. Por exemplo, em um Redirecionamento Aberto ou SSRF, a regex pode estar normalizando a URL enviada mas depois acessando-a como está.

A ferramenta recollapse permite gerar variações da entrada para fazer fuzzing no backend. Para mais informações, confira 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:

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks: