Angriffspunkt Konfigurationsdatei

Von Ralph Dombach, Mauth

Konfigurationsdateien sind eine wichtige Komponente in der Security – und zudem eine, die oft vernachlässigt wird. Zur Abwehr der mannigfaltigen Bedrohungen benötigt man heutzutage eine ganze Phalanx diverser Tools, die in Kombination versuchen, möglichst alle Angriffe und jeglichen Missbrauch zu unterbinden oder zumindest aufzudecken. Ein entscheidender Faktor sind dabei die Einstellungen dieser Security-Mechanismen. Vereinfacht gesagt, erweist sich ein Tool, bei dem elementare Schutzfunktionen (versehentlich oder absichtlich) deaktiviert sind oder das sonstwie falsch konfiguriert ist, als mehr oder minder völlig nutzlos im Kampf gegen Cyberkriminelle und andere Angreifer.

Die Security-Konfiguration ist also auch ein interessanter Angriffspunkt, für den sich zwei Bedrohungsvektoren ergeben:

• Der gezielte Zugriff auf Konfigurationsdaten, um diese zu manipulieren und beispielsweise eine Sicherheitsfunktion abzuschwächen oder auszuschalten.
• Eine klassische Fehlkonfiguration, bei der Optionen nicht (richtig) aktiviert, durch Verantwortliche oder Administratoren falsch interpretiert oder syntaktisch ungültig eingerichtet wurden.

Neben der Prüfung des eigenen Handelns (Configuration- und Change-Management) sind dabei auch die grundlegende Überprüfung der von Anbietern vorgesehenen Maßnahmen (z. B. Defaultwerte, Speicherformate und Selbstschutzmechanismen) sowie eine fortwährende Überwachung der Soll-Konfiguration gefragt.

Basis der Sicherheit

Heutzutage sollte keine Securitysoftware mehr mit einer Klartext-Konfigurationsdatei arbeiten, die noch dazu für User im Zugriff liegt. Falls dies doch der Fall ist, sollte man schleunigst mit dem Produkthersteller sprechen oder einen Tool-Wechsel ins Auge fassen.

Üblicherweise sind Konfigurationen für Produkte in einem der folgenden Bereiche gespeichert:

• Datei im Filesystem
• Datensätze in einer produkteigenen Datenbank
• Werten in der Datenbank des Betriebssystems (Windows Registry oder Active Directory)
• Datei auf einem externen Medium (Chipkarte, USB-Stick etc.)

Es versteht sich von selbst, dass ein Schutz der Konfigurationsdaten dann hinfällig wird, wenn ein Angreifer über das zentrale Programm selbst beliebige Konfigurationen erstellen oder manipulieren kann. An dieser Stelle muss daher eine starke Benutzer-Authentifizierung etabliert sein – und auch ein unveränderbares Audit-Log, um Manipulationen in der Produktkonfiguration zu erkennen.

Beim Basisschutz der eigentlichen Konfigurationsdaten sollte das Hauptaugenmerk auf zwei Features liegen:

Zum einen, dass niemand (lesenden der schreibenden) Zugriff hat außer der Applikation selbst – zum anderen, dass die Daten verschlüsselt sind. Ansonsten wären ein Administrator mit erweiterten Rechten oder ein im System befindlicher Cyberdieb in der Lage, die Werte zu manipulieren. So könnten Angreifer beispielsweise Verzeichnisse von der Überprüfung auf Malware ausschließen oder den Verkehr zwischen einer Schadsoftware und dem steuernden Command-&-Control-Server (C&C) als legitim klassifizieren.
Der Basisschutz ergibt sich folglich aus der Kombination von Zugriffsrechten über das Betriebssystem und die Verschlüsselung der Daten, die man nicht im Klartext ändern dürfen kann. Eine bloße Verschleierung (Obfuscation) der Konfigurationswerte bringt hingegen nur einen geringen Mehrwert an Sicherheit – solche „Spielereien“ sollte man unterlassen und stattdessen generell auf gängige Verschlüsselungsverfahren setzen.

Der Schlüsselwert oder das zugrunde liegende Passwort werden dabei entweder vom internen Produktadministrator vergeben oder per Automatismus durch das Programm generiert. Hier sollte man sich beim jeweiligen Hersteller erkundigen, wie der Schlüssel erzeugt wird: Wird er beispielsweise durch das Tool aus den letzten vier Stellen der Seriennummer erzeugt, ist das nicht sicher. Grundlegende Hinweise auf derartige Schwachstellen lassen sich durchaus in einschlägigen Security-Foren oder über Suchmaschinen im Web finden.

Die „dunkle Seite“ findet immer wieder mittels Grundlagenforschung Hebel, die eine unberechtigte Manipulation oder Einsichtnahme ermöglichen. Anfang 2020 wurde beispielsweise auf Github ein Python-Tool veröffentlicht, das McAfee-End-point-Konfigurationsdateien dechiffrieren soll – mit gewissen Einschränkungen funktionierte das auch. Selbst wenn renommierte Hersteller solche Angriffsflächen immer wieder eliminieren: Wer sich in der Szene auskennt oder halbwegs kreativ eine Suchmaschine nutzen kann, wird regelmäßig weitere „Support-Tools“ finden, die sich auch zum Angriff auf Security-Produkte nutzen lassen. Solche Werkzeuge wird es immer geben – und je häufiger eine Lösung eingesetzt wird, desto größer ist die Versuchung, darüber einen Sicherheitsmechanismus zu attackieren.

Verteilter Schutz

Alle Konfigurationsdaten sind normalerweise auf dem jeweiligen Client hinterlegt, auf dem die Software zum Einsatz kommt. In Firmennetzwerken mit entsprechenden Administrationsebenen sind diese Daten zudem an zentraler Stelle gespeichert und werden zumindest dann erneut zum Client übertragen, wenn es eine zentrale Änderung der Policy gibt oder die Konfigurationsdatei beschädigt wurde oder fehlt.

Um einer unerwünschten Manipulation entgegenzuwirken gibt es verschiedene Methoden – allen gemein ist jedoch, dass eine Verbindung zum Client existieren muss. Handelt es sich um ein mobiles Gerät oder ist (ggf. temporär) aus anderen Gründen keine Verbindung möglich, sollte auch keine Bearbeitung der Konfigurationswerte erlaubt sein.

Als einfachen Schutz könnte man täglich von zentraler Stelle aus die Konfiguration neu erstellen und etwaige Veränderungen damit automatisch überschreiben. Ressourcensparender ist es aber, eine Art Challenge-Response-Verfahren vorzuschalten, bei dem ein Hashwert über alle Konfigurationswerte ausgetauscht wird: Ist dieser nicht mit dem gespeicherten Wert der gewünschten Konfiguration identisch, erfolgt eine Neuerstellung der Konfigurationswerte inklusive einer nachfolgenden, erneuten Hash-Kontrolle.

Zusammenfassend sollten die Konfigurationswerte von Security-Tools:

• auf Clients sowie an zentraler Stelle gespeichert sein und dabei ein gegenseitiger Abgleich erfolgen oder eine Master-Slave-Beziehung bei Konfigurationsvorgabe durch einen zentralen Produktadministrator vorliegen.
• Konfigurationsdaten müssen mit einem hinreichend sicheren Mechanismus verschlüsselt sein, für welchen der Produktadministrator der Lösung den Schlüssel (bzw. dessen Basis) frei wählen kann.
• Die Konfigurationswerte auf dem Client müssen periodisch (täglich) bezüglich Integrität und Aktualität verifiziert werden – inklusive einem entsprechenden Report, falls Abweichungen vorliegen, und einer Korrektur des Zustands.
• Ein weiteres Plus ist es, wenn ein Tool, sofern keine oder nur fehlerhafte Konfigurationswerte vorhanden sind, zumindest in einem Notbetrieb Defaultwerte nutzt, um den Anwender nicht gänzlich ungeschützt zu lassen – und „lauthals“ verkündet, dass etwas nicht in Ordnung ist!
• Das Übertragen einer „schwachen“ Konfigurationsdatei auf einen „sicheren“ Computer sollte erkennbar sein (z. B. mithilfe von Hashwerten).

Klassische Fehlkonfigurationen

Heute genutzte Security-Tools verfügen über eine umfangreiche Bedienoberfläche (GUI), mit der sich die einzelnen Optionen individuell und auf das jeweilige Bedrohungspotenzial abgestimmt einstellen lassen. Leider ist es aber so, dass gerade in der Phase der Produkt-Einführung leicht Fehler passieren, die auf banalen Gegebenheiten basieren:

