Siete pronti?

Mi sono sempre particolarmente piaciuti i video informativi fatti in questo modo, sia perché sono molto efficaci, con qualche trucchetto, nel veicolare il messaggio sia perché forniscono dati e numeri reali (uno famosissimo è Socialnomics).

Ho scoperto di recente questo sulla storia della sicurezza informatica. Gustatevelo.

Il video è stato realizzato da CommsNet, ma voi, siete pronti?

P.S. Lo sapevate che YouTube consente di usare, come opzione di embedding di un video, una modalità privacy avanzata? Peccato che wordpress.com non sia aggiornatissimo…

In fondo è solo un RFC…

… e solo del 1981! Ma andiamo con ordine.

Qualche giorno fa, il (comatoso) mondo dei firewall è stato scosso dai risultati di un’analisi degli NSS Labs su un gruppo di prodotti recenti.

La storia in realtà è iniziata l’anno scorso, quando due ricercatori di Breaking Point hanno pubblicato un paper in cui, analizzando alcuni apparati, avevano scoperto che utilizzando una tecnica particolare di TCP handshake i firewall si comportavano in maniera strana.

Quei furbacchioni (in senso positivo ovviamente) di NSS hanno pensato bene di inserire questo tipo di test all’interno dei loro report periodici, e hanno scoperto che di questi prodotti analizzati:

  •     Check Point Power-1 11065
  •     Cisco ASA 5585
  •     Fortinet Fortigate 3950
  •     Juniper SRX 5800
  •     Palo Alto Networks PA-4020
  •     SonicWALL NSA E8500

Soltanto uno comprendeva correttamente l’handshake e lo rifiutava, gli altri erano potenzialmente a rischio. Ma, sarebbe da chiedersi, a rischio perché?

Il problema nasce dal fatto che l’RFC prevede, invece che un classico handshake in tre fasi (SYN-SYN/ACK-ACK) uno a quattro fasi, così composto:

    1) A --> B  SYN my sequence number is X
    2) A <-- B  ACK your sequence number is X
    3) A <-- B  SYN my sequence number is Y
    4) A --> B  ACK your sequence number is Y

Iniziare una sessione in questo modo è assolutamente lecito, ma di fatto mai implementato nella realtà. Cosa succede quindi ad un firewall se ha a che fare con questo tipo di handshake? Succede che, come scoperto da NSS, il firewall si “confonde” sullo stato della sessione, e comincia a comportarsi in modo stateless. Questo potrebbe portare il firewall a non applicare i controlli di sicurezza e a non controllare il flusso della sessione. Per esempio un potenziale attaccante potrebbe, una volta fatto collegare ad un proprio server un client di una rete aziendale, eseguire questo attacco e invertire il senso della connessione, avendo potenzialmente accesso alla rete del client. Gli scenari possibili sono facili da prevedere poi…

Vorrei premettere una cosa però, questo tipo di test vale per il solo prodotto firewall, se c’è di mezzo anche un IPS, reale o funzionalità che sia, un handshake a quattro fasi viene bloccato come attacco… a meno che l’IPS non sia in grado di capire il verso della connessione. Molti apparati di intrusion prevention infatti bloccano le possibili minacce analizzando il verso (da fuori a dentro ad esempio). Qualora un attaccante riuscisse, tramite handshake a quattro fasi a confondere il firewall e ad invertire il verso, sarebbe possibile evadere i controlli e inviare il proprio payload a destinazione.

Tornando all’industria, NSS ha pubblicato subito un bel remediation report ma, ovviamente, nel frattempo è successo un casino.

Tutti i produttori si sono sbrigati a dire che o sono immuni (però con quel settaggio…. però con quella funzionalità…) o che ci stanno lavorando: Fortinet, Palo Alto (che dice che l’hanno passato mentre NSS dice che rilasceranno una patch.. mah), SonicWALL e anche StoneSoft, che non era tra quelli testati da NSS per vari motivi… di Juniper ho trovato poco.

In particolare vorrei segnalare che il PSIRT di Cisco ha dimostrato anche qui serietà e prontezza, come nel caso AntiEvasion. Hanno infatti dichiarato che analizzando nel laboratorio la questione non sono riusciti a riprodurla, qui il loro bollettino. Devo fare i complimenti per la chiarezza e la trasparenza.

