ClickCease Schutz von Servern vor HeartBleed. Ja, HeartBleed. - TuxCare

Abonnieren Sie unseren beliebten Newsletter

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.

Schutz von Servern vor HeartBleed. Ja, HeartBleed.

3. November 2020. TuxCare PR Team

Schutz von Servern vor HeartBleedHeartBleed... klingt irgendwie wie ein Liebeslied aus den 1970er Jahren. Ist es aber nicht. HeartBleed ist eine ernsthafte Verwundbarkeit (CVE-2014-0160), die die gemeinsam genutzte OpenSSL-Bibliothek betrifft. Sie ist seit 2014 bekannt, aber anders als die Oldies, die man ab und zu im Radio hört, ist diese Cyberschwäche heute noch sehr präsent. NTTs 2020 Global Threat Intelligence Bericht zeigt, dass HeartBleed dazu beiträgt, dass OpenSSL die am zweithäufigsten angegriffene Softwaretechnologie der Welt ist - mit einem Anteil von 19 % der weltweiten feindlichen Aktivitäten.

HeartBleed ist ein Angriff, der einen Fehler in der Speicherverwaltung in den OpenSSL-Versionen 1.0.1 bis 1.0.1f ausnutzt. Mit HeartBleed sind Angreifer in der Lage Angreifer in der Lage, 64 Kilobyte verschlüsselter Daten während jedes "Herzschlags" der OpenSSL-Software entschlüsseln. Die Angreifer können diesen Datenverlust ausnutzen, um einen Man-in-the-Middle-Angriff durchzuführen oder sich Zugang zu sensiblen Informationen wie Passwörtern und Benutzer-IDs zu verschaffen.

Inhalte:

  1. Die Lösung heißt Patching. Das Problem ist auch Patching
  2. Live-Patching als Möglichkeit zur Eindämmung von Heartbleed mit Rebooting
  3. Schlussfolgerung

 

Die Lösung ist Patching. Das Problem ist auch Patching

Die Lösung ist Patching. Das Problem ist auch Patching.

Um HeartBleed und vergleichbare Bedrohungen zu entschärfen, müssen anfällige OpenSSL-Bibliotheken sowie die GNU C Library (glibc) gepatcht werden. Der Prozess der Bibliotheksaktualisierung kann in Form des MITRE Adversarial Tactics, Techniques and Common Knowledge (ATT&CK) Framework erfolgen. ATT&CK empfiehlt dass Organisationen "ihre nach außen gerichteten Systeme regelmäßig auf Schwachstellen überprüfen und Verfahren einrichten, um Systeme schnell zu patchen, wenn kritische Schwachstellen durch das Scannen und durch öffentliche Bekanntgabe entdeckt werden".

Nachdem kritische Schwachstellen identifiziert wurden, planen Systemadministratoren in der Regel Ausfallzeiten ein, um den Patching-Prozess selbst durchzuführen. Dies bedeutete schon immer, dass der Stack heruntergefahren, das Betriebssystem gepatcht und der Stack neu gestartet werden musste. Außerdem erfordert dies in der Regel die Zeit und Aufmerksamkeit vieler Personen, wie Linux-Administratoren, Datenbankadministratoren (DBAs), Middleware-Administratoren und Geschäftsanwender. Unter der Annahme, dass es keine Probleme gibt (was nicht immer eine verlässliche Annahme ist), validiert der Systemadministrator als Nächstes den aktualisierten Stack und nimmt ihn wieder in Betrieb.

Bei diesem Prozess treten mehrere Probleme auf:

  • Ungewissheit darüber, welche Bibliotheken aktualisiert werden müssen - Systemadministratorenhaben in der Regel keine klare Vorstellung davon, welche ihrer Bibliotheken gepatcht werden müssen. Infolgedessen führen sie in der Regel einen systemweiten Neustart durch.
    Neustart-Zyklen führen zu einer Verschlechterung der Dienste und/oder zu Ausfällen. Nach einem Neustart kann es eine Weile dauern, bis sich die Serverleistung stabilisiert. Manchmal kehren die Server nach einem Neustart nicht ordnungsgemäß zurück. 
  • Fenster der Verwundbarkeit-Wegen des hohen Arbeitsaufwands für einen Neustart und der möglichen Unterbrechung planen Unternehmen Neustarts oft für vorher festgelegte Ausfallzeiten, z. B. an Wochenenden. Durch diese Verzögerung sind ihre Server anfällig für Angriffe. Selbst wenn ein Systemadministrator alle 30 Tage einen Neustart durchführt, um die Sicherheitsstandards einzuhalten, können die Server noch zwei Wochen oder länger angreifbar sein.
  • Unvollständiges Patching: WennServer manuell gepatcht werden, ohne dass ein Neustart erfolgt, können gemeinsam genutzte Bibliotheken immer noch Sicherheitslücken enthalten. Wenn beispielsweise Bibliotheken auf der Festplatte aktualisiert werden, können alte ungepatchte Dateien im Speicher eines Servers verbleiben. Und Schwachstellen-Scanner erkennen diese alten ungepatchten Bibliotheksdateien im Speicher nicht. 

 

