Rassegna sulla sicurezza di dicembre 2020

SSL.com augura a tutti i nostri clienti e visitatori un periodo natalizio felice, sicuro e salutare e un prospero 2021! Speriamo che il nuovo anno si riveli un po 'meno, umm ... interessante rispetto al 2020 è stato per certi versi, ma siamo sicuri che non passerà mese senza notizie importanti dal mondo della sicurezza di rete, dei certificati digitali e PKI.

Vulnerabilità DoS OpenSSL

Abbiamo trattato questo problema in un file post sul blog all'inizio di questo mese, ma vale la pena ripeterlo. Una vulnerabilità ad alta gravità in OpenSSL è stato scoperto che interessa tutte le versioni di OpenSSL 1.0.2 e 1.1.1 precedenti alla 1.1.1i. Questa vulnerabilità potrebbe essere sfruttata per creare un attacco DoS (Denial of Service). OpenSSL 1.1.1i, rilasciato l'8 dicembre 2020, include una correzione.

Gli utenti di OpenSSL dovrebbero aggiornare le loro installazioni il prima possibile. Esistono due percorsi per applicare la correzione:

  • Gli utenti di OpenSSL 1.1.1 e gli utenti 1.0.2 non supportati devono eseguire l'aggiornamento a 1.1.1i.
  • I clienti con supporto Premium di OpenSSL 1.0.2 devono eseguire l'aggiornamento a 1.0.2x.

OpenSSL è attualmente installato sulla maggior parte dei server Web HTTPS. Puoi leggere di più sulla vulnerabilità in SSL.com bloge nel progetto OpenSSL Avviso di sicurezza.

Da asporto di SSL.com: Se sei un utente OpenSSL e non l'hai già fatto, leggi OpenSSL's consultivo sulla vulnerabilità e aggiorna la tua installazione il prima possibile.

Cloudflare promuove nuovi protocolli di privacy

Tim Anderson segnalati nel Registro che Cloudflare sta "spingendo per l'adozione di nuovi protocolli Internet, si dice che consentirà un 'Internet che rispetta la privacy'". Questi protocolli includono DNS su HTTPS (DoH), crittografia aggiuntiva per TLS stretta di manoe miglioramenti della sicurezza per la gestione delle password degli utenti.

DoH ignaro

DNS su HTTPS (DoH) risolve un anello debole nella privacy di Internet crittografando le query e le risposte DNS, che storicamente sono state inviate come testo in chiaro. DoH ignaro (ODoH)  porta la protezione della privacy DNS un ulteriore passo avanti impedendo ai server DoH di conoscere l'indirizzo IP del client:

L'essenza di ODoH è che introduce un proxy di rete tra il client e il server DoH. Il proxy non ha visibilità sulla query DNS, che può essere letta solo dal server DoH. Il server non è a conoscenza dell'indirizzo IP del client. La query è privata, a condizione che il proxy e il server non siano in conflitto.

Cloudflare ha già dichiarato il supporto per ODoH, sviluppato dagli ingegneri di Cloudflare, Apple e Fastly. Puoi saperne di più controllando la loro carta su arxiv.org.

Client crittografato Hello (ECH)

Client crittografato Hello (ECH) offre una crittografia handshake avanzata in formato TLS, andare oltre SNI crittografata (ESNI), che protegge solo l'indicazione del nome del server (SNI) in TLS stretta di mano. Christopher Patton, ingegnere ricercatore di Cloudflare scrive,

Sebbene ESNI abbia compiuto un significativo passo avanti, non è all'altezza del nostro obiettivo di ottenere la crittografia completa dell'handshake. Oltre ad essere incompleto - protegge solo SNI - è vulnerabile una manciata di attacchi sofisticati, che, sebbene difficile da realizzare, indica debolezze teoriche nella progettazione del protocollo che devono essere affrontate.
...
In definitiva, l'obiettivo di ECH è garantire ciò TLS le connessioni effettuate a diversi server di origine dietro lo stesso fornitore di servizi ECH non sono distinguibili l'una dall'altra.

