OpenSSL ist eine weit verbreitete Open-Source-Softwarebibliothek zur Implementierung sicherer Kommunikation über Computernetzwerke. Wie weit verbreitet? Wenn Sie jemals auf eine HTTPS-Webseite zugegriffen haben, ist die Wahrscheinlichkeit groß, dass Sie dies über eine OpenSSL-Verschlüsselung getan haben. Die Bibliothek bietet kryptografische Funktionen und Protokolle für die Datenverschlüsselung, -entschlüsselung, -authentifizierung und die Überprüfung digitaler Signaturen. OpenSSL ist fast überall zu finden, wo Webserver, E-Mail-Server, virtuelle private Netzwerke (VPNs) und andere Arten der Netzwerkkommunikation gesichert werden müssen.
Wenn man sich den obigen Absatz ansieht, sollte klar werden, wie wichtig OpenSSL für das ordnungsgemäße Funktionieren des Internets ist. Es ist eine kritische Komponente der Sicherheitsinfrastruktur für viele Computersysteme und Anwendungen. Es trägt dazu bei, sensible Daten vor unbefugtem Zugriff zu schützen und trägt dazu bei, die Integrität und Authentizität der Netzwerkkommunikation sicherzustellen. Aus diesem Grund nehmen die Betreuer der Bibliothek Schwachstellen sehr ernst und versuchen, diese so schnell wie möglich zu beheben. Es ist nahezu undenkbar, dass Angreifer Zugang zu den sicheren Kommunikationsleitungen der World-Wide-Web-Infrastruktur erhalten.
In diesem Artikel untersuchen wir die Schwachstellen, die zum OpenSSL-Patch 3.0.7 im Oktober 2022 führten, und sehen uns an, was wir aus der Art und Weise lernen können, wie die OpenSSL-Betreuer das Problem behoben haben.
Die Schwachstellen
Am 25. Oktober 2022 veröffentlichte das OpenSSL-Projekt eine beratend Warnung, dass bald ein neuer Patch verfügbar sein wird, um einige dieser Probleme zu beheben kritischem Schwachstellen. Das Tag „kritisch“ impliziert, dass die Schwachstellen wahrscheinlich ausgenutzt werden können und dass der Diebstahl privater Schlüssel und/oder RCE auf betroffenen Servern wahrscheinlich ist.
Eine Woche später, am 1. November 2022, veröffentlichte das OpenSSL-Projekt sowohl den neuen Patch 3.0.7 als auch den spezifische Schwachstellen Sie wollten das Problem beheben. In der Zwischenzeit wurde die Einstufung der Schwachstellen von „kritisch“ auf „hoher Schweregrad“ herabgestuft.
Was sind also diese Schwachstellen?
CVE-2022-3602 – X.509-E-Mail-Adresse 4-Byte-Pufferüberlauf – Bei der Überprüfung des X.509-Zertifikats, insbesondere bei der Überprüfung von Namenseinschränkungen, kann ein Pufferüberlauf von vier Bytes auftreten. Vier vom Angreifer kontrollierte Bytes auf dem Stapel können von einem Angreifer mit einer böswilligen E-Mail-Adresse überlaufen werden. Durch diesen Pufferüberlauf kann es zu einem Absturz (was zu einem Denial-of-Service führt) oder möglicherweise zur Remote-Codeausführung kommen. Ursprünglich wurde es als kritisch eingestuft, aber weitere Tests zeigten, dass zahlreiche Plattformen Stapelüberlaufschutzmaßnahmen verwenden, um das Risiko einer Remotecodeausführung zu verringern.
CVE-2022-3786 – X.509-Pufferüberlauf für E-Mail-Adressen mit variabler Länge – Bei der Überprüfung von X.509-Zertifikaten, insbesondere bei der Überprüfung von Namenseinschränkungen, kann es zu einem Pufferüberlauf kommen. Ein Angreifer kann eine bösartige E-Mail-Adresse in einem Zertifikat erstellen, um den Stapel mit einer beliebigen Anzahl von Bytes zu füllen, die das Zeichen „.“ enthalten, das der Dezimalzahl 46 entspricht. Aufgrund dieses Pufferüberlaufs kann es zu einem Absturz kommen (der einen Fehler verursacht). Denial of Service).
Nur um noch einmal zu betonen, wie ernst diese Schwachstellen sindies sind, CISA, die US-amerikanische Agentur für Cybersicherheit und Infrastruktursicherheit, veröffentlicht an beratend am selben Tag wie OpenSSL, EncouraGeben Sie Benutzern und Administratoren die Möglichkeit, dies zu überprüfen OpenSSL-Dokumentation und ggf. Upgrade auf den neuen Patch 3.0.7.
Wie bereits erwähnt, wäre RCE (Remote Code Execution) auf Betriebssystemen oder Mailservern, auf denen OpenSSL ausgeführt wird, sehr schlecht, daher ist es sinnvoll, nur das offenzulegen Sicherheitslücken, sobald ein geeigneter Patch gefunden und angeboten wurde.
What Happens Next
Sobald die erste Empfehlung veröffentlicht wurde, begannen die Leute zu streiten. „Keine Panik“ war ein gängiger Satz damals Dies zeigt, wie ernst die Menschen die Nachrichten über OpenSSL nahmen Schwachstellen.
Sobald das Advisory veröffentlicht wurde, waren alle relevanten Stakeholder damit beschäftigt, herauszufinden, welche Version von OpenSSL in ihrem Server, Betriebssystem, ihrer Anwendung, ihrem Paket usw. verwendet wurde. Über die reine interne OpenSSL-Nutzung hinaus mussten die Leute auch herausfinden, ob eine ihrer dritten Versionen verwendet wurde Partyanbieter oder Dienstanbieter verwendeten eine anfällige OpenSSL-Version. Wenn Sie damals nicht sicher waren, welche Version Sie verwendeten, oder wenn Sie nicht sicher waren, welche Version Ihre Anbieter und Dienstanbieter verwendeten, galt es als sicherer, eine Anwendung offline zu nehmen, anstatt potenzielle RCE zu riskieren.
Da das Advisory den Zeitplan für den Patch im Voraus vorgab, gaben die Leute Zeit, sich mit ihrer eigenen Infrastruktur und der ihrer Anbieter und Dienstanbieter auseinanderzusetzen. Die Idee bestand darin, alles Notwendige an der Infrastruktur so zu planen, dass das Upgrade bei Bedarf sofort nach der Veröffentlichung des Patches erfolgen kann.
Wie würden Sie damit umgehen?
Nehmen wir nun an, Sie sind Ingenieur in einem Unternehmen, das Ihres Wissens nach OpenSSL auf seinen Servern verwendet. Sobald die Empfehlung veröffentlicht wird, müssen Sie herausfinden, welche Version der Bibliothek wo verwendet wird (einschließlich etwaigem Legacy-Code, falls dieser noch ausgeführt wird) und dann dasselbe für alle Ihre Anbieter oder Dienstanbieter herausfinden.
Hier ist ein SBOM könnte wirklich nützlich sein. Eine SBOM steht für Software Bill Of Materials und ist eine Liste aller Komponenten und Softwareabhängigkeiten, aus denen ein bestimmtes Softwareprodukt besteht. Eine SBOM enthält normalerweise Informationen wie die Namen und Versionen aller Softwarekomponenten (sehen Sie, wohin ich damit gehe), ihre Quellen und Lizenzen sowie alle bekannten Schwachstellen oder Sicherheitsprobleme, die mit jeder Komponente verbunden sind.
Wenn Sie als verantwortlicher Ingenieur dafür gesorgt hätten, dass für jedes Ihrer Produkte eine aktualisierte SBOM vorhanden ist, wäre es eine einfache Sache, die SBOM-Datei zu durchsuchen, um herauszufinden, wo Sie OpenSSL verwenden und welche Version verwendet wird . Wenn Sie auch darauf geachtet hätten, bei jedem Anbieter oder Dienstleister, mit dem Ihr Unternehmen zusammenarbeitet, nach aktualisierten SBOMs zu fragen, hätten Sie die gleiche Suche auch dort durchführen können.
Da Ihnen mitgeteilt wurde, dass die Schwachstellen nur Versionen zwischen 3.0.0 und 3.0.6 betreffen, müssen Sie lediglich überprüfen, welche Versionen Sie ausgeführt haben, um zu wissen, welche Anwendungen entfernt oder mit dem neuen Patch 3.0.7 aktualisiert werden mussten. XNUMX.
Schauen Sie sich dies an, um zu zeigen, wie umfangreich die Liste bekannter Betriebssysteme und Unternehmensanwendungen ist, die OpenSSL verwenden Liste als öffentlicher Dienst veröffentlicht, damit die Menschen wissen, wie besorgt sie sein sollten.
Wie kann ein evidenzbasierter Sicherheits-Hub helfen?
Als Teil der sich entwickelnden Cybersicherheitslandschaft, einschließlich solcher weitreichender Schwachstellen, erleben wir gerade die Entwicklung der Anwendungssicherheit zur Software-Lieferkettensicherheit. Um diese Probleme zu lösen, wurde eine neue Generation von Werkzeugen und Technologien entwickelt. Durch die Bereitstellung einer evidenzbasierten Plattform zur kontinuierlichen Sicherung der Codesicherheit, die die Zuverlässigkeit des Softwareentwicklungslebenszyklus und der Softwarekomponenten gewährleisten kann, unterstützen automatisierte Tools und Lösungen Unternehmen dabei, ein neues Sicherheitsniveau zu erreichen. Durch die kontinuierliche Erfassung von Abhängigkeiten und Schwachstellen ist es einfacher, Patches zu beheben oder anzuwenden, sobald diese verfügbar sind.
Schreiber ist ein Zentrum für Software-Supply-Chain-Sicherheit. Es sammelt Beweise und präsentiert sie für jeden Build, der Ihre CI/CD-Pipeline durchläuft. Das Ziel der Scribe-Lösung bestand darin, die Einhaltung von EU- und US-Vorschriften und Best Practices zur Verbesserung der Softwaretransparenz und zur Förderung des Vertrauens zwischen Softwareentwicklern und -benutzern zu erleichtern. Die Plattform ermöglicht die Erstellung und Weitergabe umfassender SBOMs sowie anderer Sicherheitserkenntnisse. Darüber hinaus kann die Plattform bestätigen, dass der von Ihnen angezeigte Build sowohl dem SSDF-Framework des NIST als auch den SLSA Level 3-Anforderungen entspricht. Sie müssen nicht mehr herumfummeln und herausfinden, wo Sie welche Version welcher Bibliothek verwenden, da Sie über einen Beweisspeicher mit einer SBOM für jeden Ihrer Builds verfügen. Das herauszufinden ist jetzt so einfach wie die Suche nach einem bestimmten Satz in einem Textdokument.
Ein letztes Wort: Seien Sie auf die nächste große Offenlegung von Sicherheitslücken vorbereitet
Die OpenSSL-Projektgeschichte von Patch 3.0.7 bietet uns zwei gleichermaßen wichtige Standpunkte zum Umgang mit potenziell kritischen Schwachstellen.
Auf der betroffenen Seite – dem Unternehmen oder Projekt, das möglicherweise durch diese Schwachstellen gefährdet war – haben wir Transparenz geschaffen. Sie geben Informationen, die Schaden anrichten könnten, nicht sofort weiter, geben aber alles Mögliche offen, sobald sie sich eines Problems bewusst werden. Sie bieten nicht nur einen Zeitplan für die Behebung sowie möglichst viele Informationen über das Problem. Sobald ein Patch oder eine Abhilfe vorhanden ist, scheuten sie sich nicht, genau offenzulegen, was falsch war und wie es möglicherweise ausgenutzt werden könnte. Diese Art der Transparenz fördert Vertrauen. Benutzer und Kunden möchten wissen und das Gefühl haben, dass sich das Unternehmen mehr oder zumindest genauso sehr um sie kümmert wie um das Endergebnis oder den Vorstand.
Im Jahr 2014 wurde das OpenSSL-Projekt Opfer eines kritischen Fehlers namens „Herzbluten' – ein kritischer Fehler in der TLS/DTLS-Implementierung von OpenSSL, der es einem Angreifer ermöglichte, Geheimnisse wie Verschlüsselungsschlüsselmaterial, Passwörter und andere sensible Informationen von betroffenen Servern zu erhalten. Heartbleed zeigte, was eine kritische Schwachstelle in OpenSSL bewirken kann, da sie eine Vielzahl von Programmen und Linux-Distributionen betraf. Der Versuch, jedes anfällige System zu identifizieren und zu reparieren, bereitete den Sicherheitsteams monatelang Kopfzerbrechen. Die Implementierung eines Tools wie eines SBOM, das das Aktualisieren und Patchen Ihrer Software schneller und einfacher machen könnte, wäre ein Segen für das Cybersicherheitsteam eines jeden Unternehmens.
Was die Problembehebung betrifft, ist es wichtig, genau zu wissen, womit Sie arbeiten müssen und welche Version der Pakete Sie wo verwenden, um einen solchen potenziellen Notfall bewältigen zu können. Nehmen wir als Beispiel Log4J: Einige Unternehmen versuchen immer noch herauszufinden, ob sie mehr als ein Jahr nach ihrer Entdeckung von dieser Schwachstelle betroffen sind oder nicht.
Die Tatsache, dass Sie sich nicht nur um Ihre Software und Server kümmern müssen, sondern auch um die aller Drittanbieter, die Sie nutzen, oder aller Dienstanbieter, mit denen Sie zusammenarbeiten, sogar über API-Verbindungen, bedeutet, dass wir alle von uns müssen wirklich ein Netz des Vertrauens zwischen uns aufbauen. Dieses Vertrauen sollte so weit wie möglich auf stichhaltigen Beweisen beruhen. Erstellen und verfolgen Sie Ihre eigenen SBOMs und die aller Unternehmen, mit denen Sie Geschäfte machen, geben Sie diese SBOMs weiter und zeigen Sie guten Willen bei der Ankündigung und Behebung aller ausnutzbaren Schwachstellen, die Ihnen bekannt werden.
Wir alle müssten zusammenarbeiten, um zu einer Welt zu gelangen, in der das Teilen solcher Beweise genauso selbstverständlich ist wie das Teilen der neuesten PR des Unternehmens in den sozialen Medien. Ohne dieses Vertrauen bereiten wir nur die Bühne für die nächste große kritische Schwachstelle, die die vernetzte Infrastruktur, an deren Aufrechterhaltung wir alle so hart arbeiten, zerstören wird.
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Zusammenhängende Artikel
