SSL.com ønsker alle våre kunder og besøkende en lykkelig, trygg og sunn høytid og en velstående 2021! Vi håper at det nye året vil vise seg å være litt mindre, umm ... interessant enn 2020 har vært på noen måter, men vi er sikre på at det ikke vil gå en måned uten viktige nyheter fra en verden av nettverkssikkerhet, digitale sertifikater og PKI.
Sårbarhet i OpenSSL DoS
Vi dekket dette problemet i en blogginnlegg tidligere denne måneden, men det er verdt å gjenta. En alvorlighetsgrad sårbarhet i OpenSSL ble oppdaget som påvirker alle versjoner av OpenSSL 1.0.2 og 1.1.1 før 1.1.1i. Denne sårbarheten kan utnyttes for å skape et denial of service (DoS) -angrep. OpenSSL 1.1.1i, utgitt 8. desember 2020, inkluderer en løsning.
OpenSSL-brukere bør oppdatere installasjonene sine så snart som mulig. Det er to måter å bruke løsningen på:
- Brukere av OpenSSL 1.1.1 og ikke-støttede 1.0.2-brukere bør oppgradere til 1.1.1i.
- Premium support-kunder av OpenSSL 1.0.2 bør oppgradere til 1.0.2x.
OpenSSL er for øyeblikket installert på de fleste HTTPS-webservere. Du kan lese mer om sikkerhetsproblemet i SSL.com blog, og i OpenSSL-prosjektet Sikkerhetsrådgivning.
Cloudflare tar til orde for nye personvernprotokoller
Tim Anderson rapportert i The Register at Cloudflare "presser på for å ta i bruk nye internettprotokoller som det står, vil muliggjøre et" personvern-respektert internett. "" Disse protokollene inkluderer forbedret personvern DNS over HTTPS (DoH), ekstra kryptering for TLS håndtrykk, og sikkerhetsforbedringer for håndtering av brukerpassord.
Glemsk DoH
DNS over HTTPS (DoH) adresserer en svak kobling i personvernet ved å kryptere DNS-spørsmål og svar, som historisk har blitt sendt som ren tekst. Oblivious DoH (ODoH) tar DNS-personvernet et skritt videre ved å hindre DoH-servere i å kjenne klientens IP-adresse:
Essensen av ODoH er at den introduserer en nettverksproxy mellom klienten og DoH-serveren. Proxyen har ingen synlighet i DNS-spørringen, som bare kan leses av DoH-serveren. Serveren har ingen kunnskap om klientens IP-adresse. Spørsmålet er privat, forutsatt at proxyen og serveren ikke samarbeider.
Cloudflare har allerede erklært støtte for ODoH, som ble utviklet av ingeniører hos Cloudflare, Apple og Fastly. Du kan lære mer ved å sjekke ut deres papir på arxiv.org.
Kryptert klient Hei (ECH)
Kryptert klient Hei (ECH) tilbyr forbedret kryptering av håndtrykk i TLS, går utover Kryptert SNI (ESNI), som bare beskytter servernavnindikasjon (SNI) i TLS håndtrykk. Cloudflare forskningsingeniør Christopher Patton skriver,
Mens ESNI tok et betydelig skritt fremover, faller det ikke under vårt mål om å oppnå full håndtrykk-kryptering. Bortsett fra å være ufullstendig - den beskytter bare SNI - er den sårbar for en håndfull sofistikerte angrep, som, selv om det er vanskelig å trekke frem, peker på teoretiske svakheter i protokollens design som må løses.
...
Til slutt er målet med ECH å sikre det TLS forbindelser til forskjellige opprinnelsesservere bak samme ECH-tjenesteleverandør kan ikke skilles fra hverandre.
Ikke overraskende, siden ECH "bare gir full mening sammen med DoH, og i sammenheng med et CDN (innholdsdistribusjonsnettverk)", ser Cloudflare seg selv som en sannsynlig ECH-leverandør. " Du kan lese mer om ECH i IETF-ene utkast til forslag.
OPAQUE passord
OPAQUE passord - ”en slags ordspill om Oblivious Pseudo-Random Function (OPRF) kombinert med Password Authenticated Key Exchange (PAKE)” - er en mekanisme for å helt unngå overføring av brukerens passord til en server. OPAQUE oppnår dette ved å "få serveren og klienten til å beregne en saltet hash for å sammenligne ved hjelp av et mellomliggende andre salt. Dette sikrer at serveren ikke kan lære brukerens passord under autentisering, og at brukeren ikke lærer serverens hemmelige salt. ”
Du kan finne ut mye mer om OPAQUE passord i dette papiret [PDF-lenke] av forskere ved University of California, Irvine og IBM, og i Cloudflare-ingeniør Tatiana Bradleys blogginnlegg.
Lekkede FTP-legitimasjoner som muligens er knyttet til SolarWinds Attack
Med mindre du har tilbrakt de siste ukene i en ekstern hytte (ikke en dårlig idé nå som vi tenker på det), har du sannsynligvis allerede hørt ganske mye om forsyningskjedeangrep som kompromitterte SolarWinds 'Orion IT-overvåkingsprogramvare og mange av brukerne i regjeringen og industrien. Ravie Lakshmanans 16. desember historie i Hacker News diskuterer hvordan angriperne “sannsynligvis klarte å kompromittere programvarebyggingen og kodesigneringsinfrastrukturen til SolarWinds Orion-plattformen så tidlig som i oktober 2019 for å levere den ondsinnede bakdøren gjennom programvareutgivelsesprosessen.”
Ideen ... var å kompromittere byggesystemet, stille injisere sin egen kode i kildekoden til programvaren, vente på at selskapet skulle kompilere, signere pakker og til slutt, kontrollere om modifikasjonene deres dukket opp i de nylig utgitte oppdateringene som forventet.
Tidslinjen for oktober 2019 stemmer overens med sikkerhetsforskeren Vinoth Kumer Funnet, i november 2019, av en offentlig GitHub-repo som lekker FTP-legitimasjon med ren tekst for Solarwinds oppdateringsserver - og at denne serveren var tilgjengelig med passordet "solarwinds123." Den aktuelle repoen hadde vært åpen for publikum "siden 17. juni 2018", noe som ga fremtidige angripere god tid til å oppdage og utnytte den lekket legitimasjonen.
Selvfølgelig hjalp det ikke at SolarWinds også rådet brukerne til å deaktivere sikkerhetstiltak:
For å gjøre saken verre, kan skadelig kode som er lagt til i en Orion-programvareoppdatering, ha gått ubemerket av antivirusprogramvare og andre sikkerhetsverktøy på målrettede systemer på grunn av SolarWinds egen støtte rådgivende, som sier at produktene deres kanskje ikke fungerer ordentlig med mindre filkatalogene deres er unntatt antivirusskanninger og gruppepolitiske objekter (GPO).
