Inserimento CSV nei log di Azure

Con la migrazione globale al cloud, le aziende hanno dovuto ripensare il modo in cui monitorano le attività dannose nei propri ambienti. Alcuni dei vecchi meccanismi di monitoraggio (come la cattura dei pacchetti) non sono più disponibili e i registri degli eventi hanno acquisito nuova importanza. Spesso sono l'unico strumento a disposizione per tenere traccia di ciò che accade nella propria infrastruttura.

Cloud hanno avuto difficoltà nell'implementazione delle funzionalità di registrazione. Azure, in particolare, ha dovuto affrontare diversi problemi relativi alla qualità dei log. I log rappresentano inoltre un obiettivo interessante per gli hacker che cercano di mappare il vostro ambiente,con il rischio che informazioni sensibili possano esseredivulgate.

Per quanto gravi possano essere questi problemi, essi sono "passivi": la divulgazione delle informazioni è la cosa peggiore che possa accadere. Tuttavia, i log possono occasionalmente diventare il veicolo per attacchi contro l'azienda. In questo blog descriveremo uno di questi exploit.

Iniezione di log e iniezione CSV

Un log injection è un attacco in cui un avversario può influenzare il contenuto di un log aggiungendovi un payload dannoso appositamente creato. Ciò accade perché le azioni degli utenti spesso comportano l'aggiunta di nuovi record ai log, e tali record contengono spesso dati su cui l'utente ha il controllo: ID utente, indirizzi e-mail, oggetti dei messaggi e così via. Quando questi dati sono creati in modo dannoso, l'applicazione che elabora i log può essere indotta con l'inganno a eseguire un attacco. Ad esempio, si potrebbe inviare un indirizzo e-mail falso contenente un payload XSS (Cross-Site Scripting) in un modulo di registrazione dell'account. E l'amministratore dell'applicazione che apre questo log in un browser potrebbe diventare vittima di un attacco XSS.

I log in Azure possono essere scaricati come file CSV (Comma-Separated Values), che sono vulnerabili alla tecnica CSV Injection. In questo tipo di attacco, se un file CSV contiene una formula Excel (che di solito inizia con il segno di uguale "="), questa viene eseguita da Excel all'apertura del file. Alcune formule possono essere dannose, causando l'esecuzione di comandi del sistema operativo o altri exploit. Ciò può essere pericoloso non solo perché è possibile eseguire comandi arbitrari, ma anche perché gli utenti di solito non ne sono a conoscenza, pensando che i file CSV siano semplici file di testo che non possono causare alcun danno. 

Abbiamo individuato un nuovo caso di Log Injection combinato con CSV Injection in Azure, che può essere utilizzato per attaccare gli amministratori Azure. Vulnerabilità di questo tipo sono giàstate segnalate in passato, ma questo caso è più pericoloso perché può essereeseguito senza autenticazione, ovvero non è necessario disporre di un account cloud .

Scenario di attacco

L'attacco si articola in due fasi:

1. Contaminare i registri Azure

2. Indurre con tecniche di ingegneria sociale un amministratore vittima ad aprire i registri come file CSV

*Si noti che l'attacco non funzionerà su un'istanza di MS Excel completamente aggiornata (maggiori informazioni in seguito).

Inquinamento dei log Azure con user agent dannosi

Per contaminare i log con un comando dannoso, non servono permessi speciali né un account sul sistema della vittima. Basta solo il nome utente di un utente esistente.

Iniziamo inviando il payload dell'iniezione come stringa dell'agente utente:

