Transcript 19.03.2014_buratti

CMS Hacking
Analisi del rischio di utilizzo di applicazioni di terze parti
Gabriele Buratti
www.isc2chapter-italy.it
Agenda
• Definizione di CMS
• Rischi e tendenze
(e le ragioni di ciò)
• Attacchi recenti
• Perchè è così pericoloso?
• I dettagli
– Una campagna di attacco
– Attacco industrializzato
• Pretendere la sicurezza
• Demo
2
Today’s Speaker:
Gabriele Buratti
• Principal Security Engineer
@Imperva
• Fotografo
• Utilizzatore di WordPress
e Mambo/Joomla
• Programmatore PHP
“copia&incolla” 
3
Definizione di CMS
Content Management System
4
Cos’è un CMS?
Un
Content
Management
System,
in
acronimo
CMS,
(in italiano sistema di gestione dei contenuti), è uno
strumento software, installato su un server web, il cui compito è
facilitare la gestione dei contenuti di siti web, svincolando il
webmaster da conoscenze tecniche specifiche di programmazione
Web.
Source: http://it.wikipedia.org/wiki/Content_Management_System
5
Distribuzione dell’installato
Source: http://trends.builtwith.com/cms
6
Ma anche…
Il sito “CMS Matrix” elenca 1276 prodotti definiti come CMS,
incluso “Zu Pippino”.
The CMS which deserves respect.
Source: http://www.cmsmatrix.org
7
Utilizzo nella grande impresa
8
Rischi e tendenze
(e le ragioni di ciò)
9
OWASP Top 10 – 2013 Update
Nuovo, A9 – Utilizzo di componenti con vulnerabilità
note
10
Terze parti
Secondo Veracode:
– “Il 70% del codice sviluppato internamente ha
origine al di fuori del team di sviluppo”
– Il 28% delle applicazioni censite sono identificate
come create da una terza parte
11
Quando una terza parte invita
i suoi amici
• Più del 20% dei 50 plugin di WordPress più popolari è affetto da
vulnerabilità
• 7 dei 10 e-commerce plugin più popolari sono vulnerabili a comuni
attacchi web
-- Checkmarx Ltd. research lab “The Security State of WordPress’ Top 50 Plugins” white paper, June 18, 2013
Non puoi “sistemare” il codice che non possiedi,
anche se è suoi tuoi server.
12
Superficie d’attacco
In una ricerca condotta da BSI in Germania, ~20% delle vulnerabiltà
rilevate risiede nel core del CMS, ~80% in plugin ed estensioni.
Source: https://www.bsi.bund.de/DE/Publikationen/Studien/CMS/Studie_CMS.html
BSI is Germany's federal office for information security
13
Anatomia di un sito WordPress
• 238.402 linee di codice
–
–
–
–
212.241 WordPress core
24.049 plugins (10)

2089 theme

23 codice custom

