Unicode Injection

Reading time: 5 minutes

Introduction

Kulingana na jinsi back-end/front-end inavyofanya kazi wakati in pata wahusika wa unicode wa ajabu, mshambuliaji anaweza kupita ulinzi na kuingiza wahusika wa kawaida ambao wanaweza kutumika kudhulumu udhaifu wa kuingiza kama XSS au SQLi.

Unicode Normalization

Unicode normalization inatokea wakati wahusika wa unicode wanapohaririwa kuwa wahusika wa ascii.

Moja ya hali ya kawaida ya aina hii ya udhaifu inatokea wakati mfumo unavyokuwa ukibadilisha kwa namna fulani ingizo la mtumiaji baada ya kulikagua. Kwa mfano, katika lugha zingine, simu rahisi ya kufanya ingizo kuwa kubwa au dogo inaweza kuhariri ingizo lililotolewa na unicode litabadilishwa kuwa ASCII na kuunda wahusika wapya.
Kwa maelezo zaidi angalia:

Unicode Normalization

\u to %

Wahusika wa unicode kawaida huwakilishwa na \u prefix. Kwa mfano, wahusika 㱋 ni \u3c4b(angalia hapa). Ikiwa back-end inabadilisha prefix \u kuwa %, string inayotokana itakuwa %3c4b, ambayo ikitafsiriwa URL ni: <4b. Na, kama unavyoona, wahusika < umeingizwa.
Unaweza kutumia mbinu hii ku ingiza aina yoyote ya wahusika ikiwa back-end ina udhaifu.
Angalia https://unicode-explorer.com/ kupata wahusika unahitaji.

Udhaifu huu kwa kweli unatokana na udhaifu ambao mtafiti alipata, kwa maelezo zaidi angalia https://www.youtube.com/watch?v=aUsAHb0E7Cg

Emoji Injection

Back-ends fulani zinafanya kazi kwa njia ya ajabu wanap pata emojis. Hivyo ndivyo ilivyotokea katika hii andiko ambapo mtafiti alifanikiwa kufikia XSS kwa payload kama: 💋img src=x onerror=alert(document.domain)//💛

Katika kesi hii, kosa lilikuwa kwamba seva baada ya kuondoa wahusika hatari ilibadilisha string ya UTF-8 kutoka Windows-1252 hadi UTF-8 (kimsingi uandishi wa ingizo na kubadilisha kutoka uandishi vilikuwa tofauti). Kisha hii haisababishi < sahihi bali unicode ya ajabu: ‹
``Hivyo walichukua matokeo haya na kubadilisha tena sasa kutoka UTF-8 hadi ASCII. Hii ilihariri ‹ kuwa < hivi ndivyo exploit ilivyoweza kufanya kazi kwenye mfumo huo.
Hii ndiyo ilivyotokea:

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

• 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

Kama ilivyoelezwa katika hiki kipande kizuri, Windows ina kipengele kinachoitwa Best-Fit ambacho kita badilisha wahusika wa unicode ambao hawawezi kuonyeshwa katika hali ya ASCII na wahusika wanaofanana. Hii inaweza kusababisha tabia isiyotarajiwa wakati backend inatarajia wahusika maalum lakini inapata mwingine tofauti.

Inawezekana kupata wahusika bora katika https://worst.fit/mapping/.

Kama Windows kawaida hubadilisha nyuzi za unicode kuwa nyuzi za ascii kama sehemu ya mwisho ya utekelezaji (kawaida ikitoka kwenye API yenye kiambishi "W" hadi API yenye kiambishi "A" kama GetEnvironmentVariableA na GetEnvironmentVariableW) hii itawawezesha washambuliaji kupita ulinzi kwa kutuma wahusika wa unicode ambao watabadilishwa mwisho kuwa wahusika wa ASCII ambao wangeweza kufanya vitendo visivyotarajiwa.

Katika chapisho la blogu kuna mbinu zilizopendekezwa za kupita udhaifu zilizorekebishwa kwa kutumia orodha ya wahusika wa mblacklist, kutumia path traversals kwa kutumia wahusika waliotengwa kwa “/“ (0x2F) na wahusika waliotengwa kwa “\“ (0x5C) au hata kupita ulinzi wa shell escape kama vile escapeshellarg ya PHP au subprocess.run ya Python kwa kutumia orodha, hii ilifanywa kwa mfano kwa kutumia fullwidth double quotes (U+FF02) badala ya double quotes hivyo mwishowe kile kilichokuwa kama hoja 1 kiligeuzwa kuwa hoja 2.

Kumbuka kwamba ili programu iwe na udhaifu inahitaji kutumia "W" Windows APIs lakini mwishowe inaita API ya "A" ya Windows ili "Best-fit" ya nyuzi za unicode iundwe.

Udhaifu kadhaa zilizogunduliwa hazitarekebishwa kwani watu hawakubaliani ni nani anayeweza kutatua tatizo hili.