Verwendung von UChecker zur Entschärfung von HeartBleed und anderen Schwachstellen in Shared Libraries

Verwendung von UChecker zur Entschärfung von HeartBleed und anderen Schwachstellen in Shared Libraries

Wenn Server manuell und ohne Neustart gepatcht werden, können gemeinsam genutzte Bibliotheken immer noch Schwachstellen enthalten. Wenn beispielsweise Bibliotheken auf der Festplatte aktualisiert werden, können alte ungepatchte Dateien im Speicher verbleiben. Und Schwachstellen-Scanner erkennen diese alten, ungepatchten Bibliotheksdateien im Speicher nicht. Es ist jetzt möglich, festzustellen, ob das System noch anfällig für HeartBleed oder ähnliche Schwachstellen ist, indem die Bibliotheken im Speicher mit KernelCare's Uchecker

 Und so funktioniert es:

  • UChecker bezieht die aktuellsten BuildIDs von einer Ressource auf unserer Website, z.B. https://patches04.kernelcare.com/userspace.json
  • Es nimmt einen laufenden Prozess durch Iteration über /proc/
  • It then gets a linked shared library from /proc/<pid>/maps
  • An diesem Punkt prüft das Tool, ob die gemeinsame Bibliothek ersetzt oder gelöscht wurde
  • Je nach Status des Prozesses analysiert das Tool dann entweder das Executable and Linkable Format (ELF) aus dem Dateisystem oder aus dem gemappten Speicher
  • Das Werkzeug übernimmt die BuildID von .note.gnu.build-id
  • Das Tool durchläuft dann diesen Zyklus, um je nach Bedarf weitere Bibliotheken zu scannen

UChecker wie es funktioniert

Abbildung 1: So funktioniert Uchecker

Besuchen Sie die Uchecker Github-Seite und sehen Sie sich die Demonstration wie es funktioniert.

UChecker hilft bei der kostenlosen Suche nach gefährdeten Bibliotheken; um sie zu aktualisieren, ist jedoch ein Neustart erforderlich. Wenn Sie nach Sicherheitslücken suchen und Bibliotheken aktualisieren möchten, ohne Prozesse neu zu starten oder Server neu zu starten, sollten Sie KernelCare+Es prüft, ob laufende Prozesse veraltete Bibliotheken im Speicher verwenden, und aktualisiert dann anfällige gemeinsam genutzte Bibliotheken, ohne sie neu zu starten.

 

Schlussfolgerung

Gemeinsam genutzte Bibliotheken stellen für Unternehmen, die freie und quelloffene Software (FOSS) verwenden, nach wie vor eine ernsthafte Quelle für Sicherheitsrisiken dar. Uchecker und die KernelCare Live-Patching-Technologie ermöglichen die Aktualisierung von gemeinsam genutzten Bibliotheken ohne die Unterbrechungen und erweiterten Risiken eines Server-Neustarts. Zusammen ermöglichen Uchecker und KernelCare ein schnelleres und effektiveres Patchen von gemeinsam genutzten Bibliotheken. HeartBleed und andere ähnliche Schwachstellen können jetzt auf eine Weise behoben werden, die nicht das gesamte Unternehmen verlangsamt. Weitere Informationen finden Sie unter https://lp.kernelcare.com/kernelcare-early-access

Möchten Sie das Patchen von Sicherheitslücken ohne Kernel-Neustart, Systemausfallzeiten oder geplante Wartungsfenster automatisieren?

Erfahren Sie mehr über Live-Patching mit TuxCare

Werden Sie ein TuxCare-Gastautor

Los geht's

E-Mail

Beitreten

4,500

Linux & Open Source
Fachleute!

Abonnieren Sie
unseren Newsletter