In conclusione è stato un piccolo fuoco in un settore dell’industria infosec ormai comatoso appunto, perché c’è poco da fare ormai sul prodotto firewall. Lasciando perdere le sparate next/new-gen che sanno molto di marketing e poco di innovazione reale.

Chissà, forse per innovare bisogna tornarsi a leggere le RFC, visto che questo problema, di fatto, non è nemmeno una vulnerabilità!

Per avere ulteriori spiegazioni sul topic vi rimando all’ottimo articolo di Paolo Passeri sul suo blog, e all’analisi di Breaking Point che in effetti spinge a riflettere sul modo in cui vengono testati i firewall, forse troppo lontani dalla realtà. Ulteriori articoli interessanti sono anche quelli di WatchGuard, che suggerisce di farsi da se il test con lo script riportato nella ricerca, e di Technicolor.

Bye!

P.S.: se non avete capito chi sia stato l’unico a passare il test ve lo dico io: Check Point. Per gli addetti al troubleshooting non penso ci sia da stupirsi, visto quanto FW-1 rompe le scatole con il TCP-out-of-state

È tornato il ransomware

Leggevo sul blog del laboratorio di ricerca di F-Secure un’analisi su un recente malware di tipo ransomware. E la trovo molto interessante per parlare questo particolare tipo di software malevolo. Qui di seguito trovate il video in cui il grande Mikko Hyppönen spiega cosa hanno analizzato. Aggiungo solo che questo tipo di malware mi piace parecchio,  perché rende bene l’idea di come ormai ci sia una vera e propria industria criminale dietro questi programmi. Che fa anche un sacco di soldi.

Questi programmi sostanzialmente bloccano o l’intera postazione (come nel caso esposto da F-Secure) oppure criptano alcuni file di sistema e/o documenti dell’utente, come la cartella Documents&Settings ad esempio. Poi ti chiedono un riscatto e, visto che la cifratura è anche a 1024bit, hai da paga’… Potrebbero essere considerati la versione “cattiva” dei Rogue AV. Anzi, nel particolare il caso presentato da F-Secure è davvero un ibrido, visto che non c’è traccia di esplicito ricatto.

Diciamo che i ransomware non sono una novità dell’ultima ora, anzi. I Kaspersky Labs, sempre molto attenti a questo argomento, avevano previsto una nuova ondata per la fine dell’anno scorso, mostrando anche un tipo di malware che addirittura arrivava a rapire il master boot record.

La cosa interessante è che, come dicevo all’inizio, viene dimostrato chiaramente che stiamo di fronte ad atti di criminalità organizzata vera e propria. Perché per preparare una cosa del genere non ci vuole solo un cyber-criminale qualsiasi, ci vogliono: chi programma il software (e deve essere bravo, guardate la grafica..), chi si occupa di affittare i PRN, chi gestisce la botnet per spammare il malware e/o spargerlo in giro… Insomma la situazione è molto complessa.

Ormai da anni, sia nei convegni che negli spazi online, tra i professionisti dell’infosec si parla di questa industria sotterranea, con bilanci da capogiro che hanno poco da invidiare ai traffici criminali considerati normali.

Solo che se sei membro di una botnet non lo sai e non lo vedi, se ti rapiscono i tuoi dati e ti chiedono il pizzo sì. Sarà forse per questo che i ransomware non sono poi così diffusi?

Bye!

Le password sono una cosa seria!

Del Harvey è la responsabile della divisione Trust and Safety di Twitter. Dico subito che trovo il nome del gruppo sicurezza di Twitter fantastico. Rende perfettamente l’idea di un team di persone che lavorano per garantire all’utente (e all’azienda) la migliore e più sicura esperienza possibile. E Twitter del resto non è immune da problemi, anzi

Del ha scritto sul suo blog un articolo molto ben realizzato sull’importanza di avere password sicure e su alcuni consigli. Ho chiesto a Del il permesso di usare e tradurre il suo articolo, con la condizione di dire che ovviamente non è una guida esaustiva e che dovete sempre fare riferimento all’articolo originale per eventuali cambiamenti. E che, aggiungerei io, anche se vi sembrano cose dette e ridette fa sempre bene leggerle.

