Ultimo video di rev3rse security, molto interessante anche il lato storico rispetto ai cookie.
Si parla di cookie, del GDPR, di come fare tracking utilizzando la cache del browser tramite l’header etag, e di un nuovo meccanismo in via di sviluppo che permette di gestire le sessioni HTTP e via dicendo senza utilizzare i cookie, tramite un supporto hardware crittografico.
Questo meccanismo si chiama Device Bound Session Credentials (DBSC), a seguire il link al progetto su github:
Sul GDPR in futuro ne vorrei parlare pure io (diciamo andrea sfiora l’argomento, però sono abbastanza d’accordo con lui con il fatto che avere tutti questi cookie banner non aumenta in modo significativo la privacy degli utenti).
Unico punto da precisare: anche assumendo di togliere il meccanismo dei cookie, il cross-site scripting (XSS), sarebbe comunque una minaccia in quanto è codice che esegue sul browser della vittima, e quindi può utilizzare la chiave del dispositivo esattamente come il normale JS della pagina.
Detto questo, è vero che si andrebbero ad eliminare tutte le problematiche quando il session hijacking è fatto in modo “rozzo”, della serie: mi prendo il cookie e poi faccio la richiesta con il mio browser. Cosa che molto spesso succede.
Quindi alla fine è un positive net gain per la sicurezza, per quanto incrementa di un sacco la complessità (un trade-off bello tosto da bilanciare).
Ho appena finito di vedere il video: molto molto interessante e spiegato magistralmente, come tutti i video di rev3rse.
Se ho capito correttamente, in buona sostanza si utilizza il TPM per firmare in locale il cookie da inviare al server, che poi lo valida ad ogni utilizzo verificando che la firma combaci con quella del brower che invia le richieste.
A questo punto a me sorgono due domande però, magari potete aiutarmi a chiarire:
Perchè è necessario il TPM per firmare? Non sarebbe bastato semplicemente adeguare i browser affinchè generassero una coppia di chiavi uniche, al momento dell’installazione ad esempio, da utilizzare per implementare questo sistema?
Da quello che mi sembra di capire, il TPM sta diventando via via lo strumento a cui gira attorno una buona fetta di sicurezza informatica, almeno quella “locale” (anti keylogging, malware, ora xss e via dicendo). Ho letto che anche la protezione DRM sta iniziando a guardare al TPM per evitare il ripping dei contenuti, per non parlare degli anticheat dei videogiochi. Ma far passare così tanta sicurezza da un singolo chip non è a sua volta un po’ insicuro? Non diventa un possibile point of failure enome in questo modo?
Il video non l’ho ancora visto ma sicuramente sara’ super interessante, invece a proposito di sto TPM, a me non e’ mai piaciuto, lo vedo solo come un’altro pezzettino per smantellare il software libero and co. a favore dei soliti !!!
Allora non ho studiato in modo approfondito l’argomento, quindi prendi le mie parole con la giusta distanza.
Dipende dal threat model utilizzato, ovvero dipende rispetto a quale minaccia ti vuoi proteggere. Nella pagina github si legge dagli autori
DBSC depends on user devices having a way of signing challenges while protecting private keys from exfiltration by malware.
Quindi vuoi un meccanismo che non può essere compromesso da eventuali malware. Bene, qualsiasi cosa salvi sul disco (che sarebbe esattamente quello che succederebbe se il browser generasse una chiave durante l’install) può essere compromessa da malware. Quindi la tua soluzione non rispetterebbe questo requisito.
Certo che se cambi requisiti, allora puoi ottenere una soluzione più “semplice”, che ovviamente funziona in un numero più limitato di contesti. Sempre molto importante definire il contesto.
Pensa al ruolo dei password manager. Da un certo punto di vista, stanno creando un single point of failure. Eppure effettivamente se usati bene (soprattutto quelli offline) vanno ad aumentare la sicurezza globale del sistema, o almeno questa è la mia impressione.
Perché questo?
Probabilmente è perché un certo livello di “insicurezza” è inevitabile. A questo punto la domanda è: la spargiamo in giro, oppure la concentriamo in un unico punto? Può sembrare una cosa negativa concentrarla, ma in realtà stai anche concentrando gli sforzi per renderla più sicura. Nel senso, adesso devi guardare in un solo punto anche a livello di difesa. Quindi è più “semplice” renderlo sicuro (per quanto non potrà mai esserlo 100%).
Anche perché, la maggior parte delle problematiche di sicurezza, escludendo le ricerce molto sofisticate, che comunque sono poche (altrimenti ci sarebbero più ricercatori) derivano da semplice mancanza di attenzione rispetto a tante potenziali sorgenti vulnerabili.
Hai ragione, non avevo considerato il fatto di esfiltrare dei dati sul disco. In effetti sarebbe probabilmente impossibile realizzare lo stesso sistema senza il TPM.
Sul secondo punto ho ancora qualche dubbio però.
Capisco l’idea, chiaro: giustamente concentrare tutta la sicurezza in un punto è più facile da gestire, migliorare e controllare. Ed è sicuramente un miglioramento in toto alla sicurezza dei sistemi informatici in generale.
Però stiamo pur sempre “difendendo tutto quanto il castello con la sola chiave del portone” e spingiamo questo approccio sempre di più. Sono un po’ in bilico tra le due visioni, diciamo.
Mi è venuto questo dubbio più che altro perchè ho visto di recente un canale americano (Low Level Learning) parlare di bug e vulnerabilità non fixabili (una di recente sui processori ARM), proprio perchè derivanti da errori di progettazione, se ho inteso correttamente.
Il paragone con il password manager ci sta tutto, però secondo me dovremmo anche considerare che quello è puro software: relativamente semplice da fixare. Il TPM, oltre che bug e vulnerabilità software, potrebbe potenzialmente averne anche di “fisiche” essendo un chip a parte. E risolvere quelle mi sembra molto più complicato, se non impossibile a volte.
Chiaramente è più un discorso filosofico sui massimi sistemi, l’idea dei cookie è palesemente ottima. E io non sono neanche troppo competente in materia, sono più che altro ragionamenti a caldo!
Si diciamo qui la parte interessante è, come hai detto tu, osservare il fatto che questo TPM gira ad un livello molto più basso del software (hardware / firmware), e quindi potrebbe effettivamente essere molto più difficile da fixare dopo essere stato rilasciato.
Qui ci sarebbe da capire la complessità dell’oggetto in questione ed i processi di sviluppo che portano alla produzione di quel particolare oggetto. A seconda della qualità di questi processi mi potrei più o meno fidare. Ovviamente il fatto è che noi utenti finali raramente siamo informati in dettaglio su questi processi, quindi diventa molto difficile valutare l’effettiva sicurezza della questione.
A me una cosa che non piace di queste cose è l’inerente aumento di complessità, che alla fine risulta in parte necessario. In questa “necessità” ovviamente si aggiunge anche complessità dettata da altri fattori che potrebbe a livello teorico essere tolta.
Più semplice è, più è facile analizzare la sicurezza del tutto, e più è facile trovare eventuali vulnerabilità.
In ogni caso però al TPM ci si interfaccia in qualche modo (immagino tramite call del kernel), quindi, per quanto le chiavi siano in hw, le chiamate software restano potenzialmente hijackable. Quando una macchina è compromessa credo che purtroppo non resti molto da fare…
