Security Week 33: porte senza serrature, Microsoft invulnerabile, disassembler e tanto dolore

Benvenuti alla edizione di Security Week di questa settimana. Nel precedetene articolo abbiamo parlato di auto che si bloccano sole, di Stagefright di Android e di come evitare che ci

Benvenuti alla edizione di Security Week di questa settimana. Nel precedetene articolo abbiamo parlato di auto che si bloccano sole, di Stagefright di Android e di come evitare che ci spiino su Internet (ma di fatto continuano a farlo).

security-week-33 

In questo post tratteremo prima di tutto due notizie che non sembrano avere nulla in comune (ma come vedremo non è così): le vulnerabilità spesso scaturiscono dalla negligenza delle persone e dal non voler adottare le misure di sicurezza disponibili. La terza notizia non ha molto a che vedere con la sicurezza, ma tratta piuttosto di alcune relazioni che si stringono all’interno del mondo dell’industria. Tutte e tre le notizie non sono quello che sembrano.

Permettetemi di ricordavi le regole di Security Week: gli editor di Threatpost selezionano tre notizie tra le principali della settimana a cui io aggiungo alcuni paragrafi e commenti. Potete trovare tutti gli articoli cliccando qui.

Hackerando le porte degli hotel

Qui la notizia di Threatpost

Si dice che esiste una dicotomia tra il mondo della scienza e quello delle arti e che gli esperti di queste due discipline difficilmente si capiscono a vicenda. Si è soliti pensare che un intellettuale o umanista non possa trasformarsi in un uomo di scienza o in un ingegnere.

Questo luogo comune viene smentito dal musicista John Wiegand. Noto e prestigioso musicista, si dedica alla musica lavorando come pianista e direttore d’orchestra (anni trenta), fino a quando non inizia a interessarsi al disegno degli amplificatori d’auto. Negli anni quaranta inizia a lavorare su di una delle novità del momento: la registrazione su cassetta. Il 1974 (all’età di 62 anni) è poi l’anno in cui realizza la sua più grande scoperta.

Quello che è noto come interfaccia Wiegand consiste in una serie di cavi magnetici metallici di cobalto in lega di vanadi trattato in modo da formare un tessuto esterno duro attorno ad un nucleo interno morbido. I campi esterni magnetizzano facilmente il guscio, che anch’esso resiste alla smagnetizzazione, persino quando i campi esterno vengono rimossi, una caratteristica chiamata alta coercività. All’interno del cavo ha un comportamento diverso, non si magnetizza fino a quando il guscio raggiunge a pieno la magnetizzazione.

Nel momento in cui la parte esterna del cavo si magnetizza completamente e il nucleo centrale riesce ad ottenere la sua porzione di magnetizzazione, sia il nucleo che il guscio scambiano polarità. Lo scambio genera un voltaggio significativo che può essere sfruttato da applicazioni di rilevamento e movimento; è utile, per esempio, nel caso di certi sistemi di apertura delle porte degli hotel.

A differenza delle moderne schede, gli “zeri e gli uno” non vengono registrati nel chip ma nella sequenza del cablaggio speciale stabilito. È impossibile riprogrammare questo tipo di codici e lo schema generale non è come quello delle moderne schede per il trasporto pubblico o per i pagamenti bancari entrambe di tipo contactless; il sistema è simile alle tessere con banda magnetica, solo più affidabili.

Dobbiamo quindi scartare card contactless? Non ancora! Wiegand non ha dato solo il nome all’effetto, conosciuto come “effetto Wiegand”, ma anche al protocollo di scambio dati – piuttosto vecchio. Tutto quello che riguarda questo protocollo è piuttosto negativo. In primo luogo non è mai stata standardizzato adeguatamente e esistono numerose implementazione dello stesso.

In secondo luogo, l’ID della scheda può immagazzinare 16 bit, offrendo poche combinazioni possibili. In terza istanza, il design di queste schede contactless con cablaggio, che erano state invetate prima che imparassimo a inserire un sistema computerizzano in una carta di credito, restringe la lunghezza della chiave a soli 37bit, motivo per credere che il sistema non accetterà chiavi più lunghe.

Di recente, durante la conferenza Black Hat, i ricercatori Eric Evenchick e Mark Baseggio hanno mostrato al pubblico i loro dispositivi per l’intercettazione delle sequenze di chiavi (non criptate) in fase di autenticazione. Il dato più interessante in questo caso è che le card non avevano nulla da fare dato che l’informazione viene rubata durante la trasmissione dei dati dal lettore delle schede al sistema di controllo delle porte, dove si utilizza storicamente il protocollo di Wiegand.

