Osservatorio sulla sicurezza del Web nella PA Italiana

Vuln Scan di +10.000 siti della pubblica amministrazione italiana.

Padova, Parco della Fenice – Dal 2 al 5 di agosto 2018 è stato ospitato probabilmente il miglior hacker camp italiano di sempre. Durante l’evento ci sono stati molti talk uno dei quali proposto dal mes3hacklab di cui sono membro e dove ho partecipato attivamente come speaker.

Il talk in questione si intitolava: Vuln Scan di +10.000 siti della pubblica amministrazione italiana: Osservatorio sulla sicurezza del Web nella PA Italiana”

Ha inizio la storia

“Sono qui per raccontarvi una storia” così ha cominciato il talk Marco ‘b3rito’ Mehanna, e oggi sono qui per raccontarvi questa storia ma soprattutto per condividere con voi in modo più uniforme i dettagli esposti durante il talk.

Il nostro obiettivo era quello di eseguire un vulnerability scan e analizzarne i risultati.

Ci siamo chiaramente fermati alla sola analisi di vulnerabilità, senza in alcun modo andare oltre (fase di exploitation).

Subdomain Enumeration

Il primo passo è stato quello di enumerare tutti i domini dei comuni italiani. Non è stato semplice in quanto gli stessi non rispettavano un pattern specifico che potessimo seguire e spesso ci siamo trovati davanti a domini che potevano sembrare appartenenti alla PA, ma non lo erano.

Grazie al consiglio di Naif abbiamo usato una lista dei domini comunali italiani, che la stessa PA fornisce pubblicamente sotto forma di open data, evitando così il rischio di andare out of scope.

Una volta ottenuti i domini dovevamo cercare per ciascuno di essi i sottodomini correlati. Per farlo abbiamo testato diversi servizi online ma alla fine abbiamo deciso di concentrarci su Virustotal perché è il servizio che enumera più sottodomini.




In aggiunta abbiamo fatto un bruteforcing manuale di una piccola lista dei sottodomini più comuni per non perderci nessun elemento potenzialmente vulnerabile.

Terminata l’enumerazione dei domini dovevamo eseguire un’operazione di fingerprinting delle tecnologie utilizzate. Volevamo però concentrarci maggiormente sui CMS, visto che è la tecnologia più utilizzata dai comuni.

Abbiamo, con successo, usato diversi tool open source e online per tentare di identificare tali CMS, anche se si sono presentati alcuni falsi positivi.

Il totale è più basso di quanto dichiarato nel titolo del talk, perchè ci siamo concentrati solo su domini e sottodomini dei comuni italiani che utilizzavano un CMS

Qui di seguito il numero dei CMS identificati:

Totale CMS2119
CMS Open96.18%
CMS Closed3.82%

Come potete vedere ci sono molti CMS open source e un numero inferiore di soluzioni proprietarie.

Vulnerability Scan

Una volta completata l’intera identificazione dei CMS, abbiamo deciso di concentrarci sui seguenti 3:

Per la fase di vulnerability scan ci siamo lanciati subito su WordPress e Joomla perché la community open source offriva dei tools già pronti (wpscan e joomscan rispettivamente creati da Sucuri e da OWASP) con un ottimo vulnerability DB alle spalle.

Questi tools sono stati utilizzati per fare enumeration non solo delle versioni dei core ma anche di tutti i plugin identificabili, fornendoci ottimi risultati.

Il terzo CMS che abbiamo preso in esame è stato Drupal che purtroppo non ha a disposizione nessun tool che si appoggi a un vulnerability DB.

Pertanto abbiamo usato svariati tools per l’enumerazione della versione core di drupal ma non siamo riusciti a eseguire l’enumerazione dei plugin (anche per motivi di tempo).

Malgrado non fossimo riusciti a eseguire l’enumeration dei plugin di drupal, le versioni di core risultano comunque molto vulnerabili, soprattutto alle drupalgeddon.

Reporting

Completate tutte le scansioni, abbiamo cercato di raccogliere i dati e presentarli in modo che si potesse percepire la gravità di alcune situazioni.

Qui di seguito il grafico più significativo, che mostra alcune delle vulnerabilità dai noi categorizzate, raccolte dalle nostre scansioni.

Abbiamo diviso in due diverse categorie Remote Code Execution e Remote Command Execution perchè i vulnerability DB le categorizzavano in questo modo. Queste due vulnerabilita sono più comunemente conosciute come RCE

Durante il talk ho analizzato questo grafico da un punto di vista di gravità delle vulnerabilità, cercando di far percepire quando sia il vero livello di rischio, che è più alto di quanto ci si possa aspettare.

Intanto, come potete vedere, la vulnerabilità con il numero di occorrenze più elevato è la SQL Injection, che la OWASP Top 10 definisce come più comune. Questo tipo d’informazione ci ha anche dato confidenza sulla correttezza dei nostri test.

Il linea di massima si potrebbe pensare che Remote Command Execution(312), Remote Code Execution(1148) e Remote File Inclusion(414) siano le più gravi. Questo è vero, ma in questa specifica circostanza ci sono vulnerabilità di pari gravità.

La maggior parte di questi domini è in hosting presso provider, quindi ciò che è veramente importante è che queste macchine contengono solo le informazioni e non un entry point di una LAN su cui fare pivoting. Quindi: vulnerabilità come SQLi(10444), LFI(506), XXE(14) ci possono comunque permettere di ottenere informazioni sensibili potenzialmente contenute all’interno del server.

È innegabile che la gravità delle vulnerabilità appena citate e il livello di accesso che forniscono sia minore di quelle riportate precedentemente ma hanno un cosiddetto business impact molto simile ed elevato.

