Atti Convegno Cyber Crime Conference 2018 – Stefano Fratepietro

Casi pratici di Distributed Denial of Service (DDoS): dalla negazione del servizio all’attacco diversivo

Buongiorno a tutti, è un piacere essere qui anche quest’anno; io sono Stefano Fratepietro, mi occupo di sicurezza informatica per Tesla Consulting e indagini digitali. Andrei subito a presentarvi l’agenda di questo intervento: vorrei parlarvi del problema inerente agli attacchi DoS e DDoS, non tanto spiegare cosa siano e cosa facciano questi attacchi ma – per essere un po’ più pratici – raccontarvi quello che è successo nel recente passato (portando ad esempio due casi che fanno anche un po’ sorridere), fare un momento di autocritica e, soprattutto, parlarvi di come si come si possa prevenire e mitigare un determinato attacco in corso. Il tutto senza trattare le tecnologie; non voglio citarvi vendor o soluzioni tecnologiche ma parlare di metodologia, per “sporcarci un po’ le mani”.

Quando parlo di sicurezza informatica, premetto sempre che bisogna parlare di rischio informatico: l’azzardo è qualcosa che potenzialmente potrebbe farvi male, mentre il rischio è la probabilità che quell’azzardo vi faccia del male. Quando vengono fatti progetti o sperimentazioni, critiche o non critiche che siano, paradossalmente nessuno parla di azzardo rispetto al fare o meno una determinata operazione – questo indipendentemente dall’era GDPR – ma tutti parlano di rischio informatico, cioè a cosa potrebbe espormi un determinato contesto operativo. Web Application, portali su internet o qualunque cosa offra direttamente un servizio al pubblico prevedono di rado progetti per la mitigazione di questa tipologia di attacco (parliamo di DoS e DDoS, quindi attacchi distribuiti o da applicazione). Qual è il problema? Che spesso, dal sito internet più semplice alla Web Application più complessa, ci si dimentichi totalmente il rischio più banale: magari facciamo i penetration test, validiamo la nostra applicazione – e ci risulta sicura – però abbiamo completamente sbagliato il dimensionamento dal punto di vista delle richieste di servizio, quindi siamo molto esposti alla possibilità che un attaccante esterno, sovraccaricando la potenza di calcolo a nostra disposizione, ci porti a dover negare il servizio. Dimentichiamo anche che queste tipologie d’attacco potrebbero (uso il condizionale ma è avvenuto nel recente passato) portare problematiche di altro tipo: che siano utilizzati per mascherare l’intento di sferrare attacchi diversi.

Citiamo qualche caso, questo lo avrete sicuramente letto: come non si mitiga assolutamente un attacco DDoS. Intorno alla fine dello scorso anno, il sito internet del quotidiano “Libero” è stato sotto attacco per più di 90 ore. Sono tantissime: pensate alla perdita di introiti pubblicitari o più semplicemente al danno di immagine, aggravato dall’invito all’hacker che Feltri ha voluto fare dalla prima pagina, “Vieni fuori cretino”. Questo – e il video messaggio “Ci vogliono morti” – non ha fatto che peggiorare la situazione: invece di gestire questo incidente con strumenti informatici, mentre il sito era ancora down si sono limitati a fare rumore evidenziando il fatto di essere sotto attacco. Qual è stato il primo errore? Esporre direttamente sulla rete internet l’IP della Web Application: in questo modo a monte non c’è un bastione, o volgarmente una “lavatrice”, che riceve il traffico e non c’è la possibilità di applicare alcun tipo di filtraggio, pertanto se io posso ricevere fino a 1 GB di banda, sovraccaricandola – in questo caso si è sovraccaricata anche la CPU di tutta l’infrastruttura – il sito internet non risponde più ad alcuno stimolo. Altro errore: nel tentativo di mitigare l’attacco hanno applicato una cosiddetta lavatrice, quindi pubblicato il sito internet tramite un Web Application firewall cambiando anche i DNS, ma hanno lasciato il vecchio indirizzo IP pubblico. Quindi, cosa è successo? L’attaccante ha capito che, anche se era stato aggiunto un bastione nel mezzo, l’IP pubblico del web server era rimasto lo stesso; una delle tecniche d’attacco consiste nel riconfigurare i propri DNS ripuntando a quel sito internet per tutti i layer d’attacco. In questo modo l’attacco Ddos è andato avanti – ripeto – per quasi 90 ore, fino a quando a Libero non hanno capito, finalmente, che dovevano cambiare anche l’indirizzo IP del web server. Questo episodio ci dice esattamente come non si deve mitigare un attacco informatico, soprattutto dal punto di vista del rumore mediatico che si è generato.

