A causa di una vulnerabilità di tipo Information Disclosure (divulgazione delle informazioni) in Microsoft Azure, le credenziali “RunAs” dell’account di automazione (certificati PFX) in Azure Active Directory (AAD) venivano archiviate in chiaro. Queste credenziali erano disponibili per chiunque fosse stato in grado di leggere le informazioni sulle App Registrations (ossia la maggior parte degli utenti AAD).
Tali credenziali potrebbero essere utilizzate per autenticarsi appunto come App Registration, come utente di tipo Contributor nell’abbonamento contenente l’account di automazione e questo, potenzialmente, potrebbe essere sfruttato per disabilitare o eliminare risorse da interi tenant di Azure.
Indice degli argomenti
I dettagli della vulnerabilità in Azure Active Directory
L’anomalia (tracciata come CVE-2021-42306 con un punteggio CVSS di 8.1) deriva dal modo in cui vengono gestite le credenziali “RunAs” durante la creazione di un nuovo account di automazione in Azure. Sembrerebbe che l’algoritmo che era utilizzato da Azure, al posto di archiviare la chiave pubblica associata, archiviasse il file PFX nel manifesto dell’App Registration. Possiamo riscontrarlo creando un nuovo account di automazione con un account “RunAs” in un tenant di test. Come parte integrante di questo processo, assegnando il ruolo di collaboratore all’account “RunAs”, dovremo utilizzare un account con il ruolo di proprietario per completare questo passaggio. Come esempio, utilizzo l’account di automazione “BlogExample”:
Teniamo presente che occorre anche selezionare l’impostazione “Crea account RunAs di Azure”.
A questo punto, verrà creato un nuovo account dell’entità servizio che l’account di automazione potrà utilizzare all’interno degli script in esecuzione.
Per impostazione predefinita, a questa entità servizio verrà concesso anche il ruolo di Contributor nella sottoscrizione in cui viene creato l’account di automazione.
Una volta creati gli account di automazione e “RunAs”, riscontreremo la nuova entità nella sezione App Registrations del pannello del portale Azure Active Directory.
(Fonte: netspi.com).
Selezionando il nome visualizzato, potremo vedere i dettagli per la registrazione dell’App e navigare nella sezione “Manifesto”. All’interno di questa sezione, possiamo vedere le “keyCredentials”.
(Fonte: netspi.com).
Il parametro “value” è la stringa codificata in Base64 contenente il certificato PFX che potrà essere utilizzato per l’autenticazione. Prima di poter eseguire l’autenticazione come App Registration, sarà necessario decodificare il certificato da Base64. E’ possibile farlo utilizzando Notepad++ o semplicemente con due righe di PowerShell:
Successivamente, occorrerà importare il certificato nel nostro local store. Anche quest’azione può essere svolta con PowerShell (occorre avere un account con diritti da Administrator):
(Fonte: netspi.com).
Infine, potremo usare il certificato appena installato per autenticarci alla sottoscrizione di Azure come App Registration. Dovremo conoscere l’ID della directory (tenant), l’ID dell’App (client) e l’impronta del certificato per le credenziali dell’App Registration, e possiamo trovarli accedendo alla voce di menù “Overview” dell’App Registration e del manifesto.
Impatti e contromisure
Come è possibile leggere dal bollettino ufficiale di Microsoft (che invito a consultare se come piattaforma Cloud state utilizzando Azure in azienda, o per i vs clienti), tale vulnerabilità coinvolge più sistemi Azure.
Concentrando questa breve analisi solo su Azure Automation, ad esempio, leggiamo che tale vulnerabilità impatta sicuramente gli account RunAs non rinnovati e creati con un certificato self-signed tra il 15 ottobre 2020 e il 15 ottobre 2021.
Separatamente, anche i clienti che hanno utilizzato i propri certificati potrebbero essere coinvolti. E questo indipendentemente dalla data di rinnovo del certificato.
Microsoft altresì segnala che è possibile accedere a questo repository GitHub per reperire guide e script utilizzabili per identificare e correggere le applicazioni Azure AD associate agli account RunAs di automazione coinvolti, e che Azure Automation ha il supporto per le identità gestite (annunciato a ottobre 2021).
La migrazione alle identità gestite da Run-As è in grado di mitigare tale problematica (per migrare, è possibile consultare la seguente guida ufficiale Microsoft).
Sappiamo che un ambiente multi tenant è per definizione un ambiente Cloud in cui operano più clienti sulla medesima infrastruttura: al di là delle garanzie sulla privacy e sulla solidità dei meccanismi di sicurezza informatica che possono comunicarci (verbalmente o per iscritto) rivenditori e commerciali del Cloud provider, nonché uno o più Cloud Architect con dozzine di certificazioni del tal o tal altro Cloud provider in bella mostra, occorre rammentare che appunto trattasi di un ambiente computazionale e di hosting “condiviso”, dunque potenzialmente soggetto a compromissioni informatiche di vario tipo, proprio come CVE-2021-42306 ci dimostra e ci ricorda.
Ergo, occorre sempre rammentare di tener viva la Cybersecurity Posture aziendale, anche in Cloud e a prescindere dal nostro provider Cloud, per evitare spiacevoli sorprese (anche sul piano economico) a medio/lungo termine.
