Unicode Injection

Reading time: 5 minutes

tip

Impara e pratica l'Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks

Introduzione

A seconda di come si comporta il back-end/front-end quando riceve caratteri unicode strani, un attaccante potrebbe essere in grado di bypassare le protezioni e iniettare caratteri arbitrari che potrebbero essere utilizzati per sfruttare vulnerabilità di iniezione come XSS o SQLi.

Normalizzazione Unicode

La normalizzazione Unicode si verifica quando i caratteri unicode vengono normalizzati in caratteri ascii.

Uno scenario comune di questo tipo di vulnerabilità si verifica quando il sistema sta modificando in qualche modo l'input dell'utente dopo averlo controllato. Ad esempio, in alcune lingue una semplice chiamata per rendere l'input maiuscolo o minuscolo potrebbe normalizzare l'input fornito e il unicode verrà trasformato in ASCII generando nuovi caratteri.
Per ulteriori informazioni controlla:

Unicode Normalization

\u a %

I caratteri Unicode sono solitamente rappresentati con il prefisso \u. Ad esempio, il carattere 㱋 è \u3c4b(controllalo qui). Se un backend trasforma il prefisso \u in %, la stringa risultante sarà %3c4b, che decodificata in URL è: <4b. E, come puoi vedere, un carattere < è iniettato.
Potresti usare questa tecnica per iniettare qualsiasi tipo di carattere se il backend è vulnerabile.
Controlla https://unicode-explorer.com/ per trovare i caratteri di cui hai bisogno.

Questa vulnerabilità proviene effettivamente da una vulnerabilità trovata da un ricercatore, per una spiegazione più approfondita controlla https://www.youtube.com/watch?v=aUsAHb0E7Cg

Iniezione di Emoji

I back-end si comportano in modo strano quando ricevono emoji. Questo è ciò che è successo in questo writeup dove il ricercatore è riuscito a ottenere un XSS con un payload come: 💋img src=x onerror=alert(document.domain)//💛

In questo caso, l'errore è stato che il server, dopo aver rimosso i caratteri dannosi, ha convertito la stringa UTF-8 da Windows-1252 a UTF-8 (fondamentalmente l'encoding dell'input e la conversione dall'encoding non corrispondevano). Quindi questo non dà un corretto < solo un unicode strano: ‹
``Quindi hanno preso questo output e convertito di nuovo ora da UTF-8 a ASCII. Questo ha normalizzato il ‹ in <, ecco come l'exploit potrebbe funzionare su quel sistema.
Questo è ciò che è successo:

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

Windows Best-Fit/Worst-fit

Come spiegato in questo ottimo post, Windows ha una funzione chiamata Best-Fit che sostituisce i caratteri unicode che non possono essere visualizzati in modalità ASCII con uno simile. Questo può portare a comportamenti imprevisti quando il backend si aspetta un carattere specifico ma riceve un carattere diverso.

È possibile trovare caratteri best-fit in https://worst.fit/mapping/.

Poiché Windows di solito converte le stringhe unicode in stringhe ascii come una delle ultime parti dell'esecuzione (solitamente passando da un'API con suffisso "W" a un'API con suffisso "A" come GetEnvironmentVariableA e GetEnvironmentVariableW), questo permetterebbe agli attaccanti di eludere le protezioni inviando caratteri unicode che verranno convertiti infine in caratteri ASCII che eseguirebbero azioni inaspettate.

Nel post del blog vengono proposti metodi per eludere vulnerabilità risolte utilizzando una blacklist di caratteri, sfruttare path traversals usando caratteri mappati a “/“ (0x2F) e caratteri mappati a “\“ (0x5C) o persino eludere le protezioni di escape della shell come escapeshellarg di PHP o subprocess.run di Python utilizzando un elenco; questo è stato fatto, ad esempio, utilizzando virgolette doppie a larghezza piena (U+FF02) invece di virgolette doppie, quindi alla fine ciò che sembrava un argomento è stato trasformato in 2 argomenti.

Nota che affinché un'app sia vulnerabile, deve utilizzare le API Windows "W" ma finire per chiamare un'API Windows "A" in modo che venga creato il "Best-fit" della stringa unicode.

Diverse vulnerabilità scoperte non verranno risolte poiché le persone non sono d'accordo su chi dovrebbe risolvere questo problema.

tip

Impara e pratica l'Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks