Was ist eigentlich Micropatching?

Patchen, wenn es eigentlich keine Patches mehr gibt

Security-Lösungen verkleiden sich ja gern in fancy neuen Begriffen. Vielleicht sind Sie in letzter Zeit mal über den Begriff “Micropatching” gestolpert? Claudius Manthey und ich haben zusammengefasst, was es damit auf sich hat.

Photo by Luis Villasmil

Warum gibt es Micropatching?

Micropatching soll zwei Patching-Probleme lösen:

• Der Hersteller braucht zu lange, bis er Security-Patches zur Verfügung stellt
• Der Hersteller stellt gar keine Security-Patches (mehr) zur Verfügung

Ein Klassiker: End-of-Life-Betriebssysteme wie Windows 7 oder Windows XP.

Warum heißt das Micropatching?

Wichtig also: Micropatching stellt kleine Patches bereit, die nicht vom Hersteller kommen, und nur einzelne, ausgesuchte Sicherheitslücken patchen (daher auch das “micro”). Weil das aufwendig ist, wird dabei der Fokus oft auf häufig verbaute Systeme und auf besonders kritische Schwachstellen gelegt.

Die bekannteste Firma für Micropatches ist der kleine slowenische Anbieter Acros Security mit seiner Lösung “0patch”.

Wie funktioniert das technisch?

Wenn man patchen möchte, aber nicht der Hersteller der Software ist, hat man zwei Hürden zu bewältigen:

1. Die neue ausführbare Datei muss vom Zielsystem akzeptiert werden, ohne die Herstellersignaturen verwenden zu können.
   Beim herkömmlichen Patchen werden die ausführbaren Dateien (üblicherweise *.exe, *.dll, *.ocx o.ä.) auf der Festplatte durch neue ausführbare Dateien ersetzt. Sowohl die alten wie auch die neuen Dateien wurden vom Hersteller aus dem Quellcode kompiliert und dann anschließend von diesem auch signiert.
   Da ja Micropatches aber von Drittanbietern kommen, haben diese natürlich weder Zugang zum Quellcode noch zu den privaten Schlüsseln der Hersteller und können diesen üblichen Weg deshalb nicht gehen. Stattdessen muss beim Micropatching ein Täuschungsmanöver ausgeführt werden, bei dem es aufs richtigte Timing ankommt: bei jedem Laden der ausführbaren Datei in den Hauptspeicher lädt ein automatischer Agent die zu patchende Datei, nachdem die Signatur überprüft wurde, aber bevor der Binärcode ausgeführt wird.
2. Das Micropatch muss die ausführbare Datei zielgerichtet verändern, ohne den Hersteller-Quellcode zu kennen.
   Das Micropatch muss natürlich Änderungen gegenüber dem Originalcode enthalten; denn Patchen bedeutet ja gerade, den ausführbaren Binärcode zu verändern.
   Auch hier kann der Drittanbieter ohne Kenntnis des Quellcodes nicht den üblichen Weg gehen — den Quellcode verändern, kompilieren und die alte ausführbare Datei durch eine neue ersetzen. Stattdessen bleibt ihm nichts anderes übrig, als die notwendigen Änderungen aus der Analyse von Änderungen neuerer Programmversionen abzuleiten, oder entwickelt sie komplett selbst, z.B. durch Reverse Engineering.
   Ein Beispiel: Wenn sich in Office 2016 aufgrund eines Patches einige Bytes geändert haben, versuchen Micropatch-Anbieter, ob diese Änderung auch beim nicht mehr unterstützten Office 2010 funktioniert.

Wo liegen Probleme?

Das Kernproblem ist, dass ein Micropatch ein System zum Akzeptieren einer nicht vom Hersteller freigegebenen Änderung einer Software bringen muss.

Klingt vertraut? Ist es. Schadcode —ein Virus, ein Wurm, ein Trojaner — hat nämlich dasselbe Ziel, weshalb sich zuerst die technische Frage stellt, was Anti-Schadcode-Lösungen zum Micropatching sagen (sie sollten so etwas nämlich eigentlich verhindern).

Darüber hinaus bedeutet Micropatching, dass Sie viel Vertrauen in den Anbieter des Micropatches (und seine Zulieferer, und sein Security-Konzept) legen. Denn Sie erlauben damit einer Drittfirma, für Sie nicht überprüfbare Änderungen in Programmcode eines anderen Herstellers einzuspielen — in der Hoffnung, dass diese Firma überblickt, was das für Auswirkungen und Seiteneffekte hat.

Ist Micropatching in der industriellen IT (OT) eine Option?

Kurz: Geht so bis eher nicht.
Vier Gründe über die obenstehenden Probleme hinaus:

1. Herstellerfreigaben
   Vor allem in der OT sind (Leitsystem-)Hersteller extrem penibel, was die Freigabe von Systemänderungen und der Wahrung von Produktgarantien angeht — und das sogar bei “offiziellen” Patches vom Originalhersteller einer Software. Dass “nicht-offizielle” Micropatches akzeptiert werden, ist unwahrscheinlich.
2. Produktabdeckung
   Micropatching konzentriert sich (noch) auf sehr populäre, in vielen Bereichen eingesetzte IT-Software — oft sind das Microsoft-Produkte. Viele in der OT eingesetzte Produkte dürften vorerst durch das Raster fallen.
3. Internetanbindung des Micropatching-Agenten
   Für Micropatching muss in der Regel ein Agent mit Internetanbindung auf dem Zielsystem installiert sein. Das bedeutet, dass Sie für viele OT-Systeme, die keine Internetanbindung haben, die Angriffsfläche vergrößern.
   Im Prinzip gilt das natürlich auch für normales Patching, aber für OT gibt es offline- oder halb-offline-Optionen: ein lokaler Patchserver mit temporärer Internetanbindung oder sogar manuelles Patching sind populäre Lösungen.
4. Risikoärmere Alternativen
   Für viele Produkte, die Micropatching abdeckt, stellt der Hersteller noch Updates zur Verfügung — nur eben kostenpflichtig. Und: In der OT ist “informiertes Nicht-Patchen” durchaus eine Option — man kann die sehr statischen OT-Systeme manchmal sinnvoller anderweitig schützen, etwa durch Segmentierung und strenge Zugriffsreglementierung.

Dieser Beitrag ist auch im monatlichen “Security Briefing für Hard Hats” erschienen.