Microsoft Azure Defender for IoT è soggetto a cinque vulnerabilità critiche che hanno un punteggio di gravità CVSS fino a 10.0. Scoperte dai ricercatori di SentinelLabs, le falle sono monitorate con le sigle CVE-2021-42310, CVE-2021-42312, CVE-2021-37222, CVE-2021-42313 e CVE-2021-42311 e interessano sia i clienti cloud che quelli on-premise.

Se sfruttate adeguatamente, possono portare alla compromissione completa della rete. Il requisito per consentire un attacco di tale portata è che Azure Defender for IoT sia configurato per avere un TAP (Terminal Access Point) sul traffico di rete. L'azienda di Redmond ha pubblicato gli aggiornamenti di sicurezza che chiudono queste vulnerabilità critiche e, anche se al momento non risultano ancora sfruttamenti attivi, ne è fortemente caldeggiata l'installazione. Inoltre, gli esperti consigliano di revocare tutte le credenziali privilegiate distribuite sulla piattaforma prima dell'applicazione delle patch, e di controllare i registri di accesso per le irregolarità.

Falle e tecniche di attacco

I ricercatori hanno pubblicato una ricerca con tutti i dettagli tecnici, da cui si evince che le falle influenzano il meccanismo di recupero e reimpostazione delle password di Azure e "possono essere abusate da attaccanti remoti per ottenere un accesso non autorizzato". Inoltre, "più vulnerabilità SQL injection in Defender for IoT [possono] consentire agli attaccanti da remoto di ottenere l'accesso senza autenticazione".

Ricordiamo che Microsoft Defender for IoT è una soluzione di sicurezza agentless per risorse IoT e OT (Operational Technology). Include il rilevamento continuo delle risorse IoT/OT, la discovery delle minacce e la gestione delle vulnerabilità. Può essere distribuito in locale o in ambienti connessi ad Azure.

La soluzione è composta da due componenti principali: Microsoft Azure Defender for IoT Management, che consente ai team SOC di gestire e analizzare gli alert aggregati da più sensori in un'unica dashboard e fornisce una visione d'insieme dell'integrità delle reti. E Microsoft Azure Defender For IoT Sensor, che rileva e monitora continuamente i dispositivi di rete. I sensori raccolgono il traffico di rete ICS utilizzando il monitoraggio passivo (agentless) su dispositivi IoT e OT. I sensori si connettono a una porta SPAN o a una rete TAP ed eseguono DPI (Deep Packet Inspection) sul traffico di rete IoT e OT. La DPI si ottiene tramite il componente horizon, che è responsabile dell'analisi del traffico di rete. Entrambi i componenti possono essere installati in un'appliance dedicata o in una macchina virtuale.

La parte Management e quella Sensor condividono grossomodo la stessa base di codice, per questo motivo sono afflitte delle stesse vulnerabilità. La superficie di attacco più esposta e invitante per gli attaccanti è l'interfaccia web. Un'altra superficie di attacco è costituita dal servizio DPI (horizon) che analizza il traffico di rete.

Come accennato, tutto ruota attorno al meccanismo di recupero della password, che è costituito da due entità principali: API Web Python (esterna) e API web Java (interna). I ricercatori hanno individuato una vulnerabilità TOCTOU (Time-of-Check-Time-of-Use) poiché non viene applicato alcun meccanismo di sincronizzazione. Questo apre una finestra di opportunità nel flusso, che consente di modificare i file tra la prima verifica (API Python) e la seconda verifica (API Java).

In estrema sintesi, quello che può accadere è che l'API Python convalida i file sono firmati correttamente dai certificati di Azure. Se tali file vengono sostituiti da un attaccante con un certificato autofirmato che legittima il payload di un exploit, è possibile però che questo superi la verifica della firma da parte dell'API Java. Si attua così un l'attacco TOCTOU che consente di reimpostare e ricevere la password di un dato nome utente senza alcuna autenticazione.

L'attaccante ha quindi ottenuto una password funzionante per un utente privilegiato. Con queste credenziali, tramite la pagina di login dell'interfaccia web, il falso utente può accedere al server SSH (dato che le stesse credenziali dell'interfaccia web di Management sono utilizzate anche come credenziali di accesso per il server SSH), ed eseguire codice come root.