65 lines
5.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Unicode Injection
{{#include ../../banners/hacktricks-training.md}}
## Einführung
Je nachdem, wie das Backend/Frontend reagiert, wenn es **seltsame Unicode-Zeichen empfängt**, könnte ein Angreifer in der Lage sein, **Schutzmaßnahmen zu umgehen und beliebige Zeichen einzufügen**, die zur **Ausnutzung von Injektionsanfälligkeiten** wie XSS oder SQLi verwendet werden könnten.
## Unicode-Normalisierung
Die Unicode-Normalisierung erfolgt, wenn **Unicode-Zeichen in ASCII-Zeichen normalisiert werden**.
Ein häufiges Szenario dieser Art von Anfälligkeit tritt auf, wenn das System die **Eingabe** des Benutzers **nach der Überprüfung** auf irgendeine Weise **modifiziert**. Zum Beispiel könnte in einigen Sprachen ein einfacher Aufruf, um die **Eingabe in Groß- oder Kleinbuchstaben** zu konvertieren, die gegebene Eingabe normalisieren und die **Unicode wird in ASCII umgewandelt**, wodurch neue Zeichen entstehen.\
Für weitere Informationen siehe:
{{#ref}}
unicode-normalization.md
{{#endref}}
## `\u` zu `%`
Unicode-Zeichen werden normalerweise mit dem **`\u`-Präfix** dargestellt. Zum Beispiel ist das Zeichen `㱋` `\u3c4b`([hier überprüfen](https://unicode-explorer.com/c/3c4B)). Wenn ein Backend das Präfix **`\u` in `%` umwandelt**, wird die resultierende Zeichenkette `%3c4b` sein, die URL-dekodiert ist: **`<4b`**. Und, wie Sie sehen können, wird ein **`<`-Zeichen injiziert**.\
Sie könnten diese Technik verwenden, um **beliebige Zeichen einzufügen**, wenn das Backend anfällig ist.\
Überprüfen Sie [https://unicode-explorer.com/](https://unicode-explorer.com/), um die benötigten Zeichen zu finden.
Diese Anfälligkeit stammt tatsächlich von einer Schwachstelle, die ein Forscher gefunden hat. Für eine detailliertere Erklärung siehe [https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg).
## Emoji-Injektion
Backends verhalten sich manchmal seltsam, wenn sie **Emojis empfangen**. Das ist, was in [**diesem Bericht**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209) passiert ist, wo der Forscher es geschafft hat, ein XSS mit einer Payload wie: `💋img src=x onerror=alert(document.domain)//💛` zu erreichen.
In diesem Fall war der Fehler, dass der Server nach dem Entfernen der bösartigen Zeichen **die UTF-8-Zeichenkette von Windows-1252 nach UTF-8 konvertierte** (grundsätzlich stimmte die Eingabecodierung und die Umwandlung der Codierung nicht überein). Dadurch wird kein richtiges < erzeugt, sondern nur ein seltsames Unicode-Zeichen: ``\
``Also nahmen sie diese Ausgabe und **konvertierten sie erneut von UTF-8 nach ASCII**. Dies **normalisierte** das `` zu `<`, so konnte der Exploit auf diesem System funktionieren.\
Das ist, was passiert ist:
```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-Listen:
- [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
- [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)
## Windows Best-Fit/Worst-fit
Wie in **[diesem großartigen Beitrag](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)** erklärt, hat Windows eine Funktion namens **Best-Fit**, die **Unicode-Zeichen** ersetzt, die im ASCII-Modus nicht angezeigt werden können, durch ein ähnliches Zeichen. Dies kann zu **unerwartetem Verhalten** führen, wenn das Backend **ein bestimmtes Zeichen** erwartet, aber ein anderes erhält.
Es ist möglich, Best-Fit-Zeichen in **[https://worst.fit/mapping/](https://worst.fit/mapping/)** zu finden.
Da Windows normalerweise Unicode-Zeichenfolgen in ASCII-Zeichenfolgen als einen der letzten Teile der Ausführung konvertiert (normalerweise von einer "W"-suffixed API zu einer "A"-suffixed API wie `GetEnvironmentVariableA` und `GetEnvironmentVariableW`), würde dies Angreifern ermöglichen, Schutzmaßnahmen zu umgehen, indem sie Unicode-Zeichen senden, die zuletzt in ASCII-Zeichen konvertiert werden, die unerwartete Aktionen ausführen würden.
Im Blogbeitrag werden Methoden vorgeschlagen, um Schwachstellen zu umgehen, die mit einer **Blacklist von Zeichen** behoben wurden, **Pfadtraversalen** unter Verwendung von [Zeichen, die auf “/“ (0x2F) abgebildet sind](https://worst.fit/mapping/#to%3A0x2f) und [Zeichen, die auf “\“ (0x5C) abgebildet sind](https://worst.fit/mapping/#to%3A0x5c) oder sogar Schutzmaßnahmen gegen Shell-Escape wie PHPs `escapeshellarg` oder Pythons `subprocess.run` zu umgehen, indem eine Liste verwendet wird. Dies wurde beispielsweise mit **Vollbreiten-Doppel-Anführungszeichen (U+FF02)** anstelle von Doppel-Anführungszeichen durchgeführt, sodass am Ende das, was wie 1 Argument aussah, in 2 Argumente umgewandelt wurde.
**Beachten Sie, dass eine App anfällig sein muss, um "W" Windows-APIs zu verwenden, aber schließlich eine "A" Windows-API aufzurufen, damit das "Best-Fit" der Unicode-Zeichenfolge erstellt wird.**
**Mehrere entdeckte Schwachstellen werden nicht behoben, da die Leute sich nicht einig sind, wer dieses Problem beheben sollte.**
{{#include ../../banners/hacktricks-training.md}}