Alcune ricerche sono state pubblicate di recente che hanno dimostrato che la funzione SmartScreen di Windows 8 invia determinati dettagli su ogni singola applicazione che installi su Microsoft.
Ignorando le evidenti violazioni della privacy, quali altri problemi di sicurezza potrebbero causare? L'articolo tocca alcuni problemi SSL, ma afferma che non sono stati verificati come vulnerabili.
In realtà l'articolo non dice che il client SmartScreen utilizza SSLv2; dice semplicemente che il server che i contatti SmartScreen sarebbero felici di accettare le connessioni in entrata usando il protocollo SSLv2. Sarebbe sorprendente se SmartScreen utilizzasse effettivamente SSLv2: la maggior parte plausibilmente, Microsoft ha riutilizzato il proprio codice esistente per un client SSL e tale codice ha SSLv3 + per impostazione predefinita. L'uso di SSLv2 implicherebbe uno sforzo supplementare senza alcun guadagno.
Inoltre, la maggior parte di ciò che viene detto sulla sicurezza di SSLv2 (in questo articolo o altrove) è coperto da un pesante strato di FUD . SSLv2 ha problemi , sufficienti a garantire di non usarlo (specialmente dal momento che SSLv3 e TLS sono disponibili), ma non così terribile di quanto generalmente suggerito. Vedi ad esempio questa pagina ; si afferma che:
- Message integrity compromised. The SSLv2 message authentication uses the MD5 function, and is insecure.
- Man-in-the-middle attack. There is no protection of the handshake in SSLv2, which permits a man-in-the-middle attack.
- Truncation attack. SSLv2 relies on TCP FIN to close the session, so the attacker can forge a TCP FIN, and the peer cannot tell if it was a legitimate end of data or not.
- Weak message integrity for export ciphers. The cryptographic keys in SSLv2 are used for both message authentication and encryption, so if weak encryption schemes are negotiated (say 40-bit keys) the message authentication code uses the same weak key, which isn’t necessary.
Il primo punto è decisamente FUD. È una reazione istintiva: "MD5? BAD BAD BAD!". È infondato. Sono non che dice che MD5 è solido; ma sostengo che il controllo di integrità in SSLv2 non è così facile da sconfiggere.
Il secondo punto è, nel migliore dei casi, confuso e fuorviante. Gli "attacchi man-in-the-middle" a cui si fa riferimento sono i seguenti: in SSL (v2, v3 + ...), sia il client che il server possono supportare diversi pacchetti di crittografia; il client invia l'elenco di suite che supporta e il server ne sceglie uno. Con SSLv2, un utente malintenzionato che è in grado di eseguire un MitM può modificare l'elenco inviato dal client per forzare il client e il server a utilizzare una specifica suite di crittografia (all'interno dell'insieme di suite supportate da entrambi) , ovviamente). L'alterazione non viene rilevata in seguito (mentre, in SSLv3 +, verrà rilevata alla fine dell'handshake). Quindi, il ragionamento va, SSLv2 è debole perché l'utente malintenzionato può forzare client e server a utilizzare una "suite di crittografia debole" (ad esempio una con chiavi a 40 bit). Ma può? In effetti, l'attaccante può forzare l'uso di una suite di crittografia che sia il client che il server erano già pronti ad accettare - e QUESTA è la debolezza. Quello che rompe l'attacco è l'aggiornamento ottimistico a suite di cifratura più potenti quando disponibili; ma la debolezza reale si verifica quando client e server accettano di utilizzare chiavi a 40 bit.
Il quarto punto è più o meno lo stesso: si dice che se una chiave è debole e viene utilizzata per due utilizzi, la rottura della chiave consente di attaccare i due usi. Ma la vera debolezza qui sta usando una chiave debole.
Solo il terzo punto è proprio vero: un utente malintenzionato può forzare una connessione chiusa e le macchine non possono sapere se la chiusura è stata intesa dal peer. Questo è un problema serio con HTTP / 1.0 senza attributo Content-Length ma non con altri protocolli, incluso HTTP come viene usato al giorno d'oggi.
Riepilogo: SSLv2 è "rotto", ma non tanto quanto si dice. No, una connessione SSLv2 non può essere decodificata istantaneamente da un utente malintenzionato. E personalmente ritengo altamente improbabile che il client SmartScreen utilizzi SSLv2; non avrebbe molto senso.
(Nessuno dei precedenti dice nulla riguardo ai problemi di privacy con SmartScreen.)
Supponiamo che la connessione SSL sia sicura Se si presuppone che la connessione SSL sia sicura e che il server Microsoft sia valido, allora non molto.
Ma se ipotizziamo che il dispositivo sia stato violato o che un'applicazione abbia ottenuto autorizzazioni aggiuntive, un utente malintenzionato potrebbe fare cose cattive. Sostituisci la chiave pubblica di Microsoft o ascolta di nascosto l'endpoint. Un sacco di brutti potrebbero venire da esso .... ma quello viene dopo che l'utente è già di proprietà ...
Se questa è solo una connessione SSL vaniglia non riesco a pensare a nessun nuovo vettore di attacco che si apre ... solo una nuova risorsa a cui gli hacker potrebbero essere interessati.
Supponiamo che la connessione SSL non sia sicura Gli aggressori MITM potrebbero ottenere qualunque informazione passata a Microsoft che volevano. È possibile che gli utenti non scarichino nuove applicazioni, eseguano il download e l'installazione di applicazioni dannose o utilizzino le informazioni per lanciare attacchi mirati contro l'utente.
Penso che personalmente ho bisogno di vedere un whitepaper o qualcosa del genere su esattamente ciò che SmartScreen fa e esattamente quali informazioni invia prima che io possa dire o assumere più ...
Rompendo, ci sono due preoccupazioni generali che vorrei indagare - 1.) Quali dati vengono inviati e 2.) Come viene inviato.
L'articolo descrive il metodo di trasmissione - SSLv2 a un server Microsoft in Redmond. Sicurezza piuttosto semplice, ma dal momento che SSLv2 non è sicuro, supponiamo che un utente malintenzionato possa rompere questo problema.
Le connessioni SSLv2 non sicure non sono una novità, né gli attacchi e gli exploit che potremmo lanciare su di loro, quindi la prossima domanda è: in che cosa differisce da altre connessioni SSLv2 insicure dal tuo sistema? Questo ci porta alla domanda 1: quali dati vengono inviati. In questo caso, sappiamo che stiamo inviando un inventario accurato di tutte le applicazioni su un sistema.
La risposta ovvia è che per un aggressore questo è estremamente utile. Mettendo tutto insieme, ho una connessione SSL rotta con un sistema il cui footprint software ora conosco intimamente. Da lì, si tratta solo di elencare gli exploit conosciuti per ciascuno di quei pezzi di software (o di scriverne di nuovi).
Secondo me, tutto questo aggiunge semplicemente un altro vettore di attacco con il meraviglioso vantaggio di essere in grado di acquisire molto rapidamente un'impronta digitale preconfezionata del carico del software di un sistema. Immagino che dipenda da te se pensi che il rischio valga il vantaggio di avere Microsoft che "controlla il tuo software per te!" Per motivi di privacy e sicurezza, lo spegnerei, ma se non sei preoccupato per la privacy, attenderei almeno fino a quando non avranno un metodo di trasmissione più sicuro.