Non sorprende che, poiché ECH "ha pieno senso solo insieme a DoH e nel contesto di una CDN (rete di distribuzione di contenuti)", Cloudflare "si considera un probabile fornitore di ECH". Puoi leggere di più su ECH negli IETF bozza di proposta.

Password OPACHE

Le password OPACHE - "una sorta di gioco di parole su Oblivious Pseudo-Random Function (OPRF) combinato con Password Authenticated Key Exchange (PAKE)" - è un meccanismo per evitare completamente il trasferimento della password di un utente a un server. OPAQUE ottiene questo risultato “facendo in modo che il server e il client calcolino congiuntamente un hash salato da confrontare utilizzando un secondo sale intermedio. Ciò garantisce che il server non possa apprendere la password dell'utente durante l'autenticazione e che l'utente non apprenda il sale segreto del server ".

Puoi saperne di più sulle password OPAQUE in questo documento [PDF link] di ricercatori dell'Università della California, Irvine e IBM, e nell'ingegnere di Cloudflare Tatiana Bradley post sul blog.

Da asporto di SSL.com: Siamo sempre entusiasti di apprendere nuovi protocolli di sicurezza di rete, soprattutto per quanto riguarda PKI e certificati digitali. Ti forniremo ulteriori informazioni su questi e altri progressi in materia di sicurezza e privacy man mano che appaiono e vengono implementati.

Credenziali FTP trapelate possibilmente collegate ad un attacco SolarWinds

A meno che tu non abbia passato le ultime settimane in una cabina remota e fuori dalla rete (non è una cattiva idea ora che ci pensiamo), probabilmente hai già sentito parlare abbastanza del attacco alla catena di approvvigionamento che ha compromesso il software di monitoraggio IT Orion di SolarWinds e molti dei suoi utenti nel governo e nell'industria. Il 16 dicembre di Ravie Lakshmanan storia in Hacker News discute di come gli aggressori "probabilmente siano riusciti a compromettere la build del software e l'infrastruttura di firma del codice della piattaforma SolarWinds Orion già nell'ottobre 2019 per fornire la backdoor dannosa attraverso il processo di rilascio del software".

L'idea ... era quella di compromettere il sistema di compilazione, iniettare silenziosamente il proprio codice nel codice sorgente del software, attendere che la società compilasse, firmasse i pacchetti e, infine, verificare se le loro modifiche si presentassero negli aggiornamenti appena rilasciati come previsto.

La sequenza temporale di ottobre 2019 è in linea con il ricercatore sulla sicurezza Vinoth Kumer scoperta, nel novembre 2019, di un repository GitHub pubblico che perdeva credenziali FTP in chiaro per il server di aggiornamento di Solarwinds e che questo server era accessibile con la password "solarwinds123". Il repo in questione era stato aperto al pubblico "dal 17 giugno 2018", dando agli aspiranti aggressori tutto il tempo per scoprire e sfruttare le credenziali trapelate.

Ovviamente, non ha aiutato il fatto che SolarWinds abbia anche consigliato agli utenti di disabilitare le misure di sicurezza:

A peggiorare le cose, il codice dannoso aggiunto a un aggiornamento del software Orion potrebbe essere passato inosservato da software antivirus e altri strumenti di sicurezza su sistemi mirati a causa di SolarWinds consulenza di supporto, che afferma che i suoi prodotti potrebbero non funzionare correttamente a meno che le directory dei file non siano esentate dalle scansioni antivirus e dalle restrizioni sugli oggetti Criteri di gruppo (GPO).

Da asporto di SSL.com: Firma del codice è un passaggio importante, persino obbligatorio per mantenere la fiducia quando si distribuisce il software ai clienti, ma il successo dipende da un ambiente sicuro. Proteggere server cruciali con password deboli e facilmente intuibili e / o esporre inavvertitamente credenziali in chiaro al pubblico, lascia una porta aperta agli attacchi che sfruttano il tuo sistema di compilazione per rilasciare software firmato, ma con trojan.

Iscriviti alla Newsletter di SSL.com

Non perdere nuovi articoli e aggiornamenti da SSL.com

Ci piacerebbe il tuo feedback

Partecipa al nostro sondaggio e facci sapere cosa ne pensi del tuo recente acquisto.