Rich Client-Applikationen – schlummernde Gefahren in Unternehmensnetzwerken?

Die zunehmende Digitalisierung von Geschäftsprozessen geht seit Jahren mit einem deutlichen Trend zu Webapplikationen einher. Dennoch kommen in vielen Unternehmen immer noch sogenannte Rich Client-Applikationen (oftmals als Altlasten) zum Einsatz. Diese zeichnen sich dadurch aus, dass einzelne Verarbeitungsschritte clientseitig durchgeführt werden – im Gegensatz zu Webapplikationen, bei denen in der Regel die gesamte Geschäftslogik serverseitig implementiert ist.

Der Einsatz von Rich Client-Applikationen bietet verschiedene Vorteile, hat aber auch historische Gründe. Zu Beginn der vernetzten Computerwelt waren die Möglichkeiten zur Gestaltung der Benutzeroberflächen von Webapplikationen längst nicht so vielfältig wie heutzutage. Rich Client-Applikationen profitierten jedoch von den mächtigen Benutzeroberflächen der Betriebssysteme, weil sie Daten übersichtlich darstellen konnten und so eine effiziente Bedienung der Applikation ermöglichten. Ein weiterer Grund für den Einsatz von Rich Client-Applikationen ist die Möglichkeit, große Datenmengen lokal zu verarbeiten, was Kapazitäten bei der Datenübertragung und der Serverhardware einspart. Auch wenn manche Geschäftsprozesse mit speziellen Anforderungen immer noch von einer Rich Client-Implementierung profitieren, rücken diese Vorteile heutzutage jedoch immer mehr in den Hintergrund. Mit den neuesten Webtechnologien lassen sich auch sehr komplexe Benutzeroberflächen realisieren.

Auch aus Sicht der IT-Sicherheit ist der Trend zu Webapplikationen zu begrüßen. Da die Applikationslogik ausschließlich serverseitig implementiert ist, lässt sie sich viel einfacher warten und gegen Angriffe schützen. Eine Rich Client-Applikation bietet hingegen durch die lokale Verarbeitung eine wesentlich größere Oberfläche für Angriffe und Manipulationen. Verschärfend kommt hinzu, dass viele historisch „gewachsene“ Rich Clients in einer Zeit implementiert wurden, in der das Bewusstsein für Sicherheitsschwachstellen noch nicht so ausgeprägt war wie heute.

Aus diesem Grund sollten bei der Bewertung der Sicherheit im Unternehmensnetzwerk auch die eingesetzten Rich Client-Applikationen nicht außer Acht gelassen und einem gezielten Penetrationstest unterzogen werden. Um einen Einblick zu bekommen, wie ein solcher Penetrationstest bei einer Rich Client-Applikation verläuft und welche Schwachstellen auftreten können, wird im Folgenden die Vorgehensweise eines IT Security Consultants bei einem solchen Test beschrieben.

Penetrationstest einer Rich Client-Applikation: Die Vorbereitung

Für den Erfolg des Penetrationstests ist es essenziell, die Funktionalität der Applikation vollständig zu verstehen. Der Consultant durchläuft daher zunächst die typischen Arbeitsschritte eines Anwenders, um sich einen Überblick über die Funktionen und die von der Applikation verarbeiteten Daten zu verschaffen. Dies hilft dem Consultant später bei der Identifizierung von möglichen Angriffen gegen die Applikationslogik: Wie sieht das Berechtigungskonzept der Applikation aus? Welche Möglichkeiten bieten sich einem Angreifer bei einer möglichen Rechteeskalation? Gibt es Daten, die vor dem Zugriff anderer Benutzer geschützt sind? Das Ergebnis ist eine Liste der für einen Angreifer lohnenswerten Angriffsziele.

Nachdem sich der Consultant einen Überblick über die Funktionalität verschafft hat, beginnt er damit, die technische Implementierung der Applikation zu analysieren. Das Ziel ist hierbei in erster Linie, die eingesetzten Technologien der Applikation (Programmiersprachen, Entwicklungs-Frameworks, Dateiformate etc.) zu identifizieren. Durch Kenntnis der Technologien können anschließend die notwendigen Werkzeuge ausgewählt werden, um die Applikation gegebenenfalls zu dekompilieren und im weiteren Verlauf eine statische Codeanalyse durchführen zu können. Kommen Rapid Application Development (RAD) Frameworks zum Einsatz, kann die Installation des Framework oft ebenfalls hilfreich sein, da der Consultant so Zugriff auf die typischen Entwicklungswerkzeuge der Applikation erhält. Dies erlaubt in einigen Fällen auch den direkten Zugriff auf lokale Datendateien der Applikation.

Durch eine erste Analyse des Netzwerkverkehrs, beispielsweise mit dem Werkzeug Wireshark, identifiziert der Consultant zusätzlich, mit welchen Servern die Applikation kommuniziert und welche Netzwerkprotokolle eingesetzt werden.

