In che modo Anonymous ha utilizzato ASCII UTF-16 per ingannare l'escape di PHP?

Prima di tutto "la codifica ASCII UTF-16" è una contraddizione, poiché UTF-16 e ASCII sono schemi di codifica esclusivi. Ma presumibilmente si sta solo riferendo all'utilizzo di Unicode per bypassare i meccanismi di filtraggio.

Il principio generale è questo: spesso pensiamo ai caratteri codificati in ASCII - "A" è il numero 65, "z" è il numero 122. Ma non è l'unico schema di codifica dei caratteri; perché il mondo usa più dell'alfabeto inglese, dobbiamo rappresentare molti più personaggi di questo. Quindi, Unicode, che ha rappresentazioni per quasi tutti i personaggi in ogni lingua mai scritta, da Sinhala a Klingon.

Rappresentare tutti quei personaggi (circa 1,1 milioni possibili, non tutti in uso) in una forma numerica è una vera sfida. Potresti usare 32 bit, ma è uno spreco di spazio dato che 3 dei 4 byte di solito sono zero. È possibile utilizzare una lunghezza variabile, ma non è possibile eseguire operazioni di sottostringa costanti. Esistono quindi numerosi standard, uno dei quali è UTF-16 (che probabilmente hai indovinato utilizza caratteri a 16 bit).

Non tutti i programmatori sono abituati all'idea di gestire più set di caratteri, anche se il framework sottostante li supporterà spesso. Quindi, a volte le regole di filtro o le precauzioni saranno stabilite usando l'ipotesi che i caratteri saranno rappresentati in UTF-8 o ASCII, che di solito sono.

Quindi il filtro cerca una data stringa, ad esempio \" per esempio, che in ASCII e UTF-8 corrisponde allo schema {92,34}. Ma in UTF-16 sembra diverso; in realtà è {0,92,0,34}, che è semplicemente abbastanza diverso da essere filtrato da un filtro che non se lo aspettava.

E sebbene il filtro non comprenda UTF-16, il framework sottostante lo fa, quindi il contenuto viene normalizzato e interpretato proprio come qualsiasi altra cosa, consentendo alla query di continuare senza filtrare.

MODIFICA PER AGGIUNGERE:
Si noti che PHP è eccezionalmente scarso nella gestione delle codifiche dei caratteri; e semmai, questo sta minimizzando il problema. PHP considera di default tutte le stringhe come ASCII, ovvero le funzioni interne come strstr e preg_replace assumono semplicemente che tutte le stringhe siano codificate in ASCII. Se ciò sembra pericolosamente inadeguato, è perché lo è. Ma a loro difesa, ricordiamo che PHP precede UTF-16 di circa un anno, e tutto questo è apparentemente risolto nella versione 6 di PHP.

Nel frattempo, la libreria mbstring è stata creata per risolvere questa lacuna, ma non è né ampiamente utilizzata né sottosviluppata. Se sei abbastanza fortunato da avere questa estensione a tua disposizione, puoi utilizzare mbstring.overload nel file php.ini per forzare la sostituzione delle funzioni interne di elaborazione delle stringhe con alternative multibyte-aware. Questo può anche essere attivato utilizzando la direttiva php_admin_value nei file .htaccess .

Un'altra funzione utile è mb_internal_encoding , che imposta la codifica usata internamente da PHP per rappresentare stringhe. Usando una codifica interna compatibile con Unicode, puoi alleviare un po 'di cattiveria. Almeno un riferimento che ho letto (ma purtroppo non riesco a trovarlo ora) suggerisce che impostando la codifica interna su UTF-8, si abilita un'ulteriore elaborazione sulle stringhe in entrata che li normalizza su una singola codifica. D'altra parte, almeno un altro riferimento suggerisce che PHP si comporta in modo stupidamente possibile a questo proposito, e semplicemente trascina i dati non modificati indipendentemente dalla codifica, e ti consente di affrontare le conseguenze. Mentre il primo ha più senso, con quello che so su PHP, penso che quest'ultimo sia altrettanto probabile.

