Congrats Snowden

I didn’t use Microsoft machines when I was in my operational phase, because I couldn’t trust them. Not because I knew that there was a particular back door or anything like that, but because I couldn’t be sure
— Snowden said.

Ora immagino che si sia spulciato una ad una tutte le righe di codice della sua distro preferita. E che abbia compilato la sua distro preferita a mano per essere sicuro che i bit che installava erano quelli del codice che ha ispezionato. E che abbia verificato tutte le righe di codice del compilatore e l’abbia compilato a mano, prima di compilare il resto di tutto l’OS. E che magari abbia usato l’ASSEMBLER per farlo. E che abbia controllato tutto il codice del compilatore ASSEMBLER per farlo. E immagino pure che abbia scelto un’architettura safe, perché vatti a fidare di Intel. Roba risaputa sin dal 1984 (coincidenza? non credo!).

Quello che dice Snowden nel paragrafo citato è molto interessante: ad un certo punto bisogna tracciare una linea. Ma la posizione della linea è un concetto astratto e quella scelta è alquanto farlocca. Fossi nell’NSA comincerei ad inserire vulnerabilità nei compilatori usati da quelli che distribuiscono le distro. Un po’ come hanno fatto in maniera non altrettanto raffinata gli achari cinesi.

-quack

UPDATE: Apple a quanto pare è persino più paranoica e non si fida di Hardware Off-The-Shelf.

Pubblicato mercoledì 23 marzo 2016 alle 5:57 PM - 17 commenti so far
Archiviato in: Privacy, Security, Linux

The network hole

Come ripromessomi, rieccomi qui a prendere nota di come tappare un buco di cui ero consapevole ma che finora ho ignorato visto i rischi relativamente bassi.

Poi è arrivato KeRanger. Gli “espertoni” dicono che non dobbiamo preoccuparci, tanto al massimo sono stati infettati 6500 Mac, e loro – solo per questione fortuita – non erano tra gli sfigati: che peccato!

In realtà dovremmo cominciare a farlo perché là fuori c’è qualcuno intenzionato a colpire la fascia di utenti smaliziata: è un po’ strano, perché colpire utonti di solito è economicamente molto più fattibile, ma è successo. Cioè: a scaricare Transmission dal sito di Transmission e lanciarlo sul Mac avrei potuto anche essere io. Il passo successivo, quello di controllare l’hash dei file per ogni applicazione da installare, è roba da Snowden.

Aspetti negativi: gli antivirus per questo tipo di attacchi basati sulla tempestività SONO INUTILI.

Come mitigare:

  1. installare ed usare qualcosa come QUBE OS, ma anche questo è roba da Snowden.
  2. backup: funziona solo se il backup supporta la history dei file, funzionalità abbastanza comune (lo fa CrashPlan e il backup server di Windows Home Server). Perché se il backup mantiene solo l’ultima copia, potrebbe essere quella già criptata

Un altro aspetto collegato è il fatto che ormai da sempre tutti i miei contenuti, documenti/multimedia/ecc., sono depositati su un server NAS centralizzato, e questi sono accessibili con le stesse credenziali che uso quotidianamente. Da questa riflessione sviluppatasi nel forum è venuto fuori che avere permessi di scrittura su un NAS usando le stesse credenziali è altrettanto pericoloso: un’applicazione malevola potrebbe cancellare tutte le mie foto, criptarle o distruggerle in qualsiasi altra maniera irreparabile. Per questo tipo di evenienza, che copre anche il guasto hardware degli hard-disk, c’è la copertura di CrashPlan online, ma dover scaricare TB di dati non è il massimo della convenienza.

Ieri sono arrivato alla conclusione che avere un unico set di credenziali con permessi di scrittura è nocivo, sbagliato e va risolto: prima meglio che poi. E ieri ho risolto: rimossi i permessi di scrittura a tutti gli utenti interattivi di casa, ovvero gli umani, e assegnati permessi di scrittura solo ad amministratori e bot protetti da password diverse. C’era solo un piccolo problema da superare: Windows non permette di usare due credenziali diverse quando si accede a due share diverse di uno stesso server.

