Rassegna sulla sicurezza di settembre 2020

Benvenuti all'edizione di settembre del riepilogo mensile sulla sicurezza di SSL.com! Oggi parleremo di:

• SSL.com è nuovo di zecca newsletter
• Modifiche al forum CA / B Linee guida SSL EV
• I piani della Russia a protocolli di divieto che nascondono la destinazione del traffico Internet
• I Attacco di procione on TLS versioni 1.2 e precedenti
• Insicuro Internet of Things (IoT) pratiche
  

Annuncio della newsletter di SSL.com!

SSL.com è orgoglioso di annunciare la nostra nuova newsletter mensile via e-mail! Ogni mese ti invieremo notizie e informazioni sulla sicurezza in Internet, PKIe certificati digitali, insieme a informazioni sui nuovi prodotti e servizi offerti da SSL.com. Per iscriversi, è sufficiente compilare il modulo sottostante. (Puoi annullare l'iscrizione facilmente in qualsiasi momento facendo clic su cancellarsi link in ogni email che inviamo.):

Scheda del forum CA / B SC30: modifiche alle linee guida per i certificati SSL EV

In notizie di interesse per SSL.com SSL EV clienti, la versione corrente (1.7.3) del CA / Browser Forum Linee guida per il certificato SSL EV, entrato in vigore il 20 agosto 2020, ha alcuni nuovi requisiti. Nello specifico, come descritto nel Forum CA / B Scrutinio SC30, le autorità di certificazione (CA), come SSL.com, devono ora pubblicare l'elenco delle agenzie di registrazione e incorporazione che utilizzano per la convalida delle richieste di certificato SSL EV. (La mossa è in linea con un obiettivo più ampio di rendere le fonti di convalida EV coerenti tra le CA).

Di conseguenza, SSL.com pubblicherà un elenco delle fonti di informazioni che utilizziamo per la convalida di aziende e altre organizzazioni per i certificati EV. Quando non siamo in grado di individuare l'organizzazione di un richiedente nel nostro attuale elenco di fonti, tenteremo di individuare un'altra fonte di informazioni valida e di aggiungerla al nostro elenco pubblicato prima di convalidare l'ordine e di emettere il certificato.

La Russia prevede di vietare i protocolli che nascondono la destinazione del traffico

Questa storia potrebbe sembrare familiare, se ti sei tenuto aggiornato con le notizie sulla sicurezza digitale. In effetti, il mese scorso abbiamo segnalato su una storia che il "Great Firewall" cinese sta ora bloccando il traffico HTTPS che utilizza TLS 1.3 e ENSI (Encrypted Server Name Indication) nel tentativo di rendere più facile per i censori cinesi vedere quali siti i cittadini stanno cercando di visitare e per controllare l'accesso a tali siti.

Questo mese, un rapporto di Catalin Cimpanu in ZDNet ha spiegato che la Russia sta ora cercando di vietare l'uso di alcuni protocolli con un aggiornamento delle leggi sulla tecnologia che "renderebbe illegale l'uso di protocolli di crittografia che nascondono completamente la destinazione del traffico". Come notato nell'articolo, questi protocolli includerebbero TLS 1.3 DoH, DoT e ESNI. Il ragionamento è, ovviamente, molto simile al ragionamento alla base del divieto cinese: i protocolli impediscono la sorveglianza e la censura da parte dello Stato. Dall'articolo:

La Russia non utilizza un sistema firewall nazionale, ma il regime di Mosca si basa su un sistema chiamato SORM che consente alle forze dell'ordine di intercettare il traffico Internet a fini di contrasto direttamente alla fonte, nei data center delle telecomunicazioni.
Inoltre, il ministero delle telecomunicazioni russo, il Roskomnadzor, ha gestito un firewall nazionale de facto attraverso il suo potere di regolamentazione sugli ISP locali. Negli ultimi dieci anni, Roskomnadzor ha vietato i siti Web ritenuti pericolosi e ha chiesto agli ISP di filtrare il loro traffico e bloccare l'accesso ai rispettivi siti.
Con TLS 1.3, DoH, DoT ed ESNI stanno ottenendo l'adozione, tutti gli attuali strumenti di sorveglianza e censura della Russia diventeranno inutili, poiché si basano sull'accesso agli identificatori del sito Web che trapelano dal traffico web crittografato.

La legge è attualmente all'esame, in attesa di feedback pubblico, e tornerà per un voto all'inizio di ottobre. ZDNet osserva che, dato il clima, "è quasi certo che l'emendamento passerà".

New TLS Attacco: procione

Abbiamo già un file post sul blog sul "Raccoon Attack", ma vale la pena menzionarlo di nuovo poiché l'attacco può consentire a terze parti di violare SSL /TLS crittografia per leggere le comunicazioni destinate a essere mantenute sicure. Come spiegato in una recente pubblicazione carta accademica, l'attacco sfrutta una vulnerabilità temporale in TLS versioni 1.2 e precedenti e potrebbero decrittografare comunicazioni che includono nomi utente, password, dati di carte di credito e altre informazioni sensibili. Dal nostro post all'inizio di questo mese:

Anche se sembra terrificante, tieni presente che questo attacco può avvenire solo in circostanze molto specifiche e rare: il server deve riutilizzare le chiavi Diffie-Hellman pubbliche nel stretta di mano (già considerata una cattiva pratica) e l'attaccante deve essere in grado di effettuare misurazioni precise dei tempi. Inoltre, il browser deve supportare le suite di crittografia vulnerabili (a giugno 2020 tutti i principali browser le hanno abbandonate).

L'Internet delle cose (vulnerabili), edizione caffettiera

Mentre la storia sopra non lo era effettivamente sugli attacchi dei procioni, questa storia parla davvero di macchine da caffè. Per essere più precisi, l'articolo di Dan Goodin in Ars Technica riguarda come una caffettiera è stata trasformata in una "macchina del riscatto" sfruttando i punti deboli comuni nei dispositivi Internet of Things (IoT).

Fondamentalmente, iKettle dei prodotti Smarter (mal nominati) è stato a lungo un obiettivo per coloro che cercano di illustrare i pericoli di apparecchi facilmente hackerabili. Dal 2015 le versioni del bollitore sono stati comandati a distanza attraverso il reverse engineering. Anche se da allora la società ha rilasciato una nuova versione del vaso, le vecchie sono ancora in uso e, ragazzi, sono vulnerabili a quelli che le note dell'articolo sono attacchi "fuori dagli schemi". Recentemente, un programmatore di nome Martin Hron ha deciso di testare i limiti di come potrebbe apparire una violazione della sicurezza su una caffettiera, nel peggiore dei casi:

Quando Hron ha collegato per la prima volta la sua macchina da caffè Smarter, ha scoperto che funzionava immediatamente come un punto di accesso Wi-Fi che utilizzava una connessione non protetta per comunicare con un'app per smartphone. L'app, a sua volta, viene utilizzata per configurare il dispositivo e, se l'utente lo desidera, collegarlo a una rete Wi-Fi domestica. Senza crittografia, il ricercatore non ha avuto problemi ad apprendere come il telefono controllava la caffettiera e, poiché non c'era nemmeno l'autenticazione, come un'app per telefono canaglia poteva fare la stessa cosa.
Quella capacità lasciava comunque a Hron solo un piccolo menu di comandi, nessuno dei quali particolarmente dannoso. Quindi ha quindi esaminato il meccanismo utilizzato dalla caffettiera per ricevere gli aggiornamenti del firmware. Si è scoperto che erano stati ricevuti dal telefono senza, come avete indovinato, senza crittografia, senza autenticazione e senza firma del codice.

C'è un ampio post sul blog sull'hacking della macchina per il caffè chiamato "L'odore fresco del caffè riscattato. " C'è anche un divertente video dimostrando il caos derivante dallo sfruttamento delle vulnerabilità della macchina da caffè. Sebbene sia improbabile che un attacco come questo arrivi presto nella cucina di qualcuno, è un buon promemoria che "intelligente" significa più che "conveniente".