en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Sicherheitsübersicht Januar 2020

Frohes Neues Jahr von SSL.com! Willkommen zu dieser Ausgabe der Sicherheitsübersicht von SSL.com, die eine Auswahl der Entwicklungen von SSL / im Januar zeigt.TLS, digitale Zertifikate und Netzwerksicherheit. In dieser Ausgabe behandeln wir:

SHA-1: Kollision mit ausgewähltem Präfix

Es ist keine Neuigkeit, dass der kryptografische SHA-1-Hash-Algorithmus anfällig ist. Vor etwa drei Jahren haben Google-Forscher eine Kollision mit festem Präfix mit dem Algorithmus, es in einen Zeitlupentod für ernsthafte kryptografische Verwendung senden. Folglich wurde es zugunsten des weniger anfälligen SHA-2 so gut wie aufgegeben. Diesen Monat wurde es schlimmer mit einem gewähltes Präfix Kollision, wie berichtet von Ars Technica:

Die neue Kollision bietet Angreifern mehr Optionen und Flexibilität als mit der vorherigen Technik. Es ist praktisch, PGP-Verschlüsselungsschlüssel zu erstellen, die bei digitaler Signatur mit dem SHA1-Algorithmus ein ausgewähltes Ziel darstellen. Im Allgemeinen wird der gleiche Hash für zwei oder mehr vom Angreifer ausgewählte Eingaben erzeugt, indem Daten an jede von ihnen angehängt werden. Der am Dienstag enthüllte Angriff kostet ebenfalls nur 45,000 US-Dollar. Im Gegensatz dazu erlaubte der im Jahr 2017 veröffentlichte Angriff keine Fälschungen bestimmter vorgegebener Dokumentpräfixe und wurde auf der Web Services-Plattform von Amazon mit Kosten zwischen 110,000 und 560,000 US-Dollar bewertet, je nachdem, wie schnell Gegner ihn ausführen wollten.

Dieser Angriff ist signifikant. Obwohl viele den SHA-1-Algorithmus aufgegeben haben, ist er noch nicht vollständig veraltet (zum Beispiel wird er weiterhin zur Zertifizierung von PGP-Schlüsseln im älteren 1.4-Zweig von GnuPG verwendet). Dies macht diesen Verstoß zu einem ernsthaften Geschäft, und Experten wiederholen die Bitte, die Verwendung von SHA-1 für Zertifikate oder Authentifizierung aufzugeben.

Das Mitnehmen von SSL.com: SHA1 war lange Zeit unsicher und seriöse Zertifizierungsstellen (einschließlich SSL.com) haben seit mehreren Jahren keine SHA-1-Zertifikate mehr ausgestellt. Diese Kollision stellt einen neuen, besorgniserregenden Tiefpunkt in der Unsicherheit von SHA-1 dar, und wir stimmen den Forschern zu, wenn sie angeben, dass sie den Benutzern dringend empfehlen, die SHA1-Unterstützung zu entfernen, um dies zu vermeiden Downgrade-Angriffe"

Hardware-Hersteller misshandelt private Schlüssel

As entdeckt von Nick Starke und Tom Pohl und berichtet von Shaun Nichols in Das RegisterNetgear hatte kürzlich eine ziemlich peinliche Sicherheitsverletzung. Gültige, signierte Zertifikate wurden - zusammen mit privaten Schlüsseln - in die Router-Firmware eingebettet, die zum öffentlichen Download zur Verfügung stand, und mit Geräten geliefert. Diese Informationen könnten verwendet werden, um die HTTPS-Verbindungen der Benutzer zu ihren Routern zu entführen, und scheinen ein Versuch gewesen zu sein, ihren Kunden auf Kosten der Sicherheit die Arbeit zu erleichtern. Wie von Shaun Nichols berichtet:

Der Fehler ist ein Ergebnis von Netgears Ansatz in Bezug auf Sicherheit und Benutzerfreundlichkeit. Besitzer von Netgear-Geräten sollten bei der Konfiguration ihres Kits https://routerlogin.net oder https://routerlogin.com besuchen. Der Router des Netzwerks versucht sicherzustellen, dass diese Domänennamen in die IP-Adresse des Geräts im lokalen Netzwerk aufgelöst werden. Um eine HTTPS-Verbindung herzustellen und Beschwerden von Browsern über die Verwendung von unsicherem HTTP und nicht vertrauenswürdigen Zertifikaten zu vermeiden, muss der Router ein gültiges HTTPS-Zertifikat für die Router-Anmeldung erstellen .net oder routerlogin.com, denen Browser vertrauen. Um kryptografisch zu beweisen, dass das Zertifikat beim Herstellen einer Verbindung legitim ist, muss der Router den privaten Schlüssel des Zertifikats verwenden. Dieser Schlüssel wird ungesichert in der Firmware gespeichert, sodass jeder ihn extrahieren und missbrauchen kann.

