zurück zur Übersicht

Leichen im Keller – Tipps gegen Langzeitschwachstellen

Leichen im Keller hat wohl so mancher Software-Hersteller. Treten sie zutage, können sie für richtig böse Überraschungen sorgen. Doch was hilft gegen Langzeitschwachstellen?

Leiche #1 – Windows Formeleditor

Der neuste Vertreter der Kategorie „Leiche im Keller“ ist die Schwachstelle CVE-2017-11882, die den Formeleditor der Microsoft Office Suite betrifft. Sie trat erstmals bei Office 2000, also vor 17 Jahren auf. Besonders brisant ist jedoch, dass diese Leiche in Microsofts Keller ziemlich gut konserviert wurde und seitdem auch in allen Office Versionen seit Office 2007 zu finden ist, also beispielsweise auch in Office365.

Die Entdeckung des Unternehmens embedi, kann als Paradebeispiel für strukturiertes Threat Hunting gelten.

Basierend auf der Hypothese, dass Applikationen oft unter Verwendung von Legacy Komponenten erstellt werden, die aus Zeiten stammen, in denen SDLC (Software Development Lifecycle) oder SSDLC (Secure Software Development Lifecycle) Fremdwörter waren, nahmen sich die Forscher Microsoft Office vor, um gezielt nach solchen Altlasten zu suchen. Die hohen Verbreitung dieser Anwendungssoftware macht sie seit jeher zu einem überaus attraktiven Ziel für Angreifer, die den gleichen Ansatz wählen würden, um einen lohnenden Zero-Day-Exploit zu finden.

In besagtem Formeleditor EQNEDT32.EXE fanden die Sicherheitsforscher von embedi eine Schwachstelle, die es aufgrund fehlerhafter Speicheroperationen ermöglicht beliebige Kommandos im Benutzerkontext des eingeloggten Users auszuführen. Nachdem eine entsprechend präparierte Datei geöffnet wurde, ist keinerlei weitere Interaktion des Anwenders notwendig, um die Lücke auszunutzen. Damit ist es möglich eine Datei herunterzuladen, beispielsweise von einem WebDAV Share, und diese dann auszuführen – der perfekte Weg also um Schadsoftware, beispielsweise Ransomware gewinnbringend einzusetzen.

Wer jetzt meint, das Problem betrifft nur die großen Hersteller von Anwendungssoftware, der liegt leider falsch. Auch in der Vergangenheit gab es Lücken in Betriebssystemen, die über Jahre unentdeckt blieben oder Fehler, bei denen man erst im Nachhinein erkannt hat, dass sie als Schwachstelle ausnutzbar sind, wie folgendes Beispiel zeigt.

Leiche #2 – Linux Kernel Fehler

Knapp 11 Jahre schlummerte die mit CVE-2017-6074 bezeichnete Schwachstelle im Code des Linux Kernels bevor sie im Februar diesen Jahres entdeckt und damit offenbar wurde, dass sich der seit längerem bekannte Fehler im Speichermanagement nutzen lässt, um auf dem lokalen System root-Rechte zu erlangen.

Doch mit welchen Maßnahmen beugt man vor, damit man nicht seinen persönlichen „Day of The Walking Dead“ im Hinblick auf Schwachstellen erlebt?

Aus Sicht der User / Admins

Vulnerability & Patch Management

Inventarisieren Sie und überprüfen Sie all Ihre Systeme regelmässig hinischtlich bekannter Schwachstellen, beispielsweise mit einem geeigneten Schwachstellenscanner (Vulnerability Management Solution) und patchen Sie gefundene Lücken zeitnah und regelmäßig („Patch often, patch early„). Sicher das hilft nicht gegen unbekannte Schwachstellen, minimiert jedoch die Angriffsfläche deutlich, da oft verschiedene Exploits in Kombination eingesetzt werden.

Endpoint Protection

Prinzipiell sollten alle Möglichkeiten genutzt werden, um die Angriffsfläche eines Endpoints zu minimieren, z.B.

  • das Deaktivieren nicht benötigter Dienste und Funktionen,
  • Aktivieren verfügbarer Schutzfunktionen, im Falle von MS Office beispielsweise Protected View und,
  • Installation einer leistungsstarken und zuverlässigen Malware Protection Lösung, die in der Lage ist Schadsoftware auch ohne Signaturen zu erkennen.

Incident Detection & Response

Keine präventive Schutzmaßnahme bietet 100%igen Schutz. Werden Schutzmaßnahmen überwunden, wird man froh sein, sich vorab einen Plan B zurechtgelegt zu haben, der

  • dafür sorgt, dass dieser Vorfall (Incident) überhaupt erkannt wird (Detection) und
  • einem Handlungsoptionen bietet, um auf den Vorfall zeitnah zu reagieren, um Schaden zu vermeiden.

Aus Sicht der Software-Hersteller

Secure Software Development Lifecycle

Jeder Hersteller tut gut daran seinen Software Development Life Cycle kontinuierlich zu hinterfragen und dahingehend zu optimieren, dass Sicherheitsmanagement dort bestmöglich integriert wird. Hilfestellung bei der Umsetzung eines SSDLC bietet beispielsweise das OWASP Software Assurance Maturity Model (SAMM)

Security Testing

Bestandteil einer Sicherheitsstrategie für Software-Hersteller ist eine vollumfängliche, kontinuierliche Überprüfung der erstellten Software auf Schwachstellen. Infos dazu finden sich auch im Artikel Application Security Testing 2017 – Ein aktuelles Lagebild. Doch nicht nur Prüfung des selbst generierten Codes durch SAST, DAST, Penetrationstests und Security Reviews ist wichtig. Durch die vermehrte Einbindung von Fremd-Code durch Open-Source-Komponenten wird nicht nur die Entwicklungsgeschwindigkeit gesteigert, sondern auch das Risiko, auf diesem Weg Sicherheitslücken einzubauen steigt. Mit dem sogenannten Open Source Vulnerability Management lässt sich auch dem entgegenwirken.

Schreibe einen Kommentar