In einem privaten Blog-Beitrag habe ich vor rund einem Jahr ein Problem beschrieben, welches bei systematischen Sicherheitsüberprüfungen immerwieder zu Diskussionen führt:

Wann ist eine Schwachstelle eigenständig, wann eine individuelle Manifestation einer allgemeinen Schwachstelle in einem spezifischen Produkt und wann eine dedizierte Schwachstelle einer Schwachstellenklasse?

Nachfolgende Grafik illustriert den logischen Aufbau einer bestimmten Schwachstellenklasse. Die Wurzel des Baums ist definiert durch Fingerprinting. Dieses wird exemplarisch in OS Fingerprinting und Application Fingerprinting unterteilt. Letzteres ist wiederum exemplarisch in Webserver Application Fingerprinting (auch HTTP-Fingerprinting genannt) und CMS Application Fingerprinting unterteilt. Und auch hier ist letzteres exemplarisch in TYPO3 Fingerprinting und WordPress Fingerprinting unterteilt worden.

Als Beispiel der Identifikation von WordPress werden sodann Merkmale wie Pfadnamen, Dateinamen, Cookies, und Klassennamen aufgelistet. Das Prinzip einer solchen Analyse haben wir vor rund zwei Jahren im Beitrag Identifikation von Webapplikationen besprochen.

Die Frage ist nun, ob der Genauigkeit halber jedes gefundene Identifikationsmerkmal als separate Schwachstelle dokumentiert werden soll. Schliesslich weist jede von ihnen ein individuelles Exploiting – spätestens beim Erkennen des jeweiligen Merkmals – auf. Und so ist auch das Umsetzen von Gegenmassnahmen bei allen ähnlich, dann aber doch anders (z.B. Dateinamen zu ändern ist etwas gänzlich unterschiedliches weder Cookie-Strukturen anzupassen).

Das Problem einer solchen Aufgliederung ist jedoch, dass sich Fehlerquellen nur schwer einfachso vergleichen lassen. Werden zwei Systeme geprüft, kann nicht einfach die Aussage getroffen werden, ob Schwachstelle X auf beiden Systemen zutrifft. Dies ist schliesslich spätestens dann nicht der Fall, wenn auf beiden unterschiedliche Content-Management-Systeme zum Einsatz kommen (zwar können sowohl bei TYPO3 als auch bei WordPress das Produkt anhand der Cookie-Namen identifiziert werden, jedoch ist das zu suchende Pattern gänzlich unterschiedlich):

(Exploiting A ≠ Exploiting B) ⇒ (Schwachstelle Produkt A ≠ Schwachstelle Produkt B)

Das Zusammenfassen von Schwachstellen ist die Folge davon. Will man also ein TYPO3 mit einem WordPress vergleichen, darf man sich nicht an produktspezifische Eigenarten klammern. Doch diese Details sind genau das, was eine gute Sicherheitsüberprüfung ausmachen.

Die einzige Lösung besteht darin, zwar mit granularen Details zu arbeiten. Diese jedoch auf einer Meta-Ebene zu gruppieren. Die Identifikation eines Cookies muss also unabhängig vom betroffenen Produkt vergleichbar sein:

[(Schwachstelle X ∧ Produkt A) ⇒ Klasse X] = [(Schwachstelle X ∧ Produkt B) ⇒ Klasse X]

Die Schwierigkeit besteht darin, diese logischen Gruppen zu etablieren. Die Frage kann nämlich nun weitergetrieben werden, ob denn nun ein bekannter Pfadname bei einem Installations-Paket vergleichbar ist mit dem bekannten Pfadnamen einer Standardinstallation.

Wir arbeiten seit geraumer Zeit daran, dieses Problem zu lösen und damit unseren Kunden den Mehrwert aus Modularität/Genauigkeit und Homogenität/Vergleichbarkeit bereitstellen zu können. Dies erfordert sehr viel Formalisierung und Verständnis für die jeweiligen Schwachstellen. Ein Problem, das ursprünglich nur philosophischer Natur angemutet hat, hat sich damit eindeutig in der Praxis manifestiert.

Über den Autor

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

• https://www.computec.ch/news.php?item.295