Injection Unicode

Reading time: 5 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Introduction

Selon le comportement du back-end/front-end lorsqu'il reçoit des caractères unicode étranges, un attaquant pourrait être en mesure de contourner les protections et d'injecter des caractères arbitraires qui pourraient être utilisés pour exploiter des vulnérabilités d'injection telles que XSS ou SQLi.

Normalisation Unicode

La normalisation Unicode se produit lorsque les caractères unicode sont normalisés en caractères ascii.

Un scénario courant de ce type de vulnérabilité se produit lorsque le système modifie d'une manière ou d'une autre l'entrée de l'utilisateur après l'avoir vérifiée. Par exemple, dans certaines langues, un simple appel pour mettre l'entrée en majuscules ou en minuscules pourrait normaliser l'entrée donnée et le unicode sera transformé en ASCII, générant de nouveaux caractères.
Pour plus d'infos, consultez :

Unicode Normalization

\u à %

Les caractères Unicode sont généralement représentés avec le préfixe \u. Par exemple, le caractère 㱋 est \u3c4b(vérifiez-le ici). Si un backend transforme le préfixe \u en %, la chaîne résultante sera %3c4b, qui décodée URL est : <4b. Et, comme vous pouvez le voir, un caractère < est injecté.
Vous pourriez utiliser cette technique pour injecter n'importe quel type de caractère si le backend est vulnérable.
Consultez https://unicode-explorer.com/ pour trouver les caractères dont vous avez besoin.

Cette vulnérabilité provient en fait d'une vulnérabilité qu'un chercheur a trouvée, pour une explication plus approfondie, consultez https://www.youtube.com/watch?v=aUsAHb0E7Cg

Injection d'Émojis

Les back-ends se comportent parfois de manière étrange lorsqu'ils reçoivent des émojis. C'est ce qui s'est passé dans ce rapport où le chercheur a réussi à obtenir un XSS avec une charge utile telle que : 💋img src=x onerror=alert(document.domain)//💛

Dans ce cas, l'erreur était que le serveur, après avoir supprimé les caractères malveillants, a converti la chaîne UTF-8 de Windows-1252 à UTF-8 (essentiellement, l'encodage d'entrée et la conversion d'encodage étaient incompatibles). Cela ne donne pas un < correct, juste un unicode étrange : ‹
``Ils ont donc pris cette sortie et convertie à nouveau maintenant de UTF-8 à ASCII. Cela a normalisé le ‹ en <, c'est ainsi que l'exploit a pu fonctionner sur ce système.
Voici ce qui s'est passé :

php
<?php

$str = isset($_GET["str"]) ? htmlspecialchars($_GET["str"]) : "";

$str = iconv("Windows-1252", "UTF-8", $str);
$str = iconv("UTF-8", "ASCII//TRANSLIT", $str);

echo "String: " . $str;

Emoji lists:

Windows Best-Fit/Worst-fit

Comme expliqué dans ce super article, Windows a une fonctionnalité appelée Best-Fit qui va remplacer les caractères unicode qui ne peuvent pas être affichés en mode ASCII par un caractère similaire. Cela peut entraîner un comportement inattendu lorsque le backend s'attend à un caractère spécifique mais reçoit un caractère différent.

Il est possible de trouver des caractères best-fit dans https://worst.fit/mapping/.

Comme Windows convertit généralement les chaînes unicode en chaînes ascii comme l'une des dernières parties de l'exécution (passant généralement d'une API suffixée par "W" à une API suffixée par "A" comme GetEnvironmentVariableA et GetEnvironmentVariableW), cela permettrait aux attaquants de contourner les protections en envoyant des caractères unicode qui seront finalement convertis en caractères ASCII qui effectueraient des actions inattendues.

Dans l'article de blog, des méthodes sont proposées pour contourner les vulnérabilités corrigées en utilisant une liste noire de caractères, exploiter des traversées de chemin en utilisant des caractères mappés à “/“ (0x2F) et des caractères mappés à “\“ (0x5C) ou même contourner les protections d'échappement de shell comme escapeshellarg de PHP ou subprocess.run de Python en utilisant une liste, cela a été fait par exemple en utilisant des guillemets doubles en pleine largeur (U+FF02) au lieu de guillemets doubles, de sorte qu'à la fin ce qui semblait être 1 argument était transformé en 2 arguments.

Notez que pour qu'une application soit vulnérable, elle doit utiliser des API Windows "W" mais finir par appeler une API Windows "A" afin que le "Best-fit" de la chaîne unicode soit créé.

Plusieurs vulnérabilités découvertes ne seront pas corrigées car les gens ne s'accordent pas sur qui devrait résoudre ce problème.

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks