Nichtexistenz als Schwachstelle
Marc Ruef | 29.06.2009

Ein Thema, das mich die letzten Jahre stetig begleitet hat, sind sogenannte Configuration Reviews (http://www.scip.ch/?dienstleistungen.configurationreview). Bei diesen geht es darum, die Konfiguration eines Systems oder eines Dienstes auf etwaige Schwächen hin zu untersuchen. Dabei kann man grob zwischen zwei Arten von Fehlern unterscheiden:

1) Fehlerhafte Einstellungen: Diese führen dazu, dass sich die Komponente nicht so verhält, wie man das gerne hätte. Zum Beispiel wenn ein Webserver ausschliesslich SSLv3 zulassen soll, jedoch versehentlich (Unachtsamkeit oder Missverständnis) ebenfalls das als unsicher geltende SSLv2 zugelassen wird.

2) Unsichere Einstellungen: Diese führen dazu, dass mehr oder weniger Bewusst ein unsicheres Verhalten einer Komponente durchgesetzt wird, obwohl das Risiko bei umfassendem Verständnis nicht oder nur bedingt akzeptiert werden will. Es kann an das vorangegangene Beispiel angeknüpft werden, dass bewusst SSLv2 ebenfalls zugelassen wird, ohne dass man sich den Schwächen dessen bewusst ist.

In beiden Fällen hätte die Config Review zur Folge, dass die Unterstützung von SSLv2 in Bezug auf die potentiellen Sicherheitsrisiken bemängelt wird. Ist der Kunde mit dem Analysten gleicher Meinung, dass das Risiko nicht getragen werden muss oder will, wird man die Unterstützung des unliebsamen SSLv2 unterbinden wollen. Eine Anpassung an der Konfiguration ist die Folge davon.

Das Durchführen von Config Reviews wird immer mehr durch unsere Kunden begrüsst. Schliesslich kann man hier fehlerhafte Einstellungen sehr nah an der Lösung erkennen und damit die unmittelbare Administration sicherer machen.

Bei solchen Prüfungen ist das Vorgehen stetig gleich: (1) Es wird die Konfiguration des jeweiligen Systems extrahiert. (2) Nach Möglichkeit wird das proprietäre Datenformat in ein einheitliches Format konvertiert. Dies geschieht meistens mit einem spezifisch für das jeweilige Output-Format angepassten Parser. (3) Die normalisierten Daten werden auf fehlerhafte Einstellungen hin untersucht. (4) Alle potentiellen Schwächen werden dokumentiert und dem Kunden mitgeteilt, so dass dieser auf diese reagieren kann.

Bei diesem Ansatz erschliesst sich ein unmittelbares Problem. Und zwar wird in erster Linie nur das begutachtet, was existiert. Es werden also die vorhandenen Einstellungen auf ihre Richtigkeit hin untersucht. Das eigentliche Vorhandensein einer Einstellung wird jedoch nicht direkt geprüft.

Dies ist kein Problem, sollte in einer Konfigurationsdatei für jede mögliche Option mindestens eine Definition spezifiziert sein. Eine simple Konfiguationsdatei dieser Art, welche die Unterstützung für SSL in jedem Fall spezifiziert gestaltet sich folgendermassen:

code// SSL/TLS Support Definition
// Note: Specify either False or True.
SSLv2Support = False;
SSLv3Support = True;
TLSv1Support = True; /code

In jedem Fall kann nun gesagt werden, ob die definierte Einstellung den Erwartungen entspricht. Wird hingegen ein anderes Format verwendet, bei dem individuelle Abweichungen von den Standardeinstellungen explizit angegeben werden müssen, tritt das Problem der Prüfung einer Nichtexistenz auf:

code// SSL/TLS Support Definition
// Warning: SSLv2 and SSLv3 are always True unless specified as False!
TLSv1Support = True; /code

In letztgenanntem Fall müsste also neben der Definition der vorhandenen Einstellungen ebenso das Wissen um Standardeinstellungen sowie die Reihenfolge der Überschreibungen bekannt sein. Denn die soeben gezeigte Konfiguration aktiviert SSLv2, da die Unterstützung nicht explizit durch die Angabe von "SSLv2Support = False" deaktiviert wurde.

Derlei Config Reviews sind eigentlich relativ einfach, sofern jede Einstellung stets explizit vorhanden sein muss. Wird jedoch in einem Produkt davon ausgegangen, dass nur Abweichungen von den Standardeinstellungen explizit angegeben werden müssen, muss das Wissen um eben diese vorhanden sein. Dies ist vor allem dann schwierig, wenn ein Konfigurationsformat nicht oder nur schlecht dokumentiert ist. Dann kann in den meisten Fällen nur die langwierige Erfahrung dabei helfen, sämtliche Schwächen in den proprietären Lösungen umfassend auszumachen.

Doch spätestens bei der Einführung eines Patches oder der Vorstellung eines neuen Releases kann man sich eventuell wieder mit neuen Standardeinstellungen, Konfigurationsmöglichkeiten, Optionen und Vererbungen herumschlagen. Ein schlecht dokumentiertes Produkt ist also unweigerlich über Kurz oder Lang eine Gefahr für die Nutzer dessen. Denn sie müssen einer Lösung vertrauen, die sie a) nicht verstehen und b) deren Fehlnutzung sie nicht erkennen können. 3jbvh68qt2