Parliamo quindi di password.

La sicurezza delle password è super-importante! Questo perché gran parte degli account vengono “craccati” anche perché gli utenti mettono password semplici, e magari usano sempre la stessa per un gran numero di account diversi (12345 anyone?). Qui di seguito proviamo ad elencare una piccola lista di consigli e best practice

NON condividete le vostre password con altre persone. Non importa quanto sia sicura una password: se qualcuno la conosce non lo è più. Se due persone usano lo stesso account, che sia di un servizio web o di un computer, è sbagliato. Fate account diversi.

NON usate una parola che si può trovare in un dizionario (e non usate nemmeno una cosa tipo 123456!!). Usare password complesse può voler dire problemi, ok, ma ci sono prodotti come 1Password o LastPass che le gestiranno per voi. Dategli un’occhiata, dovrete solo ricordarvi una password master. Anche il semplice gestore di password di Firefox può aiutarvi in tal senso, magari con Firefox Sync.

NON usate il nome del partner, o di vostro figlio, o del cane. Sono informazioni reperibili in un attimo sui social network, quindi sono password molto a rischio.

NON inserite le credenziali dopo aver cliccato su link sospetti, magari da email. Controllate sempre le fonti, potrebbero essere phishing. Controllate che il sito sia veramente quello, nel dubbio non entrate, ma usate quello che avete già inserito nei bookmark o scrivetelo voi.

NON usate la stessa password per più siti diversi. Lo so, è molto comodo, ma vuol dire che se viene compromessa quella password, rischiate di perdere tutti i vostri account.

RICORDATE che le domande di sicurezza possono essere una vulnerabilità! Se qualcuno sta cercando di entrare nei vostri account, non sarà un problema per lui sapere in che città siete nati o qual è la vostra squadra del cuore. Per una sicurezza extra mentite nelle domande di sicurezza: siete della Roma? Dite che siete laziali! Magari se usate 1Password o LastPass potete segnarvi qual’era la vostra bugia. Se invece avete la possibilità di scrivervi le vostre domande di sicurezza: siate creativi! Con una ricerca ormai si trova tutto.

SAPPIATE che se utilizzate algoritmi per le vostre password, con una parte fissa e una che cambia a seconda del sito, tipo Google123 o Facebook123, non siete propriamente al sicuro. Perché molto spesso se viene compromessa una password, questa verrà usata anche per entrare su altri siti, provando le opportune modifiche (non è poi così difficile). E poi vi chiederete perché non ho usato password diverse?.

SIGH… dopo tutte queste parole state ancora utilizzando la stessa password su più siti vero? Se proprio non vi va di usare una password diversa per ogni sito, almeno provate a differenziare in base al rischio. Usate la stessa password per siti non importanti per voi, una molto più sicura per i siti che vi interessano e password complesse e diverse per i siti fondamentali: banca, email, facebook, ecc. Ricordate che quelli più importanti non sono solo quelli con i vostri soldi, ma anche quelli con la vostra identità.

SUGGERIMENTO: volete un aiuto su una password non presente in un dizionario ma non volete usare un password manager? Provate un testo di una canzone, prendete le prime iniziali di ogni parola e contraete il tutto. Esempio: Acqua azzura, acqua chiara, con le mani posso finalmente bere! può diventare “Aa,ac,clmpfb!” Ricordate che le maiuscole e i segni di interpunzione possono aumentare di molto la sicurezza di una password. E a volte anche gli spazi bianchi aiutano tantissimo!

Tanto per riepilogare il tutto, Twitter da parecchi consigli su quanto detto, vale la pena leggerli. Per il resto, come sempre nella sicurezza, cercate sempre di usare il buonsenso. E se avete dei dubbi, controllate sempre prima di fare qualsiasi cosa, molto spesso i dubbi sono fondati.

Se volete parlarne, sono qui.

Bye!

Phishingn nelle

Il meglio del Security Summit 2011

Logo Security SummitFinalmente (con un po’ di ritardo devo dire…) sono stati pubblicati gli atti del Security Summit 2011 a Milano.

