Vulnerabilità legata all'impersonificazione di Akamai EAA - Un'analisi approfondita

In questo post, forniamo i dettagli tecnici dellaCVE-2021-28091, una vulnerabilità che interessa la piattaforma EAA (Enterprise Application Access) di Akamai. Descriviamo il nostro processo di indagine, correzione e divulgazione per la vulnerabilità. Per una panoramica della vulnerabilità, dell'impatto su Akamai, dell'impatto sui clienti EAA e delle azioni richieste, consultare la nostra Integrazione al rapporto.

Panoramica

In questa sezione, vi spiegheremo la storia e l'anatomia di questa vulnerabilità. Alcuni lettori potrebbero voler saltare questa sezione per ora e andare direttamente alla sezione Azioni richieste, utilizzando questa panoramica come riferimento in tutte le valutazioni che devono condurre o per revisioni future.

Prima dell'acquisizione da parte di Akamai della tecnologia EAA tramite l'acquisizione di Soha Systems nel 2016, nella piattaforma è stata introdotta una funzionalità chiave che consente ai clienti della piattaforma di prendere decisioni relative al controllo degli accessi e all'autenticazione in base alle informazioni sull'identità fornite da un provider di identità di terze parti. La piattaforma EAA offre diversi metodi per l'integrazione delle identità di terze parti. Il metodo degno di nota per questo rapporto è il supporto per il protocollo di autenticazione SAML (Security Assertion Markup Language) v2.0.

SAML è uno standard aperto ampiamente utilizzato. SAML consente a un provider di identità (IdP) di passare l'asserzione, mediante firma e restituzione crittografica, a un provider di servizi (SP) tramite il client che presenta un oggetto di asserzione dall'IdP all'SP entro un periodo di tempo definito. (Vedere la sezione Background di seguito per ulteriori informazioni.)

Quando il supporto IdP di terze parti è stato aggiunto a EAA, gli sviluppatori hanno selezionato la libreria open source Lasso per implementare il supporto SAML all'interno della piattaforma. Sulla base della valutazione di Akamai del codice in cui Lasso verifica le risposte SAML fornite come SP, riteniamo che al momento dell'integrazione iniziale, gli sviluppatori abbiano implementato la funzionalità IdP di terze parti in modo ragionevole sulla base dei casi di test forniti con la biblioteca. Ulteriori indagini hanno rivelato che la suite di test utilizzata per testare l'implementazione di Akamai non era sufficientemente rigorosa per identificare questa vulnerabilità di impersonificazione o vulnerabilità simili nel processo di autenticazione. Questa lacuna è stata affrontata nella nostra risposta con l'espansione della suite di test applicata alle nuove versioni del prodotto includendo tutte le combinazioni di risposte e/o asserzioni valide e firmate in modo non valido, nonché asserzioni e risposte non firmate. Questi nuovi test faranno parte del futuro processo di controllo della qualità standard.

Nelle sezioni seguenti del rapporto, analizziamo i vari punti deboli e i fattori che hanno contribuito a creare la vulnerabilità complessiva. Il nostro obiettivo nel fornire questo livello di trasparenza è aiutare gli altri a comprendere le misure intraprese da Akamai e consentire loro di evitare circostanze simili nei propri ambienti.

Test e valutazione del sistema

Test unità, test di integrazione e test di regressione sono un aspetto critico di qualsiasi ciclo di vita di sviluppo software (SDLC). Sebbene al sottocomponente implementato fossero associati tutti questi metodi di test, abbiamo chiaramente appreso che i test non erano abbastanza rigorosi. Inoltre, questo incidente ha portato alla luce una svista in cui alcune librerie di terze parti sono integrate in progetti con il falso presupposto che l'SDLC della dipendenza sia esso stesso rigoroso e sarà informato da rilevamenti specifici del dominio, come vulnerabilità, in librerie simili.

Sebbene sia necessario un SDLC rigoroso per ogni componente e ciascuna delle sue dipendenze, spesso i test integrati nello sviluppo dei componenti e nel piano di controllo qualità non sono sufficienti. Per integrare questo test, possono essere impiegate valutazioni contraddittorie, come test di penetrazione o revisioni del codice di terze parti. Nel caso di EAA, durante il ciclo di vita del prodotto sono state condotte più valutazioni esterne di sicurezza e vulnerabilità della piattaforma EAA, spesso da parte dei clienti. Nonostante ciò, questa vulnerabilità è stata segnalata per la prima volta ad Akamai nel rapporto che ha avviato questa risposta. Akamai ha condotto valutazioni mirate rispetto ad altre parti della piattaforma EAA e alla sua applicazione client, ma questo componente specifico non è stato soggetto a tale livello di controllo.