Un altro attacco molto interessante – e recentissimo, siamo nel 2018 – di cui avrete sicuramente letto è stato quello al sito salvinipremier.com. In questo caso il fine non era il DDoS in sé: l’attacco nascondeva, in realtà, un’attività di data exfiltration (per più di 20 gigabyte) della corrispondenza salvata all’interno della Web application che gestiva tutta la comunicazione con l’elettorato di Salvini. Cosa è successo? Qui ne han fatte veramente di ogni, gli elementi distrattivi sono stati ben due: un post sulla pagina Facebook di Salvini (“Sono gay” e simili) e, contemporaneamente, un attacco Ddos su tutti i portali gestiti dall’azienda che si occupava del web marketing della campagna elettorale, per distrarre le persone impegnate nella mitigazione dell’attacco DDoS: qui il primo errore è stato non pensare che il sito di un politico come Salvini potesse essere attacco da parte di attivisti (un’analisi del rischio completamente sbagliata, ma andiamo avanti). In questo caso si è capito come mitigare il rischio, però nel frattempo è stata sfruttata un’abilità informatica – non pubblica, ma chi è nell’underground sa cosa sia stato utilizzato – che ha permesso la data exfiltration di oltre 20 gigabyte di posta elettronica: un vero e proprio data breach. Se fosse avvenuto dopo il 25 maggio, con le sanzioni del GDPR in vigore, ci sarebbe stato un impatto economico per chi non ha saputo gestire quel rischio, peraltro prevedibile, mappabile ed elevatissimo per qualunque politico, indipendentemente dal colore. In questo caso l’attacco DDoS è stato usato per distrarre, spostare l’attenzione da quello che stava accadendo alla Web Application, ovvero il download di 20 GB di posta elettronica: sicuramente dati personali, trattandosi di corrispondenza, e in alcuni casi – secondo gli analisti – persino dati sensibili. Questo è un altro esempio di come un DDoS possa essere utilizzato per nascondere la reale finalità dell’attacco informatico.

Veniamo ora al momento di autocritica. Un po’ come fossimo dagli Alcolisti Anonimi, lo ammetto: anche io sono stato sotto attacco DDoS. Il mio primo vero attacco DDoS è avvenuto il 31 dicembre su una Web Application che io, erroneamente, non avevo mai considerato critica e mi ha colpito non tanto in termini di impatto sul business – il sito web della mia azienda è un sito vetrina, niente di che – quanto sul piano personale e reputazionale. Il 30 dicembre Anon Plus fece un tweet, pubblicando l’articolo del Resto del Carlino su di me, come una sorta di “dichiarazione di guerra” perché successivamente, la notte fra il 30 e il 31, partì questo attacco DDoS al mio sito; al riguardo restano solo i miei screenshot perché il profilo di Anon Plus (autore anche dell’attacco al sito di Salvini, di cui parlavamo) è stato cancellato da Twitter. Quindi, cosa è successo? Il sito della mia azienda era pubblicato, come tanti altri siti, in WordPress su un host economico, perché l’impatto di un eventuale fermo a livello economico era pari a zero, mentre a livello di immagine il rischio non era stato mappato al momento di progettarlo; qui ne parlo perché credo che, da un punto di vista di problematiche di Cyber Security, dobbiamo fare mea culpa per imparare dai nostri errori e da quelli di chi ci circonda. Più faremo questo più diventeremo bravi a mitigare i rischi e soprattutto porteremo il nostro rischio informatico tendenzialmente verso lo zero (chi vi vende il “rischio zero” è un ciarlatano: il nostro obiettivo è portarlo il più possibile vicino allo zero assoluto, diciamo allo 0,0001%). Com’era strutturato l’attacco? Mirava direttamente al WordPress, quindi non si erano inventati niente di che: hanno mandato in load il web server, che era dimensionato per gestire un massimo di 300 richieste al secondo (e ovviamente ne sono arrivate molte di più). Non è stata sfruttata nessuna vulnerabilità, né di plug in né di WordPress, per cui tante richieste ma tutte abbastanza gestibili. Sostanzialmente si è puntato all’home page, a una news che che ci metteva più del solito a caricare rispetto ad altre: questo è uno dei tipici test che si fanno, si prova una richiesta, si vede il costo computazionale in termini di traffico ed elaborazione da parte del web server e si inviano a catena milioni di richieste. L’errore in quel caso era che il web server non fosse direttamente pubblicato. Nel momento di picco rispetto al traffico quotidiano – che è molto basso perché, ripeto, si tratta di un sito vetrina – si è arrivati a gestire 25 GB di traffico: anche se sono stati gestiti attacchi peggiori al Terabyte (c’è “giurisprudenza” ovunque al riguardo), dover gestire 25 GB di richieste su un web server dimensionato per gestirne neanche un giga rappresenta sicuramente un attacco abbastanza importante.

