Un team di ricercatori di diverse università tedesche ha sviluppato un nuovo attacco MITM su HTTPS in grado di estrarre cookie di sessione e altri dati sensibili, nonché di eseguire codice JavaScript arbitrario nel contesto di un altro sito. L'attacco si chiama ALPACA e può essere applicato ai server TLS che implementano diversi protocolli a livello di applicazione (HTTPS, SFTP, SMTP, IMAP, POP3), ma utilizzano certificati TLS comuni.
L'essenza dell'attacco è che se ha il controllo su un gateway di rete o un punto di accesso wireless, l'aggressore può reindirizzare il traffico web su un'altra porta di rete e organizzare la creazione di una connessione con un server FTP o di posta che supporti la crittografia TLS e utilizzi un Certificato TLS comune con il server HTTP e il browser dell'utente presuppone che sia stata stabilita una connessione con il server HTTP richiesto. Poiché il protocollo TLS è universale e non è legato ai protocolli a livello di applicazione, la creazione di una connessione crittografata per tutti i servizi è identica e l'errore di inviare una richiesta al servizio sbagliato può essere determinato solo dopo aver stabilito una sessione crittografata durante l'elaborazione della comandi della richiesta inviata.
Di conseguenza, se, ad esempio, si reindirizza una connessione utente originariamente indirizzata su HTTPS verso un server di posta che utilizza un certificato condiviso con il server HTTPS, la connessione TLS verrà stabilita con successo, ma il server di posta non sarà in grado di elaborare i dati trasmessi comandi HTTP e restituirà una risposta con il codice di errore. Tale risposta verrà elaborata dal browser come una risposta proveniente dal sito richiesto, trasmessa all'interno di un canale di comunicazione crittografato correttamente stabilito.
Vengono proposte tre opzioni di attacco:
- “Carica” per recuperare un Cookie con parametri di autenticazione. Il metodo è applicabile se il server FTP coperto dal certificato TLS consente di caricare e recuperare i suoi dati. In questa variante di attacco l'aggressore può ottenere la conservazione di parti della richiesta HTTP originale dell'utente, come ad esempio il contenuto dell'intestazione del cookie, se il server FTP interpreta la richiesta come un file di salvataggio o registra interamente le richieste in arrivo. Per attaccare con successo, l'aggressore deve quindi estrarre in qualche modo il contenuto archiviato. L'attacco è applicabile a Proftpd, Microsoft IIS, vsftpd, filezilla e serv-u.
- "Download" per l'organizzazione del cross-site scripting (XSS). Il metodo implica che l'aggressore, a seguito di alcune manipolazioni individuali, possa inserire dati in un servizio che utilizza un certificato TLS comune, che può poi essere emesso in risposta a una richiesta dell'utente. L'attacco colpisce i server FTP, IMAP e POP3 sopra menzionati (courier, cyrus, kerio-connect e zimbra).
- "Riflessione" per eseguire JavaScript nel contesto di un altro sito. Il metodo si basa sulla restituzione al client della parte della richiesta che contiene il codice JavaScript inviato dall'aggressore. L'attacco colpisce i server FTP sopra menzionati, i server IMAP cyrus, kerio-connect e zimbra nonché il server SMTP sendmail.
Ad esempio, quando un utente apre una pagina controllata da un utente malintenzionato, questa pagina può avviare una richiesta per una risorsa da un sito in 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 elettronica che utilizza un certificato TLS condiviso con bank.com. Poiché il server di posta non termina la sessione dopo il primo errore, le intestazioni del servizio e i comandi come "POST / HTTP/1.1" e "Host:" verranno elaborati come comandi sconosciuti (il server di posta restituirà "500 comando non riconosciuto" per ciascuna intestazione).
Il server di posta non comprende le caratteristiche del protocollo HTTP e per questo le intestazioni del servizio e il blocco dati della richiesta POST vengono elaborati allo stesso modo, quindi nel corpo della richiesta POST è possibile specificare una riga con un comando da il server di posta. Ad esempio, puoi passare: MAIL FROM: alert(1); a cui il server di posta restituirà un messaggio di errore 501 alert(1);: indirizzo malformato: alert (1); potrebbe non seguire
Questa risposta verrà ricevuta dal browser dell'utente, che eseguirà il codice JavaScript nel contesto non del sito Web inizialmente aperto dall'aggressore, ma del sito Web bank.com a cui è stata inviata la richiesta, poiché la risposta è arrivata all'interno di una sessione TLS corretta , il cui certificato confermava l'autenticità della risposta di bank.com.
Da una scansione della rete globale è emerso che in generale sono circa 1.4 milioni i server web interessati dal problema, per i quali è possibile effettuare un attacco mescolando richieste utilizzando protocolli diversi. Per 119mila server web è stata accertata la possibilità di un vero e proprio attacco, per i quali erano presenti server TLS basati su altri protocolli applicativi.
Sono stati preparati esempi di exploit per i server ftp pureftpd, proftpd, microsoft-ftp, vsftpd, filezilla e serv-u, server IMAP e POP3 dovecot, corriere, exchange, cyrus, kerio-connect e zimbra, server SMTP postfix, exim, sendmail , mailenable, mdaemon e opensmtpd. I ricercatori hanno studiato la possibilità di effettuare un attacco solo in combinazione con server FTP, SMTP, IMAP e POP3, ma è possibile che il problema si verifichi anche per altri protocolli applicativi che utilizzano TLS.
Per bloccare l'attacco si propone di utilizzare l'estensione ALPN (Application Layer Protocol Negotiation) per negoziare una sessione TLS tenendo conto del protocollo applicativo e l'estensione SNI (Server Name Indication) per associarsi al nome host in caso di utilizzo Certificati TLS che coprono diversi nomi di dominio. Lato applicazione si consiglia di limitare il numero di errori durante l'elaborazione dei comandi, dopo il quale la connessione viene terminata. Il processo di sviluppo di misure per bloccare l’attacco è iniziato nell’ottobre dello scorso anno. Misure di sicurezza simili sono già state adottate in Nginx 1.21.0 (proxy di posta), Vsftpd 3.0.4, Courier 5.1.0, Sendmail, FileZill, crypto/tls (Go) e Internet Explorer.
Fonte: opennet.ru