Responsible DisclosureIm Folgenden stellen wir unseren Hack am Physical Security Information Management System “WinGuard” der Advancis Software & Services GmbH vor. Die hier aufgeführten Schwachstellen und Findings haben wir dem Hersteller im Rahmen eines Responsible Disclosure Verfahrens mitgeteilt.
Advancis hat vorbildlich reagiert. Wir haben umgehend einen Termin mit der Geschäftsführung und Entwicklungsleitung bekommen, wurden als Sicherheitsforscher ernst genommen und konnten unsere Findings präsentieren. Das ist nicht selbstverständlich. Immer noch reagieren viele Softwareunternehmen reflexhaft defensiv und drohen gar mit Klage.
An dieser Stelle ein Shout Out an Advancis: Euer Umgang mit White Hats ist vorbildlich! Wir kommen gerne wieder 😉
Advancis hat kurzfristig alle unten genannten Schwachstellen beseitigt und den Kunden hierzu ein umfassendes Update zur Verfügung gestellt. Grundsätzlich bestanden die Sicherheitslücken nur, wenn der WinGuard-Webserver und/oder der Service-Zugang in den Einstellungen aktiviert waren. Betroffen sind die Versionen WinGuard X4 Build 17.5 und niedriger. Sollten Sie WinGuard in Ihrem Unternehmen einsetzen, stellen Sie bitte sicher, das aktuelle Release installiert zu haben.
Wie Systeme die Sicherheit schaffen sollten, selbst ein Einfallstor für Angreifer werden: Im konkreten Fall sprechen wir hier von einem Physical Security Information Management System (PSIM) bzw. Gefahrenmanagementsystemen (GMS). Diese dienen dazu, eine Vielzahl von Meldungen und Funktionen aus Subsystemen effizienter zu verarbeiten. Subsysteme sind typischerweise:
- Einbruchmeldeanlagen
- Zutrittskontrollsysteme
- Elektronische Schließanlagen
- Videoüberwachung
- Brandmeldeanlagen
- Feuerlöschanlagen
- Freigeländesicherung (Bewegungsmelder, Zaunüberwachung)
- uvm.
PSIM bzw. GMS Systeme werden meistens von Unternehmen eingesetzt, die eine Vielzahl solcher Sicherheitsanlagen implementiert haben. Das sind in der Regel Unternehmen mit hohen oder höchsten Sicherheitsanforderungen. Mit der Implementierung eines PSIM Systems zielen sie darauf ab, das Niveau der Sicherheit ihrer Gebäude, Anlagen und Liegenschaften zu erhöhen.
Mitarbeiter der Sicherheitszentrale eines solchen Unternehmens erleben durch ein PSIM System deutliche Effektivitäts- und Effizienzgewinne. Durch das Zusammenführen all der Subsysteme auf einer Bedienoberfläche ist deren Steuerung denkbar einfach geworden. (Und kaum jemand muss sich mehr mit den Subsystemen selbst befassen, die häufig nicht sonderlich benutzerfreundlich sind.)
Meldet die Brandmeldeanlage z.B. ein Feuer im Gebäude, so kann der Mitarbeiter in der Sicherheitszentrale, je nach Konfiguration, mit einem Mausklick das Videobild des Raumes einsehen. Und so verifizieren, ob es tatsächlich brennt, oder lediglich ein Täuschungsalarm vorliegt.
Ein anderes Beispiel aus der Praxis: Jemand möchte einen Standort in der Peripherie betreten, hat hierfür jedoch keine Zutrittsberechtigung. Vielleicht, weil der Zutritt außerhalb der üblichen Geschäftszeiten erfolgt. Diese soll ihm nun ausnahmsweise gewährt werden. Nun kann der Mitarbeiter in der Sicherheitszentrale über das PSIM System, je nach Konfiguration, komfortabel
die Einbruchmeldeanlage für den Bereich bzw. das Gebäude deaktivieren
über die elektronische Schließanlage die erforderlichen Türen öffnen
Und spätestens dieses Beispiel lässt doch etwas aufhorchen. Was wäre, wenn ein solches PSIM System durch böswillige Dritte gesteuert würde? Diese Frage hat uns beschäftigt. Insbesondere weil PSIM Systeme häufig von Betreibern Kritischer Infrastrukturen (KRITIS) eingesetzt werden. Die zuverlässige Versorgung mit Energie und Wasser, sowie mit anderen kritischen Dienstleistungen nach BSI-KritisV ist ein elementarer Baustein für unseren gesellschaftlichen Frieden. Wenn die Sicherheit von KRITIS durch unzureichend gesicherte PSIM Systeme kompromittiert würde, könnte dies fatale Folgen haben.
Den Marktführer im Fokus
Das PSIM System “WinGuard” aus dem Hause Advancis Software & Services GmbH wird weltweit eingesetzt und ist eines der fortschrittlichsten Lösungen auf dem Markt. Auf der Website schreibt Advancis:
“Physical Security Information Management (PSIM) ist eine Softwareplattform, die mehrere unverbundene Sicherheitssysteme integriert und sie aus einer umfassenden Benutzeroberfläche heraus steuert. Dadurch wird der Anwender in die Lage versetzt, auftretende Situationen vollständig zu erfassen und optimal zu lösen.”
Diese Beschreibung deckt sich gut mit dem, wie auch wir PSIM wahrnehmen und wie wir es auch selbst oben beschrieben haben. Darüber hinaus führt Advancis aus:
“Mit WinGuard definieren wir PSIM+ als eine Lösung, die über den bekannten Umfang hinausgeht und gewerkübergreifende Integration der gesamten Gebäude-, Kommunikation und IT-Infrastruktur bietet. Auch die Anbindung an übergeordnete Einsatzleitsysteme ist eine Erweiterung gegenüber klassischen PSIM-Systemen.”
Advancis bemüht sich offensichtlich, möglichst alle relevanten Systeme zu vernetzen und dringt hierbei auch in Bereiche vor, die originär wenig mit der Gebäude- und Anlagensicherheit selbst zu tun haben. Ziel von Advancis ist es, den Nutzen für den Betreiber zu steigern. Aber klar ist: Je höher der Grad der Vernetzung von Systemen, desto höher ist auch das Risiko, welches sich aus einer einzigen Schwachstelle ergeben kann.
Die Suche nach Schwachstellen in WinGuard
Für unsere Sicherheitsforschung haben wir keinerlei Finanzierung oder Zuwendung erhalten. Unsere Sicherheitsforschung betreiben wir aus reiner Neugier und im Interesse daran, durch das Aufdecken von Sicherheitslücken Hersteller zur Verbesserung ihrer Produkte zu motivieren.
Advancis spricht selbst von einem erhöhten IT-Sicherheitsstandard, den sie u.a. mit folgenden Maßnahmen erreichen wollen:
- Eingesetzte Verschlüsselung (TLS und AES)
- Möglichkeit der Redundanz
Um diese Aussagen zu überprüfen, haben wir WinGuard auf mögliche Schwachstellen hin untersucht. Dabei wurden Sicherheitsprobleme, die nicht praxisrelevant sind, ignoriert. Hierunter fällt z.B.Information disclosure
Der Versuchsaufbau
Die Herausforderung beim Aufbau einer Versuchsumgebung besteht immer darin, eine möglichst realistische Simulation eines Angriffs zu gestalten.*
Unser Setup:
- Blackbox Test: Wir hatten weder Kenntnis über den Quellcode, noch über Systemarchitektur
- Wir haben ausschließlich Informationen aus öffentlich verfügbaren Dokumentationen verwendet.
- Wir haben uns auf eine lokale WinGuard Installation beschränkt. Schließlich wird ein Angreifer auch kein großes Testnetzwerk mit verschiedensten Schnittstellen zur Verfügung haben.
Das alles geschah unter der Prämisse, dass der Angreifer mit dem WinGuard Server kommunizieren kann.
Ausloten der Angriffsvektoren
Eine Stärke von WinGuard liegt darin, dass es eine Vielzahl von Subsystemen anbinden kann. Für nahezu jedes gängige Sicherheitssystem bietet WinGuard eine passende Schnittstelle. Aus der Perspektive eines Angreifers sind jedoch genau diese Schnittstellen besonders interessant. Denn jede von Ihnen bietet ihm einen potentiellen Zugang zum System.
Bevor wir die Schnittstellen zu Subsystemen untersuchten, wollten wir uns jedoch den noch vielversprechenderen Schnittstellen zur Steuerung von WinGuard widmen. Hierzu zählen u.a. der Webserver und die Service-Schnittstelle.
Finding 1: Der Webserver
Webserver sind typischerweise nach außen hin exponiert und für Angreifer auch dann zugänglich, wenn diese sich nicht im internen Netz befinden.
Dementsprechend wählten wir einen Versuchsaufbau nach folgendem Schema:
Ein Angreifer könnte in diesem Fall den WinGuard Server nicht direkt angreifen, sondern müsste sich zuerst den WinGuard Webserver vornehmen.
Entsprechend haben wir unseren Angriff beim Webserver angesetzt. Dieser lieferte, soweit gewöhnlich, Dateien für die WebApp aus (JS, HTML, CSS,…).
Außerdem stellte der Webserver einen “Websocket” Server bereit. Die Webanwendung selbst wird durch den Webserver ausgeliefert, kommuniziert dann jedoch mit dem “Websocket” Server.
Ein Beispiel aus dieser Kommunikation:
{„method“:“login“,“params“:{„username“:“Benuter1″,
„password“:“Geheim“,“language“:“de“,“workstation“:
„Web“,“type“:“web“},“Id“:3}
Denial of Service via “Websocket” Server
Ist der Webserver nicht mehr erreichbar, erhält der User über diesen Weg auch keinen Zugriff mehr auf WinGuard.
Denial of Service Angriffe sind eine weit verbreitete Vorgehensweise. In diesem “klassischen Ansatz” senden die Angreifer Millionen von nutzlosen Anfragen. Der Webserver ist mit diesen Anfragen ausgelastet und ermöglicht in diesem Zustand für reguläre Benutzer keinen Zugriff mehr.
Für den Angreifer gibt es bei dieser Vorgehensweise jedoch auch eine Reihe von Problemen. Zum einen müsste er über eine sehr gute Netzwerkanbindung verfügen, zumindest über eine, die besser ist als das angegriffene System. Zum anderen kann die IP des Angreifers einfach gesperrt werden (z.B. in den Einstellungen der Firewall). In einem solchen Fall wäre die Auslastung des Webservers sofort wieder normalisiert und seine Erreichbarkeit für Benutzer wiederhergestellt. Jedoch findet sich ein interessanter Fehler in der Websocket Funktion:
{„method“:“GetSettings“,“params“:{„keys“:[]….
Der WinGuard Server führt den Befehl wie folgt aus:
Das Problem hierbei ist, dass kein Length-Check des Parameters “Keys” vorgenommen wird. Hierdurch ist ein Denial of Service möglich.
Sendet der Angreifer viele leere Keys, werden diese daher ohne Überprüfung durch WinGuard in den Speicher geladen und dort vorgehalten. Aufgrund der WinGuard Speicherstruktur genügt es völlig, wenn der Angreifer wenige Megabyte Daten sendet, um den Speicher komplett zu füllen.
Die oben beschriebenen “klassischen” Probleme eines Denial of Service waren aus Sicht des Angreifers damit gelöst. Die Netzwerkanbindung des Angreifers spielte nun keine Rolle mehr, da die sich wenigen Megabyte an Daten auch problemlos z.B. über das Mobilfunknetz übertragen ließen. Und auch das Sperren der IP-Adresse des Angreifers blieb wirkungslos, da WinGuard bereits ausgelastet war, als die Daten einmalig gesendet wurden.
Finding 2: WinGuard Service-Zugang
Nach dem Webserver haben wir unsere Aufmerksamkeit auf den Service-Zugang gerichtet. Ist diese Schnittstelle in der Konfiguration aktiviert, ergeben sich gleich mehrere Sicherheitsprobleme.
Passwort Brute Force
Über die Einstellungen lässt sich in WinGuard ein Schutz vor Brute-Force-Angriffen einstellen. Der Service-Zugang scheint auf den ersten Blick uninteressant für Angreifer, denn
- es handelt sich hierbei lediglich um ein Monitoring Interface
- es macht keinen Unterschied, ob man sich als User oder als Admin anmeldet
- die Einstellungen können nicht geändert werden
Mutmaßlich hat Advancis aus ebendiesen Gründen für den Service-Zugang keine umfassenden Schutzmaßnahmen ergriffen. Beim Client Login war dies ja durchaus gegeben.
Auffällig war jedoch, dass es keine speziellen Nutzer für den Service-Zugang gab. Damit lag die Vermutung nahe, dass für den Service-Zugang dieselben User Credentials gültig sind, wie für die Clients.
Wir richteten die Brute-Force-Attacke daher auf den Service-Zugang und konnten feststellen, dass dieser, im Gegensatz zum Client, über keinen Brute-Force-Schutz verfügte.
Der Service-Zugang nutzte ein eigenes Protokoll, welches nicht öffentlich dokumentiert ist. Die Bitweise Analyse der übertragenen Daten brachte jedoch hervor, dass keine Verschlüsselung eingesetzt war.
Die fehlende Verschlüsselung ermöglichte den Angreifern, Passwörter im Netzwerk einfach mitzulesen. Systemseitig war an dieser Stelle auch keine Verschlüsselung vorgesehen, sprich – sie konnte an keiner Stelle aktiviert werden, wie der folgende Screenshot der Service Panel Oberfläche zeigt:
So reichten in diesem Fall verbreitete Netzwerk-Sniffer (z.B. Wireshark), um das Passwort im Klartext zu erhalten.
Mit den Erkenntnissen aus der Protokollanalyse haben wir ein Programm entwickelt, welches Passwörter für einen Benutzer-Account ausprobiert. Auf diese Weise konnten wir mehrere tausend Passwort-Versuche pro Sekunde ausprobieren. Hierfür haben wir vier gleichzeitige Verbindungen zum Server hergestellt. Je nach Netzwerkverbindung kann diese Zahl noch erhöht werden. Das ist natürlich abhängig von der Position des Angreifers im Netzwerk.
Die Wortlisten mit Passwörtern haben wir mit verbreiteten Programmen (crunch, cewl) auf unser Ziel hin zugeschnitten.
User Enumeration
Neben dem Passwort benötigen wir nun natürlich noch gültige Benutzernamen. Es hat sich gezeigt, dass WinGuard sich unterschiedlich bei Paketen mit gültigen und ungültigen Benutzernamen verhält.
Ein Beispiel:
1. Packet [Benutzer: root , Passwort: dummy] → Antwort: 24 Bytes
2. Packet [Benutzer: toor, Passwort: dummy] → Antwort: 24 Bytes
3. Packet [Benutzer: admin , Passwort: dummy] → Antwort: 1024 Bytes
Als wir mit verschiedenen Usernamen experimentiert haben, ist uns aufgefallen, dass bei gültigen Benutzern (hier “admin”) die Antwort länger ist (hier 1024 Bytes), als bei nicht vorhandenen Benutzern (“root” und “toor”). Bei WinGuard scheint an dieser Stelle Zeit ein Faktor zu sein, weshalb das Vorgehen nicht komplett deterministisch war. Bei Tests mit einigen hundert Benutzernamen gab es jedoch eine Treffsicherheit von > 90%. Für unsere Zwecke war das völlig ausreichend.
Zur Identifikation gültiger Benutzernamen haben wir ein weiteres Programm entwickelt mit der Aufgabe, zu prüfen, ob ein bestimmter Benutzer existiert. Das Programm hat sich hierfür aus einer Wordlist möglicher Benutzernamen bedient und diese nacheinander ausprobiert.
Ergebnis unserer Untersuchung
Unsere Analyse hat gezeigt, dass zum Zeitpunkt unserer Untersuchung sehr praxisrelevante Sicherheitslücken in WinGuard existieren, die auch für einen böswilligen Angriff hätten genutzt werden können. Abhängig von der genutzten Konfiguration (Webserver, Service-Zugang) ließ sich entweder der Betrieb von WinGuard erheblich stören (Denial of Service) oder, schlimmer noch: Der Angreifer konnte durch Mitlesen des Netzwerkverkehrs oder durch simples Ausprobieren Login-Daten erhalten. Mit diesen hätte der Angreifer das System und alle Subsysteme kontrollieren können.
Ende gut, alles gut.
Advancis hat nach unserem Hinweis alle Schwachstellen geschlossen und Kunden ein Update zur Verfügung gestellt. Die untersuchten Sicherheitslücken bestanden, wenn der WinGuard-Webserver und/oder der Service-Zugang in den Einstellungen aktiviert waren. Betroffen sind die Versionen WinGuard X4 Build 17.5 und niedriger. Sollten Sie WinGuard in Ihrem Unternehmen einsetzen, stellen Sie bitte sicher, dass Sie die aktuelle Version nutzen. In seinen Release Notes veröffentlicht der Hersteller Advancis darüber hinaus alle Änderungen, die stets in der neuesten WinGuard-Version umgesetzt wurden, sowie weitere technische und Erweiterungsinformationen.
Was unsere Forschungen immer wieder aufweisen ist, dass es essentiell ist, physische Sicherheitssysteme hinsichtlich Ihrer Angriffsflächen im Cyberraum im Blick zu behalten. Achten Sie auf Ihre Schnittstellen, sonst tut es evtl. ein anderer. Sind Ihre Systeme sicher? Gerne überprüfen wir Ihre Sicherheitsarchitektur auf Schwachstellen!
