Un gruppo di ricercatori di diverse università tedesche ha sviluppato un nuovo metodo di attacco MITM su HTTPS, che consente di estrarre cookie con identificatori di sessione e altri dati sensibili, oltre a ottenere l'esecuzione di 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 applicativi (HTTPS, SFTP, SMTP, IMAP, POP3), ma utilizzano certificati TLS comuni.
L'essenza dell'attacco è che, avendo il controllo su un gateway di rete o su un punto di accesso wireless, l'attaccante può reindirizzare il traffico web su un'altra porta di rete e stabilire una connessione con un server FTP o di posta elettronica che supporta la crittografia TLS e utilizza un certificato TLS comune con il server HTTP. Il browser dell'utente sarà portato a credere di aver stabilito una connessione con il server HTTP richiesto. Poiché il protocollo TLS è universale e non è legato ai protocolli di livello applicativo, l'installazione di una connessione crittografata per tutti i servizi è identica, e l'errore di invio della richiesta al servizio sbagliato può essere determinato solo dopo l'installazione della sessione crittografata durante l'elaborazione dei comandi della richiesta inviata.
Pertanto, se, ad esempio, si reindirizza una connessione utente originariamente indirizzata a HTTPS a un server di posta che utilizza un certificato condiviso con il 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à interpretata dal browser come la risposta del sito richiesto, trasmessa all'interno di un canale di comunicazione criptato correttamente stabilito.
Sono stati proposti tre tipi di attacco:
- «Upload» per estrarre i cookie contenenti i parametri di autenticazione. Questo metodo è applicabile se il server FTP coperto dal certificato TLS consente il caricamento e l'estrazione dei propri dati. In questo tipo di attacco, l'attaccante può riuscire a mantenere parti della richiesta HTTP originale dell'utente, come il contenuto dell'intestazione dei cookie, ad esempio, se il server FTP interpreta la richiesta come un file da salvare o registra completamente le richieste in arrivo. Per un attacco di successo, l'attaccante deve quindi trovare un modo per estrarre il contenuto salvato. L'attacco è applicabile a Proftpd, Microsoft IIS, vsftpd, filezilla e serv-u.
- «Download» per l'organizzazione del cross-site scripting (XSS). Questa tecnica implica che un aggressore, attraverso alcune manovre specifiche, possa inserire dati in un servizio che utilizza una comune un certificato TLS, che possono poi essere restituiti in risposta a una richiesta dell'utente. L'attacco è applicabile ai server FTP, ai server IMAP e ai server POP3 sopra menzionati (courier, cyrus, kerio-connect e zimbra).
- «Reflection» per eseguire JavaScript nel contesto di un altro sito. Questa tecnica si basa sul ritorno al client di parte della richiesta, contenente il codice JavaScript inviato dall'aggressore. L'attacco è applicabile ai server FTP, ai server IMAP cyrus, kerio-connect e zimbra, nonché al server SMTP sendmail.
Ad esempio, quando un utente apre una pagina controllata da un attaccante, da questa pagina può essere avviata una richiesta di risorsa a un sito web dove l'utente ha un account attivo (ad esempio, bank.com). Durante un attacco MITM, questa richiesta, diretta 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 chiude la sessione dopo il primo errore, le intestazioni di servizio e i comandi, come «POST / HTTP/1.1» e «Host:», verranno elaborati come comandi sconosciuti (il server di posta risponderà a ogni intestazione con «500 unrecognized command»).
Il server di posta non interpreta le specifiche del protocollo HTTP e pertanto le intestazioni di servizio e il blocco dati di una richiesta POST vengono trattati allo stesso modo, per cui nel corpo della richiesta POST si può specificare una stringa con un comando per il server di posta. Ad esempio, si può inviare: MAIL FROM: a cui il server di posta risponderà con 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 di un sito non originariamente aperto dall'attaccante, ma del sito bank.com, al quale è stata inviata la richiesta, poiché la risposta è pervenuta all'interno di una corretta sessione TLS, il cui certificato ha confermato l'autenticità della risposta di bank.com.
Una scansione della rete globale ha rivelato che circa 1,4 milioni di server web sono vulnerabili a problemi di attacco di mescolamento delle richieste attraverso diversi protocolli. La possibilità di un reale attacco è stata identificata per 119.000 server web, per i quali esistevano server TLS corrispondenti basati su altri protocolli applicativi.
Esempi di exploit sono stati preparati per server FTP come pureftpd, proftpd, microsoft-ftp, vsftpd, filezilla e serv-u, server IMAP e POP3 come dovecot, courier, exchange, cyrus, kerio-connect e zimbra, e server SMTP come 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, e non si esclude che il problema possa manifestarsi anche per altri protocolli applicativi che utilizzano TLS.
Per bloccare un attacco, si consiglia di utilizzare l'estensione ALPN (Application Layer Protocol Negotiation) per negoziare la sessione TLS tenendo conto del protocollo applicativo e l'estensione SNI (Server Name Indication) per legare il nome host quando si utilizzano certificati TLS che coprono più di un nome. di nomi di dominioSul lato delle applicazioni, si raccomanda di limitare il numero di errori durante l'elaborazione dei comandi, oltre il quale 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 state già adottate in Nginx 1.21.0 (mail proxy), Vsftpd 3.0.4, Courier 5.1.0, Sendmail, FileZilla, crypto/tls (Go) e Internet Explorer.
Fonte: opennet.ru
