Unicode Injection

Reading time: 5 minutes

Wprowadzenie

W zależności od tego, jak zachowuje się back-end/front-end, gdy otrzymuje dziwne znaki unicode, atakujący może być w stanie obejść zabezpieczenia i wstrzyknąć dowolne znaki, które mogą być użyte do wykorzystania luk w wstrzykiwaniu, takich jak XSS czy SQLi.

Normalizacja Unicode

Normalizacja Unicode zachodzi, gdy znaki unicode są normalizowane do znaków ascii.

Jednym z powszechnych scenariuszy tego typu luki jest sytuacja, gdy system modyfikuje w jakiś sposób wejście użytkownika po jego sprawdzeniu. Na przykład, w niektórych językach proste wywołanie do zamiany wejścia na wielkie lub małe litery może znormalizować dane wejściowe, a unicode zostanie przekształcone na ASCII, generując nowe znaki.
Aby uzyskać więcej informacji, sprawdź:

Unicode Normalization

\u do %

Znaki unicode są zazwyczaj reprezentowane z prefiksem \u. Na przykład znak 㱋 to \u3c4b(sprawdź to tutaj). Jeśli backend przekształca prefiks \u na %, wynikowy ciąg będzie %3c4b, który po dekodowaniu URL to: <4b. I, jak widać, znak < jest wstrzykiwany.
Możesz użyć tej techniki do wstrzykiwania dowolnego rodzaju znaku, jeśli backend jest podatny.
Sprawdź https://unicode-explorer.com/, aby znaleźć potrzebne znaki.

Ta luka pochodzi z rzeczywistej luki, którą odkrył badacz, aby uzyskać bardziej szczegółowe wyjaśnienie, sprawdź https://www.youtube.com/watch?v=aUsAHb0E7Cg

Wstrzykiwanie Emoji

Back-endy zachowują się dziwnie, gdy otrzymują emoji. Tak było w tym opisie, gdzie badacz zdołał osiągnąć XSS z ładunkiem takim jak: 💋img src=x onerror=alert(document.domain)//💛

W tym przypadku błąd polegał na tym, że serwer po usunięciu złośliwych znaków przekonwertował ciąg UTF-8 z Windows-1252 na UTF-8 (w zasadzie kodowanie wejściowe i konwersja kodowania były niezgodne). Wtedy to nie daje poprawnego <, tylko dziwne unicode: ‹
``Więc wzięli ten wynik i przekonwertowali ponownie z UTF-8 na ASCII. To znormalizowało ‹ do <, w ten sposób exploit mógł działać w tym systemie.
To, co się wydarzyło:

<?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:

• https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv
• https://unicode.org/emoji/charts-14.0/full-emoji-list.html

Windows Best-Fit/Worst-fit

Jak wyjaśniono w tym świetnym poście, Windows ma funkcję nazwaną Best-Fit, która zastępuje znaki unicode, które nie mogą być wyświetlane w trybie ASCII, podobnym znakiem. Może to prowadzić do nieoczekiwanego zachowania, gdy backend oczekuje konkretnego znaku, ale otrzymuje inny.

Można znaleźć znaki best-fit w https://worst.fit/mapping/.

Ponieważ Windows zazwyczaj konwertuje ciągi unicode na ciągi ascii jako jedną z ostatnich części wykonania (zwykle przechodząc z API z sufiksem "W" do API z sufiksem "A", jak GetEnvironmentVariableA i GetEnvironmentVariableW), pozwala to atakującym na obejście zabezpieczeń, wysyłając znaki unicode, które zostaną ostatecznie przekształcone w znaki ASCII, które wykonają nieoczekiwane działania.

W poście na blogu zaproponowano metody obejścia luk, które zostały naprawione przy użyciu czarnej listy znaków, wykorzystując przechodzenie ścieżek przy użyciu znaków mapowanych na “/“ (0x2F) i znaków mapowanych na “\“ (0x5C) lub nawet obejście zabezpieczeń przed ucieczką powłoki, takich jak escapeshellarg w PHP lub subprocess.run w Pythonie, używając listy; zrobiono to na przykład, używając pełnozakresowych podwójnych cudzysłowów (U+FF02) zamiast podwójnych cudzysłowów, więc na końcu to, co wyglądało jak 1 argument, zostało przekształcone w 2 argumenty.

Zauważ, że aby aplikacja była podatna, musi używać "W" Windows API, ale kończyć wywołując "A" Windows API, aby utworzyć "Best-fit" ciągu unicode.

Wiele odkrytych luk nie zostanie naprawionych, ponieważ ludzie nie zgadzają się, kto powinien zająć się tym problemem.