2.6 CVE-2004-0473

Questo tipo di attacco coinvolge un attaccante che sfrutta i meta-caratteri nelle intestazioni delle e-mail per iniettare un comportamento improprio nei programmi di posta elettronica. Il software di posta elettronica è diventato sempre più sofisticato e ricco di funzionalità. Inoltre, le applicazioni di posta elettronica sono onnipresenti e collegate direttamente al Web, rendendole obiettivi ideali per lanciare e propagare gli attacchi. Man mano che la domanda degli utenti per nuove funzionalità nelle applicazioni di posta elettronica cresce, esse diventano più simili ai browser con un rendering complesso e routine di plug in. Poiché più funzionalità di posta elettronica sono incluse e astratte dall'utente, questo crea opportunità per gli attaccanti. Praticamente tutte le applicazioni di posta elettronica non elencano le informazioni dell'intestazione dell'email per impostazione predefinita, tuttavia l'intestazione dell'email contiene preziosi vettori di attacco per l'attaccante da sfruttare in particolare se il comportamento dell'applicazione client di posta elettronica è noto. I metacaratteri sono nascosti all'utente, ma possono contenere script, enumerazioni, sonde e altri attacchi contro il sistema dell'utente. [Identificare e caratterizzare le vulnerabilità di elaborazione dei metacaratteri nelle intestazioni delle e-mail] Un attaccante crea e-mail con intestazioni contenenti vari payload dannosi basati sui metacaratteri, al fine di determinare se l'applicazione di destinazione elabora il contenuto dannoso e in che modo lo fa. Un attaccante sfrutta le vulnerabilità identificate durante la fase di esperimento per iniettare intestazioni di email malevole e far sì che l'applicazione email mirata abbia un comportamento al di fuori dei suoi vincoli previsti.

In questo tipo di attacco, un avversario inietta comandi del sistema operativo in funzioni di applicazioni esistenti. Un'applicazione che utilizza input non fidati per costruire stringhe di comando è vulnerabile. Un avversario può sfruttare l'iniezione di comandi del sistema operativo in un'applicazione per elevare i privilegi, eseguire comandi arbitrari e compromettere il sistema operativo sottostante. L'attaccante determina l'input controllabile dall'utente che viene passato come parte di un comando al sistema operativo sottostante. A seconda che l'applicazione sfruttata sia remota o locale, l'attaccante crea l'input dannoso appropriato, contenente i comandi del sistema operativo, da passare all'applicazione [Eseguire comandi dannosi] L'attaccante può rubare informazioni, installare un meccanismo di accesso back door, elevare i privilegi o compromettere il sistema in qualche altro modo.

Un avversario manipola il contenuto dei parametri di richiesta allo scopo di minare la sicurezza dell'obiettivo. Alcune codifiche dei parametri usano caratteri di testo come separatori. Per esempio, i parametri in un messaggio HTTP GET sono codificati come coppie nome-valore separate da una e commerciale (&). Se un attaccante può fornire stringhe di testo che vengono utilizzate per compilare questi parametri, allora può iniettare caratteri speciali utilizzati nello schema di codifica per aggiungere o modificare i parametri. Per esempio, se l'input dell'utente viene inserito direttamente in una richiesta HTTP GET e l'utente fornisce il valore "myInput&new_param=myValue", allora il parametro di input viene impostato a myInput, ma viene anche aggiunto un nuovo parametro (new_param) con un valore di myValue. Questo può cambiare significativamente il significato della query che viene elaborata dal server. Qualsiasi schema di codifica in cui i parametri sono identificati e separati da caratteri di testo è potenzialmente vulnerabile a questo attacco - la codifica HTTP GET usata sopra è solo un esempio.

Un avversario approfitta di una convalida impropria dei dati per iniettare parametri globali malevoli in un file Flash incorporato in un documento HTML. I file Flash possono sfruttare i dati inviati dall'utente per configurare il documento Flash e accedere al documento HTML incorporato. [Usando un browser o uno strumento automatizzato, un avversario registra tutte le istanze dei documenti HTML che hanno file Flash incorporati. Se c'è un file Flash incorporato, elencano come passare parametri globali al file Flash dall'oggetto incorporato. [Determinare la suscettibilità dell'applicazione all'iniezione di parametri Flash] Determinare la suscettibilità dell'applicazione all'iniezione di parametri Flash. Per ogni URL identificato nella fase di esplorazione, l'avversario tenta di utilizzare varie tecniche come DOM based, reflected, flashvars, e attacchi persistenti a seconda del tipo di parametro passato al file Flash incorporato. [Execute Flash Parameter Injection Attack] Iniettare parametri nel file Flash. Sulla base dei risultati della fase di sperimentazione, l'avversario crea l'URL maligno sottostante contenente i parametri Flash iniettati e lo invia al server web. Una volta che il server web riceve la richiesta, il documento HTML incorporato sarà controllabile dall'avversario.

Un avversario aggiunge parametri HTTP GET/POST duplicati iniettando delimitatori di query string. Tramite HPP può essere possibile sovrascrivere i parametri HTTP hardcoded esistenti, modificare i comportamenti dell'applicazione, accedere e, potenzialmente sfruttare, variabili incontrollabili e aggirare i punti di controllo della validazione dell'input e le regole WAF. [Trovare l'input dell'utente] L'avversario trova ovunque nell'applicazione web che utilizza l'input fornito dall'utente in un modulo o in un'azione. Questo può essere trovato anche guardando i parametri nell'URL nella barra di navigazione del browser [Aggiungere valori di parametri duplicati] Una volta che l'avversario ha identificato quali input dell'utente sono utilizzati come parametri HTTP, aggiungerà i duplicati ad ogni parametro uno ad uno per osservare i risultati. Se la risposta della richiesta HTTP mostra il valore del parametro duplicato concatenato con il valore del parametro originale in qualche modo, o semplicemente il valore del parametro duplicato, allora HPP è possibile. [Una volta che l'avversario ha identificato il modo in cui il backend gestisce i parametri duplicati, lo sfrutterà inquinando i parametri in modo da trarne vantaggio. In alcuni casi, i parametri hardcoded saranno ignorati dal backend. In altri, l'avversario può bypassare un WAF che potrebbe controllare un parametro solo prima che sia stato concatenato dal backend, con il risultato di far passare query malevole.