I rischi di Power Apps: l'uso improprio della piattaforma per colpire i server on-premise

I servizi Power Platform di Microsoft offrono una piattaforma a uso limitato di codice/no-code (LCNC) che include l'analytics dei dati (Power BI), sviluppo di siti web (Power Pages), assistente virtuale (Power Virtual Agent) e una sorta di sviluppo "full application" (Power Apps). Queste piattaforme possono offrire agli utenti business meno tecnici la possibilità di creare soluzioni che tradizionalmente richiederebbero uno sviluppatore più tecnico con esperienza di programmazione.

Mentre le piattaforme LCNC possono essere uno strumento potente per gli utenti business, gli sviluppatori della piattaforma devono assicurarsi che la sicurezza sia integrata in ogni fase. Gli utenti business senza esperienza formale di programmazione potrebbero non avere lo stesso livello di consapevolezza della sicurezza di uno sviluppatore software moderno. Questo può aumentare la probabilità che l'utente introduca configurazioni errate in queste piattaforme LCNC.

In questo post sul blog, esamineremo come, nel 2022, il team Adversary Simulation di X-Force Red abbia combinato una configurazione errata comune all'epoca con un problema di bypass di sicurezza ancora presente nella piattaforma Power Apps di Microsoft. Questo ha consentito a X-Force Red di violare un perimetro esterno rafforzato e ottenere l'esecuzione di codice su un SQL Server on-premise, che alla fine ha portato alla completa compromissione di Active Directory.

Nel 2022, il comportamento predefinito di Power Apps prevedeva che quando un'applicazione Power Apps veniva condivisa con gli utenti, anche tutte le connessioni associate venivano condivise. Questo comportamento rendeva molto facile per gli utenti condividere accidentalmente le connessioni con tutti gli utenti in un'organizzazione, quando forse intendevano solo condividere l'applicazione frontend. Questo comportamento è stato modificato nel gennaio 2024, secondo Microsoft, rendendo molto meno probabile che gli utenti condividano accidentalmente le connessioni.

Nel 2022, tuttavia, X-Force Red ha identificato una connessione SQL che utilizzava un "Gateway di dati on-premise" per connettersi a un SQL Server on-premise ampiamente condiviso in questo modo. Sebbene le query SQL native non siano supportate per SQL Server on-premise nei flussi Power Apps, X-Force Red ha identificato che l'azione "Trasforma i dati utilizzando Power Query" poteva essere utilizzata per eseguire SQL Query native su server on-premise. Questo ha permesso a X-Force Red di passare a SQL Server on-premise e di raggiungere tutti gli obiettivi dell'incarico.

Questo bug è stato recentemente segnalato al Microsoft Security Response Center (MSRC), che gli ha assegnato un livello di gravità basso, quindi ora possiamo pubblicarne i dettagli.

Power Apps consente agli utenti di creare "app" e "flussi" utilizzando una GUI drop-and-drag tipica delle piattaforme LCNC. Le app possono essere utilizzate per creare applicazioni front-end, che generalmente servono a prelevare dati da qualche parte e mostrarli all'utente. Di seguito è riportata un'applicazione demo "Budget Tracker" fornita da Microsoft che preleva i dati da un foglio di calcolo Excel e li mostra all'utente.

L'altro lato di Power Apps, Flows, sarà familiare a chiunque abbia già utilizzato un altro servizio LCNC come Azure Logic Apps. I flussi consentono agli utenti di creare un programma simile a un diagramma di flusso e sono in genere utilizzati per raccogliere i dati, elaborarli e poi inviarli da qualche parte. Di seguito è riportato un flusso molto basilare che effettua una richiesta HTTP e poi analizza il JSON risultante.

Power Apps dispone di una suite di connettori che consentono agli utenti di eseguire attività come l'inserimento di dati o l'invio di e-mail, senza dover ricorrere a una serie di azioni di richiesta HTTP. Molti di questi connettori sono solo librerie precostituite di richieste HTTP, ma astraggono tutti i dettagli tecnici dall'utente. Invece di dover creare una richiesta HTTP all'API Graph per ottenere informazioni su un utente Entra ID, puoi semplicemente collegare un connettore Entra ID e utilizzare l'azione "Ottieni utente".

Power Apps offre connettori per molti servizi popolari, inclusi servizi Microsoft e offerte di terze parti. Puoi scaricare file da SharePoint, convertire un documento in PDF usando Adobe PDF Services o riavviare le macchine virtuali in Azure, solo per citarne alcuni. Quando crei una connessione, ti verrà chiesto di fornire materiale di autenticazione a seconda del servizio a cui ti stai collegando. Per quasi tutto ciò che riguarda Microsoft, ti basterà autenticarti tramite il tuo account O365.

Nota: per il resto di questo post, userò il termine "connettore" per descrivere la libreria di azioni in Power Apps (ad esempio: il connettore ID Entra) e "connessione" per fare riferimento a un connettore creato e autenticato da un utente (ad esempio: la connessione ID Entra autenticata come john.smith@contoso.com) e può essere usato per creare nuove azioni.