Zu diesem Zeitpunkt verfügt das Unternehmen über einige Lösungen, die natürlich wird derzeit online diskutiert.

Das Mitnehmen von SSL.com: Hardwareanbieter sollten ihre privaten Schlüssel an einem anderen Ort als der herunterladbaren Firmware speichern (und wir können Hilfe damit). In der Zwischenzeit müssen diese Zertifikate widerrufen werden.

NSA stellt in Windows 10 eine kritische kryptografische Sicherheitsanfälligkeit fest

Die National Security Agency hat in Windows 10 eine so genannte "kritische Sicherheitsanfälligkeit" festgestellt, die sich auf die kryptografische Funktionalität auswirkt. Insbesondere wirkt sich die Sicherheitsanfälligkeit auf HTTPS-Verbindungen, signierte Dateien und E-Mails sowie signierten Code aus. Aus diesem Grund empfiehlt die Agentur den Benutzern, diese Sicherheitsanfälligkeit zu verringern, indem sie alle Patch-Dienstag-Patches für Januar 2020 so schnell wie möglich installieren. Sie können mehr von der NSA lesen auf ihrer Website.

Die als "breit" bezeichnete Sicherheitslücke hat die Forscher verunsichert. Als Dan Goodin bei Ars Technica , erklärtDie Sicherheitsanfälligkeit nutzt eine Lücke aus, die die Vertrauenskette durchbricht:

Der Fehler betrifft die Art und Weise, wie die neuen Windows-Versionen die Gültigkeit von Zertifikaten überprüfen, die Kryptografie mit elliptischen Kurven verwenden. Während die anfälligen Windows-Versionen drei ECC-Parameter prüfen, verifizieren sie keinen vierten, entscheidenden Parameter, der als Basispunktgenerator bekannt ist und in Algorithmen häufig als "G" dargestellt wird. Dieser Fehler ist eher auf die Implementierung von ECC durch Microsoft als auf Fehler oder Schwächen in den ECC-Algorithmen selbst zurückzuführen.

Angreifer können den Fehler ausnutzen, indem sie den öffentlichen Schlüssel eines Stammzertifikats extrahieren, das standardmäßig in Windows ausgeliefert wird. Diese Zertifikate werden als root bezeichnet, da sie großen Zertifizierungsstellen gehören, die entweder ihre eigenen ausstellen TLS Zertifikate oder validieren zwischengeschaltete Zertifizierungsstellen, die Zertifikate im Namen der Stammzertifizierungsstelle verkaufen. Jedes Stammzertifikat funktioniert, solange es mit einem ECC-Algorithmus signiert ist. Der Angreifer untersucht den spezifischen ECC-Algorithmus, der zum Generieren des öffentlichen Schlüssels des Stammzertifikats verwendet wird, und erstellt einen privaten Schlüssel, der alle Zertifikatparameter für diesen Algorithmus außer kopiert für den Punktgenerator. Da anfällige Windows-Versionen diesen Parameter nicht überprüfen können, akzeptieren sie den privaten Schlüssel als gültig. Damit hat der Angreifer ein Windows-vertrauenswürdiges Stammzertifikat gefälscht, mit dem jedes einzelne Zertifikat geprägt werden kann, das zur Authentifizierung von Websites, Software und anderen vertraulichen Eigenschaften verwendet wird.

Kurz gesagt, dieser Fehler kann von bösen Jungs ausgenutzt werden, um den Eindruck zu erwecken, dass böswillige ausführbare Dateien aus vertrauenswürdigen, verifizierten Quellen stammen, und um digitale Zertifikate zu fälschen. Besorgt? Hier ist ein Link zum Testen wenn Sie für den Angriff anfällig sind.

Das Mitnehmen von SSL.com: Dies ist eine großartige Gelegenheit, den Ratschlägen der NSA zu folgen und Microsoft zu installieren Flicken das wird das Problem beheben. Wie sie bemerken, "ist die schnelle Einführung des Patches die einzige bekannte Abschwächung zu diesem Zeitpunkt und sollte der Hauptfokus für alle Netzwerkbesitzer sein." Wir sind damit einverstanden Catalin Cimpanu von ZD Net dass dieser "so schlimm wie es nur geht" ist. Hier ist ein Link zum Fix.
Vielen Dank, dass Sie sich für SSL.com entschieden haben! Bei Fragen wenden Sie sich bitte per E-Mail an Support@SSL.com, Anruf 1-877-SSL-SECUREoder klicken Sie einfach auf den Chat-Link unten rechts auf dieser Seite.


Abonnieren Sie den Newsletter von SSL.com

Verpassen Sie keine neuen Artikel und Updates von SSL.com