Cinque vulnerabilità critiche in Azure API Connections hanno consentito al ricercatore di Binary Security di usare le connessioni di altri clienti per agire sui servizi collegati. L'impatto non dipendeva dalla compromissione diretta di Key Vault, Azure SQL o di un'applicazione esterna: consisteva nell'indurre l'infrastruttura dei connettori Azure a utilizzare l'autorizzazione già configurata nella connessione della vittima.
Il ricercatore afferma che i risultati descritti gli hanno fruttato 200.000 dollari. Indica inoltre che Microsoft ha corretto le vulnerabilità dopo aver ricevuto le segnalazioni, anche se la serie mostra come una correzione incentrata su un endpoint potesse lasciare aperto un altro percorso verso la stessa capacità.
“In total, the vulnerabilities here netted me a cool $200,000.”
— autore di Binary Security
Una connessione che porta con sé la propria autorità
API Connections fa parte di Azure Logic Apps. Consente a un flusso di lavoro di chiamare servizi esterni senza dover implementare separatamente l'intera autenticazione e lo scambio di credenziali. Secondo la descrizione di Binary Security, una Logic App interroga un'istanza condivisa di Azure API Management (APIM); questa convalida l'operazione rispetto alla definizione OpenAPI del connettore, scambia il token ricevuto con la credenziale configurata per il servizio e invia la richiesta al backend.
Il backend può essere un servizio Azure, come Key Vault o Azure SQL, oppure un'applicazione esterna come Jira o Salesforce. Per questo, il confine di sicurezza non riguarda soltanto chi può modificare una Logic App: conta anche se ogni richiesta è vincolata alla connessione specifica che il richiedente è autorizzato a usare. Se APIM finisce per operare su una connessione altrui, il backend riceve una chiamata con l'autorità già associata a quella connessione.
flowchart LR A["Logic App o ARM"] --> B["APIM compartido"] B --> C["Valida operación y cambia credencial"] C --> D["Servicio conectado"] E["Conexión de otro cliente"] --> B
Lo schema riassume il meccanismo descritto da Binary Security: il problema si presentava quando una richiesta riusciva a indirizzare l'operazione verso una connessione che non apparteneva al cliente che l'aveva inviata. Anche ARM, il piano di gestione di Azure, poteva essere una via per invocare tramite APIM le operazioni delle connessioni.
Da un percorso di accesso a diverse correzioni parziali
Il primo caso esaminato dal ricercatore proviene da una pubblicazione precedente della sua serie. Una vulnerabilità di path traversal nell'endpoint DynamicInvoke dell'API REST di ARM ha consentito di leggere un segreto di Key Vault appartenente a un altro tenant usando una propria connessione. L'esempio pubblicato da Binary Security mostra una risposta contenente il valore del segreto. Il ricercatore afferma che Microsoft ha contrassegnato la falla come corretta alcune settimane dopo la segnalazione.
La correzione sembrava limitare i percorsi accettati da DynamicInvoke, senza risolvere il problema di fondo: la possibilità che la richiesta raggiungesse la credenziale associata a un'altra connessione. Per verificare quali altre superfici fossero esposte, il ricercatore ha estratto il codice del tipo di risorsa di una Logic App Standard dedicata. Sottolinea di non sapere se quel codice fosse eseguito sui sistemi Microsoft o fosse un artefatto incluso, ma ha trovato diverse funzioni pubbliche nello stesso percorso, tra cui DynamicList, che non erano documentate.
Testando DynamicList, ha riprodotto la stessa logica di path traversal e dimostrato la possibilità di scrivere in un database Azure SQL tramite la connessione della vittima. Secondo il suo resoconto, Microsoft ha bloccato gli endpoint non documentati dopo aver ricevuto la segnalazione. Il ricercatore non descrive questa decisione come una correzione della causa comune: osserva che, se quegli endpoint venissero esposti di nuovo, potrebbero tornare a essere vulnerabili.
Il cambiamento della superficie non ha concluso l'indagine. Il ricercatore è passato ai flussi di Logic Apps e ha individuato differenze tra i modelli Consumption e Standard. Le Logic Apps Standard usano un host dedicato e creano connessioni di versione 2, autorizzate tramite l'identità gestita della Logic App. Le Logic Apps Consumption, i cui flussi condividono l'ambiente con altri, creano connessioni di versione 1 e non dispongono di una propria identità per l'autorizzazione.
Partendo da questa differenza, il ricercatore ha dedotto che le Logic Apps Consumption potessero avere accesso implicito alle connessioni di versione 1 e che la convalida degli input fosse l'effettiva barriera di sicurezza. Modificare direttamente il riferimento al connettore della vittima non funzionava: il runtime verificava che la connessione appartenesse all'utente. Tuttavia, esaminando la definizione del flusso, ha trovato il parametro host.api.RuntimeUrl, che consentiva di sostituire l'URL di runtime incluso nella connessione.
Il ricercatore afferma che, se l'host indicato terminava con azure-apihub.net, la richiesta continuava a includere l'intestazione di autorizzazione necessaria. In questo modo era possibile superare il controllo di proprietà della connessione referenziata e indirizzare la chiamata verso un altro percorso. Microsoft ha aggiunto un controllo per richiedere che l'URL corrispondesse all'endpoint previsto per quella connessione. Ma, secondo Binary Security, la convalida avveniva prima della normalizzazione del percorso: il runtime e APIM interpretavano la destinazione in modo diverso.
La sequenza delle correzioni ha avuto anche un effetto inatteso. Il ricercatore afferma che, quando Microsoft ha corretto il path traversal, ha smesso di convalidare il percorso originale di RuntimeUrl, riaprendo così il precedente vettore di attacco. L'indagine illustra quindi qualcosa di più concreto di una serie di errori indipendenti: diversi input e percorsi conducevano a una capacità comune e le modifiche applicate a uno potevano alterare il comportamento di un altro.
L'impatto dipende dalle autorizzazioni di ciascuna connessione
L'impatto non equivale a ottenere automaticamente privilegi illimitati su tutti i servizi collegati. Binary Security riconosce che i proprietari possono limitare l'ambito di token e chiavi. La capacità ottenuta nel backend dipende dalle autorizzazioni già concesse alla connessione: una credenziale con accesso limitato offre meno margine di una con autorizzazioni ampie. Il ricercatore ritiene che le restrizioni minime non siano comuni, ma questa è una sua valutazione, non una misurazione delle configurazioni dei clienti.
Per i team che usano Logic Apps, la conseguenza pratica è verificare quali autorizzazioni hanno le proprie connessioni, non soltanto chi può modificare i flussi. Una connessione a Key Vault, SQL o a un servizio di terze parti può rappresentare autorizzazioni concesse a un'identità o alla persona che ha autorizzato OAuth. Ridurre tali autorizzazioni limita i danni potenziali in caso di malfunzionamento di un livello di isolamento; non sostituisce l'obbligo di verificare che ogni chiamata possa usare solo la connessione corrispondente.
Conta anche il modo in cui vengono valutate le correzioni nei servizi gestiti. Nei casi descritti, Microsoft ha modificato il comportamento lato servizio, quindi il ricercatore non parla di installare una patch in ogni Logic App. Tuttavia, limitare i percorsi in un endpoint, bloccare funzioni non documentate e convalidare un URL prima di normalizzarlo sono difese diverse. Il ripetersi di falle attorno alla stessa capacità chiarisce perché una correzione debba essere verificata anche rispetto a percorsi alternativi e trasformazioni delle richieste.
Binary Security afferma che le cinque falle critiche sono state corrette entro tempi ragionevoli dalla segnalazione ed esprime una soddisfazione generale per la risposta, nonostante i disaccordi con MSRC. Il ricercatore ha inoltre presentato il lavoro a Blue Hat Asia 2026. La sua pubblicazione non afferma che i casi dimostrati nei test abbiano comportato accessi non autorizzati ai dati di clienti reali.
La domanda che resta alle organizzazioni non è se ogni connessione consenta l'accesso a tutto il backend, ma quali operazioni siano effettivamente consentite da ciascuna identità o credenziale e se i log permettano di rilevare utilizzi al di fuori dei flussi previsti.
Fonti: Binary Security AS, The Protec Blog - Guarding Your Future, One Byte at a Time., Glonce, PAN
