Fünf High-Schwachstellen, kein Weg hinein

Kontext

Der Kunde gab uns einen engen, präzisen Umfang: gut ein Dutzend öffentliche Adressen im Internet, ein klassischer Perimeter. Die Frage war ebenso einfach. Kann jemand von außen hier ins Innere gelangen?

Die Umgebung war über Jahre gewachsen, und das sah man. Ein paar Linux-Server mit Web-Diensten und SSH, eine Handvoll Switches, ein Zeitserver, DNS, SNMP, Admin-Panels offen im Netz. Ein Teil der Hosts wirkte frisch gepflegt, ein anderer erinnerte an Zeiten, über die wir lieber nicht in der Gegenwart schreiben.

Herausforderung

Auf den ersten Blick sah es schlecht aus. Ein automatischer Scan zählte fünf Schwachstellen der Stufe High und neunzehn Medium, vor allem auf veralteten Versionen von OpenSSH und nginx. Einer der Server meldete sich mit einem SSH-Banner, das ein Jahrzehnt alt war:

$ nc klient.example 22
SSH-2.0-OpenSSH_6.0p1 ...

Für einen Scanner ist ein solches Banner eine fertige CVE-Liste. Er hängt sie automatisch an, weil er eine Versionsnummer sieht; ob sich die Lücke tatsächlich nutzen lässt, prüft er nicht. Und hier beginnt die eigentliche Arbeit.

Denn die andere Seite sah anders aus, als die Liste nahelegte. Der Perimeter war nicht gedankenlos. Die Mail lag hinter einem externen Security-Gateway, der Web-Verkehr hinter einem Anti-DDoS-Dienst, der SPF-Eintrag war korrekt, Standardpasswörter des Herstellers gab es nirgends. Hier hat jemand an Sicherheit gedacht, nur ungleichmäßig. Ein glaubwürdiger Bericht muss das einräumen, bevor er eine These aufstellt.

Was wir getan haben

Wir begannen mit vollständiger Informationsbeschaffung: einem Scan aller TCP-Ports und der tausend häufigsten UDP-Ports, ohne Ping, um Hosts zu finden, die auf Echo nicht antworten, aber trotzdem lauschen. Danach das Fingerprinting jedes Dienstes, um zu wissen, womit wir es zu tun haben, und nicht nur, welche Versionsnummer er angibt.

Parallel gingen wir in die Open-Source-Recherche. Ein Grey-Box-Ansatz, minimale Interaktion mit dem System, maximale Nutzung dessen, was die Welt ohnehin über den Kunden weiß: Subdomains, DNS-Konfiguration, öffentliche Datenlecks.

Den Erstzugriff haben wir zweigleisig getestet. Brute Force gegen Dienste mit Anmeldung, darunter Admin-Panels und das VPN. Und den Versuch, das in den Lecks Gefundene als echte Anmeldedaten zu verwenden.

Das Ganze bildet sich auf MITRE ATT&CK so ab:

Der wichtigste Teil dieses Tests ist nicht die CVE-Tabelle. Es ist die manuelle Prüfung jedes Eintrags darin. Wir haben die Bedingungen für eine Ausnutzung der Reihe nach kontrolliert: ob das nötige Modul überhaupt aktiviert ist, ob der Angriff nur über eine Rückverbindung funktioniert, ob sich das mit irgendetwas anderem zu einem sinnvollen Vektor verketten lässt. Die Antwort fiel jedes Mal ähnlich aus. Nicht von hier.

Ergebnis

Über keine der am Perimeter gefundenen Schwachstellen ließ sich von außen ins Netz gelangen. Null CRITICAL. Die fünf High und neunzehn Medium waren echte veraltete Versionen, aber ohne erfüllte Bedingungen für eine Ausnutzung: aktivierte Module fehlten, ein Teil der Angriffe funktionierte nur über Rückverbindungen, keine ließ sich verketten. Standarddaten des Herstellers gab es ebenfalls nicht. Die Brute-Force-Versuche schlugen fehl.

Würde der Bericht hier enden, wäre er angenehm und nutzlos. Denn das reale Risiko lag außerhalb der Spalte "Severity".

Erstens fanden wir in öffentlichen Lecks funktionierende Paare: die E-Mail-Adresse eines Mitarbeiters und ein Passwort für Konten der Kundendomain. Nicht aus seinem Netz, sondern aus fremden Datenbanken, die vor Jahren geleakt wurden. Der Perimeter war dicht, und die Ersatzschlüssel lagen beim Nachbarn.

Zweitens sagte schon das Alter dieser Software etwas aus. Ein Server mit SSH von vor einem Jahrzehnt ist heute nicht gefährlich, aber er ist der Beweis, dass es keinen Prozess zum automatischen Einspielen von Patches gibt. Was heute harmlos ist, bekommt morgen einen öffentlichen Exploit, und niemand bemerkt es, weil niemand hinsieht.

Die Empfehlungen haben wir nach Priorität geordnet:

• Einen Prozess für automatisches Patchen einführen und veraltete Dienste auf unterstützte Versionen heben, beginnend mit den ins Internet gestellten Hosts.
• Für die in den Lecks aufgetauchten Konten einen Passwort-Reset erzwingen und die Mehr-Faktor-Authentifizierung dort aktivieren, wo sie noch fehlt.
• Eine laufende Überwachung von Datenlecks fest einbinden, damit die nächste Kombination aus Login und Passwort auffällt, bevor sie ein anderer findet.
• Die Zertifikatskonfiguration und die Vertrauenskette auf den ins Internet gestellten Diensten in Ordnung bringen und die übermäßige Preisgabe von Versionen in Headern und Fehlerseiten einschränken.
• Schwache MAC-Algorithmen und CBC-Chiffren auf SSH abschalten und die Terrapin-Schwachstelle durch einen strengen Schlüsselaustausch schließen.

Ein externer Netzwerktest, der mit einer bloßen CVE-Liste endet, beantwortet die falsche Frage. "Welche alten Versionen haben Sie" ist nicht dasselbe wie "lässt sich darüber eindringen", und diese beiden Sätze führen zu völlig unterschiedlichen Budgetentscheidungen.

War Ihr letzter Test eine Liste von Schwachstellen ohne einen einzigen Satz dazu, ob sich eine davon real ausnutzen lässt, haben Sie einen Scan bekommen, keinen Test. Wann hat zuletzt jemand geprüft, ob Ihre Konten nicht schon in einem fremden Leck liegen?