Im Rahmen von breitflächigen Sicherheitsüberprüfungen pflegen wir eine besondere Philosophie zu verfolgen:

Sowohl jede mögliche als auch jede potentielle Schwachstelle, auch wenn sie (durch uns und im Rahmen des Projekts) nicht ausgenutzt werden kann, wird vermerkt und gemeldet. Es liegt sodann im Ermessen des Kunden darüber zu entscheiden, ob die potentielle Eintrittswahrscheinlichkeit und Auswirkung des Problems für ihn wahrgenommen werden will bzw. tragbar ist.

Wir melden also auch Schwachstellen, die durch andere oftmals nicht als solche verstanden werden. Ein typisches Beispiel ist die Möglichkeit eines Reverse DNS Lookup. Kennt ein Angreifer die IP-Adressen eines Zielnetzwerks, kann er versuchen anhand dieser die Hostnamen der im Nameserver vermerkten Systeme zu identifizieren:

maru@debian:~$ host 80.238.216.33
33.216.238.80.in-addr.arpa domain name pointer www.scip.ch.

In diesem Fall kann anhand der IP-Adresse 80.238.216.33 der Hostname www.scip.ch ausgemacht werden. Eine solche Auswertung der Zielumgebung ist in mancherlei Hinsicht von Nutzen:

Hostnamen …

• erleichtern für Menschen den Umgang mit Systemen
• sind Voraussetzung für Zugriffe/Angriffe (z.B. Shared Hosting)
• ermöglichen Rückschlüsse auf Funktionalität zu (z.B. www.scip.ch ⇒ ^www\.(.*)$ ⇒ Webserver)
• ermöglichen Rückschlüsse auf Technologien zu (z.B. cpfw1.scip.ch ⇒ ^cpfw1\.(.*)$ ⇒ Checkpoint Firewall-1)
• identifizieren öffentlich zugängliche Systeme

Aus diesem Grund pflegen wir eine solche Möglichkeit als Schwachstelle der niedrigsten Einstufung Low (CVSS2 Base Score 5.0, CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) zu dokumentieren. Auch wenn damit kein direkter Angriff umgesetzt werden kann, können die daraus ableitbaren Informationen eine elementare Grundlage für weiterführende Auswertungen und Angriffe schaffen.

Obschon sich die meisten Kunden bei einem ersten Projekt an dem Ausweisen dieser und ähnlicher Schwachstelle stören, können sich nach einem klärenden Gespräch unsere Bedenken nachvollziehen. In manchen Fällen wird sich entsprechend darum bemüht, dass Reverse DNS Lookups bzw. Hostnamen gänzlich abgeschafft werden. Besonders bei Systemen, die nur für den internen Gebrauch bzw. nicht für Direktzugriffe durch Clients vorgesehen sind, ist dies ein gangbarer Weg.

Umso mehr erstaunt es dann die Kunden, wenn bei einem folgenden Re-Check das Fehlen eines Hostnamens bzw. der Möglichkeit einer Namensauflösung ebenfalls als Schwachstelle der gleichen Einstufung Low vermerkt wird. Auch dieser umgekehrte Zustand kann im Rahmen eines Angriffs von Nutzen sein:

Fehlende Hostnamen …

• deuten auf nicht-öffentliche Systeme hin (z.B. Router, interne Server)
• verunmöglichen Zugriffe (z.B. Shared Web Hosting)
• erschweren menschliche Nutzung (IP-Adressen statt Hostnamen)
• erschweren Debugging (Identifikation von Systemen/Funktionen)
• widersprechen Empfehlung von RFC 1912, Absatz 2.1 (Every Internet-reachable host should have a name.)

Diese Schwachstelle ist ein typisches Beispiel dafür, das sich nicht eliminieren, sondern lediglich transformieren lässt. Es gibt eine Reihe von Schwachstellen dieser Art. Nachfolgende Tabelle listet die populärsten Vertreter auf, wobei die erste Spalte die übliche Form und die zweite Spalte die empfohlene Alternative der Schwachstelle zeigt:

Da wir stets darum bemüht sind unseren Kunden einen Mehrwert zu bieten, suchen wir zu Beginn eines Projekts das Gespräch. Dabei legen wir unsere Philosophie vollster Transparenz dar. Sodann kann er festlegen, ob wir diese weiterhin verfolgen oder im Rahmen des Projekts gewisse Schwachstellen ausblenden sollen (Ein gänzliches Ausblenden findet dennoch nicht statt. Die Findings werden rapportiert, jedoch nicht als gleichwertige Schwachstellen, sondern in einem separaten Anhang/Dokument).

Hierbei geht es nicht darum, dass der Report mit nichtigen Findings aufgebläht werden soll. Viel mehr ist es wichtig, dass der aktuelle Zustand in all seinen Belang festgehalten wird. Nur so kann bei weiterführenden Prüfungen oder Untersuchungen dafür gesorgt werden, dass ein Informationsvorsprung und damit ein stabiles Mass an Qualität gewährleistet werden können.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• http://blog.fefe.de/?ts=b25a597b
• http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00
• http://tools.ietf.org/html/rfc1912