• Es gab noch keine Schulung für das Tool.
• Handbücher sind nicht in der Muttersprache verfügbar.
• Der Scope von Funktionen hat sich gegenüber der Vorgängerversion geändert.
• Funktionen in anderen Tools, die gleich klingen, haben eine andere Auswirkung.
• Die interne Dokumentation kommt erst später.
• Automatische Updates sind nicht aktiviert und/oder das Einspielen von Patches dauert aufgrund von Kompatibilitätsüberprüfungen zu lange.
• Tests werden nur oberflächlich durchgeführt.

Funktionsprüfungen

Komplexe Sicherheitssysteme sind dabei nicht immer leicht auf ein korrektes und wunschgemäßes Funktionieren hin zu prüfen. Bei einem Anti-Malware-Produkt ist das noch relativ einfach möglich. Ein Funktionstest mit dem „eicar-Virus“ (Anti-Malware-Testfile, www.eicar.org/?page_id=3950) ist dabei ein Muss und wird wohl auch tatsächlich von vielen Anwendern als genereller „Lebt!“-Funktionstest angesehen.

Aber was ist mit komprimierten Daten, mehrfach gepackten Dateien, passwortgeschützten Makro-Viren und so weiter? Weil es „Zip-Bomben“ (aka Archiv-Bomben, siehe etwa https://de.wikipedia.org/wiki/Archivbombe) gibt, verbietet sich das unbeschränkte komplette Durchsuchen komprimierter Dateien – aber ist die erforderliche Suchtiefen-Beschränkung auf einen sinnvollen Wert gesetzt? Sind die Parameter für weitere Bedrohungen passend eingestellt? Nutzen Administratoren ein eigenes (unternehmensspezifisches) Testset an Dateien, um Funktion und Qualität ihrer Anti-Malware-Lösung zu überprüfen?

Vermutlich deutlich weniger bekannt als der eicar-Check sind die Tests der Anti-Malware Testing Standards Organization (AMTSO, www.amtso.org/security-features-check/), mit denen sich etwa auch verifizieren lässt, ob die Sicherheitssoftware mit einem cloudbasierten Suchsystem verbunden ist oder ob Drive-by-Downloads und Phishingseiten erkannt werden (vgl. Abb. 1). Außer für Desktopsysteme stehen einige Tests auch für Android-Security-Software bereit.

Selbst wenn die prinzipielle Funktionalität überprüft wird: Erfasst die Anti-Malware-Lösung wirklich alle Bereiche/Server/Dienste, wo Dateien abgelegt werden? Oder wurden, etwa aufgrund von Laufzeiterwägungen oder um Nebeneffekte zu verhindern, großzügig temporäre Verzeichnisstrukturen exkludiert und keiner Malware-Prüfung unterzogen? Einige Anwendungen fordern dies sogar – ungeachtet dessen, welches Anti-Malware-Tool tatsächlich eingesetzt wird und ob dies überhaupt erforderlich wäre. Und wie sieht es mit anderen Security-Tools aus? Gibt es (regelmäßige?) Funktionsprüfungen für Firewalls? Wird stetig verifiziert, dass alle installierten Produkte aktuell sind?

Fazit

Die beschriebenen Voraussetzungen zur Absicherung von Konfigurationswerten sind elementare Funktionen, die „eigentlich“ in jedem Security-Tool implementiert sein sollten. Aber auch hier gilt das alte Sprichwort: Vertrauen ist gut, Kontrolle ist besser! Und bei bei all der Technik darf man den menschlichen Faktor nicht vergessen. Gerade Security-Administratoren müssen im Produktmanagement häufig verschiedene Interessen unter einen Hut bringen – das geht oft mit einer reduzierten Sicherheit einher. Und auch „kreative“ Endanwender, die sich mit Beschränkungen nicht abfinden wollen, können ein Risiko für die vorgesehene Konfiguration darstellen – von Angreifern ganz zu schweigen.

Für die Praxis bedeutet dies, dass nicht nur die Konfigurationsdateien selbst gesichert werden müssen, sondern auch ihre Inhalte einer ständigen oder zumindest regelmäßigen Kontrolle unterliegen sollten. Denn eine Regel „Allow Any to Any“ macht bei einer Firewall ebenso wenig Sinn wie ein „Exclude c:. /sub“ bei einem Anti-Malware-Scanner.

Ralph Dombach ist freier Autor – neben seinem Blog www.secutach.de twittert er unter @secuteach mit einem Augenzwinkern über das, was IT-Sicherheit ist und ausmacht sowie über securityrelevante Dinge, die ihn in seinem Berufsleben „heimsuchen“.