1. Avvia Microsoft Edge (è possibile utilizzare qualsiasi browser purché sia possibile manipolare l'user agent come descritto di seguito, così come qualsiasi proxy di attacco come Burp o ZAP).

2. Apri gli Strumenti di sviluppo (Ctrl+Maiusc+I), clicca sul menu in alto a destra e seleziona Esegui comando(Ctrl+Maiusc+P):

3. Digita "condizioni di rete" e premi Invio:

4. Nel riquadro che si apre, deseleziona "Usa impostazioni predefinite del browser" e incolla la seguente stringa nel campo in basso:

=msexcel|'\..\..\..\Windows\System32\cmd.exe /c calc.exe'!'A1'

Questa formula Excel di esempio utilizzerà il protocollo DDE (Dynamic Data Exchange) per avviare la Calcolatrice. Un payload reale sarà qualcosa di più distruttivo (ad esempio un comando PowerShell che scarica la fase successiva dell'infezione).

5. Senza chiudere il cassetto, vai suhttps://portal.azure.com einserisci l'indirizzo e-mail di qualsiasi account esistente nel tuo sistema di destinazione.

6. Quando ti viene richiesta una password, inserisci una stringa qualsiasi (il nostro obiettivo non è effettuare correttamente il login!):
   
    

Indurre la vittima ad aprire i registri

I registri di accesso nel tenant Azure di destinazione ora contengono il record di registro compromesso (la consegna effettiva potrebbe richiedere alcuni minuti).

Ora è possibile manipolare l'amministratore di destinazione affinché apra i registri. Nel portale sono disponibili due servizi che consentono di eseguire questa operazione: Log Analytics e Microsoft Entra ID. Descriveremo il primo.

È sufficiente qualsiasi utente con accesso in lettura ad Azure Log Analytics, quindi non è necessario che sia un amministratore con privilegi di livello superiore. 

Sono possibili diversi pretesti. Ad esempio, un "tecnico dell'assistenza Azure" può contattare l'amministratore per richiedere assistenza nell'indagare su "tentativi di accesso sospetti".

I passaggi sono i seguenti:  

1. Chiedi al destinatario diaprire Azure Log Analytics ecaricarela tabella SigninLogsnella finestra di query (fai doppio clic su di essa). Fai clicsul pulsante Eseguiper eseguire la query predefinita:
   
   

2. Il log verrà caricato e una delle voci conterrà il nostro payload:

3. Istruisci il destinatario a caricare il registro come file CSV in Excel per "facilitare l'analisi":
   
   

4. I registri verranno caricati in Excel. Apparirà un messaggio di avviso che il destinatario dovrà ignorare:
   
   

5. Verrà visualizzato un altro messaggio di avviso, che il destinatario dovrà ignorare. Si noti che l'applicazione segnalata è "MSEXCEL.EXE", che è meno sospetta rispetto ad esempio a "CMD.EXE":  
   

6. Verrà visualizzata l'istanza Calculator (proprio come previsto dal nostro payload):
   
   

Puoi vedere l'attacco in azione in questo video:

Gestione della protezione DDE di Excel

Questa vulnerabilità non si attiva automaticamente nell'ultima versione aggiornata di MS Excel. Microsoft ha implementato delle misure di mitigazione per impedire l'avvio del server DDE dalle formule di Excel per impostazione predefinita. Affinché il payload funzioni correttamente, il bersaglio deve utilizzare una versione precedente di Excel oavere abilitato l'avvio del server DDEnell'ultima versione di Excel (ad esempio, su istruzione dell'autore dell'attacco come parte della fase di ingegneria sociale).

Per disattivare questa protezione in Excel, vaisu File > Opzioni > Centro protezione > Impostazioni Centro protezione... > Contenuto esterno eseleziona Abilita avvio server scambio dati dinamico (non consigliato):

Oltre il DDE

La restrizione delle chiamate DDE può sembrare una misura di sicurezza per gli utenti, ma tale sicurezza è ingannevole. È possibile inserire diverse altre formule pericolose che non richiedono DDE. Ecco alcuni esempi (la maggior parte genererà un messaggio di avviso all'apertura del file):

Divulgazione

Abbiamo segnalato questa vulnerabilità a Microsoft in modo responsabile:

13/09/2022 - Segnalato a MSRC
21/09/2022 - Risposta di MSRC: "... la vulnerabilità esiste realmente nel modo in cui Microsoft Excel apre i file. Richiede inoltre di cliccare su un avviso in Microsoft Excel. Potremmo considerare il blocco dei payload di iniezione CSV come precauzione DND come correzione nelle versioni Next Version".

Microsoft sembrava non voler impegnarsi ad apportare modifiche per impedire i payload di CSV injection, e la vulnerabilità esiste ancora oggi. 

Mitigazione

Sebbene Microsoft avesse ragione nell'affermare che gli aggiornamenti di sicurezza in Excel impediscono l'attivazione dei payload DDE, ci sono diversi altri fattori da considerare:

• La vittima potrebbe avere installata una versione obsoleta e non aggiornata di Excel oppure potrebbe essere vittima di social engineering che la induce ad abbassare le difese. Abbiamo illustrato uno scenario di questo tipo sopra.

• Esistono formule non DDE in Excel che potrebbero essere pericolose. Abbiamo riportato diversi esempi al riguardo. Inoltre, Microsoft sta aggiungendonuove funzionalità Python alle formule di Excel e l'invocazione del codice Python tramite iniezione potrebbe portare a conseguenze nuove e impreviste.  

• Altre applicazioni potrebbero aprire file CSV, causando potenzialmente nuovi exploit. Ad esempio, su Linux, LibreOffice è una suite per ufficio molto diffusa che viene utilizzata per aprire file CSV. Esegue formule Excel e supporta anche DDE.

• Infine, è importante mettere in pratica la "difesa in profondità". Sarebbe coerente con questa pratica non solo affidarsi a una correzione di Excel, ma anche eliminare la possibilità di inserimento di formule alla fonte nei file CSV generati da Azure.

We believe that the right course of action is for Microsoft to sanitize values in CSV file cells that begin with "=" (and some others cells that start with "+", "-", "@", and some other characters can also be interpreted as formulas). The original values do not have to be removed (after all, they may be important to the defender). Prefixing them with some string that clarifies the intent (e.g. "<INSERTED TO MITIGATE POSSIBLE CSV INJECTION>") will be sufficient.

Fino a quel momento, si consiglia agli utenti Azure di aggiornare completamente tutti gli strumenti utilizzati per aprire i file CSV e di informare il proprio personale IT sui pericoli rappresentati dai payload dannosi nei log Azure e dagli attacchi di social engineering che potrebbero tentare di sfruttarli.

Interagisci direttamente con noi riguardo a questo post del blog e ad altri argomenti nella comunitàVectra AI .