SSL.com ønsker alle vores kunder og besøgende en god, sikker og sund feriesæson og et velstående 2021! Vi håber, at det nye år vil vise sig at være lidt mindre, umm ... interessant end 2020 har været på nogle måder, men vi er sikre på, at der ikke går en måned uden vigtige nyheder fra verdenen af netværkssikkerhed, digitale certifikater og PKI.
Sårbarhed i OpenSSL DoS
Vi dækkede dette spørgsmål i en blogindlæg tidligere på denne måned, men det er værd at gentage det. En sårbarhed med høj sværhedsgrad i OpenSSL blev opdaget, der påvirker alle versioner af OpenSSL 1.0.2 og 1.1.1 før 1.1.1i. Denne sårbarhed kan udnyttes til at skabe et denial of service (DoS) angreb. OpenSSL 1.1.1i, udgivet den 8. december 2020, inkluderer en rettelse.
OpenSSL-brugere skal opdatere deres installationer så hurtigt som muligt. Der er to veje til at anvende rettelsen:
- Brugere af OpenSSL 1.1.1 og ikke-understøttede 1.0.2-brugere skal opgradere til 1.1.1i.
- Premium support-kunder af OpenSSL 1.0.2 skal opgradere til 1.0.2x.
OpenSSL er i øjeblikket installeret på de fleste HTTPS-webservere. Du kan læse mere om sårbarheden i SSL.com's blogog i OpenSSL-projektet Sikkerhedsrådgivning.
Cloudflare fortaler nye protokoller for privatlivets fred
Tim Anderson rapporteret i The Register, at Cloudflare "presser på for vedtagelse af nye internetprotokoller, som det siger, vil muliggøre et 'privatlivets respekt for internet'." Disse protokoller inkluderer forbedret privatliv DNS over HTTPS (DoH), ekstra kryptering til TLS håndtrykog sikkerhedsforbedringer til håndtering af brugeradgangskoder.
Glemsom DoH
DNS over HTTPS (DoH) adresserer et svagt led i internetbeskyttelse ved at kryptere DNS-forespørgsler og svar, som historisk er sendt som almindelig tekst. Oblivious DoH (ODoH) tager DNS-beskyttelse af personlige oplysninger et skridt videre ved at forhindre DoH-servere i at kende klientens IP-adresse:
Essensen af ODoH er, at den introducerer en netværksproxy mellem klienten og DoH-serveren. Proxyen har ingen synlighed i DNS-forespørgslen, som kun kan læses af DoH-serveren. Serveren har ikke kendskab til klientens IP-adresse. Forespørgslen er privat, forudsat at proxyen og serveren ikke kolliderer.
Cloudflare har allerede erklæret støtte til ODoH, som blev udviklet af ingeniører hos Cloudflare, Apple og Fastly. Du kan lære mere ved at tjekke ud deres papir på arxiv.org.
Krypteret klient Hej (ECH)
Krypteret klient Hej (ECH) tilbyder forbedret kryptering af håndtryk i TLS, går ud over Krypteret SNI (ESNI), som kun beskytter servernavnindikation (SNI) i TLS håndtryk. Cloudflare forskningsingeniør Christopher Patton skriver,
Mens ESNI tog et betydeligt skridt fremad, falder det ikke under vores mål om at opnå fuld håndtrykskryptering. Bortset fra at være ufuldstændig - det beskytter kun SNI - er den sårbar over for en håndfuld sofistikerede angreb, som, selvom det er svært at trække af, peger på teoretiske svagheder i protokollens design, der skal løses.
...
I sidste ende er målet med ECH at sikre det TLS forbindelser til forskellige oprindelsesservere bag den samme ECH-tjenesteudbyder kan ikke skelnes fra hinanden.
Ikke overraskende, da ECH “kun giver fuld mening sammen med DoH og i sammenhæng med et CDN (indholdsdistributionsnetværk)” ser Cloudflare sig selv som en sandsynlig ECH-udbyder. ” Du kan læse mere om ECH i IETF'erne udkast til forslag.
OPAQUE adgangskoder
OPAQUE adgangskoder - ”en slags ordspil på Oblivious Pseudo-Random Function (OPRF) kombineret med Password Authenticated Key Exchange (PAKE)” - er en mekanisme til fuldstændigt at undgå overførsel af en brugers adgangskode til en server. OPAQUE opnår dette ved at ”have serveren og klienten til at beregne en saltet hash til sammenligning ved hjælp af et mellemliggende andet salt. Dette sikrer, at serveren ikke kan lære brugerens adgangskode under godkendelse, og at brugeren ikke lærer serverens hemmelige salt. ”
Du kan finde ud af meget mere om OPAQUE adgangskoder i dette papir [PDF-link] af forskere ved University of California, Irvine og IBM og i Cloudflare-ingeniør Tatiana Bradleys blogindlæg.
Lækkede FTP-legitimationsoplysninger muligvis knyttet til SolarWinds Attack
Medmindre du har tilbragt de sidste par uger i en fjern, off-grid kabine (ikke en dårlig idé nu, når vi tænker på det), har du sandsynligvis allerede hørt en hel del om angreb på forsyningskæden der kompromitterede SolarWinds 'Orion IT-overvågningssoftware og mange af dets brugere i regeringen og industrien. Ravie Lakshmanans 16. december historie i Hacker News diskuterer, hvordan angriberne “sandsynligvis formåede at kompromittere infrastrukturen til softwareopbygning og kodesignering af SolarWinds Orion-platformen så tidligt som i oktober 2019 for at levere den ondsindede bagdør gennem sin softwareudgivelsesproces.”
Ideen ... var at kompromittere build-systemet, stille og roligt indsprøjte deres egen kode i kildekoden til softwaren, vente på, at virksomheden skulle kompilere, underskrive pakker og til sidst kontrollere, om deres ændringer dukkede op i de nyligt frigivne opdateringer som forventet.
Tidslinjen fra oktober 2019 stemmer overens med sikkerhedsforskeren Vinoth Kumer opdagelsei november 2019 af en offentlig GitHub-repo, der lækker FTP-legitimationsoplysninger med almindelig tekst til Solarwinds 'opdateringsserver - og at denne server var tilgængelig med adgangskoden "solarwinds123." Den pågældende repo havde været åben for offentligheden “siden 17. juni 2018”, hvilket gav kommende blivende angribere rigelig tid til at opdage og udnytte de lækkede legitimationsoplysninger.
Selvfølgelig hjalp det ikke, at SolarWinds også rådede brugerne til at deaktivere sikkerhedsforanstaltninger:
For at gøre tingene værre kan ondsindet kode, der er føjet til en Orion-softwareopdatering, muligvis gået ubemærket hen af antivirussoftware og andre sikkerhedsværktøjer på målrettede systemer på grund af SolarWinds 'egen supportrådgivning, der angiver, at dets produkter muligvis ikke fungerer korrekt, medmindre deres filmapper er undtaget fra antivirusscanninger og gruppepolitiske objekt (GPO) -restriktioner.