Finché esiste questa connessione, la tua autenticazione sarà associata ad essa. Qualsiasi utente con accesso a tale connessione può creare nuove azioni che utilizzeranno la tua autenticazione. Ad esempio, se crei una connessione Entra ID, un altro utente con accesso a tale connessione potrebbe creare un'azione "Aggiungi utente al gruppo", che utilizzerà la tua autenticazione, anche se quell'utente non dispone delle autorizzazioni ID Entra necessarie per aggiungere un utente a un gruppo. In passato ho scritto sul blog sull'abuso di questa azione in Azure Logic Apps e ho trovato un utilizzo di escalation dei privilegi funzionante in Azure Logic Apps a proposito di questa funzionalità.

Fino al 2024, questo tipo di attacco era molto più probabile che si verificasse in Power Apps. In passato, quando si condivideva un'applicazione che utilizzava una connessione, anche la connessione associata veniva condivisa. Puoi vedere tutto questo documentato in questa pagina di Microsoft, che non è stata aggiornata dal 2022. Tuttavia, secondo questa pagina del 2024, non è più così. Ora dovrai condividere la connessione con il tuo account, che rappresenta un errore di configurazione molto meno probabile. Questo potrebbe essere stato il risultato del discorso di BlackHat 2023 "All You Need Is Guest" di Michael Bargury, un eccellente discorso che riguardava anche l'enumerazione e il dumping di informazioni da Power Apps.

Cosa succede se hai bisogno di accedere a dati che non sono disponibili su Internet? E se avessi bisogno di accedere ai dati da un SQL Server on-premise? Microsoft ha già pensato a questo e ha creato i data gateway on-premise. I gateway sono installati su un host on-premise e agiscono essenzialmente come un proxy che permette ai connettori Power Apps di comunicare con le risorse. Per accedere a un SQL Server on-premise, puoi semplicemente installare un gateway sul SQL Server (o su un altro server, o magari anche sulla tua workstation se fai shadow IT) e poi usare il connettore SQL per eseguire query sul server.

Sono supportati sei tipi di autenticazione per la connessione a un SQL Server, anche se non tutti funzionano per SQL Server on-premise. Per le attività on-premise, probabilmente userai l'autenticazione SQL Server o l'autenticazione Windows, fornendo le tue credenziali AD o le credenziali SQL locali.

Una volta creata la tua connessione o ottenuto accesso a una condivisa, puoi eseguire una serie di azioni contro SQL Server. Quello che attirerà l'attenzione della maggior parte dei lettori è "Esegui una SQL Query (V2)".

Se non conosci le implicazioni della capacità di eseguire SQL Query native, ti suggerisco di leggere questo blog del mio collega, Sanjiv Kawa, sul suo strumento SQLRecon. Ovviamente, se puoi eseguire SQL Query su un server, allora puoi scaricare tutti i dati a cui hai i permessi di accesso, e questo potrebbe essere preoccupante se nel database sono memorizzati dati sensibili. Tuttavia, se hai un accesso privilegiato al SQL Server, puoi eseguire codice sul sistema operativo sottostante. Ecco alcuni modi in cui potresti farlo:

• La procedura xp_cmdshell memorizzata
• Procedure di automazione OLE
• Esecuzione di assemblaggi .NET CLR
• Job per Agent SQL

Questo dipende in ultima analisi dai privilegi dell'utente che ha creato la connessione, ma se hai mai fatto un pivot attraverso un SQL Server per raggiungere un obiettivo, allora sai quanto siano comuni gli account con privilegi eccessivi. Anche se l'utente connesso non ha i privilegi per eseguire codice, puoi anche verificare l'impersonificazione, i collegamenti ad altri SQL Server o le credenziali memorizzate in testo chiaro nei database.

Detto questo, tutto ciò è in definitiva privo di significato, poiché l'azione "Esegui una SQL Query (V2)" non è supportata per i gateway.

Altre azioni, come "Ottieni righe (V2)", che estrarrà le righe da una tabella specificata, funzionano bene. Semplicemente non possiamo eseguire query arbitrarie sul server. Presumo che ciò sia dovuto al fatto che Microsoft ha considerato la possibilità di abusi e ha deciso che esporre le insicurezze dei SQL Server on-premise agli utenti esterni di O365 sia negativo.

Se si esaminano tutte le azioni disponibili per il connettore SQL, si noterà l'azione "Trasforma dati tramite Power Query". Nonostante il nome, Power Query non fa parte della famiglia di servizi Power Platform. Piuttosto, è un motore di trasformazione dei dati che puoi trovare in altri servizi/applicazioni, come Excel. Come motore di trasformazione dei dati, Power Query è progettato per prendere dati e trasformarli senza modificare i dati sorgente.

Dopo aver creato un'azione "Trasforma dati tramite Power Query" con una connessione valida, verrà visualizzato un menu che mostra tutte le tabelle nel database a cui è connessa. Nel mio SQL Server di test, c'è solo una tabella vuota chiamata "Persone".

