Beveiligingsoverzicht van december 2020

SSL.com wenst al onze klanten en bezoekers een gelukkig, veilig en gezond vakantieseizoen, en een voorspoedig 2021! We hopen dat het nieuwe jaar iets minder wordt, umm ... interessant dan 2020 in sommige opzichten is geweest, maar we zijn er zeker van dat er geen maand voorbij zal gaan zonder belangrijk nieuws uit de wereld van netwerkbeveiliging, digitale certificaten en PKI.

OpenSSL DoS-kwetsbaarheid

We hebben dit probleem behandeld in een blogpost eerder deze maand, maar het is voor herhaling vatbaar. Een zeer ernstige kwetsbaarheid in OpenSSL werd ontdekt dat alle versies van OpenSSL 1.0.2 en 1.1.1 vóór 1.1.1i beïnvloedt. Dit beveiligingslek kan worden misbruikt om een ​​Denial of Service-aanval (DoS) te veroorzaken. OpenSSL 1.1.1i, uitgebracht op 8 december 2020, bevat een oplossing.

OpenSSL-gebruikers moeten hun installaties zo snel mogelijk bijwerken. Er zijn twee paden om de fix toe te passen:

  • Gebruikers van OpenSSL 1.1.1 en niet-ondersteunde 1.0.2-gebruikers moeten upgraden naar 1.1.1i.
  • Klanten met premiumondersteuning van OpenSSL 1.0.2 moeten upgraden naar 1.0.2x.

OpenSSL is momenteel geïnstalleerd op de meeste HTTPS-webservers. U kunt meer lezen over de kwetsbaarheid in SSL.com's blog, en in de OpenSSL Project's Beveiligingsadvies.

De afhaalmaaltijd van SSL.com: Als u een OpenSSL-gebruiker bent en dit nog niet heeft gedaan, lees dan OpenSSL's adviserend over de kwetsbaarheid en update uw installatie zo snel mogelijk.

Cloudflare pleit voor nieuwe privacyprotocollen

Tim Anderson gerapporteerd in The Register dat Cloudflare "aandringt op de acceptatie van nieuwe internetprotocollen die volgens hem een ​​'privacy-respecterend internet' mogelijk zullen maken." Deze protocollen omvatten privacy-verbeterde DNS via HTTPS (DoH), aanvullende codering voor de TLS handdruk, en beveiligingsverbeteringen voor het omgaan met gebruikerswachtwoorden.

Onwetend DoH

DNS via HTTPS (DoH) pakt een zwakke schakel in internetprivacy aan door DNS-vragen en antwoorden te versleutelen, die in het verleden als leesbare tekst werden verzonden. Onbewust DoH (ODoH)  gaat een stap verder met DNS-privacybescherming door te voorkomen dat DoH-servers het IP-adres van de klant kennen:

De essentie van ODoH is dat het een netwerkproxy introduceert tussen de client en de DoH-server. De proxy heeft geen zicht op de DNS-query, die alleen kan worden gelezen door de DoH-server. De server heeft geen kennis van het IP-adres van de klant. De vraag is privé, op voorwaarde dat de proxy en de server niet samenspannen.

Cloudflare heeft al ondersteuning aangekondigd voor ODoH, dat is ontwikkeld door ingenieurs bij Cloudflare, Apple en Fastly. U kunt meer leren door af te rekenen hun krant op arxiv.org.

Versleutelde client Hallo (ECH)

Versleutelde client Hallo (ECH) biedt verbeterde handshake-encryptie in TLS, verder gaan Versleutelde SNI (ESNI), die alleen Server Name Indication (SNI) in het TLS handdruk. Cloudflare-onderzoeksingenieur Christopher Patton schrijft,

Hoewel ESNI een belangrijke stap voorwaarts heeft gezet, voldoet het niet aan ons doel om volledige handshake-encryptie te bereiken. Behalve dat het onvolledig is - het beschermt alleen SNI - is het kwetsbaar voor een handvol geavanceerde aanvallen, die, hoewel moeilijk te realiseren, wijzen op theoretische tekortkomingen in het ontwerp van het protocol die moeten worden aangepakt.
...
Uiteindelijk is het doel van ECH om daarvoor te zorgen TLS verbindingen die zijn gemaakt met verschillende oorspronkelijke servers achter dezelfde ECH-serviceprovider zijn niet van elkaar te onderscheiden.