In einem letzten Schritt wird schließlich festgestellt, auf welche lokalen Ressourcen (Dateien, Bibliotheken, Windows-Registry etc.) die Applikation zugreift. Diese Ressourcen können dann später nach sensiblen Informationen (wie beispielsweise statische Zugangsdaten) durchsucht werden.

Penetrationstest einer Rich Client-Applikation: Der Angriff

Nachdem der Consultant alle notwendigen Informationen gesammelt hat, geht es nun darum, mögliche Schwachstellen der Applikation zu identifizieren. Die größte Angriffsfläche zur Kompromittierung der Vertraulichkeit oder der Integrität der Daten einer Rich Client-Applikation stellt erfahrungsgemäß der Netzwerkverkehr selbst dar. Die erste Frage, die sich der Consultant daher stellt, ist, ob die Applikation eine Transportverschlüsselung einsetzt. Ist dies nicht der Fall, könnten Daten, die zwischen der Applikation und einem Server versendet werden, von Angreifern im Netzwerk eingesehen und geg+ebenenfalls auch manipuliert werden.

In jedem Fall wird der Consultant versuchen, den Netzwerkverkehr genauer zu untersuchen, indem er sich in eine Man-in-the-Middle-Position zwischen der Applikation und dem Server bringt.

Bei Applikationen, die über einen Webservice mit dem Server kommunizieren, können die gleichen Werkzeuge wie bei Webapplikationstests, beispielsweise Burp Suite Pro, eingesetzt werden. Falls keine Webprotokolle eingesetzt werden, kommen andere Werkzeuge zum Einsatz, die es ermöglichen, den Netzwerkverkehr auf Nutzdatenebene zu manipulieren. Hier sind unter anderem insbesondere SSLsplit, Scapy oder Echo Mirage erwähnenswert.

Bei der Netzwerkkommunikation eines Rich Clients können grundsätzlich ähnliche Schwachstellen auftreten wie bei einer Webapplikation, z. B. SQL Injections, das Auslesen von Serverdateien bis hin zur Ausführung von Betriebssystembefehlen auf dem Server. Zusätzliche Informationen zur Analyse des Netzwerkverkehrs liefern dem Consultant auch Reverse Engineering-Methoden wie statische und dynamische Codeanalysen.

Hierdurch erfährt er zusätzlich mehr über die interne Implementation der Applikation: Wie wurden beispielsweise die Benutzeranmeldung oder das Berechtigungskonzept umgesetzt? Wird dies lediglich durch die Clientapplikation und nicht serverseitig geprüft, kann die Anmeldung im nächsten Schritt mit den gewonnenen Informationen umgangen werden. Oft lassen sich bei der Codeanalyse auch statische Passwörter und Schlüssel extrahieren, die Zugriff auf weitere Angriffsflächen ermöglichen.

Der letzte Schritt des Penetrationstests ist nun, die identifizierten Schwachstellen zu verifizieren und auszunutzen. Das Vorgehen hängt hier stark von der Architektur der Applikation und den verwendeten Technologien ab. Ebenso wie bei der Analyse können auch bei Angriffen gegen einen Webservice Angriffswerkzeuge wie bei typischen Webapplikationstests zum Einsatz kommen.

Bei anderen Protokollen müssen manuelle Prüfmethoden wie beispielsweise Laufzeitmanipulationen oder Manipulationen des Datenverkehrs durchgeführt werden. Die Werkzeuge der Wahl sind für den Consultant unter anderem SoapUI, Burp Suite Pro, SQLmap, dnSpy, IntelliJ oder Immunity Debugger.

Bei Angriffen gegen die Applikationslogik werden entsprechende Entwicklungswerkzeuge eingesetzt, um beispielsweise direkt den Code der Applikation zu manipulieren. In manchen Fällen wählt der Consultant auch den Weg, einzelne Codeteile der Applikation zu extrahieren, um sie in einem separaten Programm für einen Angriff gezielt zu kombinieren. Auf diese Weise entsteht ein speziell für diese Applikation entwickeltes Angriffswerkzeug.

Empfehlungen

Aufgrund der Erfahrung der SySS GmbH bei zahlreichen durchgeführten Rich Client-Penetrationstests lassen sich zur Vermeidung der typischen Schwachstellen die folgenden Empfehlungen aussprechen:

• Die Sicherheitsanforderungen der Applikation sollten bereits in der Planungsphase berücksichtigt werden.
• Eine Drei-Schichten-Architektur ermöglicht eine sichere, serverseitige Authentifikation und Autorisation.
• Eine Transportverschlüsselung inklusive Authentifikation sollte immer eingesetzt werden.
• Eine sicherheitsrelevante Applikationslogik (insbesondere auch Datenbankabfragen) sollte grundsätzlich serverseitig implementiert werden.
• Bereitgestellte automatische Updates sollten signiert werden.

Werden diese Empfehlungen berücksichtigt, wird die Angriffsfläche der Applikation effektiv verringert. Dabei sollte jedoch auch die Sicherheit der serverseitigen Komponente nicht außer Acht gelassen werden.