Selezionando "Trasforma dati" verremo indirizzati alla schermata successiva, che è un editor di Power Query. Power Query utilizza il linguaggio delle formule M, un linguaggio di trasformazione dei dati sviluppato da Microsoft. La documentazione di riferimento per il linguaggio M documenta le "Funzioni di accesso ai dati", un elenco di funzioni che possono essere utilizzate per inserire dati in Power Query. Quando apriamo il nostro editor di Power Query sulla query predefinita, vediamo che la funzione "Sql.Databases" viene utilizzata per estrarre informazioni dal database SQL connesso.

Dopo aver sfogliato la versione PDF di 1.394 pagine del linguaggio M, ho notato che la funzione "Sql.Database" (notare la "S" mancante) ha un parametro opzionale chiamato "Query". Questo parametro è descritto come "Una SQL Query utilizzata per recuperare i dati".

Se si inserisce il seguente codice Power Query nell'editor, viene visualizzato un avviso che indica che "Le query native potrebbero non essere sicure e alterare il database".

Bene, "modificare il database" è il mio secondo nome, quindi dopo aver cliccato su "Continua", veniamo ricompensati con l'output di una SQL Query nativa.

Per ricapitolare, ecco come puoi abusare di questo per compromettere un SQL Server on-premise che ha accesso solo a una licenza Power Apps:

1. Un utente crea un'applicazione che utilizza una connessione SQL on-premise e la condivide con tutti, sia intenzionalmente che involontariamente.
2. Un attaccante crea un nuovo flusso e aggiunge un'azione "Trasforma i dati con Power Query" utilizzando la connessione SQL esistente.
3. Se l'utente connesso è un amministratore SQL o possiede privilegi di impersonificazione, o ci sono collegamenti SQL privilegiati o credenziali in chiaro nei database, o hai ottenuto altre credenziali in chiaro privilegiate, puoi ora passare a un SQL Server on-premise.

Secondo questi documenti Microsoft aggiornati l'ultima volta nel 2022, se condividi un'app che utilizza dati da un gateway, allora anche il gateway verrà condiviso. Dai test effettuati sul mio tenant, sembra che non sia più così. Detto questo, se hai accesso a un gateway, puoi creare nuove connessioni tramite esso, e ciò significa che non sei più limitato dalle connessioni esistenti. Questo significa che devi avere credenziali compromesse per account AD o SQL e conoscere i nomi host dei SQL Server, anche se non è raro imbattersi in queste informazioni su SharePoint/Confluence.

È possibile utilizzare al meglio anche altri connettori che impiegano i gateway, come l'azione "File System", che richiede anche credenziali e nomi host validi, ma significa che è possibile leggere/scrivere file sugli host interni.

Se hai accesso a un account con accesso Power Apps, dovrai controllare tutti gli ambienti a cui hai accesso. Puoi verificarlo selezionando il menu a discesa "Ambiente" nell'angolo in alto a destra. In ogni ambiente, dovrai selezionare "...Altro" e poi "Scopri tutto". Verrai indirizzato a una pagina in cui potrai accedere a tutti gli elementi di Power Apps.

Da lì, puoi selezionare "Connessioni" per vedere tutte le connessioni a cui hai accesso e "Gateway" per vedere tutti i gateway a cui hai accesso. Puoi anche vedere chi possiede le connessioni, così puoi verificare se l'utente ha privilegi o meno.

Inoltre, sul lato sinistro dello schermo si trovano i pulsanti "Flussi" e "App". Dovrai cliccare su "Condiviso con me" in modo da poter vedere tutto e iniziare a cercare credenziali in chiaro o informazioni sensibili. Le azioni di flusso HTTP sono particolarmente adatte per trovare password e chiavi API.

Gli amministratori dovrebbero valutare la possibilità di limitare gli utenti che possono installare i gateway o di disattivarli completamente se non vi è alcun caso d'uso. Puoi farlo accedendo alla piattaforma di amministrazione di Power Apps, selezionando "Dati", spuntando la casella "Amministrazione tenant" e quindi selezionando "Gestisci programmi di installazione gateway". Da lì, puoi abilitare l'impostazione "Impedisci agli utenti della tua organizzazione di installare gateway" e aggiungere gli utenti che devono installare gateway. Per maggiori informazioni, consulta la documentazione di Microsoft.

Valuta periodicamente le connessioni nel tuo ambiente e assicurati che gli utenti non condividano ampiamente connessioni sensibili.

In questo blog, abbiamo esaminato come un utente con accesso a un connettore SQL server utilizzando un data gateway on-premise possa eseguire query native sul server e potenzialmente passare da O365 alle risorse on-premise. Il comportamento che in precedenza rendeva comune questa configurazione errata è stato modificato nel 2024, ma con l'accesso giusto, un aggressore può ancora trovarsi nella posizione di abusarne. Con la pubblicazione di questo blog, ci auguriamo che i difensori verifichino il loro ambiente per identificare i gateway e i connettori eccessivamente condivisi, per prevenire futuri attacchi mirati a Power Apps.

02/10/2025: Caso MSRC originale inviato

11/02/2025: MSRC dichiara che si tratta di una questione di ingegneria sociale e chiude il caso

12/02/2025: Secondo caso MSRC presentato

24/02/2025: MSRC valuta la vulnerabilità con gravità bassa