Iniezione CSV nei log di Azure

Con la migrazione globale verso il cloud, le aziende hanno dovuto ripensare a come tracciare le attività dannose nei loro 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 nell'infrastruttura.

I fornitori di Cloud hanno avuto problemi di crescita nell'implementazione delle funzionalità di log. Azure, in particolare, ha avuto a che fare con diversi problemi di qualità dei log. I registri rappresentano anche un succoso obiettivo di ricognizione per gli aggressori che cercano di mappare l'ambiente, con la possibilità di fartrapelare informazioni sensibili.

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

Iniezione di log e iniezione di 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 dell'utente comportano spesso l'aggiunta di nuovi record ai registri e tali record contengono spesso i dati su cui l'utente ha il controllo: ID utente, indirizzi e-mail, oggetti dei messaggi e così via. Quando questi dati vengono creati in modo malevolo, l'applicazione che elabora i registri può essere indotta a eseguire un attacco. Ad esempio, si potrebbe inviare un indirizzo e-mail falso contenente un payload XSSCross-Site Scripting) in un modulo di registrazione di un account. L'amministratore dell'applicazione che apre questo registro in un browser può diventare vittima di un attacco XSS.

I registri in Azure possono essere scaricati come file CSV (Comma-Separated Values), che sono vulnerabili a una tecnica di CSV Injection. In questo tipo di attacco, se un file CSV contiene una formula di Excel (che di solito inizia con un segno di uguale - '='), questa viene eseguita da Excel quando apre il file. Alcune formule possono essere dannose e causare l'esecuzione di comandi del sistema operativo o altri exploit. 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 trovato una nuova istanza di Log Injection combinata con CSV Injection in Azure, che può essere utilizzata per attaccare gli amministratori di Azure. Vulnerabilità di questo tipo sono statesegnalate in passato, ma questa istanza è più pericolosa perché può essere eseguitasenza autenticazione, cioè non è necessario disporre di un account nell'ambiente cloud .

Scenario di attacco

L'attacco consiste in due fasi:

1. Inquinare i log di Azure

2. L'ingegnere sociale di un amministratore vittima è in grado di aprire i registri come file CSV.

*Si noti che l'attacco non funzionerà su un'istanza di MS Excel completamente aggiornata (per saperne di più in seguito).

Inquinamento dei registri di Azure con un agente utente dannoso

Per inquinare i registri con un comando dannoso, non sono necessari permessi speciali e nemmeno un account sul sistema vittima. È sufficiente il nome utente di un utente esistente.

Si inizia inviando il payload dell'iniezione come stringa dell'interprete:

1. Avviare Microsoft Edge (qualsiasi browser funzionerà purché sia possibile manipolare l'agente utente come descritto di seguito, così come qualsiasi proxy d'attacco come Burp o ZAP).

2. Aprite gliStrumenti per gli sviluppatori (Ctrl+Maiusc+I), fate clic sul menu in alto a destra e selezionate Esegui comando(Ctrl+Maiusc+P):

3. Digitare"condizioni di rete" e premere Invio:

4. Nel cassetto che si apre, deselezionate"Usa il browser predefinito" e incollate la seguente stringa nel campo inferiore:

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

Questa formula Excel di esempio utilizzerà il protocollo Dynamic Data Exchange (DDE) per avviare Calculator. 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, accedere ahttps://portal.azure.come inserire l'e-mail di un account esistente nel sistema di destinazione.

6. Quando viene richiesta una password, inserire una stringa qualsiasi(non è il nostro obiettivo quello di accedere con successo!):
   
    

Far aprire i registri alla vittima

I registri di accesso nel tenant Azure di destinazione contengono ora il record di registro avvelenato (potrebbero essere necessari alcuni minuti per consegnarlo).

A questo punto, è possibile ingegnerizzare l'amministratore di destinazione per fargli aprire i registri. Nel portale sono presenti due servizi che consentono di effettuare questa operazione: Log Analytics e Microsoft Entra ID. Descriviamo il primo.

È sufficiente qualsiasi utente con accesso in lettura ad Azure Log Analytics, quindi non deve essere un amministratore con privilegi di primo livello. 

