Schwachstelle des Monats: Januar ’23

‍

Willkommen zu unserer neuen Blogserie: Schwachstelle des Monats! Mit dieser Reihe möchten wir Ihnen Einblicke in unsere tägliche Arbeit und die unserer Hacker geben und über Sicherheitslücken sprechen. Wir hoffen, so wichtiges Sicherheitswissen über spezifische Schwachstellen, deren Auffindung und die dabei verwendeten Techniken zu verbreiten und das Bewusstsein für all die Sicherheitslücken zu schärfen, die möglicherweise noch existieren.  

‍

So funktioniert es

‍

Wir berichten über aktuelle Schwachstellen, mit denen wir uns befassen und die direkt aus unserer Arbeit mit unseren Programmen und Kunden stammen. Das bedeutet, dass die Schwachstellen zum Zeitpunkt des Blogbeitrags nicht unbedingt behoben sind, was einige Konsequenzen mit sich bringt:

• Der Kunde und Eigentümer des Systems wird niemals genannt
• Das betroffene Produkt oder das spezifische System wird niemals genannt
• Wenn beides nicht garantiert werden kann, werden wir nicht über die Schwachstelle sprechen
• Eine spätere Offenlegung ist im Rahmen von CVD (Coordinated Vulnerability Disclosure) möglich

‍

Warum dieses Vorgehen?

‍

So können wir über das sprechen, was uns aktuell beschäftigt und noch mit allen Details frisch ist. Wir können Wissen und Einblicke in das vermitteln, was gerade passiert, anstatt über Dinge zu berichten, die in der Vergangenheit liegen. Wir sind fest davon überzeugt, dass geteiltes Wissen über Techniken oder technische Details von Schwachstellen die Sicherheit voranbringt – die Geschichte hat gezeigt, dass das Zurückhalten solcher Informationen langfristig nie geholfen hat. Kundennamen, betroffene Produkte oder spezifische Systeme sind nicht erforderlich, um über die technischen Aspekte zu sprechen; für diese Bereiche gibt es andere, etablierte Verfahren (CVD mit Advisories, CVE-IDs, …).

‍

Schwachstelle vom Januar 2023

‍

Credits: Diese Schwachstelle wurde von Raphaël Arrouas („Xel“) gemeldet

‍

Kontext des Bug-Bounty-Programms

• Ein zeitlich und budgetär begrenztes privates Programm (Reality Check)
• Nahezu die gesamte im Internet exponierte Angriffsfläche des Kunden im Scope (breiter Scope mit IP-Bereichen und den wichtigsten Second-Level-Domains)
• Zeitraum zwischen Programmstart und Einreichung des Berichts: 4 Tage

‍

Das System

• Mehrere Appliances für das Streaming von Videoinhalten (z. B. Live-Streaming von Events, Webcasts)
• Über das Internet exponiert, per IP erreichbar

‍

Die vom Hacker beschriebene Schwachstelle

‍

Der erste Schritt bestand darin, die Appliances im IP-Bereich zu identifizieren. Dazu gehörten der Systemtyp, die spezifische Version, der Hersteller usw. Im nächsten Schritt erfolgte die Registrierung auf der Website des Herstellers, um detailliertere Informationen und Zugriff auf die Firmware der Appliances selbst zu erhalten. Es stellte sich heraus, dass die Firmware nach der Registrierung in genau der Version heruntergeladen werden konnte, die der Kunde verwendete.

‍

Mit der vorliegenden Firmware konnte diese extrahiert und dekomprimiert werden (die Firmware selbst ist ein Linux-Dateisystem). Die Analyse ergab einen undokumentierten Benutzer, der identisch mit dem Admin-Benutzer war und den Namen des Herstellers im Benutzernamen trug.

‍

‍

Während das Passwort des Admin-Benutzers über dokumentierte Methoden geändert werden kann, lässt sich der andere, undokumentierte Benutzer weder ändern noch deaktivieren. Eine Änderung des Benutzers ist explizit ausgeschlossen, wie im Quellcode (aus einer dekompilierten DLL) zu sehen ist.

‍

‍

In der htpasswd-Datei ist lediglich der Hash des Passworts verfügbar – und dieser scheint nicht leicht zu knacken zu sein. Wie sich herausstellte, war dies jedoch gar nicht nötig, da der Benutzer in einem Startskript verwendet wird, das das Passwort im Klartext enthält…

‍

Kurz gesagt: Die Appliances verfügen über einen undokumentierten, unveränderbaren Hersteller-Admin-Benutzer, der nicht deaktiviert werden kann.

‍

Eine schnelle Censys-Suche nach dem Zertifikatsaussteller (der bei allen Appliances identisch ist) ergab etwa 8.850 solcher Geräte, die offen im Internet erreichbar sind.

‍

Auswirkungsanalyse

‍

Die entscheidende Frage bei diesem Backdoor-Benutzer lautet: Was lässt sich damit anstellen? Nun, eine ganze Menge:

• Die Appliances stellen zahlreiche Webservices bereit (nicht alle sind dokumentiert, aber die vollständige Liste lässt sich durch Dekompilieren der Firmware ermitteln).
• Die Überprüfung zeigt, dass diese Webservices tatsächlich aufgerufen und mit dem Backdoor-Benutzer genutzt werden können.
• Einige Möglichkeiten mit den Webservices:
  • Abrufen der Geräteprotokolle (die Challenge- und Response-Details einiger Authentifizierungsverfahren enthalten – aber das ist eine andere Geschichte…)
  • Konfiguration des Streamings (Festlegen und Abrufen von Stream-Details)
  • …

‍

Laufende Schritte (entweder durch uns, den Kunden oder in Kombination):

• Koordination mit dem Anbieter zur Behebung der Schwachstelle
• Herausgabe eines CVE-Advisory

Interessieren Sie sich für dieses Thema und möchten Sie mit unseren Kunden und Hackern an solchen Schwachstellen arbeiten? Wir stellen ein – melden Sie sich gerne bei uns.

Interessiert daran, Schwachstellen zu finden? Wir sind immer auf der Suche nach neuen Hacking-Talenten – bitte registrieren Sie sich hier: www.signalfisher.com!