Eigene Schwachstellen sind gleicher als andere

Wer kennt es nicht? Ein normaler Montagmorgen. Man steht auf, fährt ins Büro, macht sich einen Kaffee und hackt nebenbei mal ein Portal. Nein? Nicht normal? Na gut, dann fangen wir mal weiter hinten an.

Security spielt in der heutigen Zeit eine essenzielle Rolle. Das sollte jedem mittlerweile klar sein. Demnach sollten Projekte, insbesondere im Bereich der Softwareentwicklung, auf Sicherheit getestet werden. Das beginnt bei der Sensibilisierung und Schulung der Entwicklerinnen und Entwickler, der Etablierung eines SecDevOps-Prozesses bis hin zu umfangreichen Pentests vor einem Release. Um dem nachzukommen, wurde ich von Kollegen gebeten, ein Portal durch einen sogenannten Pentest auf Sicherheit zu überprüfen. Es sollte dabei um ein Portal für einen größeren Kunden gehen, dass im Backend Keycloak für das Identity and Access- Management (IAM) einsetzt. Der Pentest sollte etwa eine Woche andauern.

Der Test ergab erfreulicherweise wenige Sicherheitslücken. Jedoch stach eine besonders hervor. Sicherheitsschwachstellen werden mit der sogenannten Common Weakness Enumeration (CWE) kategorisiert und die entsprechende Lücke war aus der Kategorie „CWE-208 Observable Timing Discrepancy“. Zudem ließ sich die Schwachstelle auch in „CWE-640 Weak Password Recovery Mechanism for Forgotten Password“ einordnen. Das bedeutet so viel wie, dass es möglich ist, aus der Reaktions- beziehungsweise Responsedauer Schlussfolgerungen über interne Prozesse ziehen zu können. In diesem expliziten Fall ging es dabei um den Prozess der Passwortwiederherstellung. Prinzipiell sollte eine entsprechende Funktion so gestaltet sein, dass man keine Informationen darüber erhält, ob der Benutzerzugang, für den man das Passwort zurücksetzen will, existiert oder nicht. Dies könnte zum Beispiel so aussehen, dass man nach jeder Eingabe einer Zugangskennung die Nachricht erhält, dass eine E-Mail zur Wiederherstellung verschickt wurde – unabhängig davon, ob der Zugang existiert. Dies war bei dem Portal auch genauso umgesetzt. Jedoch fiel mir schnell auf, dass dieser Prozess manchmal etwas länger dauert. Mit dieser Erkenntnis konnte ich schnell zeigen, dass die endgültige Bestätigung des E-Mail-Versands ungefähr zehnmal so lang dauert, wenn ein Benutzerkonto existiert. Einem „Script-Kiddie“ mag das vielleicht kaum auffallen, aber ein geübter Angreifer sieht hier eine Möglichkeit, schnell an existierende Benutzernamen oder E-Mail-Adressen zu kommen. Nachdem die Schwachstelle mit den Developern des Portals besprochen wurde, stellte sich schnell heraus, dass dieses Problem bei Keycloak und nicht im Code des Portals liegt.

Wie kann ein Angreifer diese Schwachstelle nun ausnutzen?

Um diese Frage zu beantworten, sollten folgende Punkte betrachtet werden.

1. Keycloak wird von vielen Unternehmen eingesetzt

Der primäre Einsatz von Keycloak findet sich im Unternehmensbereich. In der Regel haben Unternehmen ihre eigenen Keycloak-Instanzen, welche auch nur für ihre Mitarbeitenden und/oder Kundinnen und Kunden genutzt wird.

2. Mitarbeitende eines Unternehmens können einfach identifiziert werden

Durch soziale Medien wie LinkedIn, Xing oder Facebook ist es in der heutigen Zeit sehr einfach, Mitarbeitende bestimmter Unternehmen zu identifizieren. Zudem ist es auch einfach, persönliche Informationen über Mitarbeitende oder Kundinnen und Kunden eines Unternehmens zu finden, da diese meist freiwillig von Personen geteilt und verbreitet werden. Das können Informationen wie Hobbys, politische Einstellungen, Familienmitglieder, Freunde und Bekannte oder bestimmte Aktivitäten sein.

3. Kunden eines Unternehmens identifizieren

