Unicode Injection

Reading time: 5 minutes

Introduction

U zavisnosti od toga kako se back-end/front-end ponaša kada primi čudne unicode karaktere, napadač bi mogao da obiđe zaštite i ubrizga proizvoljne karaktere koji bi mogli biti korišćeni za iskorišćavanje ranjivosti injekcije kao što su XSS ili SQLi.

Unicode Normalization

Unicode normalizacija se dešava kada se unicode karakteri normalizuju u ascii karaktere.

Jedan uobičajen scenario ove vrste ranjivosti se dešava kada sistem menja na neki način ulaz korisnika nakon što ga je proverio. Na primer, u nekim jezicima jednostavan poziv za pravljenje ulaza velikim ili malim slovima mogao bi normalizovati dati ulaz i unicode će biti transformisan u ASCII generišući nove karaktere.
Za više informacija pogledajte:

Unicode Normalization

\u to %

Unicode karakteri se obično predstavljaju sa \u prefiksom. Na primer, karakter 㱋 je \u3c4b(proverite ovde). Ako backend transformiše prefiks \u u %, rezultantni string će biti %3c4b, što je URL dekodirano: <4b. I, kao što možete videti, karakter < je ubrizgan.
Možete koristiti ovu tehniku da ubrizgate bilo koju vrstu karaktera ako je backend ranjiv.
Pogledajte https://unicode-explorer.com/ da pronađete potrebne karaktere.

Ova ranjivost zapravo dolazi iz ranjivosti koju je istraživač pronašao, za dublje objašnjenje pogledajte https://www.youtube.com/watch?v=aUsAHb0E7Cg

Emoji Injection

Back-endovi se čudno ponašaju kada primi emojije. To se desilo u ovoj analizi gde je istraživač uspeo da postigne XSS sa payload-om kao što je: 💋img src=x onerror=alert(document.domain)//💛

U ovom slučaju, greška je bila da je server nakon uklanjanja zlonamernih karaktera konvertovao UTF-8 string iz Windows-1252 u UTF-8 (osnovno, kodiranje ulaza i konverzija kodiranja su se neslagali). Tada ovo ne daje pravi < već samo čudan unicode: ‹
``Tako su uzeli ovaj izlaz i ponovo konvertovali sada iz UTF-8 u ASCII. Ovo je normalizovalo ‹ u <, tako je eksploatacija mogla da funkcioniše na tom sistemu.
To je ono što se desilo:

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

• 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

Kao što je objašnjeno u ovom sjajnom postu, Windows ima funkciju pod nazivom Best-Fit koja će zameniti unicode karaktere koji se ne mogu prikazati u ASCII modu sličnim karakterom. To može dovesti do neočekivanog ponašanja kada backend očekuje određeni karakter ali dobija drugačiji.

Moguće je pronaći best-fit karaktere u https://worst.fit/mapping/.

Kako Windows obično konvertuje unicode stringove u ascii stringove kao jedan od poslednjih delova izvršenja (obično prelazeći sa "W" sufiksiranog API-ja na "A" sufiksirani API kao što su GetEnvironmentVariableA i GetEnvironmentVariableW), to bi omogućilo napadačima da zaobiđu zaštite slanjem unicode karaktera koji će na kraju biti konvertovani u ASCII karaktere koji bi izvršili neočekivane radnje.

U blog postu su predložene metode za zaobilaženje ranjivosti koje su ispravljene korišćenjem crne liste karaktera, iskorišćavanje putanja prelaza koristeći karaktere mapirane na “/“ (0x2F) i karaktere mapirane na “\“ (0x5C) ili čak zaobilaženje zaštita od shell escape-a kao što su PHP-ov escapeshellarg ili Python-ov subprocess.run koristeći listu, ovo je urađeno na primer korišćenjem punih dvostrukih navodnika (U+FF02) umesto dvostrukih navodnika tako da je na kraju ono što je izgledalo kao 1 argument transformisano u 2 argumenta.

Napomena da aplikacija bude ranjiva, mora koristiti "W" Windows API-je ali završiti pozivajući "A" Windows API tako da se kreira "Best-fit" unicode stringa.

Nekoliko otkrivenih ranjivosti neće biti ispravljeno jer se ljudi ne slažu ko bi trebao da reši ovaj problem.