1 / 25

La lumaca e la chiocciola Pavia, 18 novembre 2010

La lumaca e la chiocciola Pavia, 18 novembre 2010. Chi sono. Davide ‘Rebus’ Gabrini Per chi lavoro non è un mistero. Oltre a ciò: Consulente tecnico e Perito forense Docente di sicurezza informatica e computer forensics per Corsisoftware srl Socio istituzionale IISFA

akiko
Download Presentation

La lumaca e la chiocciola Pavia, 18 novembre 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. La lumaca e la chiocciola Pavia, 18 novembre 2010

  2. Chi sono • Davide ‘Rebus’ Gabrini • Per chi lavoro non è un mistero. • Oltre a ciò: • Consulente tecnico e Perito forense • Docente di sicurezza informatica e computer forensics per Corsisoftware srl • Socio istituzionale IISFA • Come vedete non sono qui in divisa 

  3. La catena… 2 R2 R3 R3 3 1 R1 4 Alice Bob

  4. …e i suoi anelli più deboli 2 R2 R3 R3 3 1 R1 4 Alice Bob

  5. Comunicazioni tra i nodi • Tutte le comunicazioni tra i soggetti coinvolti avvengono attraverso protocolli cifrati e strumenti di firma digitale • Anche la connessione tra utente e provider avviene via SMTP/S o via HTTPS (webmail) • L'utilizzo della firma digitale, però, avviene automaticamente solo alla presa in consegna del messaggio da parte dell'ISP • E' possibile per un attaccante, nonostante l'uso di SMTP/S o HTTPS, interferire nella comunicazione tra il mittente e il suo ISP? • Temo proprio di sì, e in diversi modi

  6. SecureSocketLayer • SSL è un protocollodi handshake basatosualgoritmidicrittografiaasimmetrica • Ogniutentepossiedeunacoppiaunivocadichiavi: • unachiavepubblica, chepuòessereconosciutadatutti • unachiaveprivata, tenuta al sicurodalproprietariodimodochesolo luipossautilizzarla • Il funzionamento del sistemadibasasu due proprietàdellacoppiadichiavi: • un messaggiocodificato con unadelle due chiavipuòesseredecodificatosolo e soltanto con l'altra; • non è matematicamentepossibile (o quantomenofattibile) ricavareunachiavedall'altra • …a menodi non avere a disposizionequalchemilionedi computer cheeseguanocalcoli per alcunisecoli…

  7. Esempio • Tuttiipassaggivengonogestitidal PC di Alice e dai server dell'ISP in modotrasparenteall'utente • Se anchequalcunointercettasseiltraffico, non vedrebbemaipassarenessuna password utile a decifrarlo: • la chiavesegretadell'ISP non vienemaicomunicata • la MasterPassword è trasmessa in modoche solo l'ISPpossaleggerla • Se qualcunosisostituisseall'ISP, non potrebbedisporredi un certificatovalido, firmatodauna CA, che lo identifichi come il Provider. Richiesta di comunicazione sicura Certificato ISP (chiave pubblica ISP firmata da CA) MasterPassword scelta da Alice, cifrata con chiave pubblica ISP Messaggio di conferma cifrato con MasterPassword Comunicazione sicura cifrata con MasterPassword ISP Alice

  8. Primo scricchiolio… • L’utente dovrebbe così avere la garanzia di essere collegato con il sito web legittimo, e non con un sito contraffatto • Il certificato SSL del sito dovrebbe infatti garantire anche l’identità del sito stesso • Tuttavia esistono vari tipi di certificati SSL, alcuni dei quali non garantiscono l’identità del titolare del sito web • Per ottenere un certificato DV-SSL(Domain Validated SSL) è sufficiente infatti dimostrare la proprietà del dominio sul quale il certificato verrà installato. La reale identità non è in alcun modo verificata. • Tali certificati sono comunque validi, in quanto provenienti da CA ufficiali e riconosciute dai browser, e possono essere rilasciati persino gratuitamente, per la pacchia di phisher e truffatori 

  9. Per fortuna c’è rimedio… • Naturalmente, esistono anche certificati più sicuri, detti Extended Validation SSL (EV-SSL) che sono rilasciati solo dopo che la CA abbia verificato approfonditamente l’identità del proprietario, proprio al fine di evitare truffe. • I browser però non fanno grosse distinzioni tra i vari tipi di certificato, riconoscendoli entrambi per validi. La barra degli indirizzi potrebbe cambiare colorazione (blu o verde), ma il famigerato lucchetto sarebbe comunque visualizzato, per la tranquillità dell'utente • Un attaccante può quindi non solo creare un sito clone simile a quello della PEC, ma anche renderlo credibile applicando un certificato DV-SSL • il prefisso HTTPS://, l’immagine del lucchetto e l'assenza di allarmi tranquillizzeranno l'utente - che già di suo non è facile agli allarmismi ;-)

  10. …a patto di impiegarlo! • Quindi un servizio web, per difendersi da contraffazioni, dovrebbe basarsi su certificati EV-SSL (sfondo verde), anziché su banali DV-SSL (sfondo blu), giusto? Giusto!

  11. Ok, facciamolo! • Scrivo su Google "DV-SSL" e clicco "Mi sento fortunato" • instantssl.com mi offre un certificato gratuito • Lo prendo! Seguo la procedura proposta sul sito • In pochi minuti ho un certificato SSL valido per il mio dominio tipiloschi.net. Lo installo subito e son pronto! Poi, se fossi un malintenzionato, potrei… • Creare un clone del sito web di un noto servizio PEC • Mandare qualche mail di phishing agli utenti del servizio – magari trovo gli elenchi on-line… • Raccogliere le credenziali di accesso di una parte tristemente consistente di essi • Dedicarmi a ghiotte attivitá illecite quali intercettazione abusiva, alterazione o soppressione delle comunicazioni, furto d’identitá ecc. ecc.

  12. Sito originale

  13. Sito clone

  14. Sito originale

  15. Sito clone

  16. Altrepossibilitá • Sovversione del servizio DNS • cache poisoning, pharming, spoofing… • Compromissione workstation • Come fa un browser a decidere se una CA é autorevole o no? Semplice: conservauna “rubrica” con icertificatipubblicidelle CA • Quindi se un malware riesce a compromettere la rubrica, qualunquerogue CA puódivenirefidata! • …e in generaletutte le veriegatetecnichediattaccogiàimpiegate con successop.e. nel phishing

  17. DalMan in the Middle al Man in the Browser • Il MitB è una tecnica che viene utilizzata dai moderni malware • L’attacco si localizza nello strumento principale usato dall’utente per interagire col mondo: il suo web browser • Infettando e prendendo il controllo di un web browser, il malware può modificare le pagine visualizzate dall’utente, catturare informazioni, persino eseguire operazioni nascoste, ecc… • Il tutto furtivamente, senza che l’utente o l’applicazione web lato server se ne accorgano, utilizzando abusivamente credenziali legittime

  18. Altre possiblità • Come si recupera una password dimenticata? • Ad esempio chiedendo al provider di inviarla in chiaro su una comune casella e-mail non PEC • EH?!! =8-O • Eppure è proprio quello che fa un importante fornitore di PEC – e magari non è l’unico… • Una password che viaggia in chiaro su canali non protetti è un invito a nozze per i malintenzionati…

  19. SPAM & Co. • Le regole tecniche della PEC prevedono comunque la gestione di messaggi di posta elettronica provenienti da indirizzi non PEC, o ad essi destinati • Con questa configurazione, i virus saranno comunque in parte arginati, ma spam e phishing continueranno come sempre(non è previsto dai disciplinari tecnici che i provider debbano filtrarli) • Anzi, un indirizzo PEC offre persino dei vantaggi agli spammer: profilazione, identità del destinatario, persino garanzia formale della consegna  • Anche con una configurazione più restrittiva, nulla impedirebbe ad un bot di inviare spam sfruttando abusivamente un account PEC legittimo

  20. Firma digitale • Per mitigare buona parte di questi problemi, occorre estendere le funzioni PEC con strumenti di firma digitale per gli utenti • Diventa cosí possibile garantire anche l’identificazione certa delle parti e la confidenzialitá dei messaggi • Ora vi sentite sicuri? Fate male ;-)

  21. Meccanismidi firma digitale • I meccanismi di firma sono analoghi a quelli descritti per SSL, in quanto sempre basati su algoritmi di cifratura asimmetrici • Buona parte della sicurezza risiede quindi nella custodia della chiave segreta • Per salvaguardarla, essa puó essere memorizzata su un dispositivo hardware che ne consente l’uso, ma non l’estrazione o l’alterazione (con protezioni sia fisiche che logiche) • Tuttavia il dispositivo viene comunque usato tramite un PC, che é esposto a numerosissime vulnerabilitá!

  22. Eversionedella firma digitale • Il device fisico(la smartcard) é soggetto a sottrazione, utilizzoabusivo, manomissione • Il PIN puóesseresottratto, carpito, intercettato (p.e. con un keylogger) • La workstation puófacilmenteesserecompromessa • milionidibotin tuttoilmondo lo confermano • assenzadi hardening, scarsamanutenzione, policy carenti, usopromiscuo del PC, esposizione verso l’esterno, cattiveabitudinidell’utente, vulnerabilitávarie… • E se l’attaccante fosse l’amministratore?

  23. Eversionedella firma digitale • L’utente, anche per buona fede o scarsa competenza tecnica, puó essere ingannato • Soprattutto, non vede necessariamente ció che sta firmando! • Contenuti dinamici, layer nascosti... • Software di firma compromessi o sostituiti • sostituzione dei documenti • catturadei PIN • utilizziabusivi e nascosti(purché con smartcard inserita – tanto la smartcard non parla…) • Un attacco di questo tipo dápotere di firma • Non c’é perizia calligrafica che tenga…

  24. Conclusioni • La sicurezza assoluta non esiste, ma il grado di sicurezza generale puó essere aumentato in modo da ridurre il rischio • Il processo rimane comunque insicuro perché i PC sono insicuri • La PEC ha valore legale, ma non necessariamente veicola la Veritá • Anche “la firma digitale non dovrebbe essere considerata come una prova non ripudiabile, ma semplicemente come un'evidenza plausibile.”- Ronald L. Rivest

  25. Teniamoci in contatto… • Davide Rebus Gabrini • e-mail: • rebus@mensa.it • davide.gabrini@poliziadistato.it • GPG Public Key: (available on keyserver.linux.it) • www.tipiloschi.net/rebus.asc • KeyID: 0x176560F7 • Instant Messaging: • MSN therebus@hotmail.com • ICQ 115159498 • Yahoo! therebus • Skype therebus • Queste e altre cazzate su http://www.tipiloschi.net

More Related