In poche parole, non si può usare Topolino per accedere a \\SERVER\topolino ed usare Paperino per accedere a \\SERVER\paperino. Ora se solo fosse possibile avere due “nomi” per lo stesso “SERVER”, visto che le credenziali sono legate al nome del server, si sarebbe a cavallo.

Questo per fortuna è possibile in un paio di modi:

  • se sul server si usa SAMBA, intesa come l’implementazione Linux/Unix del protocollo SMB, allora è semplicissimo. Basta aggiungere una riga in cima al file di configurazione (smb.conf). Esempio:
    netbios aliases = SERVER TOPOLINO PAPERINO
    Una volta riavviato il servizio nmbd, si può raggiungere il server usando uno qualsiasi dei nomi indicati. Per Windows sembreranno server diversi, quanto basta per assicurarsi la possibilità di usare appunto credenziali diverse.
  • se si tratta di un server Windows o altra roba e se il server Windows ha un indirizzo IP statico, allora basta aggiungere la coppia “indirizzo_IP aliasserver” al file in \WINDOWS\SYSTEM32\etc\drivers\hosts e risolvere la questione (sfortunatamente sul lato client)
  • in ogni altro caso, il consiglio è di passare ad Ubuntu Server 16.04: supporta ZFS nativamente e a tanta bell’altra roba (dieci anni fa, altri tempi)

A questo punto si tratta solo di creare le share con diversi permessi ed il gioco è fatto.

Data la centralizzazione del controllo, il primo metodo è preferibile al secondo, ma in ogni caso dal punto di vista operazionale sono identici.

Alla fine della giornata, se anche facessi girare il malware usando le mie credenziali, il danno sarebbe comunque limitato alla macchina su cui gira. Se anche questa è regolarmente backuppata possiamo veramente “smettere di preoccuparci”.

-quack

Pubblicato sabato 19 marzo 2016 alle 12:19 AM - 55 commenti so far
Archiviato in: Windows, Security, Linux

Accesso Fisico

Siore e siori, Thunderstrike (notizia non molto fresca, ma da reazioni alquanto inquietanti).

Un paio di simpatiche citazioni:

"Since the boot ROM is independent of the operating system, reinstallation of OS X will not remove it. Nor does it depend on anything stored on the disk, so replacing the hard drive has no effect. A hardware in-system-programming device is the only way to restore the stock firmware."

e

"There are neither hardware nor software cryptographic checks at boot time of firmware validity, so once the malicious code has been flashed to the ROM, it controls the system from the very first instruction," Trammell Hudson said. "It could use SMM and other techniques to hide from attempts to detect it."

I soliti “apologisti” sono già al lavoro per spiegarci che Apple ci metterà una pezza, dimenticano – o forse non comprendendo – che si può sempre fare un downgrade attack sui laptop già esistenti (quelli futuri pure, conoscendo i signori di Cupertino).

Poi ci spiegano che purtroppo di fronte all’accesso fisico e l’attacco della evil maid, non si può fare niente. Peccato eh, sono quasi dieci anni che è stato rilasciato Windows Vista e coi computer con TPM è possibile sigillare il sistema quasi completamente (*). Però il TPM era quell’aggeggio che avrebbe consentito a MS la dominazione globale garantendo al tempo stesso che gli utenti sarebbero stati colpiti da un pianoforte entro 30 giorni dall’acquisto.

-quack

(*) La cameriera cattiva potrebbe sostituire il disco di boot, con un disco che emula la schermata del PIN di bitlocker permettendo di memorizzare il segreto da qualche parte, per poi riavviare il PC “normalmente”. Questo assumendo che l’utonto non si accorga della procedura di avvio stranamente insolita… sì, vabbè, come no…

Pubblicato venerdì 23 gennaio 2015 alle 7:22 PM - 8 commenti so far
Archiviato in: Apple, Security

Fingerprints

