Giornata da dimenticare per gli sviluppatori che lavorano al sito dell'INPS nel giorno dedicato alle richieste delle indennità da 600 euro spettanti ai lavoratori autonomi come bonus di marzo per i mancati guadagni dovuti all’epidemia Covid-19: il sistema non ha retto alle tantissime richieste ricevute e si è comportato in modo anomalo, alternando periodi di "down" alla visualizzazione di pagine contenenti dati personali di altri utenti. Non soltanto un problema tecnico dunque, ma un vero e proprio "data breach" che ha certamente determinato l'accesso non autorizzato a dati particolari (situazione patrimoniale e contributiva) da parte di un numero imprecisato di utenti.
Le dimensioni della fuga di dati non sono ancora rese note, ma l'episodio è stato definito "gravissimo" dal vicepresidente dell'Inps Luisa Gnecchi in un videoforum organizzato dal Sole 24 Ore sul tema: la situazione ha inoltre provocato la reazione immediata dei leader di opposizione, alle cui domande il premier Giuseppe Conte - in un vertice a Palazzo Chigi - ha risposto spiegando che il problema è riconducibile a un attacco hacker (fonte: AdnKronos).
La spiegazione di Conte, per quanto possibile, appare - almeno ad una prima analisi - piuttosto inverosimile: analizzando quello che è stato riportato dai tantissimi utenti che hanno lamentato la problematica sui principali social network, lo spiacevole incidente non sembra affatto legato ad attività esterne e ha tutto l'aspetto di un problema tecnico legato a un errore di configurazione della cache: vediamo perché.
Per prima cosa, cerchiamo di riassumere quello che è accaduto: oggi il sito dell'INPS, preso d'assalto da oltre 100 richieste al secondo, ha cominciato a restituire agli utenti pagine relative ad altre sessioni (ovviamente contenenti dati personali) ad ogni reload.
PER DIO METTETE OFF LINE TUTTO @INPS_it ad ogni reload ho accesso ad una posizione di uno sconosciuto. Seguono screen.@g_bonfiglio @raistolo @quinta @fabiochiusi @rscano @chiaragribaudo
— Andrea Ganduglia (@andreaganduglia) April 1, 2020
La causa di questo "insolito" comportamento è presumibilmente da ricondurre all'errata configurazione di un sistema di cache (reverse proxy o CDN), magari installato proprio in previsione dell'atteso incremento di accessi benché ancora non sufficientemente testato.
Questi sistemi, per dirla in breve, hanno il compito di memorizzare i contenuti richiesti dagli utenti per un certo lasso di tempo e servirli al posto del sito, risparmiando a quest'ultimo il compito di dover rispondere più volte alla stessa richiesta (ne abbiamo parlato diffusamente in questo articolo, e più in generale in vari approfondimenti su NGINX).
Come si può facilmente comprendere, si tratta di un sistema molto efficace quando si ha a che fare con un gran numero di utenti che richiede l'accesso agli stessi contenuti, come ad esempio immagini, home page, news, pagine di presentazione del servizio, FAQ e così via.
Al tempo stesso, però, si tratta di una strategia inadeguata - o per meglio dire insufficiente - quando il gran numero di accessi riguarda contenuti privati, personalizzati ovvero specifici per ciascun utente. In quel caso la cache HTTP, che resta valida per gestire i contenuti comuni a tutti, dovrebbe accompagnarsi ad accorgimenti infrastrutturali basati su scale-up (potenziamento dei server), scale-out (adozione di architetture distribuite) e load balancing (distribuzione del carico): a queste tecniche di scaling e balancing è inoltre spesso opportuno implementare una cache di secondo livello da gestire a livello applicativo, volta a ridurre il carico sui database. In questo modo i contenuti comuni a tutti ("pubblici") vengono messi in cache e restituiti dai proxy, mentre quelli "privati" continuano ad essere gestiti a livello applicativo, sia pure in modo più efficiente, evitando che possano erroneamente finire in cache.
Le informazioni ad oggi note consentono di ipotizzare, con le cautele del caso, che questo pattern non sia stato seguito: i contenuti "privati" dei singoli utenti potrebbero ragionevolmente essere finiti in cache ed essere così serviti anche agli utenti immediatamente successivi, ovviamente al posto delle pagine che avrebbero dovuto contenere i dati di loro proprietà: il data breach potrebbe dunque essere dovuto a un errore di configurazione, grave ma al tempo stesso piuttosto comune quando si mette "sotto reverse proxy" (o sotto CDN) un sito che fa largo uso di richieste AJAX, specie se implementate con framework che gestiscono le XMLHttpRequest ad alto livello (es. JQuery) senza adeguati test.
Se davvero è andata così, è bene precisare che errori di questo tipo, quasi certamente dovuti alla fretta con cui gli operatori IT hanno dovuto lavorare in questo periodo complicato e quindi in una certa misura persino comprensibili, non hanno nulla a che spartire con il volume di traffico o con qualsivoglia attacco hacker: si tratta semplicemente di sviste, solitamente legate alla fretta di portare il lavoro in produzione e alla mancanza del tempo, della possibilità o del personale di svolgere i controlli adeguati.
Alla luce di quanto detto, ci auguriamo che il premier Conte - così come i molti giornali che hanno rilanciato le sue parole - sia in possesso di informazioni più precise a supporto di quanto dichiarato sull'accaduto. Se così non fosse rischieremmo di trovarci di fronte a un'affermazione oltremodo avventata, nonché a un precedente potenzialmente pericoloso: attribuire agli hacker il comportamento anomalo riscontrato oggi sul sito dell'INPS in mancanza di informazioni certe ci sembra un modo piuttosto fuorviante di giustificare una problematica grave, che avrà certamente delle conseguenze di ampio respiro in termini di data protection, oltre ad essere poco rispettoso nei confronti dell'utenza vittima di questo fastidiosissimo data breach.
In questo momento l’#INPS sta compiendo la più grande violazione dei dati personali mai avvenuta in italia. Se compili la domanda vengono fuori i dati di altre persone. Tutto, nome, cognome, indirizzo. Ci sarà la più grande class action d’Italia contro l’Inps. Garantito #INPSdown
— Cathy La Torre ?️? (@catlatorre) April 1, 2020
A scanso di equivoci, precisiamo che la dichiarazione, così come è stata fatta, non risulterebbe corretta anche nell'ipotesi in cui vi fossero stati attacchi di tipo Denial of Service in parallelo: chiunque lavori nell'IT security e abbia una certa esperienza di siti ad alto traffico sa perfettamente che questi portali subiscono attacchi (manuali e automatici) con cadenza ormai pressoché costante: è del tutto probabile che l'INPS subisca attacchi perimetrali ogni settimana volti a compromettere in vario modo l'operatività del sito, senza che questo abbia nulla a che spartire con la pubblicazione non autorizzata di dati personali. Attendiamo comunque di ricevere maggiori informazioni dall'ente, sperando nella corretta applicazione di quella trasparenza amministrativa più volte promessa dagli ultimi governi e che oggi più che mai ci sembra fondamentale.