Il nome del dispositivo è BLEkey, un piccolo hardware che ha bisogno di essere inserito in un lettore di schede, per esempio, come quello usato nelle porte degli hotel. I ricercatori hanno mostrato che l’intera operazione dura pochi secondi. È semplice: leggiamo la chiave, aspettiamo che il vero proprietario esca e apra la porta; oppure non aspettiamo o non apriamo mai la porta. Senza entrare troppo in dettagli tecnici, il dialogo tra la porta e il lettore/wireless si trasforma in una cosa del genere:

“Chi è?”

“Sono io.”

“A sei tu? Entra!”

Sembra facile. Però, come sempre, non tutti i sistemi di controllo di accesso sono vulnerabili a questo genere di attacco. E persino quelli che lo sono, possono essere protetti senza essere totalmente rimpiazzati. Secondo i ricercatori, i lettori hanno alcune misure di sicurezza contro gli hackeraggi ma queste funzionalità sono spesso (ehm…) disabilitate.

Queste sistema supporta persino l’Open Supervised Device Protocol che permette di criptare la sequenza di chiave trasmessa. Ma, ripeto, queste “funzionalità” non vengono usate; non smetterò mai dirlo ma sembra proprio che non adottare le misure di sicurezza sia facile e conveniente.

Infine, c’è un altro studio interessante del 2009 su questo argomento, con molti dettagli tecnici. Apparentemente, le vulnerabilità delle schede (e non dei lettori) siano state scoperte nel 1992, ma poi si suggeriva che la scheda dovesse essere disassemblata e passata ai raggi X. Per farlo dovevano toglierle ai proprietari. Ora la soluzione si trova in un piccolo dispositivo della dimensione di una moneta. Questo è quello che chiamo progresso!

Immunità di Microsoft: gli “altarini aziendali” di Windows Server Update Services

Qui la notizia di Threatpost. La ricerca originale cliccando qui.

Windows Server Update Service permette alle grandi aziende di centralizzare l’installazione degli aggiornamenti sui computer attraverso un server interno piuttosto che via fonte esterna. Si tratta di un sistema piuttosto sicuro e molto affidabile. Per i principianti tutti gli aggiornamento devono essere firmati da Microsoft. In secondo luogo, le comunicazioni tra l’update server dell’azienda e il server del vendor sono criptate via protocollo SSL.

È un sistema piuttosto semplice. Il server aziendale riceve una lista di aggiornamenti come un file XML dove viene infatti indicato quale, dove e come scaricare l’aggiornamento. Pare però che questa comunicazione avviene in plain text. Scusate, ma non è una buona idea comunicare in questo modo. Tutto deve essere essere criptato e quando lo si implementa in WSUS, è fortemente raccomandato abilitare un amministratore per abilitare la crittografia. Ma è disabilitata di default.

In fin dei conti però, non è così terribile perché rimpiazzare le “istruzioni” non è facile, ma se un hacker ha la possibilità di intercettare il traffico (per esempio, via attacco man-in-the-middle) lo farà. I ricercatori Paul Stone and Alex Chapman hanno scoperto che rimpiazzando le istruzioni l’utente potrebbe finir col eseguire un codice arbitrario con alti privilegi sul sistema aggiornato. Microsoft controlla i certificati digitali, ma accetta i certificati di qualsiasi azienda. Per esempio, è possibile introdurre clandestinamente un’utility PsExec da  SysInternals kit e, con con il suo aiuto, lanciare qualsiasi processo.

Perché succedono queste cose? Il punto è abilitare l’SSL utilizzando WSUS non può essere automatizzato dato che si ha bisogno di generare un certificato. Come sottolineano i ricercatori, in questo caso Microsoft non può far alto che abilitare l’SSL. Quindi è un po’ come se ci fosse e al tempo stesso non ci fosse la vulnerabilità. E non c’è nulla che può essere d’aiuto. E la colpa non è di nessuno, se non dell’amministratore.

Kaspersky Lab ha scoperto lo spyware Flame, un’altra minaccia che usava Windows Update per infettare le sue vittime, tuttavia lo faceva in un modo doverso: un proxy falso intercettava le richieste inviate al server di Microsoft e i file di risposta inviati erano un po’ diversi e, di fatto, alcuni erano stati firmati dal vendor.

Ingegneria inversa e dolore

Qui la notizia di Threatpost. Il post originale di Oracle CSO (la cache di Google cache e un’altra copia – Internet non dimentica mai).

