SSL.com önskar alla våra kunder och besökare en lycklig, säker och hälsosam semester och en framgångsrik 2021! Vi hoppas att det nya året kommer att bli något mindre, umm ... intressant än 2020 har varit på vissa sätt, men vi är säkra på att det inte går en månad utan viktiga nyheter från världen av nätverkssäkerhet, digitala certifikat och PKI.
Sårbarhet i OpenSSL DoS
Vi behandlade denna fråga i ett blogginlägg tidigare denna månad, men det är värt att upprepa det. En sårbarhet med hög svårighetsgrad i OpenSSL upptäcktes som påverkar alla versioner av OpenSSL 1.0.2 och 1.1.1 före 1.1.1i. Denna sårbarhet kan utnyttjas för att skapa en DoS-attack (Denial of Service). OpenSSL 1.1.1i, släppt den 8 december 2020, innehåller en fix.
OpenSSL-användare bör uppdatera sina installationer så snart som möjligt. Det finns två vägar att tillämpa korrigeringen:
- Användare av OpenSSL 1.1.1 och icke stödda 1.0.2-användare bör uppgradera till 1.1.1i.
- Premium-supportkunder av OpenSSL 1.0.2 bör uppgradera till 1.0.2x.
OpenSSL är för närvarande installerat på majoriteten av HTTPS-webbservrar. Du kan läsa mer om sårbarheten i SSL.com bloggoch i OpenSSL-projektet Säkerhetsrådgivning.
Cloudflare förespråkar nya integritetsprotokoll
Tim Anderson rapporterade i registret att Cloudflare “driver för antagandet av nya internetprotokoll som det säger kommer att möjliggöra ett" integritetsrespekterande internet. "" Dessa protokoll inkluderar integritetsförbättrad DNS via HTTPS (DoH), ytterligare kryptering för TLS handskakningoch säkerhetsförbättringar för hantering av användarlösenord.
Omedvetna DoH
DNS via HTTPS (DoH) adresserar en svag länk i integriteten på internet genom att kryptera DNS-frågor och svar, som historiskt har skickats som klartext. Oblivious DoH (ODoH) tar DNS-sekretessskyddet ett steg längre genom att hindra DoH-servrar från att känna till klientens IP-adress:
Kärnan i ODoH är att den introducerar en nätverksproxy mellan klienten och DoH-servern. Proxyn har ingen synlighet i DNS-frågan, som bara kan läsas av DoH-servern. Servern har ingen kunskap om klientens IP-adress. Frågan är privat, förutsatt att proxyn och servern inte samverkar.
Cloudflare har redan förklarat stöd för ODoH, som utvecklades av ingenjörer på Cloudflare, Apple och Fastly. Du kan lära dig mer genom att kolla in deras papper på arxiv.org.
Krypterad klient Hej (ECH)
Krypterad klient Hej (ECH) erbjuder förbättrad kryptering av handskakning i TLS, går utöver Krypterad SNI (ESNI), som bara skyddar servernamnindikering (SNI) i TLS handskakning. Cloudflare forskningsingenjör Christopher Patton skriver,
ESNI tog ett betydande steg framåt, men det är inte vårt mål att uppnå fullständig kryptering av handskakningar. Förutom att vara ofullständig - skyddar den bara SNI - är den sårbar för en handfull sofistikerade attacker, som, även om det är svårt att ta fram, pekar på teoretiska svagheter i protokollets design som måste åtgärdas.
.
I slutändan är målet med ECH att säkerställa det TLS anslutningar till olika originalservrar bakom samma ECH-tjänsteleverantör skiljer sig inte från varandra.
Inte överraskande, eftersom ECH "bara är fullt meningsfullt vid sidan av DoH och i samband med ett CDN (innehållsdistributionsnätverk)" ser Cloudflare sig själv som en sannolik ECH-leverantör. " Du kan läsa mer om ECH i IETF: s förslag till förslag.
OPAQUE lösenord
OPAQUE lösenord - ”någon form av ordlek på Oblivious Pseudo-Random Function (OPRF) kombinerat med Password Authenticated Key Exchange (PAKE)” - är en mekanism för att helt undvika överföring av användarens lösenord till en server. OPAQUE uppnår detta genom att ”låta servern och klienten gemensamt beräkna en saltad hash för att jämföra med ett mellanliggande andra salt. Detta säkerställer att servern inte kan lära sig användarens lösenord under autentisering och att användaren inte lär sig serverns hemliga salt. ”
Du kan ta reda på mycket mer om OPAQUE-lösenord i detta papper [PDF-länk] av forskare vid University of California, Irvine och IBM, och i Cloudflare ingenjör Tatiana Bradleys blogginlägg.
Läckta FTP-referenser som eventuellt är kopplade till SolarWinds Attack
Om du inte har spenderat de senaste veckorna i en avlägsen hytt utanför nätet (inte en dålig idé nu när vi tänker på det), har du nog hört en hel del redan om leveranskedjeangrepp som komprometterade SolarWinds Orion IT-övervakningsprogramvara och många av dess användare inom regeringen och industrin. Ravie Lakshmanans 16 december Historien i Hacker News diskuterar hur angriparna "sannolikt lyckades kompromissa med programvaruuppbyggnaden och kodsigneringsinfrastrukturen på SolarWinds Orion-plattformen så tidigt som i oktober 2019 för att leverera den skadliga bakdörren genom sin mjukvarulanseringsprocess."
Idén ... var att kompromissa med byggsystemet, tyst injicera sin egen kod i programvarans källkod, vänta på att företaget skulle kompilera, signera paket och äntligen kontrollera om deras ändringar dyker upp i de nyligen släppta uppdateringarna som förväntat.
Tidslinjen för oktober 2019 är i linje med säkerhetsforskaren Vinoth Kumer Upptäckten, i november 2019, om en offentlig GitHub-repo som läcker FTP-referenser i ren text för Solarwinds uppdateringsserver - och att den här servern var tillgänglig med lösenordet "solarwinds123." Repo ifråga hade varit öppen för allmänheten "sedan 17 juni 2018", vilket gav blivande angripare gott om tid att upptäcka och utnyttja de läckta uppgifterna.
Naturligtvis hjälpte det inte att SolarWinds också rekommenderade användare att inaktivera säkerhetsåtgärder:
För att göra saken värre kan skadlig kod som läggs till i en Orion-programuppdatering ha gått obemärkt förbi antivirusprogram och andra säkerhetsverktyg på riktade system på grund av SolarWinds egna supportrådgivning, som anger att dess produkter kanske inte fungerar korrekt om inte deras filkataloger är undantagna från antivirusskanningar och grupppolicyobjekt (GPO) -begränsningar.