Sono da sempre stato un big fan di lettori di impronte digitali e ne ho provato in tutte le salse. Devo dire che mi fa piacere che Apple abbia a suo modo messo la tecnologia sotto i riflettori ma sono un po’ deluso dal fatto che l’implementazione scelta sia completamente “noiosa”. Insomma niente di nuovo rispetto a quello che si faceva già da tempo su Windows a parte il fatto di averla integrata nei loro telefoni. Ad esempio: nessuna possibilità di usare le impronte come uno di più multi-factor authentication mechanism che so abbinando PIN + Impronte su uno o più livelli (ti logghi con l’impronta e allora hai accesso ad alcune cose, per avere accesso ad altre cose devi inserire anche il PIN, ecc.).

Poi c’è la finta questione hacker, su cui ovviamente si è spostata l’attenzione dei media. Insomma è possibile copiare un’impronta ma questo si sapeva già da tantissimo tempo. Semmai l’unica cosa deplorevole è che AuthenTec vendeva la sua tecnologia  vantandone fantasiose proprietà “anti-spoofing”, però non dovrebbe essere scandaloso visto che ora il tutto è di proprietà di quelli che “il loro Mac non piglia virus”. Per maggiori dettagli consiglio l’articolo di Ed Bott.

Dal punto di vista implementativo, a voler credere a quello che dicono in Apple e in questo particolare contesto ho pochi dubbi sul fatto che stiano dicendo “il giusto”, le cose son state fatte in maniera corretta. Non viene memorizzata l’immagine dell’impronta ma la sua “trasformata” (hash), l’hash è sigillato dentro un processore cattivo e amen. In pratica l’NSA non può provare che l’impronta sia la stessa senza avere il telefono a disposizione e quindi da questo punto di vista, backdoor a parte, il tutto sembra inattacabile.

API: pare che abbiano deciso di non esporre il sensore all’uso di applicazioni. Sarebbe bastato che lo storage fosse “silosizzato ermeticamente” per ogni app e si sarebbero potute sviluppare applicazioni interessanti. Ad esempio un password manager bluetooth basato su cellulare: io ho infatti abbandonato l’idea del lettore di impronte in quanto una gestione centralizzata delle password richiede un lettore per ogni pc che si usa, cosa estremamente non pratica. Però se il password manager fosse sul cellulare con il lettore di impronte e facesse le sue cosine con il bluetooth o via USB…

…non mi resta che sognare e sperare che in Google copino qualcosa e lo migliorino.

-quack

Pubblicato martedì 24 settembre 2013 alle 5:51 PM - 2 commenti so far
Archiviato in: Privacy, Apple, Security

Virus e teoria dei giochi

Tempo fa pubblicai un link di Adam J. O’Donnell che applicava la Teoria dei Giochi all’analisi del Malware su piattaforma. Il ricercatore aveva prodotto una formula:

(1-p)fv = (1-f)v

p e’ la probabilita’ che un attacco su Windows riesca e chiamiamola efficacia del sistema che comprende difese builtin (ASLR, firewall, valori di default) e aggiuntive (antivirus).

Gli attacchi su Mac sarebbero cominciati quando f (il market share di OSX) avrebbe risolto l’equazione. Il ricercatore all’epoca aveva considerato un valore di efficacia pari all’80% sentenziando che i Mac sarebbero diventati bersagli interessanti qualora la percentuale di market share avesse superato il 16%.

Qualcuno ha provato a giocare con questo valore usando i risultati di un test comparativo di antivirus e pigliando il risultato peggiore (Microsoft Security Essentials, ovvero 93.1%). Viene fuori una percentuale diversa, in grado di giustificare quanto sta accadendo ultimamente. Ovviamente il modello e’ estremamente semplificato (si da lo stesso valore al PC della nonna e a quello delle centrifughe iraniane; non si tiene conto dei costi di acquisizione di conoscenza per bersagliare una piattaforma diversa; ecc.). Ma se la correlazione continuasse ad essere rinforzata, sarebbe la fine per l’ingrediente segreto alla base della sicurezza dei Mac: la polvere magica.

-quack

Pubblicato venerdì 20 aprile 2012 alle 11:46 PM - 9 commenti so far
Archiviato in: Apple, Security