Qui stiamo mappando come sia possibile prevenire attacchi di tipo DoS e DDoS. Prima di tutto, lo ripeto, non bisogna assolutamente pubblicare l’IP del web server direttamente su internet. L’IP deve rimanere riservato, soprattutto se il progetto parte da zero; se invece il progetto è in corso e da domani volete pensare alla mitigazione del rischio chiedete al vostro provider, pagatelo, ma fatevi dare un nuovo indirizzo IP perché probabilmente, da fonti aperte, in qualche modo è comunque possibile risalire a quell’indirizzo. Utilizzate il sistema che volete – una cache, un Web Application firewall, esistono servizi cloud e non, on premises… – ripeto, non sono qui per parlare di tecnologie; l’importante è che vi facciate mettere, volgarmente, una “lavatrice”, ovvero uno strumento più o meno intelligente che filtri il vostro traffico in caso di necessità, distinguendo le richieste malevole da quelle che non lo sono. Ponetevi anche la domanda: ho veramente bisogno di contenuti dinamici a tutto spiano? dico questo perché un blog o un sito vetrina che pubblicizza news possono tranquillamente essere considerati siti statici; posso avere una base dinamica (come WordPress) per generare i contenuti ma usare poi una qualsiasi altra tecnologia per tradurre quei contenuti in modo statico. Questo è il miglior modo per essere completamente inattaccabili dal punto di vista degli attacchi DoS/DDoS applicativi: rendere la pagina web statica – cioè, per intenderci, non far lavorare i PHP e la parte ASP – vi mette a un livello in cui un attaccante non può far altro che saturare la vostra banda; l’applicazione lavorerà pochissimo perché dall’altra parte il client starà chiedendo una pagina HTML statica. Ma se, in assenza di prevenzione, ci si trova davanti a un attacco di questo tipo, cosa deve fare un sistemista o un Risk Manager? Molto importante: fate una ricerca da fonti OSINT (Open Source Intelligence) per vedere se l’IP pubblico del vostro web server risulti da qualche parte, o perché è stato scritto o perché la stessa web application, per qualche masochistico motivo, lo mostra a fronte di una discovery fatta sul server. Quando questa informazione esce dal perimetro di riservatezza, diventate immediatamente vulnerabili: le tecnologie che avete comprato o messo in produzione non serviranno assolutamente a nulla perché saranno bypassate, a meno che non lavorino a livello di routing geografico.

Per chiudere il mio intervento – come vedete ho cercato di annoiarvi il meno possibile e di essere molto rapido, andando dritto al sodo della questione – dobbiamo assolutamente cambiare tutti modo di lavorare: non siamo più negli anni 2000, non siamo più nella bolla di internet o ai tempi del web master (ormai non esiste nemmeno più questa figura professionale). Gli hacker sono organizzati, i good guys – noi, quindi – assolutamente no. Questo è un serio problema di cultura, di prevenzione e anche manageriale, perché c’è la tendenza di guardare alla spesa al momento di prevenire ma non si pensa mai a quanto si può spendere davanti a una problematica grave: il costo di un Incident Response Team chiamato senza contratto preventivo supera i 1.000,00 € al giorno per l’operatore che viene a risolvervi il cosiddetto “marone informatico”, senza contare i danni in termini reputazionali. Bisogna farsi questi calcoli, ma soprattutto costruire una nuova cultura. Dobbiamo essere più organizzati degli altri, dove per “gli altri” intendo i cattivoni che vivono dei nostri errori: meno errori faremo e meno ci troveremo esposti a rischi come quelli che vi ho fatto vedere.

Grazie a tutti!

Stefano Fratepietro, Esperto di Cyber Security e Digital Forensics