Kundinnen und Kunden eines Unternehmens sind etwas schwieriger zu identifizieren, jedoch ist es nicht unmöglich. Wenn besagte Kundinnen oder Kunden nicht freiwillig Informationen veröffentlichen, die ihre Verbindung zu einem Unternehmen preisgeben, kann eine Sicherheitslücke wie die oben beschriebene helfen. Es ist einfach, sehr große Datenbanken und Listen mit E-Mail-Adressen im Internet zu finden. Diese stammen häufig aus älteren Hacks oder anderen Leaks. Mit solchen Listen kann nun ein einfacher Enumeration-Angriff auf eine Passwort-Recovery-Funktion durchgeführt werden, um anhand der Zeitdiskrepanz zu erkennen, welche der E-Mail-Adressen einen Zugang zu der entsprechenden Keycloak-Instanz hat.

Beim Hacken geht es primär um Informationen. Nicht umsonst heißt die erste Regel „Enumeration, Enumeration, Enumeration“. Kurz: so viel Information wie möglich zusammentragen. Solche Daten können dann anschließend für Dictionary-Attacks (ausprobieren von Passwörtern aus Datenbanken mit weitverbreiteten Passwörtern) oder für Spear-Phishing-Angriffe (Phishing mit persönlichem Kontext, was den Angriff glaubwürdiger macht) genutzt werden.

Bekannte Schwachstellen in Software-Produkten werden in der Regel in einer globalen Liste der Common Vulnerabilities and Exposures-Datenbank (CVE) gesammelt. Für einen Pentester ist es eine große Ehre, eine bisher noch unbekannte Schwachstelle zu finden und dafür eine offizielle CVE-Nummer zu erhalten. Damit eine Schwachstelle jedoch in die Datenbank aufgenommen wird, muss diese einen Prozess durchlaufen. Dazu gehört das Melden der Schwachstelle, ein Feedback des Developers und so weiter. Beim Melden gibt es zwei Vorgehensweisen: Es gibt sogenannte CNAs (CVE Numbering Authority). Diese sind dafür verantwortlich, CVE-Nummern für Produkte anzulegen, die aus ihrem Hause kommen. Sollte der Developer eines Produkts keine CNA sein, so wird die Mitre Corportation, eine NPO und Forschungseinrichtung für IT-Security, informiert und vergibt eine CVE-Nummer. Red Hat ist sowohl der Entwickler von Keycloak, wie auch eine CNA. Somit kann für diese gefundene Schwachstelle ausschließlich Red Hat eine CVE vergeben.

Da es sich hier um eine ernst zu nehmende Schwachstelle handelt, die auch in entsprechenden CWEs kategorisiert werden kann, meldete ich den Fehler an Red Hat. Obwohl auf der Webseite eine Antwort binnen weniger Werktage versprochen wird, erhielt ich vier Wochen keine Reaktion. Daraufhin meldete ich den Fehler erneut mit dem Hinweis, dass ich die Sicherheitsschwachstelle zeitnah veröffentlichen werde, sollte Red Hat erneut nicht reagieren. Diesmal ging es sehr schnell und ich erhielt bereits nach zwei Tagen den Hinweis, dass man sich das Problem anschaue. Nach einer weiteren Woche erhielt ich dann eine Antwort. Trotz meiner Argumente sowie einer eindeutigen Einordnung in mindestens zwei CWEs, stufte Red Hat dieses Problem nicht als Sicherheitsrisiko ein. Das ist etwas verwunderlich, da es bereits für andere Produkte ähnliche CVEs wie zum Beispiel Novel iChain 2.2 aus dem Jahr 2003 gibt. Auf der einen Seite kann ich das Verhalten nachvollziehen, denn wer möchte schon eine CVE für die eigene Software erhalten? Auf der anderen Seite ist Red Hat eine CNA. Es steckt nicht umsonst das Wort „Authority“ in dem Kürzel und besonders als CNA sollte man eine Vorbildfunktion einnehmen.

Trotzdem habe ich mich dazu entschlossen, ein Advisory zu verfassen und zu veröffentlichen. Bei einem Advisory handelt es sich um ein Whitepaper zu einer gefundenen Schwachstelle, worin die Schwachstelle beschrieben wird und als Medium für eine Veröffentlichung genutzt wird. Das Advisory befindet sich am Ende des Artikels zum Download.

Trotz der unterschiedlichen Einschätzung hat Red Hat eine Verbesserung versprochen, sodass dieses Problem in der Zukunft hoffentlich behoben wird und das ist am Ende das, was zählt! Also auf zum nächsten Kaffee und zur nächsten Schwachstelle!

Zum Advisory