Evitate la divulgazione prematura

All'inizio di questo processo di risposta agli incidenti, Akamai ha iniziato a scrivere una notifica di alto livello per assistere i clienti ad avviare le indagini suggerite nella sezione Azioni richieste nel  post integrativo. In una revisione pre-pubblicazione di tale documento, al personale di Akamai che non era stato informato della vulnerabilità è stata fornita una copia della messaggistica rivolta al cliente. Entro un'ora dalla fornitura del messaggio, i nostri revisori sono stati in grado di identificare il protocollo interessato (SAML), il pacchetto interessato (Lasso) e, con alcune attività recenti del gestore del progetto Lasso, di formulare un'ipotesi su quale fosse la vulnerabilità. Questa rivelazione ha messo immediatamente in pausa i nostri piani di notifica parziale per rispettare i principi della divulgazione responsabile. 

Dopo ulteriori conversazioni con i nostri revisori, il team addetto agli incidenti è stato in grado di apprendere il processo tramite il quale ha effettuato queste scoperte. Un risultato chiave segnalato dai revisori è stato il messaggio di errore restituito dall'IdP quando si è verificata una condizione di errore. Fino al rilascio della correzione per la vulnerabilità, gli errori SAML restituivano una pagina di errore che esponeva l'errore Lasso all'utente finale, come mostrato nell'immagine seguente. L'inoltro di un errore, in particolare per i processi di sicurezza critici come l'autenticazione, è contrario alle best practice, motivo per cui l'errore non sarà visibile agli utenti finali a partire da questa versione. 

Il documento XML riportato sopra è stato semplificato per gli scopi di questo rapporto, ma la struttura è la stessa. Il documento "padre" esterno è la risposta SAML che include i metadati sulla richiesta e un documento di asserzione. L'asserzione, detta anche asserzione SAML, sono i dati forniti dall'IdP all'SP per l'utilizzo nel processo di autenticazione. In una singola risposta SAML possono essere presenti più asserzioni. Nell'esempio precedente, il contenuto tra le parentesi  ds:Signature  è una firma crittografica sul contenuto dell'oggetto padre, che in questo caso è l'asserzione. Lo stesso oggetto firma può essere applicato anche all'intero oggetto risposta. Lo scopo della firma è consentire all'SP di convalidare che i dati contenuti nell'asserzione o nella risposta sono legittimi e forniti dall'IdP. Nel caso dell'asserzione, la firma si applica solo a tutti i dati contenuti all'interno dell'asserzione, come un nome utente, un indirizzo e-mail o indicazioni di appartenenza a un gruppo. Le firme applicate a livello di risposta si applicano all'intero contenuto della risposta e a tutte le asserzioni in essa contenute.

La verifica delle varie firme nella risposta SAML è affidata all'SP e spesso viene configurata nel momento in cui l'IdP viene configurato per comunicare con l'applicazione. Nella nostra risposta a questo problema, riteniamo che le condizioni di verifica predefinite per le risposte SAML dovrebbero essere le seguenti.

• Quando l'intera risposta SAML è firmata in modo valido, tutte le asserzioni nella risposta devono essere firmate correttamente o non avere firma. Se vengono trovate firme non valide, la verifica non deve riuscire. Questo metodo si basa sul fatto che l'IdP sia autorevole per l'intero corpo del messaggio, che è firmato.
• Quando la risposta SAML non è firmata, tutte le asserzioni nella risposta devono essere firmate correttamente, altrimenti la verifica non deve riuscire.
• Quando la risposta SAML ha una firma non valida, la verifica non deve riuscire.

Le suddette condizioni di elaborazione sono quelle implementate dalla patch proposta da Akamai per Lasso.

Il rapporto fornito ad Akamai all'inizio di questo numero ha mostrato che il ricercatore inviava due asserzioni SAML in un'unica risposta SAML, la prima era firmata in modo valido ma la seconda non era firmata. La configurazione predefinita per Lasso prevedeva le seguenti condizioni di verifica predefinite.

