Unicode Injection

Reading time: 5 minutes

Introduction

Afhangend van hoe die back-end/front-end optree wanneer dit weird unicode karakters ontvang, mag 'n aanvaller in staat wees om beskermings te omseil en arbitrêre karakters in te spuit wat gebruik kan word om inspuitingskwesbaarhede te misbruik soos XSS of SQLi.

Unicode Normalization

Unicode normalisering vind plaas wanneer unicode karakters genormaliseer word na ascii karakters.

Een algemene scenario van hierdie tipe kwesbaarheid gebeur wanneer die stelsel die invoer van die gebruiker op 'n of ander manier aanpas nadat dit nagegaan is. Byvoorbeeld, in sommige tale kan 'n eenvoudige oproep om die invoer hoofletters of kleinletters te maak die gegewe invoer normaliseer en die unicode sal in ASCII omgeskakel word, wat nuwe karakters genereer.
Vir meer inligting, kyk:

Unicode Normalization

\u na %

Unicode karakters word gewoonlik verteenwoordig met die \u voorvoegsel. Byvoorbeeld, die karakter 㱋 is \u3c4b(kyk dit hier). As 'n backend die voorvoegsel \u in % omskakel, sal die resulterende string %3c4b wees, wat URL-dekodeer is: <4b. En, soos jy kan sien, is 'n < karakter ingespuit.
Jy kan hierdie tegniek gebruik om enige soort karakter in te spuit as die backend kwesbaar is.
Kyk https://unicode-explorer.com/ om die karakters te vind wat jy nodig het.

Hierdie kwesbaarheid kom eintlik van 'n kwesbaarheid wat 'n navorser gevind het, vir 'n meer diepgaande verduideliking, kyk https://www.youtube.com/watch?v=aUsAHb0E7Cg

Emoji Injection

Back-ends gedra soms vreemd wanneer hulle emojis ontvang. Dit is wat gebeur het in hierdie skrywe waar die navorser daarin geslaag het om 'n XSS te bereik met 'n payload soos: 💋img src=x onerror=alert(document.domain)//💛

In hierdie geval was die fout dat die bediener, nadat dit die kwaadwillige karakters verwyder het, die UTF-8 string van Windows-1252 na UTF-8 omgeskakel het (basies het die invoer kodering en die omskakeling van kodering nie ooreengestem nie). Dit gee dan nie 'n behoorlike < nie, net 'n vreemde unicode een: ‹
``So het hulle hierdie uitvoer geneem en weer van UTF-8 na ASCII omgeskakel. Dit het die ‹ na < genormaliseer, dit is hoe die eksploit op daardie stelsel kon werk.
Dit is wat gebeur het:

<?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 Beste-Pas / Sleg-Pas

Soos verduidelik in hierdie wonderlike pos, het Windows 'n kenmerk genaamd Beste-Pas wat unicode karakters wat nie in ASCII-modus vertoon kan word nie, met 'n soortgelyke een sal vervang. Dit kan lei tot onverwagte gedrag wanneer die agterkant 'n spesifieke karakter verwag, maar 'n ander een ontvang.

Dit is moontlik om beste-pas karakters te vind in https://worst.fit/mapping/.

Aangesien Windows gewoonlik unicode strings na ascii strings omskakel as een van die laaste dele van die uitvoering (gewoonlik van 'n "W" agtervoegsel API na 'n "A" agtervoegsel API soos GetEnvironmentVariableA en GetEnvironmentVariableW), sal dit aanvallers in staat stel om beskermings te omseil deur unicode karakters te stuur wat laastens in ASCII karakters omgeskakel sal word wat onverwagte aksies sal uitvoer.

In die blogpos word voorgestelde metodes aangebied om kwesbaarhede te omseil wat reggestel is met 'n swartlys van karakters, om pad traversals te benut met karakters wat na “/“ (0x2F) gekarteer is en karakters wat na “\“ (0x5C) gekarteer is of selfs om shell escape beskermings soos PHP se escapeshellarg of Python se subprocess.run te omseil deur 'n lys te gebruik, dit is byvoorbeeld gedoen deur volledige breedte dubbele aanhalings (U+FF02) te gebruik in plaas van dubbele aanhalings, sodat wat aan die einde soos 1 argument gelyk het, in 2 argumente omgeskakel is.

Let daarop dat vir 'n app kwesbaar te wees, dit "W" Windows APIs moet gebruik, maar uiteindelik 'n "A" Windows API moet aanroep sodat die "Beste-pas" van die unicode string geskep word.

Verskeie ontdekte kwesbaarhede sal nie reggestel word nie, aangesien mense nie saamstem wie hierdie probleem moet regstel nie.