Un altro fattore di cui ho discusso velocemente sono quelle che io ho chiamato Exploit Chain, riferendomi a dei tipi di exploitation particolare che rendono una privilege escalation grave quanto una RCE.

A questo link è possibile trovare un ottimo esempio di un exploit chain in joomla: https://www.exploit-db.com/exploits/40637/

Questo exploit scritto in python permette di concatenare 3 diverse vulnerabilità per ottenere una reverse shell sul sistema target.

L’exploit nella prima fase utilizza una vulnerabilità di Account Creation per creare un account joomla non privilegiato; successivamente utilizza una seconda vulnerabilità di Privilege Escalation che vi permette di elevare l’utente appena creato al livello di “Administrator” (attenzione: non a SuperUser che in joomla è l’utente più privilegiato). In aggiunta l’exploit, una volta ottenuto il cookie di sessione di questo nuovo utente “Administrator”, cerca anche di caricare un file pht con una reverse shell che in alcune versioni vulnerabili di joomla viene interpretato come un file php.

Una volta lanciato lo script in python, se l’exploitation funziona con successo, siete passati da attaccante con nessun privilegio all’avere una reverse shell con i permessi dell’utente del web server (di solito www-data).

Vorrei specificare che non c’è stato modo di verificare la presenza di queste exploit chain, ma ne esistono diverse, raramente note e pronte all’utilizzo come in questo caso. E’ molto facile trovarsi davanti a una situazione simile se stiamo conducendo un penetration test su un CMS abbastanza vecchio.

Le 3 tabelle seguenti mostrano le versioni dei CMS utilizzati. Sono state comunicate alla PA in un’ottica di responsible disclosure.

CERT-PA li ha successivamente pubblicati sul proprio sito: https://www.cert-pa.it/web/guest/news?id=11043

Drupal

VersionsOccurrencesPercentage for each single version
5.210.83%
6.1010.83%
6.1543.31%
6.1921.65%
6.2232.48%
6.2510.83%
6.2886.61%
6.3010.83%
6.3110.83%
6.3310.83%
6.3575.79%
6.3732.48%
6.3875.79%
7.2110.83%
7.2210.83%
7.2910.83%
7.433125.62%
7.5610.83%
7.5832.48%
7.593932.23%
8.5.043.31%
121100.00%

WordPress

VersionsOccurrencesPercentage for each single version
2.7.110.29%
2.9.210.29%
3.1.110.29%
3.1.210.29%
3.4.110.29%
3.5.151.45%
3.5.210.29%
3.641.16%
3.7.110.29%
3.7.2610.29%
3.8.120.58%
3.8.2620.58%
3.920.58%
4.0.1610.29%
4.0.23195.49%
4.110.29%
4.1.2361.73%
4.2.220.58%
4.2.2041.16%
4.2.310.29%
4.2.410.29%
4.2.510.29%
4.3308.67%
4.3.1672.02%
4.3.210.29%
4.4.130.87%
4.4.1551.45%
4.4.251.45%
4.5.1461.73%
4.5.230.87%
4.5.310.29%
4.5.410.29%
4.610.29%
4.6.120.58%
4.6.1151.45%
4.710.29%
4.7.10185.20%
4.7.210.29%
4.7.361.73%
4.7.410.29%
4.7.541.16%
4.84212.14%
4.8.110.29%
4.8.230.87%
4.8.320.58%
4.8.6257.23%
4.9.110.29%
4.9.3154.34%
4.9.441.16%
4.9.541.16%
4.9.68925.72%
346100.00%

Joomla

VersionsOccurrencesPercentage for each single version
1.0.0122.81%
1.510524.59%
1.5.010.23%
1.5.1530.70%
1.5.220.47%
1.5.910.23%
1.610.23%
2.5.110.23%
2.5.1161.41%
2.5.1320.47%
2.5.1481.87%
2.5.1620.47%
2.5.1771.64%
2.5.1830.70%
2.5.1992.11%
2.5.2010.23%
2.5.2761.41%
2.5.287417.33%
2.5.410.23%
2.5.620.47%
2.5.710.23%
2.5.8143.28%
2.5.9102.34%
3.1.110.23%
3.1.410.23%
3.1.510.23%
3.2.110.23%
3.2.210.23%
3.3.110.23%
3.3.320.47%
3.3.630.70%
3.4.120.47%
3.4.210.23%
3.4.330.70%
3.4.410.23%
3.4.620.47%
3.4.830.70%
3.5.010.23%
3.5.110.23%
3.6.020.47%
3.6.240.94%
3.6.430.70%
3.6.5235.39%
3.7.010.23%
3.7.271.64%
3.7.340.94%
3.7.410.23%
3.7.551.17%
3.8.130.70%
3.8.330.70%
3.8.410.23%
3.8.561.41%
3.8.651.17%
3.8.7307.03%
3.8.8327.49%
427100.00%

L’Osservatorio della Pubblica Amministrazione è un progetto appena iniziato e in via di sviluppo, che speriamo stia veramente aiutando la PA a migliorare la situazione. Periodicamente rieseguiremo le scansioni e pubblicheremo i risultati su un sito liberamente consultabile.

Gli script da noi utilizzati non sono ancora stati resi pubblici per motivi di responsible disclosure.

Per eventuai domande o suggerimenti potete contattarci all’indirizzo info@mes3hacklab.org

Link Talk IHC: https://youtu.be/u5jibHkRzXA

Chi ha partecipato al progetto?

Federico klez Culloca : Uno dei fondatori del mes3hacklab

Marco b3rito Mehanna : Uno dei fondatori del mes3hacklab

David her0 Lana : Co-Fondatore di Knifesec

Edoardo electroxero Novello : Fondatore di Knifesec

Alessio Righetz: Un tizo che gira al mes3hacklab