• Se la prima asserzione SAML nella risposta era firmata in modo valido, la verifica aveva esito positivo, indipendentemente dal fatto che la firma completa della risposta SAML fosse valida o meno.
• Se la prima asserzione SAML era stata firmata in modo non valido, la verifica non riusciva.
• Se la risposta SAML era stata firmata in modo valido e nessuna delle asserzioni era firmata, la verifica aveva esito positivo.
• Altrimenti la verifica non sarebbe riuscita.

 A complicare le cose, quando la risposta veniva ritenuta valida dalla libreria, la funzione per recuperare l'asserzione dalla risposta SAML restituiva l'ultima asserzione nell'oggetto risposta, indipendentemente dal fatto che avesse una firma valida. Ad esempio, supponiamo che un autore di attacchi ottenga una risposta SAML valida con una singola asserzione da un IdP, come quella sopra, e aggiunga quanto segue come seconda asserzione:

Nel caso in cui l'utente fornito sia valido per l'organizzazione ma disponga di più privilegi, avrebbe la risposta SAML combinata per l'invio all'SP:

Quando Lasso avrebbe tentato di convalidare questa risposta SAML, il risultato sarebbe stato che la risposta era valida. Quando l'applicazione chiamante avrebbe recuperato l'asserzione dalla risposta precedente, l'asserzione con l'ID utente (uid) del superutente sarebbe stata restituita e probabilmente considerata un'asserzione valida. Oltre all'esempio mostrato sopra, se la risposta SAML stessa avesse avuto una firma valida, sarebbe stato possibile lo stesso metodo di rappresentazione. Questo è stato il caso dell'elaborazione delle risposte SAML da parte di EAA. 

Condizioni di sfruttamento

Affinché la risposta SAML venga modificata prima dell'invio all'SP, deve verificarsi una delle seguenti condizioni:

• Il client legittimo, controllato da un utente autorizzato valido e tramite il quale viene reindirizzata una risposta SAML, deve modificare la risposta SAML inserendo il documento di asserzione aggiuntivo come parte della risposta SAML. Ad esempio, ciò potrebbe avvenire tramite un'estensione del browser dannosa o altro malware sul sistema client, a volte indicato come attacco "MITB (Man-in-the-Browser)".
• Un autore di attacchi deve ottenere una copia valida di una risposta SAML che sia ancora valida, avendo ancora tempo prima che l'asserzione scada o, in alcune applicazioni, se l'asserzione non è stata ancora presentata all'SP. Ad esempio, una parte intermedia può intercettare e modificare una risposta SAML tramite un proxy, spesso indicato come attacco "MITM (Man-in-the-Middle)".
• Un client non autorizzato conosce o è in grado di indovinare le informazioni di accesso di un utente autorizzato. Le informazioni di accesso possono essere raccolte mediante molti processi, tra cui phishing, violazione delle password, ipotesi o attacchi di forza bruta.

Ognuna delle condizioni riportate sopra potrebbe comportare la compromissione della sessione di un utente e, se l'implementazione SAML è errata come indicato sopra, l'SP sarebbe vulnerabile a un attacco di impersonificazione.

Storia della vulnerabilità

Questa stessa vulnerabilità, nota come XML Signature Wrapping, è stata segnalata più e più e più volte ancora .

La revisione degli archivi Lasso indica che la debolezza della libreria è stata incorporata nel codice già nel novembre 2005, ben prima della nostra integrazione della libreria e anche prima del rilascio delle precedenti vulnerabilità annunciate ad altre piattaforme.

Durante l'indagine, abbiamo anche notato che i gestori della libreria Lasso avevano preso parte al progetto poco dopo che la notifica del problema era stata inviata ad Akamai.   Nelle discussioni con l'autore del rapporto, questo impegno non era affatto correlato al loro rapporto, ma era solo una coincidenza.

La correzione proposta il 24 febbraio 2021 ha risolto parzialmente l'impatto dell'exploit, ma dopo un'ulteriore revisione abbiamo stabilito che non si trattava di una correzione completa, motivo per cui infine abbiamo proposto la nostra patch ai gestori.

Uno sguardo alla risposta agli incidenti di Akamai