Sono possibili diversi pretesti. Ad esempio, un"ingegnere del supporto tecnico di Azure" può contattare l'amministratore per richiedere assistenza nell'investigazione di"tentativi di accesso sospetti".

I passaggi sono i seguenti:  

1. Indicare al target di aprireAzure Log Analyticse caricare la tabellaSigninLogsnella finestra della query (facendo doppio clic). Fare clic sul pulsanteEseguiper eseguire la query predefinita:
   
   

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

3. Indicare al target di caricare il log come file CSV in Excel per"facilitare l'analisi":
   
   

4. I registri verranno caricati in Excel. Verrà visualizzato un messaggio di avvertimento che l'utente dovrà ignorare:
   
   

5. Verrà visualizzato un altro messaggio di avviso, che il destinatario dovrà ignorare. Si noti che l'applicazione di cui si lamenta è "MSEXCEL.EXE", che è meno sospetta di qualcosa come "CMD.EXE":  
   

6. L'istanza di Calculator apparirà (proprio come previsto dal nostro payload):
   
   

Potete vedere l'attacco in azione in questo video:

Gestione della protezione DDE di Excel

Questa vulnerabilità non si attiva immediatamente nell'ultima versione aggiornata di MS Excel. Microsoft ha implementato delle mitigazioni per impedire l'avvio del server DDE dalle formule di Excel per impostazione predefinita. Affinché il payload funzioni correttamente, l'obiettivo deve utilizzare una versione precedente di Excel o avere l'avvio del server DDEabilitato nell'ultima versione di Excel (ad esempio, in seguito a istruzioni dell'aggressore nell'ambito della fase di social engineering).

Per disattivare questa protezione in Excel, andare suFile > Opzioni > Centro fiduciario > Impostazioni centro fiduciario... > Contenuto esternoe selezionareAbilita l'avvio del server di scambio dati dinamico (non consigliato):

Oltre il DDE

La limitazione delle chiamate DDE può sembrare che lasci gli utenti al sicuro, ma questa sicurezza è ingannevole. È possibile iniettare 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 comunicato responsabilmente questa vulnerabilità a Microsoft:

2022-09-13 - Segnalato a MSRC
2022-09-21 - MSRC ha risposto: "...la vulnerabilità esiste davvero nel modo in cui Microsoft Excel apre i file. Richiede inoltre di fare clic su un avviso in Microsoft Excel. Potremmo prendere in considerazione la possibilità di bloccare i payload di iniezione CSV come precauzione DND come correzione nelle versioni successive".

Microsoft non sembra essersi impegnata ad apportare modifiche per impedire i payload CSV injection e la vulnerabilità esiste tuttora. 

Mitigazione

Sebbene Microsoft abbia dichiarato correttamente che gli aggiornamenti di sicurezza di Excel impediscono l'attivazione di payload DDE, ci sono diversi altri fattori da considerare:

• La vittima potrebbe avere installato una versione vecchia e non aggiornata di Excel o essere stata sottoposta a social engineering per abbandonare le difese. Abbiamo illustrato uno scenario di questo tipo sopra.

• In Excel esistono formule non-DDE che potrebbero essere pericolose. Ne abbiamo illustrato diversi esempi. Inoltre, Microsoft sta aggiungendo nuovefunzionalità Python alle formule di Excel e l'invocazione di codice Python tramite iniezione può portare a nuove conseguenze inaspettate.  

• Altre applicazioni potrebbero aprire i file CSV, dando luogo a nuovi exploit. Ad esempio, su Linux, LibreOffice è una popolare suite per ufficio che viene utilizzata per aprire i file CSV. Esegue formule di Excel e supporta anche DDE.

• Infine, è importante praticare la "difesa in profondità". Sarebbe coerente con questa pratica non solo affidarsi a una correzione di Excel, ma anche eliminare la possibilità di iniezione di formule alla fonte nei 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 questo momento, si consiglia agli utenti di Azure di aggiornare completamente tutti gli strumenti che utilizzano per aprire i file CSV e di educare il personale IT sui pericoli dei payload dannosi nei log di Azure e sugli attacchi di social engineering che possono tentare di sfruttarli.

Per discutere di questo blog post e di altri argomenti, contattateci direttamente nella community di comunitàVectra AI Reddit.