A partire da quest’anno, finalmente, è stata introdotto l’utilizzo della fatturazione elettronica verso tutti. Avendo lavorato allo sviluppo e l’implementazione di tutte le soluzioni software necessarie per un mio cliente (che gestisce uno studio di commercialisti), ho potuto vedere come molte aziende sono andate in panico per quella che è in realtà una novità bella, utile ed ecologica.
Ovviamente il formato delle fatture elettroniche è documentato, aperto e standard, per consentire a tutti quanti di creare software che permetta di generare fatture elettroniche, nonché visualizzare e importare quelle prodotte da altri. Esistono anche diversi siti web che forniscono un servizio di visualizzatore online per fatture elettroniche.
Una caratteristica interessante della fattura elettronica è il fatto che il formato consente l’inserimento di allegati, tramite l’uso di specifici tag XML e la codifica in base64 del documento allegato. Molti gestionali usano questa possibilità per inserire una rappresentazione in PDF dentro alla fattura elettronica XML. Si tratta della vecchia fattura “cartacea” digitale, più semplice da leggere ma senza valore legale.
Questo si traduce, dentro al file XML, in un codice simile a questo:
<Allegati>
<NomeAttachment>documento.pdf</NomeAttachment>
<Attachment>
JVBERi0xLjcKJeLjz9MNCjIgMCBvYmoKPDwvQ291bnQgMSAvS2lkcyBbMSAwIFJdIC9UeXBlIC9QYWdl
cyA+PgplbmRvYmoKCjUgMCBvYmoKPDwvTGVuZ3RoIDQgL1JlYWRkbGVQYWdlQmFja2dyb3VuZENvbnRl
bnRTdHJlYW0gPDw+PiA+PnN0cmVhbQpxClEKCmVuZHN0cmVhbQplbmRvYmoKCjQgMCBvYmoKPDwvUHJv
Y1NldCBbL1BERiAvVGV4dF0gPj4KZW5kb2JqCgoxIDAgb2JqCjw8L0NvbnRlbnRzIFs1IDAgUl0gL0Ny
b3BCb3ggWzAgMCA2MTIgNzkyXSAvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXSAvUGFyZW50IDIgMCBSIC9S
ZWFkZGxlUGFwZXJJbmZvIDw8L0NvbG9ySWQgL1doaXRlIC9TdHlsZUlkIC9CbGFuayA+PiAvUmVzb3Vy
Y2VzIDQgMCBSIC9Sb3RhdGUgMCAvVHlwZSAvUGFnZSA+PgplbmRvYmoKCjMgMCBvYmoKPDwvUGFnZXMg
MiAwIFIgL1R5cGUgL0NhdGFsb2cgPj4KZW5kb2JqCgo2IDAgb2JqCjw8L0NyZWF0aW9uRGF0ZSAoRDoy
MDE5MDExOTIzMTIzOCswMScwMCcpIC9Nb2REYXRlIChEOjIwMTkwMTE5MjMxMjM4KzAxJzAwJykgL1By
b2R1Y2VyIChQREYgRXhwZXJ0IDIuNC4yMSBNYWMpID4+CmVuZG9iagoKNyAwIG9iago8PC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlIC9JRCBbPGM5NmM5NTBhZGJmZDY1OTE4Y2E0ZTVjNmNhNzVmOGE5PiA8Yzk2Yzk1
MGFkYmZkNjU5MThjYTRlNWM2Y2E3NWY4YTk+XSAvSW5kZXggWzEgN10gL0luZm8gNiAwIFIgL0xlbmd0
aCAzNyAvUm9vdCAzIDAgUiAvU2l6ZSA4IC9UeXBlIC9YUmVmIC9XIFsxIDQgNF0gPj5zdHJlYW0KeJxj
ZGBguAjEDIxALABlME6GiSyDMTxhUkegDCY3EAMAc7sDeQplbmRzdHJlYW0KZW5kb2JqCgoKJSBQREYg
RXhwZXJ0IDYwOSBNYWMgT1MgRG1nIDhiMTQ2ZWU0NzQyOSsKCnN0YXJ0eHJlZgo1ODIKJSVFT0YK
</Attachment>
</Allegati>
Questo esempio può sembrare artificiale, ma in realtà la rappresentazione in base64 scritta qui sopra contiene un vero file PDF, con una sola pagina bianca completamente vuota in formato Letter. Naturalmente un documento con del testo occuperebbe più spazio.
Come potete notare, viene anche indicato il nome del file allegato.
I visualizzatori online
Perché vi ho spiegato tutti questi dettagli sugli allegati alle fatture elettroniche? È presto detto: mi era stato chiesto di cercare un visualizzatore che potesse mostrare agevolmente gli allegati. Tra i primi che ho trovato ce n’erano due:
Provando entrambi i servizi con una fattura contenente allegati, ho potuto verificare che tutti e due i siti (scritti in PHP) funzionavano nello stesso modo:
- L’utente carica un file XML
- Il sito lo riceve e ne crea una copia in una directory temporanea
- Il sito controlla la presenza di eventuali allegati, se presenti estrae anch’essi con il nome originale
- All’utente viene permesso di visualizzare graficamente il contenuto della fattura, con i link agli eventuali allegati
Nel caso in cui leggere il punto 3 non vi abbia fatti trasalire, sentendo un forte brivido corrervi lungo la schiena, posso dirvi che mi auguro non lavoriate nell’industria dello sviluppo software. Se invece lo fate, vi chiedo di rileggerlo un paio di volte.
La vulnerabilità
Permettere ad un utente di caricare dei file non è di per sé pericoloso, posto che vengano prese le misure di sicurezza necessarie. Tuttavia i siti analizzati effettuavano dei controlli sulla fattura XML ma non sugli allegati. Questo significa che era possibile creare una fattura (vera o finta, non ha importanza) con allegato un file con estensione PHP, il linguaggio più comunemente usato per programmare siti web.
I siti stessi estraevano i file PHP dagli allegati e li copiavano nella rispettiva directory temporanea, fornendone poi l’URL all’utente. Al malintenzionato di turno sarebbe bastato quindi inserire del codice malevolo per poi effettuare vari tipi di operazioni.
Per fare un test rivelatore ma innocuo, ho creato una fattura la cui sezione degli allegati è la seguente:
<Allegati>
<NomeAttachment>wowowowo.php</NomeAttachment>
<Attachment>PD9waHAgcGhwaW5mbygpOw==</Attachment>
</Allegati>
Potete visualizzare il documento completo cliccando qui. Il contenuto codificato corrisponde al seguente programma:
<?php phpinfo();
Si tratta di uno script inerte, che non arreca nessun tipo di danno al server sul quale viene eseguito, ma mostra soltanto le informazioni sulla versione del software installato. Perciò consente in modo semplice di verificare se il codice PHP gira correttamente.
Entrambi i siti summenzionati hanno accettato senza problemi la mia fattura emessa da Paperino a Zio Paperone, estraendo l’allegato in PHP e fornendone l’URL. Dagli screenshot potete vedere chiaramente che il codice veniva eseguito:
In realtà, pur avendo eseguito un codice assolutamente innocuo e privo di conseguenze, se io fossi stato un malintenzionato avrei potenzialmente potuto fare molto peggio. Per esempio, un attaccante avrebbe potuto decidere di caricare un file manager in PHP come questo su uno dei siti e usarlo per:
- Modificare il visualizzatore di fatture affinché salvasse una copia di ogni file caricato
- Alterare la pagina di login, in modo che le credenziali inserite dagli utenti finissero nelle mani sbagliate
- Creare pagine in una posizione qualsiasi del sito e usarle per una campagna di phishing
- Cancellare completamente tutto il sito web
No, non sto esagerando.
Conclusione
Quando si sviluppa del software, specialmente le applicazioni web esposte all’utilizzo indiscriminato di migliaia di utenti, prestare la massima attenzione alla sicurezza è assolutamente imprescindibile. In questo caso sussisteva un rischio per i dati caricati dagli utenti, nonché per i contenuti stessi del sito web che avrebbero potuto essere alterati o eliminati.
Il rischio dato dalla possibilità di upload di file da parte degli utenti si può eliminare in diversi modi:
- Inserendo una whitelist di estensioni consentite (ad esempio PDF, JPG)
- Disattivando l’esecuzione degli script nella directory di destinazione degli upload, in tal caso visitare un file PHP avrebbe mostrato il codice senza eseguirlo
- Nel caso degli allegati di fatture, optando per non estrarli e ripresentarli all’utente tramite data URL (non tutti i formati sono consentiti, ma quelli ai file PDF sì)
Ovviamente i gestori di entrambi i siti web sono stati preventimente informati del problema ed è stato dato loro modo di correggerlo prima che questo articolo venisse pubblicato. L’autore di AmministrazioniComunali.it ha risposto con estrema prontezza comunicandomi di aver chiuso la falla.
Da quanto ho potuto vedere, tutti e due i siti hanno optato per la whitelist, che è un’ottima soluzione.
Come considerazione finale, aggiungo che prima di scrivere questo post ho verificato che anche Ser.Val. ha risolto la falla segnalata, anche se non avevo ricevuto risposta. Risulta degno di nota il fatto che sul loro server la pagina di informazioni mostrava la presenza di PHP versione 5.6, che è quantomeno bizzarro. Come avevo già avuto modo di commentare su Facebook, PHP 5.6 è una versione fuori supporto dal 31 dicembre 2018 e sarebbe bene migrare prontamente ad una versione più recente, nello specifico PHP 7.2 o 7.3.
Come già scrivevo in questo post di due mesi fa, è bene che chi opera in questo settore prenda sul serio l’importanza della sicurezza informatica. Eventualmente facendo anche analizzare la propria infrastruttura software da un consulente esterno.
Cronologia della responsible disclosure
- 11 gennaio 2019: scorgo la presenza di una potenziale vulnerabilità
- 13 gennaio 2019: notifico i gestori dei due siti web coinvolti
- 14 gennaio 2019: AmministrazioniComunali.it risponde confermando di aver risolto il problema
- 16 gennaio 2019: mi accorgo che anche Ser.Val. ha modificato il sito, senza però rispondere
- 20 gennaio 2019: pubblico questo articolo
- 22 gennaio 2019: Ser.Val. risponde confermando di aver risolto il problema ed effettuato una verifica interna per verificare eventuali data breach, ai sensi del GDPR
Aggiornamento del 22 gennaio 2019: Ser.Val. ha risposto alla mia segnalazione dopo la pubblicazione di questo post, ringraziandomi e descrivendo le contromisure che hanno adottato. Il contenuto del post è stato modificato per tenere conto di questa risposta.
Mi piace:
Mi piace Caricamento...