Akamai segue un processo di risposta agli incidenti formale. Gli incidenti vengono generalmente gestiti tramite un'azione coordinata tra il personale dello sviluppo di sistemi/progettazione, operazioni di rete e assistenza clienti. In generale, maggiore è la gravità dell'incidente, maggiore è il numero di persone coinvolte nella risoluzione e maggiore è la priorità rispetto alle operazioni e al lavoro pianificati. In tutti gli incidenti, l'obiettivo di Akamai è: 

• limitare l'impatto del problema, 
• garantire un funzionamento continuo e sicuro dei nostri sistemi,
• garantire la continuità, la sicurezza e l'assistenza dei nostri addetti alla sicurezza,
• mantenere i clienti soddisfatti e i loro dati al sicuro,
• aderire a varie leggi e regolamenti,
• garantire che siamo in grado di imparare e migliorare da qualunque rischio abbia permesso il verificarsi dell'incidente.

Come descritto in precedenza, abbiamo attivato il nostro processo di risposta agli incidenti dopo la notifica di questa vulnerabilità. Tale processo ha consentito ad Akamai di allineare le risorse tecniche, comunicare con le parti interessate interne e la direzione, comunicare con le parti interessate esterne e coordinare tutte le attività relative all'incidente in modo tempestivo ed efficace.

Processo di implementazione delle patch &

Il processo di sviluppo di una correzione per questa vulnerabilità e di implementazione della patch sulla rete EAA è stato molto simile al normale processo seguito per gli aggiornamenti pianificati, ma con una modifica molto minore e una tempistica molto più rapida.

Entro le prime ore dalla risposta all'incidente, abbiamo preparato una bozza della tempistica per la correzione prendendo in considerazione alcune decisioni chiave. Secondo tale tempistica, una volta pronta la correzione, il processo di controllo della qualità avrebbe dovuto richiedere 3 giorni dopo il processo di controllo della qualità standard e la fase di implementazione sarebbe durata 48 ore. Dopo la fase di implementazione, abbiamo pianificato la comunicazione del problema sotto forma di post del blog e notifiche ai clienti. Queste tempistiche avrebbero potuto essere accelerate, ma poiché non c'erano prove di sfruttamento attivo, abbiamo dato la priorità alla stabilità della nostra rete e abbiamo garantito ai nostri clienti la stabilità durante l'intero processo.

Dopo la valutazione iniziale del problema, il team di tecnici ha adottato due approcci alla correzione tramite due percorsi, utilizzando diverse risorse di progettazione e di controllo della qualità. 

Un team ha esaminato e sviluppato una soluzione parziale al problema, chiudendo il problema segnalato e limitando i requisiti sull'elaborazione delle risposte SAML a quella che riteniamo sia la normale presentazione di una risposta SAML con un'asserzione. Questo metodo potrebbe aver comportato il rifiuto di alcune risposte da parte di alcuni IdP anche se erano valide e sicure. Questo approccio prevedeva anche la possibilità di disabilitare il controllo più rigoroso per ciascun cliente per consentire di proteggere il resto della base di clienti in caso di interazione imprevista con un numero ridotto di IdP.

L'altro team ha adottato un approccio simile al primo team, ma anziché lavorare su una correzione parziale configurabile, ha lavorato su quella che riteniamo essere una correzione completa. Tale approccio è stato esaminato attentamente per garantire che tutte le risposte SAML con formato corretto e firmate correttamente venissero accettate, riducendo la complessità necessaria per consentire il downgrade dei clienti.

Abbiamo adottato questo approccio simultaneo perché consentirebbe di bloccare un percorso o di incorrere in problemi di controllo della qualità pur consentendo l'implementazione di una correzione. Nella tarda giornata del 24 febbraio, fuso orario della costa orientale degli Stati Uniti, ci aspettavamo che la correzione parziale fosse pronta per il controllo della qualità tre giorni dopo l'inizio dell'incidente, mentre lo sviluppo della correzione completa avrebbe dovuto richiedere una settimana in più. Il lavoro è proseguito durante la notte fino al 25, quando il rapporto sullo stato di avanzamento del team di tecnici ha mostrato che l'opzione di correzione completa stava procedendo bene e si prevedeva che alla fine sarebbe stata più veloce da sviluppare e meno complessa da testare.