È possibile quindi procedere con un’analisi degli interventi a cui ho assistito e che ritengo comunque più significativi.

Ricordo che dei keynote avevo già parlato.

Parto subito dalla fine, ovvero dall’evento satellite che ha chiuso le prime due giornate del Summit, l’Hacker Film Festival. Devo dire che è stato senza dubbio lo spazio più piacevole del convegno, sia per l’atmosfera informale che per l’apertura della discussione tra chi presentava i corti e i (pochi, per fortuna) spettatori rimasti. Lo spazio era veramente amichevole e ha permesso di dialogare sulla cultura hacker, sulle problematiche che da anni affrontiamo nel campo delle libertà civili. Il tutto dimenticando per un attimo l’ambito lavorativo e tornando alla passione che, in fondo, ci spinge a fare quello che facciamo. Poter discutere di queste cose con gente come Perri, Ziccardi e i soliti Chiesa/Pennasilico poi, vale sicuramente la fatica di chiudere 12 ore di incontri. E poi offrivano anche l’aperitivo! 🙂

Ma veniamo agli interventi regolari.

Attacchi alle infrastrutture virtuali: l’intervento di Pennasilico/Nencini ha ripreso i concetti di sicurezza dei sistemi virtualizzati di cui si parla praticamente da quando esistono. Rimane tuttavia attuale poiché noto che molto spesso chi si occupa di queste piattaforme, soprattutto dal lato sistemistico, non conosce il rischio derivato dalla possibilità di effettuare un escape from VM (e il link è del 2007). Questo sia per una estrema difficoltà nell’eseguire l’attacco, sia nel fatto che forse (…) i vendor di tecnologie di virtualizzazione tendono a non evidenziare troppo i problemi di sicurezza. Tra virtualizzazione e cloud poi ho apprezzato molto il discutere di come il perimetro attuale che conosciamo (isolato da firewall, ips e quant’altro), abbia ancora senso. La chiave ancora una volta è analizzare e progettare bene le proprie infrastrutture e i propri sistemi. Senza farsi prendere dalla moda del momento (che sia cloud o virtualizzazione o, in molti casi, entrambi) e senza ragionare con schemi ormai antiquati (ad esempio pensare solo a difendere il perimetro o trattare gli host virtuali come se fossero fisici).

Mobile Security: Rischi, Tecnologie, Mercato e Rischi ed opportunità nell’utilizzo degli Smartphones: Raoul Chiesa (in entrambi gli interventi) e Philippe Langlois (solo nel primo) hanno presentato prima una tavola rotonda (molto animata, come sempre quando c’è Raoul) sulla sicurezza dei dispositivi mobili e poi un intervento più mirato al malware. La chiave è stata senza dubbio la comprensione che i principali scopo degli attacchi ai telefonini è il billing. Sia malware che truffe classiche hanno come obiettivo far chiamare la vittima dei PNR (Premium Rate Numbers) da cui trarre grossi profitti. Devo dire che una soluzione possibile, a livello aziendale, per proteggersi è senza dubbio quella di stipulare contratti con gli operatori mobili che non permettano di eseguire queste chiamate. Magari resterà da proteggere i dati e le reti, ma almeno si risparmieranno un po’ di soldi. Il discorso è poi spaziato agli attacchi diretti all’infrastruttura del carrier ma lì, tra Femtocell e SS7 mi sono un po’ perso. Ammetto la mia ignoranza in materia e mi sto già aggiornando…

Application security dal modello tradizionale al Cloud: la presentazione di Riccetti/Gai ha posto enfasi su un argomento che mi interessa particolarmente, ovvero i processi di sviluppo di applicazioni sicure, in ambito cloud computing. In particolare il concetto di secure engineering, quando parliamo di software sicuro, è ancora più attuale se si sta progettando un’applicazione in-the-cloud. Anche se possiamo sparare un insieme di buzzwords (IaaS, PaaS, Private Cloud, ecc.), il punto da tenere a mente è che sono fondamentali ancora una volta un’ottima analisi dei requisiti e una seria progettazione architetturale. Perché possiamo continuare a parlare di parole in aria (o nella nuvola) quanto vogliamo, ma se non vengono recepiti correttamente i requisiti che l’applicazione deve soddisfare, e se non viene progettata in modo sicuro by-design e ragionato, allora i rischi sono tanti: lock-in, loss of governance, data leakage, dos applicativi, ecc. Insomma non bastano i tool e i prodotti, bisogna metterci la testa e non fidarsi mai dei vendor!