Come alternativa finale; e menziono questo solo in parte per scherzo, è semplicemente non usare PHP e invece adottare un'architettura migliore. È difficile trovare un framework così popolare che abbia così tanti problemi fondamentali come PHP. Il linguaggio, l'implementazione, il team di sviluppo, l'architettura dei plugin, il modello di sicurezza - è davvero un peccato che PHP sia così ampiamente implementato. Ma questa è, ovviamente, solo un'opinione.

Non ho idea se questo sia il metodo utilizzato da Anonymous, ma dai un'occhiata al link

Sembra che ci sia un bug in Connector.Net (il driver .Net gestito da MySQL). Dalla segnalazione bug collegata:

.net strings are a encoded in UTF-16. Strings are converted to Windows-1252 (SBCS Encoding) to be sent over the network and during this conversion unicode characters that may not have been checked for will "become" single quotes.

Il bug report continua ad elencare una stringa contenente il problema del carattere Unicode e dire:

Specifically, In the second string the problem quote is unicode character 8242 ("\u8242"). When this string is received by the server the quote will be a single quote (ASCII 96) and break the query and could be used as a sql injection attack.

Il bug collegato è stato contrassegnato come duplicato di un bug fisso nel 2009, ma è del tutto possibile che il server sfruttato stesse eseguendo una versione precedente di MySql che presentava questo problema.

Sono giunto alla conclusione dall'articolo che il sito dipendeva più dalle tecniche di "hardening" piuttosto che dal buon input / filtraggio di input di sql. Non ci sono prove che il codice sql per i siti porno kiddie non sia difettoso.

Bypassare i cosiddetti filtri PHP hardened è spesso piuttosto banale. Ad esempio, ModSecurity può essere facilmente aggirato e ci sono numerosi metodi utilizzati costantemente dagli hacker per aggirare tali filtri di input.

Ci sono anche filtri che sono inclusi nel codice del sito web come plugin che non urldecode l'input correttamente prima di cercare input dannosi.

Ad esempio: %5e

come visto in

id=0%5E(select%20position(0x61%20in%20(select%20id%20from%20users%20where%20num=1))=1)

Giocando con questi personaggi come "% bf% 5c% 27", "% bf% 27", "% ef% bb% bf", "% 8c% 5c", è possibile ignorare il cosiddetto hardening per attivare l'iniezione.

Peggio ancora sono i filtri nella whitelist che aggiorna in modo ricorsivo $ _GET con caratteri consentiti nella whitelist come:

$cleansed = preg_replace( "/[^\s{}a-z0-9_\.\-]/i", "", urldecode( $get ) );

Quindi considera questo: id = -1% 20ui * o + s | e | l | e | c | t + 1, ^ 2, * 3, [4, [5,] 6,] 7, < 8, < 9, & gt ; 10 >

Anche se l'idea di urldecoding prima del filtraggio è una buona idea, è del tutto inutile che i caratteri in lista nera vengano rimossi, fornendo così il vettore di iniezione nella sua forma grezza.

In realtà questo metodo può migliorare la capacità degli attaccanti di aggirare i "Mi piace" dei cosiddetti indurenti PHP e mods di filtraggio come la modsecurity.

Alla fine la richiesta viene elaborata in un modo specifico per bypassare il filtraggio degli input, una volta che le difese vengono bypassate, il codice del sito stesso deve avere la codifica degli input del DB difettosa in primo luogo affinché i vettori di iniezione si attivino indipendentemente dalle affermazioni degli aggressori, in questo caso Anonimo.

Solo un'ipotesi selvaggia. Possono codificare le stringhe ASCII in UTF-16, in questo modo, le routine che erano forse usate per controllare l'input dell'utente pericoloso sono state ingannate / aggirate. La stringa è stata quindi interpretata e l'input dannoso non è stato filtrato.

Sembra che gli sviluppatori abbiano usato pratiche di codifica non sicure o che alcune librerie / applicazioni fossero obsolete e quindi pericolose. Non è come gli hacker anonimi / le scritture hanno una magia di bypass, è tutta una questione di sperimentazione.

Per lo più, se hanno 0days o alcune nuove tecniche per hackerare tutto, non permetterebbero alle persone di saperlo. Stanno spesso usando tecniche di vecchia scuola che continuano a funzionare a causa dell'incompetenza di alcuni programmatori / amministratori. La sicurezza è importante.