Alla fine l'opzione di correzione completa è stata consegnata al team del controllo qualità circa un giorno prima della correzione parziale. Una volta che la prima opzione è stata consegnata al team del controllo qualità, è stata inviata una notifica di patch a tutti i clienti EAA indicando i tempi di implementazione previsti.

Questo stato è rimasto lo stesso durante il processo di controllo della qualità. Poco prima della finestra di manutenzione, la correzione completa ha ricevuto l'approvazione del team del controllo qualità, aprendo la strada alla distribuzione.

Il processo di implementazione è iniziato con un POP (Point of Presence) con carico ridotto su cui abbiamo eseguito una suite di regressione estesa monitorando attentamente il traffico per rilevare potenziali interruzioni per i clienti.  È stato aggiornato un altro POP con carico ridotto , con un processo di test ridotto e un periodo di monitoraggio. Nelle prime ore del giorno del 2 marzo, i POP che forniscono l'implementazione EAA interna di Akamai sono stati aggiornati per consentire ulteriori test di carico con i nostri quasi 8.000 utenti finali. Quando non abbiamo riscontrato problemi con nessuna delle implementazioni fino a quel momento, gli altri POP sono stati aggiornati nelle restanti 36 ore della finestra di manutenzione, completando infine il processo di implementazione prima della chiusura della finestra di manutenzione. 

Durante il processo di aggiornamento, la maggior parte degli utenti che interagiva con le proprie applicazioni EAA probabilmente ha riscontrato una o più interazioni di riautenticazione.  Queste in genere consistono in un'interruzione temporanea della sessione e un reindirizzamento al proprio IdP per inserire le proprie credenziali, per poi tornare alla normale attività. Anche gli utenti del client EAA potrebbero aver osservato questo comportamento. I tentativi di riautenticazione sono stati raggruppati dai clienti EAA durante l'implementazione. Dopo l'aggiornamento del codice su ciascun POP, la cache della sessione gestita da EAA è stata cancellata, il che, in un intervallo di 5 minuti, attiverebbe una nuova autenticazione per tutte le richieste. Una volta riautenticati, non abbiamo osservato alcun ulteriore impatto sugli utenti finali.

Gestione del team addetto agli incidenti

Un aspetto chiave per lo sviluppo, la verifica e l'implementazione sicura della soluzione nella nostra rete per problemi significativi come questo include un'attenzione particolare alla cura del team che lavora su un problema. Il processo di gestione degli incidenti di Akamai e la relativa formazione includono indicazioni su come limitare l'esaurimento per i team tecnici e di gestione che rispondono a un incidente. Queste indicazioni includono la verifica che il team responsabile dell'incidente:

• Mangi (regolarmente)
• Dorma (idealmente una "notte" intera di sonno)
• Adempia ai propri impegni personali
• Si mantenga in salute (vaccini anti-COVID-19, esercizio fisico)

Anche se mitigare l'incidente in questione è fondamentale, riteniamo che occuparsi della cura del team durante l'intero processo contribuisca ad assicurare un destino più sicuro per il prodotto e/o il sistema interessato, riducendo anche il numero di errori evitabili e di eventi che potrebbero avere un impatto sul cliente spesso associato a una risposta agli incidenti altamente stressante.

Un altro aspetto chiave del processo di gestione degli incidenti di Akamai è il principio secondo cui siamo tutti coinvolti e non attribuiremo la colpa ai singoli, ora o in futuro. Il team addetto agli incidenti lavora insieme per risolvere il problema, qualunque esso sia nel miglior modo possibile, concentrandosi prima sulla riduzione dell'impatto, quindi cercando di comprendere come evitare che accada di nuovo. Akamai si concentra sulla ricerca dei presupposti che hanno causato un incidente, apprendendo da tali presupposti incompleti e apportando le modifiche appropriate per ridurre le possibilità che quello o altri eventi simili si ripetano.

Azioni richieste

I proprietari di sistemi che si affidano a Lasso per l'autenticazione SAML dovrebbero applicare la patch il prima possibile. Potrebbero essere necessarie ulteriori azioni per esaminare l'impatto sui sistemi autenticati. Ulteriori informazioni su quali azioni possono essere richieste sono disponibili nella sezione Azioni richieste del post integrativo  a questo documento.

Cronologia