9 core developers (+ contributors) *
1 sviluppatore per plugin
1 sviluppatore
Io!
• Manca un 2° paio di occhi
• Binari morti
• Lento processo di patching
* Source: http://make.wordpress.org/core/handbook/project-organization/
14
Come prevengo ciò?*
[the OWASP way]
Un’opzione è quella di non utilizzare componenti che non avete scritto voi.
Ma non è molto realistica. Molti sviluppatori di componenti non creano
patch per le vecchie versioni. Invece, la maggior parte risolve i problemi nelle
nuove versioni. Aggiornare a queste versioni diventa critico.
I progetti software dovrebbero avere un processo in grado di:
1) Identificare tutte le componenti e le versioni in uso.
2) Monitorare la sicurezza di questi componenti nei database pubblici,
mailing list di progetto, e tenerli aggiornati.
3) Stabilire policy di sicurezza che governino l’utilizzo di componenti.
4) Aggiungere “security wrappers” ove appropriato.
Punti 1,2,3 in una parola: Patching !
* Source: OWASP Top 10 2013
15
Patching WordPress
WordPress è molto semplice da aggiornare. Ciononostante, molti siti girano
ancora su vecchie versioni
Source:
http://www.wordpress.org/about/stats/
16
Virtual Patching
• 193 Giorni: Tempo medio di fix delle vulnerabilità*
Vulnerability
found
Code fix developed and tested
System
protected
• Il Virtual Patching ci consente di ridurre la finestra di esposizione da
193 giorni a 0-5 giorni.
Vulnerability
found
*
Virtual
Patch
WhiteHat Website Security Statistics Report, May 2013
System protected
Perchè è così pericoloso?
18
Hacking “classico”
Attacco a sito singolo
Hacking
Information Gathering
Trial and error
Gaining Access
«Do things»
Clearing Tracks
19
Hacking “classico”
Attacco a molti siti
20
CMS Hacking
Attacco rivolto a CMS
Hacking
Identify vulnerability
Gain access
«Do things»
Confidential
21
Attacchi recenti
22
Attacchi attraverso codice
di terze parti
Intrusione via componente di terze parti nei server di Drupal.org.
23
Attacchi attraverso codice
di terze parti
Dati dei clienti compromessi a causa di un servizio di terze parti.
24
Attacchi attraverso codice
di terze parti
L’attacco a Yahoo dettagliato nel January HII report di Imperva.
HII Report: http://www.imperva.com/docs/HII_Lessons_Learned_From_the_Yahoo_Hack.pdf
25
Attacchi relativi a CMS
26
Attacchi relativi a CMS
27
Attacchi relativi a CMS
Source:
http://punto-informatico.it
28
Bersagli speciali
Source:
http://www.zone-h.org
29
I dettagli
Aspetti di una campagna d’attacco a CMS
30
Nel mirino dell’attaccante
Controllo del server
•
•
Per le risorse
Per la visibilità
Furto di dati
31
Hacking massivo di CMS
Step 1: Trovare una vulnerabilità nel CMS
Source: www.exploit-db.com
I database pubblici che raccolgono le vulnerabilità contengono
migliaia di record relativi ai CMS.
32
CMS Gone Wild(card)
Step 2: Identificare una fingerprint in un sito basato su CMS
La fingerprint può essere
• Immagine
• URL
• Tag
• Object Reference
• Risposta a una query
• etc..
33
Fingerprinted
Tag based
Il codice generalmente contiene fingerprint del CMS in uso (a meno che
non siano offuscate).
34
Fingerprinted
Basate su URL
L’interfaccia di amministrazione esposta facilita il rilevamento del CMS e
consente i tentativi di login
35
Google Dork per le masse
• Query: inurl:(wp-config.conf | wp-config.txt | wp-config.php.bak) ext:(conf
| txt | config | bak)
• Risutati: 53.000
36
Google Dork per le masse
In questo caso: Database Host, User e Password esposti
37
Botnet a caccia del vostro CMS
Osservazioni recenti:
– Le Botnet scansionano i
siti web alla ricerca di
vulnerabilità
– Iniettano codice nei siti
vulnerabili
– I sistemi infettati
diventano parte della
Botnet (Zombie)
38
Comunicazioni di una Botnet
Google Dork
L’operatore della Botnet utilizza
gli zombie per scansionare altri
siti
* As observed by Imperva’s ADC Research Team
39
Comunicazioni di una Botnet
La Botnet utilizza le vulnerabilità
e assorbe i server attaccati
* As observed by Imperva’s ADC Research Team
40
Pretendere la sicurezza
Mettere in sicurezza le applicazioni di terze parti
41
Analisi della superficie d’attacco
Alcune vulnerabilità possono essere bloccate solo dai Web Application Firewall.
Graphics Source: https://www.bsi.bund.de/DE/Publikationen/Studien/CMS/Studie_CMS.html
BSI is Germany's federal office for information security
42
Raccomandazioni
Di solito quando un’azienda costruisce la propria policy di
sicurezza non tiene in conto gli elementi che non sono in
controllo diretto, che sono quelli che alla fine creano i
problemi.
Le aziende dovrebbero:
• Implementare policy che tengano in considerazione sia gli
aspetti legali che quelli tecnici di controllo degli accessi e
dell’utilizzo dei dati.
• Richiedere che le componenti di terze parti aderiscano alla
propria policy. Implementare i controlli.
• Pensare «dati di business» al posto di «quel server»
– Considerare l’introduzione di un Database Activity Monitor
– Considerare l’introduzione di un File Activity Monitor
• Monitorare.
43
43
Raccomandazioni tecniche
• Presupporre che il codice di terze parti – che arrivi da
partner, vendor, fusioni, acquisizioni- contenga serie
vulnerabilità
• Pentest prima della messa in produzione per identificare le
vulnerabilità
• Anteporre un WAF alle applicazioni in modo da:
– Fare Virtual Patching integrandosi con gli strumenti di
pentesting
– Mitigare i nuovi rischi (sconosciuti al momento del pentest)
– Mitigare i problemi non evidenziati dal pentest
– Utilizzare il cloud WAF per le applicazioni in hosting/housing
remoto
• Fare Virtual Patching dei nuovi CVE
– Richiede un robusto servizio di aggiornamento
44
44
Demo
Hackers vs WordPress
45
Demo di attacco (e di difesa)
Hacker
WordPress powered
website
Brute force + XSS injection
Malware
download
Victim
46
Confidential
47
The attack
The
atta
ck
Considerazioni
• Questo NON è un attacco automatizzato
• E’ un attacco misto, in parte logico (il brute force usando il
dizionario), in parte tecnico (cross-site scripting)
• Entrambe le parti possono essere automatizzate
– 3 secondi per 500 password = 5 minuti per 50000 password
– Ricerca del plugin e seguente iniezione di codice possono essere
automatizzate
• Ottenere l’accesso come amministratore non è l’unico
modo per piantare un XSS. WordPress 3.6.1 non aveva
vulnerabilità conosciute al momento della registrazione.
48
The defense
The defense
Confidential
49
“Firewall e Intrusion Prevention System non forniscono
sufficiente protezione alla maggior parte dei siti web e
delle applicazioni web business critical. [In questo
documento] spieghiamo come i Web Application
Firewall (WAF) aiutino i responsabili della sicurezza a
proteggere le applicazioni web della loro
organizzazione.”
Web Application Firewalls Are Worth the Investment for
Enterprises, Gartner, Feb 28 2014.
Grazie
[email protected]
51