Certificati jolly o wildcard e ALPACA attacks

L’Agenzia per la Sicurezza Nazionale degli Stati Uniti (NSA) sta avvertendo dei pericoli derivanti dall’uso di certificati ampiamente definiti per autenticare più server in un’organizzazione.

In un documento rilasciato la scorsa settimana, l’agenzia fornisce misure di mitigazione contro i rischi associati all’uso di certificati jolly. Questi includono una tecnica recentemente divulgata, chiamata ALPACA, che potrebbe essere utilizzata per vari attacchi di reindirizzamento del traffico.

ALPACA può colpire L’agenzia si riferisce ai pericoli rappresentati dai certificati digitali jolly o multi-dominio che validano l’identità del server per consentire una connessione sicura e affidabile tramite il protocollo crittografico Transport Layer Security (TLS).

In una presentazione di due mesi fa, i ricercatori hanno mostrato che i server TLS che eseguono protocolli diversi ma con certificati compatibili (ad esempio jolly, multi-dominio) potrebbero essere sfruttati tramite un attacco di confusione del contenuto del protocollo a livello di applicazione.

Hanno chiamato la tecnica ALPACA, acronimo di Application Layer Protocols Allowing Cross-Protocol Attack, notando che un attore malintenzionato che soddisfa determinate condizioni potrebbe almeno rubare cookie o eseguire attacchi di cross-site scripting.

Un certificato digitale jolly può essere utilizzato con più sottodomini sullo stesso dominio, quindi può coprire più server (ad esempio email, FTP, applicazioni), mentre un certificato multi-dominio viene utilizzato per più domini su un singolo indirizzo IP.

L’NSA afferma che “ALPACA è una classe complessa di tecniche di sfruttamento che può assumere molte forme,” e che uno scenario realistico per un tale attacco richiederebbe i seguenti elementi:

• un’applicazione web di destinazione che utilizza TLS
• un altro servizio/applicazione (tipicamente non un server web) che presenta un certificato TLS valido con un nome di soggetto che sarebbe valido per l’app web di destinazione, come quando i certificati jolly sono troppo ampiamente definiti
• un mezzo per l’attore malintenzionato per reindirizzare il traffico di rete della vittima destinato all’app web di destinazione verso il secondo servizio (probabilmente realizzato tramite avvelenamento del Domain Name System (DNS) o compromissione man-in-the-middle)
• una richiesta HTTP che viene accettata dal secondo servizio che risulta in almeno parte della richiesta riflessa al mittente

Un attore di minaccia che soddisfa queste “condizioni relativamente rare” sarebbe in grado di eseguire almeno attacchi di phishing, watering hole, malvertising odd man-in-the-mile (MitM).

Utilizzando la tecnica ALPACA, un avversario potrebbe indurre il browser web della vittima a fidarsi ed eseguire risposte riflesse da un servizio malevolo che sono firmate con il certificato corretto.

Questo apre la porta al furto di cookie di sessione, dati utente privati e all’esecuzione di codice arbitrario nel contesto di un server vulnerabile.

Compromissione di un’applicazione web sicura utilizzando la tecnica ALPACA

• L’attore malintenzionato induce l’utente a visitare un URL creato ad hoc (phishing, malvertising, ecc.)
• L’utente invia una richiesta per l’URL a app.example.com
• Utilizzando una delle molte tecniche di manipolazione della rete, la richiesta dell’utente viene reindirizzata dall’attore malintenzionato a service.example.com invece
• Il servizio non HTTP service.example.com (ad esempio, un File Transfer Protocol [FTP], Simple Mail Transfer Protocol [SMTP], o altro server non web) tenta di elaborare la richiesta HTTP causando un errore che riflette il contenuto malevolo nella risposta del server
• La risposta del server è firmata dal certificato *.example.com
• Il browser dell’utente riceve la risposta alla loro richiesta. Poiché la richiesta era per app.example.com e la risposta è autenticata da *.example.com, il browser si fida della risposta e la esegue nel contesto di app.example.com. Questo dà accesso allo script malevolo ai dati utente e ai cookie per app.example.com all’interno del browser

L’NSA ricorda inoltre alle organizzazioni il ruolo dei certificati jolly in un’architettura di fiducia poiché “possono essere utilizzati per rappresentare qualsiasi sistema all’interno del loro ambito.”

Per questo motivo, devono garantire la protezione della chiave privata di un certificato jolly e mantenerla su un server ben gestito per evitare il rischio che un attaccante possa ottenerla compromettendo una macchina poco sicura.

Passare a un server sicuro dopo aver violato una macchina non sicura all’interno dello stesso ambito del certificato

Mitigazione dei rischi dei certificati jolly L’NSA raccomanda alle organizzazioni di assicurarsi che i certificati jolly siano utilizzati responsabilmente e che il loro ambito all’interno dell’organizzazione sia ben compreso.

Le aziende dovrebbero identificare dove sono memorizzate le chiavi private per questi certificati e utilizzare il livello di sicurezza richiesto da tutte le applicazioni nell’ambito dei certificati.

Utilizzare un application gateway o un Web Application Firewall (WAF) davanti ai server, inclusi quelli non HTTP, è un’altra raccomandazione dell’agenzia.

DNS crittografato e convalida delle estensioni di sicurezza DNS (DNSSEC) per prevenire il reindirizzamento DNS che potrebbe portare gli utenti target in una posizione malevola.

L’NSA raccomanda inoltre di abilitare il Application-Layer Protocol Negotiation (ALPN) se possibile, e di mantenere i browser aggiornati alla loro ultima versione.