Het is niet verwonderlijk dat, aangezien ECH "alleen volkomen zinvol is naast DoH en in de context van een CDN (content distributienetwerk)", Cloudflare zichzelf ziet als een waarschijnlijke ECH-provider. " U kunt meer over ECH lezen in de IETF's conceptvoorstel.

OPAQUE wachtwoorden

OPAQUE wachtwoorden - "een soort woordspeling op Oblivious Pseudo-Random Function (OPRF) gecombineerd met Password Authenticated Key Exchange (PAKE)" - is een mechanisme om de overdracht van het wachtwoord van een gebruiker naar een server volledig te vermijden. OPAQUE bereikt dit door “de server en de klant gezamenlijk een salted hash te laten berekenen om te vergelijken met een tussenliggende second salt. Dit zorgt ervoor dat de server het wachtwoord van de gebruiker niet kan leren tijdens authenticatie en dat de gebruiker het geheime zout van de server niet leert. "

U kunt veel meer over OPAQUE-wachtwoorden vinden in dit papier [PDF-link] door onderzoekers van de University of California, Irvine en IBM, en in Cloudflare-ingenieur Tatiana Bradley's blogpost.

De afhaalmaaltijd van SSL.com: We zijn altijd enthousiast om meer te weten te komen over nieuwe netwerkbeveiligingsprotocollen, vooral als ze betrekking hebben op PKI en digitale certificaten. We zullen u meer informatie geven over deze en andere beveiligings- en privacyverbeteringen zodra ze verschijnen en worden geïmplementeerd.

Gelekte FTP-inloggegevens mogelijk gekoppeld aan SolarWinds Attack

Tenzij je de afgelopen weken in een afgelegen, off-grid hut hebt doorgebracht (geen slecht idee nu we er aan denken), heb je waarschijnlijk al behoorlijk wat gehoord over de supply chain aanval die de Orion IT-bewakingssoftware van SolarWinds en veel van zijn gebruikers bij de overheid en de industrie in gevaar bracht. Ravie Lakshmanan's 16 december verhaal in de Hacker News bespreekt hoe de aanvallers "waarschijnlijk al in oktober 2019 de software-build en code-ondertekeningsinfrastructuur van het SolarWinds Orion-platform in gevaar konden brengen om de kwaadaardige achterdeur te leveren via het software-releaseproces."

Het idee ... was om het build-systeem in gevaar te brengen, stilletjes hun eigen code in de broncode van de software te injecteren, te wachten tot het bedrijf compileert, pakketten te ondertekenen en ten slotte te verifiëren of hun wijzigingen zoals verwacht in de nieuw uitgebrachte updates verschijnen.

De tijdlijn van oktober 2019 komt overeen met beveiligingsonderzoeker Vinoth Kumer ontdekking, in november 2019, van een openbare GitHub-repo die FTP-inloggegevens in platte tekst lekte voor de updateserver van Solarwinds - en dat deze server toegankelijk was met het wachtwoord 'solarwinds123'. De repo in kwestie was "sinds 17 juni 2018" open voor het publiek, waardoor potentiële aanvallers voldoende tijd hadden om de gelekte inloggegevens te ontdekken en te exploiteren.

Het hielp natuurlijk niet dat SolarWinds gebruikers ook adviseerde om beveiligingsmaatregelen uit te schakelen:

Om het nog erger te maken, is het mogelijk dat kwaadwillende code die aan een Orion-software-update is toegevoegd, onopgemerkt is gebleven door antivirussoftware en andere beveiligingstools op gerichte systemen, dankzij de eigen software van SolarWinds. ondersteunend advies, waarin staat dat zijn producten mogelijk niet correct werken, tenzij hun bestandsmappen zijn vrijgesteld van antivirusscans en beperkingen van groepsbeleidsobjecten (GPO).

De afhaalmaaltijd van SSL.com: Code ondertekening is een belangrijke, zelfs verplichte stap om het vertrouwen te behouden bij het distribueren van software naar klanten, maar het hangt af van een veilige omgeving voor succes. Het beschermen van cruciale servers met zwakke, gemakkelijk te raden wachtwoorden en / of het onbedoeld vrijgeven van inloggegevens in platte tekst aan het publiek, laat een deur open voor aanvallen die uw build-systeem misbruiken om ondertekende, maar trojaanse software vrij te geven.

Abonneer u op de nieuwsbrief van SSL.com

Mis geen nieuwe artikelen en updates van SSL.com

We willen graag uw feedback

Vul onze enquête in en laat ons uw mening over uw recente aankoop weten.