Le due presentazioni citate sopra del Black Hat sono relazionate dato che gli autori di questi studi (gli esperti di sicurezza informatica) hanno scoperto falle di sicurezza di molte tecnologie e prodotti sviluppati da qualcun’altro. Hanno pubblicato le loro scoperte e nel caso di BLEKey, hanno anche presentato il codice intero e l’hardware di libero accesso. Questo, in generale, è il modo normale di interagire con il mondo esterno, ma non a tutti piace questa situazione.

Non mi piace dare giudizi quindi dirò solo che si tratta di un argomento molto delicato. È giusto analizzare i codici di altre persone? Sotto quali condizioni è corretto farlo? In che modo dobbiamo rivelare informazioni sulle vulnerabilità? Posso essere pagato per le vulnerabilità che ho scoperto? Restrizioni legislative, codici criminali e leggi non scritte dell’industria, sono tutti elementi che hanno molto peso in questa questione.

Il recente articolo di Mary Ann Davidson, Chief Security Officer di Oracle ha avuto un effetto clamoroso. Si intitolava “No, realmente non puoi” (in inglese No, You Really Can’t“) ed è quasi interamente dedicato ai propri clienti (non all’industria in generale) che hanno inviato informazioni sulle vulnerabilità che avevano trovato nei prodotti.

Vale la pena menzionare il testo del 10 agosto del 2015 pubblicato nel blog di Oracle, ma menziono solo un punto importante: se un cliente potesse imparare a capire come funzionano le vulnerabilità via ingegneria inversa (dato che è l’unico modo), avrebbe violato l’accordo di licenza e perciò sarebbe un errore.

 

Ecco qui il brano dove se ne parla:

Un cliente non può analizzare il codice per vedere se c’è un processo che possa prevenire un attacco annunciato dal tool responsabile della scansione (il che è quasi sempre un falso positivo). Un cliente non può emettere una patch per risolvere il problema, solo il vendor può farlo. Il cliente finirebbe col violare l’accordo di licenza usando uno strumento che di analisi statica (che opera contro il codice sorgente).

La reazione pubblica fu una cosa del genere:

https://twitter.com/nicboul/status/631183093580341248

O così:

O persino così:

Il post non durò che un giorno ed è stato rimosso per via delle “incongruenze con i punti di vista (ufficiali) sull’interazione con i clienti” (ma Internet non dimentica). Ricordiamo che Oracle sviluppa Java e solo i pigri non sfruttano le vulnerabilità di Java. Tre anni fa abbiamo contato le vulnerabilità di Java poer 12 mesi e ne abbiamo trovate 160!

In un mondo ideale, i vendor dei software troverebbero e risolverebbero tutte le vulnerabilità dei propri software, ma purtroppo viviamo nel mondo reale. In questo mondo questo non esiste, anzi quello che spesso accade è che chi muove i fili della trama fanno giusto il contrario.

Ma vediamo l’altro lato della medaglia.

La scorsa settimana il fondatore di Black Hat, Jeff Moss, ha parlato dei vendor di software responsabili delle falle di sicurezza nei propri codici. Ha detto che è  ora di disfarsi di EULA e di tutti quei documenti dove si afferma che l’azienda non ha nessuna responsabilità verso i suoi clienti. La dichiarazione è interessante ma non meno pretenziosa della frase “Va bandito il disassembler”. Al momento c’è solo una cosa chiara: se gli utenti non (aziende e utenti privati), fornitori e ricercatori non possono comprendersi a vicenda  questo non verrà risolto attraverso dichiarazioni e battute su Twitter.

Che altro è successo?

Un’altra presentazione tenutasi durante il Black Hat ha trattato l’hackeraggio di Square Reader, quel dispositivo che permetter il pagamento di una merce con lo smartphone. Richiede saldatura.

È stato trovato un altro rootkit di un vendor nei portatili Lenovo (non tutti, ma in alcuni). La notizia qui.

Oldies

La “piccola” famiglia dei malware

I “virus residenti” in memoria vengono aggiunti alla fine dei file .com (eccetto per i Small-114, -118, -122 che sono scritti all’inizio) quando si  caricano i file nella memoria. La maggior parte dei virus usano comandi POPA e PUSHA con processatori  80×86. Small-132, -149 infetta certi file in modo incorretto. Appartengono a diversi autori. Apparentemente, l’origine della “piccola famiglia” potrebbe essere vista come una gara al virus residente in memoria per MS-DOS più corto. Rimane solo da decidere il premio per il vincitore.

Citazione da: “Computer viruses in MS-DOS” di Eugene Kaspersky, 1992, pp. 45.

Dichiarazione di non responsabilità: questo articolo riflette la persona opinione dell’autore. Può coincidere o no con la posizione di Kaspersky Lab.

 

 

 

Consigli
Iscriviti per ricevere le nostre notizie via e-mail
  • Tutti gli altri paesi