In breve, la risposta è sì all'uso di caratteri UTF-8 in una catena di attacco. Ci sono alcuni casi che hanno attraversato la mia strada. Quello che ho letto su questo metodo di attacco, è che questo è l'ultimo passo per "rilasciare shell" su una catena di attacco in un sistema nativo. Con un rapido "Google", questo articolo è apparso.
"Using UTF-8 Encoding to Bypass Validation Logic"
L'articolo continua spiegando esattamente come questo particolare metodo viene utilizzato. Ecco il riepilogo esecutivo.
"This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the "shortest possible" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters."
Questo argomento è già apparso in precedenza, sebbene il caso d'uso non sia disponibile durante questa stesura. Se viene trovato in seguito, verrà aggiunto come commento.
Quello che viene ricordato, era un metodo di catena d'attacco che aveva ottenuto l'accesso a un sistema nativo e si era seduto in dormitorio. Quando è stata acquisita la voce tramite il firewall, l'accesso è stato negato. Il programma si è quindi trasformato in un file UTF-8 fino a quando non è stato possibile accedere al software di sicurezza. Una volta che il buco è stato aperto, a causa della codifica dei bit dei caratteri, il programma python è stato in grado di aprire un prompt dei comandi o "drop shell". L'utente malintenzionato ha quindi avuto pieno accesso alla radice. Ha quindi aperto un gateway per un'altra parte del programma in attesa.
È molto simile allo studio "Usando la codifica UTF-8 per bypassare la logica di convalida" nel modo in cui si maschera e diventa illeggibile per il software di sicurezza. I metodi di attacco sono molto simili.
Methods of Attack
1. Injection
2. Protocol Manipulation
3. API Abuse
Nel caso che avevo letto prima, l'obiettivo del programma era di penetrare il più profondamente possibile. Se bloccato, in caso contrario, si trasforma in UTF-8 ed esegue attacchi nella materia prescritta. In caso di successo, apri un gateway per un'altra parte del malware che si trova più in basso lungo la catena di attacco.
Devo dire che è interessante pensare. Per come la vedo io, se riesci a scrivere codice in grado di sovraperformare la portata limitata di un altro sistema, avrai successo nell'attacco. Se il codice di difesa ha dei vincoli e il codice di attacco ha scelte e opzioni che non sono mai state programmate nell'ambito del difensore, allora è una perdita evidente. Soprattutto quando puoi avere un IA o un attaccante di apprendimento automatico.
Attributo al gruppo di contenuti CAPEC, The MITER Corporation 2014-06-23 Internal_CAPEC_Team per l'articolo.