Warum Ihre Server immer noch von (einem) Heartbleed betroffen sein können - und was zu tun ist
Seit der Entdeckung von Heartbleed, einer gefährlichen OpenSSL-Sicherheitslücke, von der Millionen von Systemen betroffen waren, ist etwa ein Jahrzehnt vergangen - und eine Sicherheitslücke, die ihren Weg in die Medien fand.
Geschichte, richtig? Die Technologie entwickelt sich schnell... zehn Jahre sind eine lange Zeit... und diese Schwachstelle ist längst verschwunden, oder?
Falsch.
Wir veröffentlichen einen weiteren Artikel über Heartbleed, weil es uns immer noch beschäftigt. Ja, wenn man bedenkt, wie schnell ein Patch veröffentlicht wurde, und wenn man das schnelle Tempo der technologischen Entwicklung berücksichtigt, sollte Heartbleed eigentlich schon in den Hintergrund getreten sein.
Und wenn Sie Ihre Systeme jedes Mal rechtzeitig gepatcht haben, müssen Sie sich keine Sorgen machen.
Was aber, wenn Sie irgendwo einen Patch übersehen haben? Was ist, wenn Ihr Unternehmen vor kurzem mit einem anderen Unternehmen fusioniert hat, bei dem das Patching nicht auf dem neuesten Stand war? Oder was ist, wenn die brandneue Technologielösung ein Stück veralteten Code enthält?
Wie sich herausstellt, ist es immer noch üblich, dass Systeme für Heartbleed anfällig sind. In diesem Artikel geben wir einen kurzen Überblick über Heartbleed und seine Geschichte. Außerdem verweisen wir auf aktuelle Untersuchungen, die zeigen, dass unzählige Systeme immer noch dem Risiko eines Angriffs ausgesetzt sind, der durch einen Heartbleed-Exploit ermöglicht wird.
Außerdem erfahren Sie, wie Sie ganz einfach überprüfen können, ob Ihre OpenSSL-Bibliotheken für Heartbleed anfällig sind, und was Sie tun können, um sich gegen diese gefährliche Sicherheitslücke zu schützen.
Was genau ist der "Heartbleed-Bug"? Ein kurzer Überblick
Im Jahr 2014 entdeckten Forscher, dass die OpenSSL-Versionen 1.0.1 bis 1.0.1f eine Art von Fehler bei der Speicherverwaltung enthielten, der als fehlende Überprüfung der Grenzen. Mit anderen Worten: Der OpenSSL-Code prüfte nicht, ob die in den Speicher eingegebenen Daten die zugewiesene Puffergröße nicht überschreiten.
Ein Angreifer kann daher den OpenSSL-Dienst dazu bringen, einen 64-KB-Puffer zuzuweisen, nur um dann Daten zu senden, die diese Puffergröße überschreiten. Auf diese Weise kann der Angreifer Daten in 64-KB-Schritten aus dem Rechner des Opfers abfließen lassen (oder ausbluten). Dies ist nur eine kurze Beschreibung - weitere Einzelheiten zu diesem Exploit finden Sie in dem ausführlichen Artikel des CSO Magazine ausführlichen Artikel hier.
Die Schwachstelle wurde Heartbleed genannt, weil die Daten Bit für Bit abgegriffen werden müssen und weil der Angriff während eines so genannten "Heartbeat" erfolgt - einer Impulsnachricht, die zwischen zwei Servern gesendet wird, um zu bestätigen, dass der verbundene Server noch am Leben ist.
Die Möglichkeiten zur Ausnutzung der Heartbleed-Schwachstelle waren breit gefächert und schwerwiegend. Angreifer können alles stehlen, von Kryptographieschlüsseln und Benutzeranmeldeinformationen bis hin zu privaten Dokumenten und Kommunikation. Ein Angreifer kann dies alles erreichen, ohne im Besitz von Zugangsdaten zu sein - und ohne auch nur eine Spur zu hinterlassen.
Auch wenn 64 KB nicht nach viel klingen, öffnen sie doch die Tür für große Sicherheitslücken. In einem erschreckenden Beispiel für einen Heartbleed-Hack gelang es einem Angreifer 4,5 Millionen Patientendaten zu stehlen von Community Health Systems im Jahr 2014 zu stehlen.
Heartbleed ist immer noch im Freien
Okay, das war im Jahr 2014. Warum ist Heartbleed immer noch einen Artikel wert? Ganz einfach, weil es eine große Anzahl von Anwendungen und Servern gibt, die auf OpenSSL angewiesen sind, was zusammen mit der Tendenz zu inkonsistenten Patches dazu führt, dass eine große Anzahl von Diensten immer noch anfällig ist.
Als Heartbeat entdeckt wurde, berichtete Netcraft, dass etwa 17 % der sicheren Webserver verwundbar warendarunter einige der beliebtesten Dienste der Welt. Das ist eine riesige Anzahl von Servern.
Patches für OpenSSL wurden zwar sofort nach Bekanntwerden der Sicherheitslücke veröffentlicht, aber das bedeutet nicht, dass Heartbleed bereits Geschichte ist.
Sicherheitsforscher weisen nach wie vor auf Risiken im Zusammenhang mit Heartbleed hin. Vor kurzem hat der japanische Technologieriese NTT in einem Forschungsbericht darauf hingewiesen darauf hin, dass Heartbleed einer der Hauptgründe dafür ist, dass OpenSSL immer noch zu den Diensten gehört, die am häufigsten von Hackern angegriffen werden.
Ähnlich im November 2020, ein Forscher des SANS Internet Storm Center die Shodan-Suchmaschine und entdeckte, dass mehr als 200.000 Rechner immer noch anfällig sind für CVE-2014-0160anfällig sind, der offiziellen Kennung der Heartbleed-Sicherheitslücke. Durch einen Validierungsprozess stellte der Forscher fest, dass Shodan mit seinen Einschätzungen größtenteils richtig lag.
Auch wenn es Abhilfemaßnahmen gibt, ist Heartbleed immer noch ein Problem. Wenn Sie den Bibliotheks-Patching-Service von TuxCare, LibraryCarenutzen, müssen Sie sich kaum Sorgen machen, da Ihre Bibliotheken immer auf dem neuesten Stand sind. In Ermangelung einer automatisierten und rebootlosen Lösung zum Patchen von Bibliotheken müssen Sie jedoch prüfen, wie Ihr Betrieb aufgrund einer OpenSSL-Bibliotheksschwachstelle weiterhin für Heartbleed anfällig sein kann.
Patching ist die Lösung... aber auch das Problem
Der Grund, warum Heartbleed immer noch im Umlauf ist, liegt keineswegs an einem Mangel an Patches. Für die meisten Dienste, die auf OpenSSL angewiesen sind, steht ein Patch zur Beseitigung der Heartbleed-Bedrohung zur Verfügung. Wenn man den Patch anwendet, ist die Heartbleed-Bedrohung verschwunden - so einfach ist das, so die Theorie.
Doch ganz so einfach ist es aus mehreren Gründen nicht. In einer Unternehmensumgebung reicht es nicht aus, einfach einen Patch auszulösen und einen Dienst oder ein Gerät neu zu starten. Das Patchen erfordert eine geplante Ausfallzeit und erhebliche Ressourcen, die von einer Reihe von Experten, darunter Sysadmins, DBAs und Linux-Administratoren, aufgebracht werden müssen. Bei diesem Prozess treten viele Probleme auf:
- Ungewissheit darüber, welche Bibliotheken aktualisiert werden: Bei der Durchführung eines Patch-Prozesses ist oft ein gewisses Maß an Automatisierung erforderlich, was dazu führen kann, dass Sysadmins nicht wissen, welche Bibliotheken während des Prozesses gepatcht wurden. Dies kann zu ausgedehnten, unnötigen Neustarts und zusätzlichen Ausfallzeiten führen - was wiederum eine Unterbrechung des umfassenden Patchings zur Folge haben kann.
- Nicht konsequentes Patchen: Eine weitere Gefahr besteht darin, dass einige Bibliotheken nicht gepatcht werden, weil die Administratoren nicht wissen, dass diese Bibliotheken gepatcht werden müssen. Ein vollständiger und umfassender Katalog von Bibliotheken kann schwer zu erstellen sein, und alles, was es für einen Verstoß braucht, ist eine einzige ungepatchte Bibliothek. Auch das manuelle Patchen kann schnell dazu führen, dass Bibliotheken übersehen werden.
- Schwachstelle Fenster: Patches werden oft schnell veröffentlicht, aber weniger schnell angewendet. Der Grund dafür ist die Schwierigkeit, Ausfallzeiten einzuplanen und alle technischen Voraussetzungen für die Anwendung eines Patches zu schaffen. So bleibt ein Zeitfenster zwischen dem Zeitpunkt, an dem eine Schwachstelle gemeldet wurde, und dem Zeitpunkt, an dem diese Schwachstelle vom Endbenutzer gepatcht wird. Während dieses Zeitfensters sind die Systeme Ihres Unternehmens anfällig für Angriffe.
Es ist klar, dass das Patchen schnell zu einer "Hit and Miss"-Angelegenheit werden kann. Auch Jahre nach der Entdeckung von Heartbleed ist es keineswegs ausgeschlossen, dass Ihr Unternehmen es versäumt hat, gründliche Patches zum Schutz vor Heartbleed zu installieren.
Es ist auch möglich, dass Sie in der Zwischenzeit eine Technologie erworben haben, die immer noch die kritische OpenSSL-Schwachstelle aufweist.
Prüfen auf ungepatchte Bibliotheken mit Uchecker
Wenn Sie sich als Systemadministrator fragen, ob Ihre Bibliotheken konsistent gepatcht sind, sollten Sie den Einsatz von uChecker in Betracht ziehen - ein freies, GNU-lizenziertes Tool, das von dem Team hinter TuxCare.
uChecker hilft Ihnen bei der Überprüfung, ob Ihre Bibliotheken gegen die Heartbleed-Schwachstelle gepatcht sind, und erstellt einen leicht lesbaren Bericht, der aufzeigt, welche Bibliotheken nicht auf dem neuesten Stand sind. uChecker kann sowohl Bibliotheken im Speicher als auch auf der Festplatte gespeicherte Bibliotheken überprüfen.
Dies ist ein Vorteil gegenüber anderen Scannern, die ungepatchte Bibliotheken im Speicher nicht erkennen. Es ist einfach, uChecker zu installieren - besuchen Sie einfach die GitHub-Seite hier.
$ curl -s -L https://kernelcare.com/uchecker | sudo python
Sobald Sie einen Scan mit uChecker durchgeführt haben, können Sie alle OpenSSL-Dienste patchen, die noch für Heartbleed anfällig sind.
Aus Sicherheitsgründen sollten Sie Code, den Sie aus dem Internet herunterladen, gründlich überprüfen, bevor Sie ihn auf Ihren Systemen ausführen. Der obige Befehl kann und sollte in zwei Teile aufgeteilt werden - einen, um den zu prüfenden Code herunterzuladen, und einen weiteren, um ihn tatsächlich auszuführen. Das oben gezeigte Beispiel ist nur eine bequeme Art, uChecker auszuführen, nicht die beste Sicherheitspraxis.
Es lohnt sich, Heartbleed doppelt zu prüfen
Jahre nach dem Auftreten von Heartbleed lohnt es sich zweifellos, zu überprüfen, ob Ihre Server gründlich gegen diese gefährliche Bedrohung geschützt sind. Wir haben zwei Beispiele dafür angeführt, wie aktuelle Untersuchungen zeigen, dass Unternehmen immer noch Lücken in ihrer Reaktion auf Heartbleed haben.
Wenn Sie derzeit kein automatisiertes Live-Patching-Tool einsetzen, empfehlen wir Ihnen uChecker - ein kostenloses und einfaches Tool, das schnell aufzeigt, ob Ihre Server noch anfällig für Heartbleed sind.
In jedem Fall ist es wichtig, OpenSSL genau im Auge zu behalten. Es ist eine wichtige Sicherheitsschicht und gleichzeitig eine der am meisten gefährdeten Softwarekomponenten, mit 202 Sicherheitslücken seit seiner Veröffentlichung bis zum Zeitpunkt der Erstellung dieses Artikels entdeckt - Heartbleed war nur eine davon.
Und nicht zu vergessen - LibCare von TuxCare hält Ihre Bibliotheken, einschließlich OpenSSL, auf dem neuesten Stand - ohne viel Aufhebens. Lesen Sie hier mehr über LibCare.