Cloud, Security, SaaS, ed altre meraviglie: come uscirne illesi! ancora Alessio Pennasilico e Antonio Ieranò parlano di sicurezza del cloud e degli altri servizi (il tema era molto presente, come prevedibile, durante tutto il Summit). Ancora una volta analisi dei pro e dei contro ma, appunto, ancora una volta viene ripetuto che bisogna fare analisi prima di imbarcarsi in un’impresa che potrebbe solo creare problemi. E non va fatto perché “è di moda“, “quegli altri ce l’hanno” o cose del genere (e si sentono…).

Seminario a cura del Capitolo Italiano di OWASP: oltre al riepilogo delle attività del progetto e del capitolo italiano fatte da Matteo Meucci, c’è stato un’illuminante talk di Giorgio Fedon sui Falsi miti nell’uso dei tool automatici, per l’analisi delle applicazioni web. Illuminante non tanto per chi, come me, è abbastanza conscio delle problematiche dell’analisi delle applicazioni, quanto per una platea generale ed molto vendor-oriented come può essere quella del Summit. E in fatti molti nasi si sono storti, mentre Giorgio parlava… Il succo in sostanza è che un’azienda che ha le risorse per acquistare questo tipo di tool (che costano molto) non può poi limitarsi semplicemente a farli girare ed aspettare i risultati, come se fossero un’enorme lavatrice di vulnerabilità. Deve invece analizzare molto criticamente i risultati che tirano fuori, scremarli con personale addestrato e, comunque, non scordare mai che un code review manuale e un pentest effettuato da specialisti non può essere sostituito da questi strumenti. Le argomentazioni sono senza dubbio interessanti, la mia opinione è che comunque questo tipo di strumenti in una realtà grande non può mancare. Vuoi perché un team di penetration tester non è proprio disponibile sempre, vuoi perché, se implementati con criterio, possono comunque aiutare parecchio. Importante anche il talk di Paolo @thesp0nge Perego, che ha purtroppo annunciato la prossima deadline del progetto Owasp Orizon, e sta quindi ricercando collaboratori. Se potete e volete aiutare, fatelo.

Infrastrutture Critiche vs Cyberthreats: Chiesa e Fabio Guasconi hanno riportato le ultime novità sulle minacce del cyber-warfare, riprendendo un po’ quanto detto da Schneier, e ricollegando il tutto al lavoro svolto dagli enti internazionali per emettere degli standard (ISO 27001 e seguenti) capaci di recepire e normare le procedure da effettuare in ambito sicurezza informatica. Molto interessanti gli argomenti di Raoul, soprattutto sapere che c’è una nazione, l’India, che prevede esplicitamente in una legge di usare tecniche di hacking per difendere le strutture critiche nazionali in caso di cyber attacco. Molto interessante anche la classificazione fatta da Chiesa dei rischi provenienti da determinate nazioni: la Russia è il paradiso dei cyber criminali, mentre dall’Ucraina vengono molte botnet, ecc. E che tutte le principali nazioni “a rischio” hanno comunque precise politiche di cyberwarfare già in essere da più di dieci anni. Considerato questo e considerato che gli hacker più pericolosi individuati dall’Hacker Profiling Project sono proprio quelli militari/governativi non è proprio una situazione in cui stare tranquilli. Soprattutto non stiamo proprio parlando di fantascienza… anche perché il paragone fatto da Chiesa tra armi tradizionali e cyber-armi è stato parecchio inquietante, considerati soprattutto i danni già fatti da queste ultime.

Spero di aver fatto un discreto riassunto delle sessioni più rilevanti, almeno per me.

Tutti gli altri atti sono sul sito e, se ci riesco, sarò anche a giugno al Security Summit Roma Sperando soprattutto che ci siano cose nuove.

Bye!