Debatten darüber, wie schwerwiegend Schwachstellen tatsächlich sind, gehören zum Alltag in der IT. Dabei gibt es ganz unterschiedliche Perspektiven bzw. Beweggründe, warum Schwachstellen als schwerwiegender oder weniger relevant eingeschätzt werden:
- Das Interesse eines Softwareherstellers, eine Lücke “kleinzureden”
- Der Wunsch nach Publicity, wenn eine IT-Sicherheitsfirma eine Schwachstelle möglichst groß darstellen möchte
- Kunden, für die ein Pentest nur ein Punkt auf einer Checkliste ist und die möglichst gut “dastehen” möchten
- Unterschiede in der Bewertung durch das Cybersecurity-Team auf der einen und das Operations-/Admin-Team auf der anderen Seite
Ein Teil des Problems besteht darin, dass oft nur der CVSS-Base-Score als Maßstab für eine Bewertung der Kritikalität verwendet wird. Warum der CVSS-(Base-)Score allein nicht ausreicht und welche Aspekte bei der Bewertung von Schwachstellen eine Rolle spielen können, habe ich bereits in früheren Beiträgen erläutert.
Wichtig ist, dass dabei selbst auf den ersten Blick kleine Schwachstellen große Bedeutung bekommen können.
Cache-Control-Header in Webapplikationen
Mittels des HTTP-Headers “Cache Control” können Webapplikationen steuern, ob und wie Inhalte vom Browser oder Proxies zwischengespeichert werden dürfen. Werden sensible Inhalte ausgeliefert, sollten Proxies und Clients angewiesen werden, keine Inhalte zwischenzuspeichern:
Cache-Control: no-storeEin fehlender Header würde bei einer Webseite mit einem “normalen” Sicherheitsniveau mit der Kritikalität “Medium/Mittel” im Pentestbericht vermerkt werden. Denn auch wenn dadurch ggf. schutzbedürftige Daten zwischengespeichert werden, so ist im Regelfall noch ein Zugriff auf die lokalen Cache-Dateien des Browsers bzw. Proxies nötig, um unbefugten Zugriff auf geschützte Inhalte zu erlangen.
Doch was passiert, wenn es plötzlich um kritische Daten geht? Wenn es – angelegt an ein reales Beispiel aus einem unserer Penetration Tests – um die Weboberfläche eines Enterprise-Key-Management-Systems (KMS) geht? Also um ein System, welches die wichtigsten Schlüssel und Geheimnisse eines Unternehmens verwalten soll und welches mit einer ganzen Reihe von Sicherheitsmaßnahmen wie Verschlüsselung, Hardware-Security-Modul, Zwei-Faktor-Authentifizierung, Vier-Augen-Prinzip und Trennung von Verantwortlichkeiten geschützt ist?
Fehlt hier die Anweisung, dass Inhalte nicht zwischengespeichert werden können, kann es dazu kommen, dass Inhalte, die verschlüsselt bleiben müssen, plötzlich vom Browser im Klartext gespeichert werden. In einem Unternehmensumfeld bedeutet dies dann, dass z.B. alle lokalen Administratoren z.B. Helpdesk-Mitarbeiter) und Domainadministratoren Zugriff auf die Klartext-Schlüssel erhalten können. Durch diese Lücke werden auch Angriffe möglich, gegen die ein KMS explizit schützen soll, sobald nur von einem Gerät zugegriffen wird, welches selbst nicht verschlüsselt ist. Letztlich wird so der Daseinszweck des KMS teilweise konterkariert.
Im konkreten Fall war dies Anlass für uns, die Schwachstelle als “High/Hoch” einzustufen, da hiermit eine ganze Reihe von Schutzmaßnahmen unterlaufen wurden.
Hoch + Hoch = Kritisch
Schwachstellen isoliert zu betrachten, ist wie mit Scheuklappen unterwegs zu sein. Gelingt es einem Angreifer eine einzelne Schwachstelle (z.B. mit einer “mittleren” oder “hohen” Kritikalität) auszunutzen, erhält er oft nur begrenzten Zugriff auf das betroffene System. Oftmals gelingt es erst in Kombination mit einer weiteren Schwachstelle auf dem System oder einem benachbarten System, welches vorher vom Zugriff geschützt war, das System zu übernehmen.
Ein typisches Beispiel sind Serverdienste die im Kontext des “root”-Benutzers ausgeführt werden. Diese Praxis ist 2024 zwar weitaus weniger verbreitet als noch vor wenigen Jahren, sie kommt allerdings immer noch vor. So wird dann z.B. der Java-Applikationsserver Tomcat mit Root-Rechten ausgeführt. Ein kleiner Fehler in Java-Webapplikation genügt dann, um einem Angreifer root-Rechte auf dem Server zu verschaffen.
Oder ein weiteres Beispiel, ebenfalls angelehnt an ein aktuelles Engagement: die Datenbankbankdateien werden verschlüsselt auf dem Server gespeichert. Schlecht allerdings, wenn sowohl die Datenbankdateien als auch die Verschlüsselungskeys für jeden Benutzer auf dem Server zugänglich sind. Dazu noch ein Benutzer, dessen Passwort in Sekunden erraten ist und schon macht man es Angreifern fast zu leicht…
Fazit: Genau hinsehen, es kommt darauf an…
Allein auf die Kritikalität einer einzelnen Schwachstelle zu schauen, greift also zu kurz. Neben der betroffenen Applikation bzw. dem betroffenen Server, ihrer Aufgaben, Wichtigkeit und Umgebung muss auch die Gesamtheit bzw. Kombination von Schwachstellen betrachtet werden. Unter Umständen können Schwachstellen, denen man sonst nur geringe Bedeutung zumessen würde, in einem speziellen (Sicherheits-) Kontext hohe Bedeutung gewinnen. Oder zwei Schwachstellen, die für sich genommen vergleichsweise harmlos wären, ermöglichen in Kombination die komplette Übernahme des Systems.
Bist du auf der Suche nach Unterstützung im Bereich des Schwachstellenmanagements oder benötigt dein Unternehmen einen Penetration Test?