Un gruppo di ricercatori di diverse università tedesche ha sviluppato un nuovo metodo di attacco MITM su HTTPS, che consente di estrarre cookie con identificativi di sessione e altri dati riservati, oltre a eseguire codice JavaScript arbitrario nel contesto di un altro sito. L'attacco è stato chiamato ALPACA e può essere applicato ai server TLS che implementano diversi protocolli di livello applicativo (HTTPS, SFTP, SMTP, IMAP, POP3), ma utilizzano certificati TLS comuni.
Il principio dell'attacco è che, avendo il controllo su un gateway di rete o un punto di accesso wireless, l'attaccante può reindirizzare il traffico web a un'altra porta di rete e organizzare l'instaurazione di una connessione con un server FTP o di posta che supportano la crittografia TLS e utilizzano un certificato TLS condiviso con il server HTTP, mentre il browser dell'utente crederà di aver stabilito una connessione con il server HTTP richiesto. Poiché il protocollo TLS è universale e non legato ai protocolli di livello applicativo, l'instaurazione di una connessione crittografata per tutti i servizi è identica e un errore di invio della richiesta al servizio sbagliato può essere identificato solo dopo l'instaurazione della sessione crittografata durante l'elaborazione dei comandi della richiesta inviata.
Di conseguenza, se, ad esempio, si reindirizza una connessione dell'utente inizialmente destinata a HTTPS a un server di posta che utilizza un certificato condiviso con quello del server HTTPS, la connessione TLS sarà stabilita con successo, ma il server di posta non sarà in grado di elaborare i comandi HTTP inviati e restituirà una risposta con codice di errore. Questa risposta sarà elaborata dal browser come se fosse la risposta del sito richiesto, trasmessa all'interno di un canale di comunicazione crittografato correttamente stabilito.
Sono stati proposti tre varianti di attacco:
- «Upload» per estrarre i cookie con i parametri di autenticazione. Il metodo è applicabile se il server FTP coperto dal certificato TLS consente di caricare ed estrarre i propri dati. In questa variante dell'attacco, l'attaccante può riuscire a mantenere parti della richiesta HTTP originale dell'utente, come il contenuto dell'intestazione Cookie, ad esempio, se il server FTP interpreta la richiesta come un file da salvare o registra interamente le richieste in arrivo. Per un attacco di successo, l'aggressore deve quindi trovare un modo per estrarre il contenuto salvato. L'attacco è applicabile a Proftpd, Microsoft IIS, vsftpd, filezilla e serv-u.
- «Download» per organizzare lo scripting cross-site (XSS). Il metodo implica che l'attaccante, a seguito di alcune manovre, possa inserire dati in un servizio che utilizza un comune certificato TLS, che possono poi essere restituiti in risposta a una richiesta dell'utente. L'attacco è applicabile ai server FTP sopra menzionati, server IMAP e server POP3 (courier, cyrus, kerio-connect e zimbra).
- «Reflection» per eseguire JavaScript nel contesto di un altro sito. Il metodo si basa sul restituire al cliente parte della richiesta, contenente il codice JavaScript inviato dall'attaccante. L'attacco è applicabile ai server FTP sopra menzionati, ai server IMAP come cyrus, kerio-connect e zimbra, oltre al server SMTP sendmail.
Ad esempio, quando un utente apre una pagina controllata dall'attaccante, da questa pagina può essere avviata una richiesta di risorsa da un sito su cui l'utente ha un account attivo (ad esempio, bank.com). Durante un attacco MITM, questa richiesta, indirizzata al sito web bank.com, può essere reindirizzata a un server di posta che utilizza un certificato TLS condiviso con bank.com. Poiché il server di posta non termina la sessione dopo il primo errore, le intestazioni e i comandi di servizio, come «POST / HTTP/1.1» e «Host:», vengono trattati come comandi sconosciuti (il server di posta restituirà «500 unrecognized command» per ogni intestazione).
Il server di posta non analizza le specifiche del protocollo HTTP e per lui le intestazioni di servizio e il blocco di dati della richiesta POST vengono trattati in modo identico, quindi nel corpo della richiesta POST si può specificare una stringa con un comando al server di posta. Ad esempio, si può fornire: MAIL FROM: a cui il server di posta restituirà un messaggio di errore 501 : malformed address: alert(1); may not follow
Questa risposta sarà ricevuta dal browser dell'utente, che eseguirà il codice JavaScript nel contesto non del sito originariamente aperto dall'attaccante, ma del sito bank.com, al quale è stata inviata la richiesta, dato che la risposta è arrivata all'interno di una corretta sessione TLS, il cui certificato ha confermato l'autenticità della risposta di bank.com.
La scansione della rete globale ha rivelato che circa 1,4 milioni di server web sono vulnerabili a problemi di questo tipo, nei quali è possibile effettuare attacchi tramite miscelazione di richieste su diversi protocolli. È stata identificata la possibilità concreta di attacco per 119.000 server web che presentavano server TLS associati basati su altri protocolli applicativi.
Esempi di exploit sono stati preparati per server FTP pureftpd, proftpd, microsoft-ftp, vsftpd, filezilla e serv-u, server IMAP e POP3 dovecot, courier, exchange, cyrus, kerio-connect e zimbra, server SMTP postfix, exim, sendmail, mailenable, mdaemon e opensmtpd. I ricercatori hanno esaminato la possibilità di attacco solo in combinazione con server FTP, SMTP, IMAP e POP3, non escludendo che il problema possa manifestarsi anche per altri protocolli applicativi che utilizzano TLS.
Per bloccare l'attacco, si consiglia di utilizzare l'estensione ALPN (Application Layer Protocol Negotiation) per la negoziazione della sessione TLS tenendo conto del protocollo applicativo e l'estensione SNI (Server Name Indication) per legarsi al nome host nel caso siano utilizzati certificati TLS che coprono più nomi di dominio. Sul lato delle applicazioni, si raccomanda di limitare il numero di errori durante l'elaborazione dei comandi, superato il quale si deve interrompere la connessione. Il processo di sviluppo di misure per bloccare l'attacco è iniziato già nell'ottobre dello scorso anno. Misure simili per la protezione sono già state adottate in Nginx 1.21.0 (mail proxy), Vsftpd 3.0.4, Courier 5.1.0, Sendmail, FileZill, crypto/tls (Go) e Internet Explorer.
Fonte: opennet.ru
