Articoli della categoria 'Sicurezza'

DECT, security through obscurity e i meravigliosi talk del CCC

01 Gennaio 2009 | Pubblicato in: Sicurezza, Telefonia

Fidarsi della sicurezza di prodotti “completamente chiusi” nel tempo √® risultata una scelta, spesso, disastrosa: anche per questa ragione la rete Mynet, sebbene basata anche su prodotti di vendor che non rilasciano il sorgente dei propri software, si avvale di quelli che abbracciano “security best practices” ben delineate e cercano, dove possibile, di onorare il naturale e salutare (dal punto di vista della sicurezza informatica) ecosistema nel campo dell’IT e dell’intranetworking.

Logo DECT

DECT √® un maturo standard di telefonia cordless: √® stato proposto come la risoluzione definitiva ai problemi di sicurezza in questo campo (oltre a quelli di interoperabilit√† e di qualit√† della fonia) rispetto a sistemi precedenti e non standardizzati che trasmettevano la fonia in modulazione di frequenza e la segnalazione in banda, facilmente intercettabili e banalmente utilizzabili come vettori per effettuare frodi. Il sistema DECT basa la sua sicurezza su un sistema di autenticazione denominato DSAA e su un cipher denominato DSC. Etrambi i sistemi di sicurezza vengono ceduti dall’ETSI (similmente ai “segreti” dell’UMTS e del GSM) solo attraverso una NDA che perentoriamente vieta al firmatario la diffusione del dettaglio degli stessi. Al CCC Communication Congress Andreas Schuler, Erik Tews, Ralf-Philipp Weinmann hanno presentato un paper sulla sicurezza DECT, delineando quanto segue:

  • Sniffare il protocollo DECT attraverso USRP √® possibile, ma assolutamente non “tecnicamente comodo”
  • Sniffare il protocollo DECT attraverso una scheda PCMCIA “Com-On-Air” √® risultata la via migliore: con duro lavoro √® stato possibile fare ingegneria inversa del driver di Windows per realizzarne uno per Linux, nonch√© analizzare il chip della National che si occupa specificatamente della gestione DECT e ne contiene i “segreti”.
  • Molti telefoni DECT non richiedono nessun tipo di autenticazione con la base. Spesso la crittografia non √® attiva. I telefoni accettano di essere redirezionati (handover) su una base senza crittografia anche se la telefonata in corso, prima dell’handover, era di tipo criptato. E’ possibile impersonare le funzionalit√† di una base DECT.
  • Attraverso un duro lavoro di ingegnieria inversa dell’hardware, √® stato possibile derivare una implementazione dell’algoritmo di DSAA, ed √® ipotizzabile creare un attacco con forza bruta, ottimizzabile attraverso hardware dedicato basato su FPGA.
  • Apparentemente contrariamente a quanto richiesto nello NDA, Alcatel Standard El√©ctrica SA di Madrid ha registrato, a met√† anni ‘90, un brevetto (5608802) negli USA che, presentando un sistema di risparmio energetico per il sistema di generazione di numeri pseudocasuali del cipher DECT, ne rivela parzialmente il funzionamento: le informazioni del brevetto unite al lavoro di ingegneria inversa dell’hardware a breve permetteranno di ricostruire completamente l’algoritmo DSC; dalla sua criptoanalisi e (probabilmente) dalle sue vulnerabilit√† (√® un algoritmo non scrutinato dalla comunit√† scientifica), si potrebbe ottenenre la possibilit√† di intercettare anche comunicazioni criptate senza conoscere i seed originari, nonch√© altre interessanti “applicazioni”.

Quanto sopra significa che le comunicazioni telefoniche (e in alcuni casi, non telefoniche, come per i POS DECT, salvo protocolli aggiuntivi di sicurezza) sono da considerarsi assolutamente non confidenziali (ovvero facilmente intercettabili). Inoltre, a breve (quando si affineranno le tecniche di epxloit e l’analisi di sicurezza sul sistema sar√† pi√Ļ completa), diventer√† imperativo, per chi usa reti DECT, implementare un sistema di sicurezza che effettui alerting del traffico anomalo sulle reti DECT aziendali (o limitarne l’uso al solo traffico inbound o anche in uscita ma solo tramite operatore).

ISC BIND e la pazzia umana

24 Agosto 2008 | Pubblicato in: Rete Mynet, Sicurezza

E’ incomprensibile come alla fine del 2008 alcuni (molti!) operatori possano ancora usare come resolver esterno ed interno BIND. Dopo anni e anni di continui bug, spesso disastrosi (come l’ultimo accaduto e previsto da D.J. Bernstein molto tempo fa), solo la pazzia umana pu√≤ giustificare l’utilizzo di BIND come DNS server.

Stessa diagnosi è probabilmente applicabile a chi ha deciso di usare ISC BIND come reference per il proprio DNS server (Microsoft nei prodotti Windows e Cisco nel proprio IOS e derivati).

Mynet impiega da tempo immemore i software “secure by design” di Dan Bernstein, ivi incluso il DNS server (attualmente, una versione modificata di TinyDNS parte di DJBDNS).

Mentre gli altri operatori si “affannavano” (al lettore curioso consiglio di verificare da se se il proprio provider ha provveduto) ad aggiornare i propri DNS server per garantire ai propri clienti che digitare http://www.paypal.com/ equivalesse veramente ad andare sul sito PayPal, il nostro staff sorrideva pensando che avevamo gestito il problema della port randomization molti anni fa.

Anche l’attitudine alla sicurezza proattiva ci rende positivamente diversi: sicuramente il problema di insicurezza intrinseca nel protocollo DNS non √® risolto, ma usare il peggior software in circolazione per dare un dato servizio ai clienti non √® condivisibile. E’ da pazzi, appunto.