Unsere Security Analyst*innen im usd HeroLab decken während ihrer Penetrationstests (Pentests) immer wieder Einfallstore auf, die erhebliche Risiken für die Unternehmenssicherheit darstellen. Dabei begegnen ihnen vermehrt die gleichen Schwachstellen. Unsere Blogserie „Top 3 Schwachstellen“ stellt diese dar und gibt Ihnen Tipps für die Vermeidung – für #moresecurity über alle IT-Assets.
Heute betrachten wir die drei häufigsten sicherheitskritischen Schwachstellen, die unsere Analyst*innen bei Pentests von Fat Clients in den vergangenen Jahren identifizieren konnten.
Warum Pentests von Fat Clients?
Bei Fat Clients, auch Thick Clients genannt, handelt es sich um Desktop-Anwendungen, welche im Gegensatz zu Web-Anwendungen auf den lokalen Endgeräten der Nutzer installiert werden. Neben dieser lokal installierten Komponente (Frontend-Client), gibt es meist noch Backend-Komponenten wie Applikations- oder Datenbankserver. Schwachstellen in diesen Anwendungen ermöglichen Angreifern Zugriff auf die serverseitige Business-Logik der gesamten Anwendungslandschaft des Nutzers, inklusive aller dort gespeicherten Daten.
Durch Fat Client Pentests können Schwachstellen in der Anwendung proaktiv identifiziert und behoben werden, bevor sie zur Ausweitung des Zugriffs auf den gesamten Server ausgenutzt werden können. Technisch gesehen liegt der Fokus der Durchführung dieser Penetrationstests daher auf der Netzwerk-Kommunikation von Client- und Server-Komponenten sowie dem Reverse-Engineering der Anwendungsbestandteile und Kommunikationsprotokolle.
Two-Tier-Architektur
Einige der von uns getesteten Clients setzen auf eine Two-Tier-Architektur. Hierbei greift das Frontend der Anwendung auf dem Endgerät des Nutzers direkt auf die Datenbank im Backend zu. Häufig werden dazu in Konfigurationsdateien der Frontend-Anwendung oder im Code selbst die Zugriffsdaten auf diese Datenbank hinterlegt. Verfügt die Anwendung über ein Rechte- und Rollenkonzept, müssen diese Credentials alle Privilegien-Stufen abbilden - vom einfachen, niedrig privilegierten Account bis zum Administrator. Als Resultat verfügt die Anwendung durch diese Datenbank-Zugangsdaten über administrativen Zugang zum Datenbestand.
Angreifern ist es auf verschiedenen Wegen möglich, an diese Zugangsdaten zu gelangen und somit direkt auf die Datenbank zuzugreifen. Die Zugangsdaten können beispielsweise aus Konfigurationsdateien oder dem Code extrahiert werden. Alternativ können sie häufig auch durch einen Netzwerkmitschnitt bei Authentifizierung des Clients an der Datenbank im Klartext mitgeschnitten werden. Gelangt ein Angreifer auf einem der beschriebenen Wege an diese Zugangsdaten, kann das existierende Zugriffskonzept der Gesamtanwendung umgangen und auf den Datenbestand zugegriffen werden.
Sicherheits-Tipp:
Wir empfehlen die Implementierung einer Three-Tier-Architektur. Hierbei wird zwischen der Frontend-Anwendung und der Datenbank ein Applikationsserver als dritte Schicht eingeführt. Dieser Applikationsserver verfügt exklusiv über die Zugangsdaten der Datenbank und hat die Aufgabe, Anfragen der Clients entgegenzunehmen, diese auf Authentizität und korrekte Authentifizierung zu prüfen, sowie im Anschluss die Operation auszuführen.
Fehlerhafte Zugriffskontrollen
Viele Fat Clients, vor allem im Kontext des .NET Frameworks oder Java, setzen auf Remote Procedure Call (RPC) Mechanismen. Techniken aus der Java-Welt sind hier beispielsweise Java RMI oder Enterprise Java Bean (EJB). Bei diesen Mechanismen werden Befehlsaufrufe vom Client in einem für die Programmiersprache und Framework spezifischen Format an die Server-Komponente gesendet und hier ausgeführt.
In einer Vielzahl von Projekten haben wir die Entdeckung gemacht, dass diese Aufrufe teilweise ohne explizite Authentifizierung stattfinden. Der Hersteller der Software geht davon aus, dass für einen Zugriff auf die Remote-Objekte und deren Methoden eine gültige Sitzung im Frontend-Client nötig ist. Nutzt nun ein Angreifer jedoch einen eigens entwickelten Client, der die Kommunikation mit dem Backend nachbildet (sehr ähnlich zu der Kommunikation des Frontend-Clients), ermöglicht es dieser, die Endpunkte auf Serverseite direkt aufzurufen. Hierdurch wird das gesamte Rollen- und Rechtekonzept der Anwendung umgangen und jegliche Operationen ohne Kenntnis von Zugangsdaten ausgelöst.
Sicherheits-Tipp:
Zur Behebung oder bestenfalls Vermeidung empfehlen wir, an allen serverseitigen Endpunkten einen Mechanismus zur Authentifizierung zu implementieren, beispielsweise in Form von Session-Tokens, die mit jedem Funktionsaufruf an den Server gegeben werden. Der Server kann anhand dieser Tokens den aufrufenden Account sowie dessen Berechtigungen prüfen, und in Folge dessen nur legitime Anfragen bearbeiten.
Unzureichende Authentifizierung
Ein Großteil der Unternehmen setzt auf Microsoft Windows als Betriebssystem für Endgeräte seiner Mitarbeiter*innen. Mit Active Directory bietet Microsoft eine einheitliche Lösung zur Verwaltung von Nutzer-Accounts/-Gruppen und Berechtigungen. Weiterhin wird eine Vielzahl von Authentifizierungsverfahren wie NTLM oder Kerberos unterstützt. Um eine Fat-Client-Anwendung nahtlos in diese Umgebung zu integrieren, wird in vielen Clients die Authentifizierung mittels des Active Directory Accounts eines Nutzers hinzugefügt. Dieser Account wird ebenso für die Anmeldung am Betriebssystem selbst genutzt.
Häufig sehen wir hierbei jedoch eine fehlerhafte Implementierung, welche die Authentifizierung dem Betriebssystem überlässt und lediglich den Nutzernamen aus der aktuellen Sitzung ausliest. Hintergedanke ist dabei, dass sich nur gültige Accounts am System anmelden können, und dem Nutzernamen, welchen man aus der Windows-Sitzung erhält, vertraut werden kann. Startet ein Angreifer allerdings die Software über eine eigene virtuelle Maschine (kurz VM), ermöglicht ihm dies, dem lokalen Windows-Konto den Namen des Accounts zu geben, den er zu übernehmen plant. Durch die fehlerhafte Implementierung wird dieser Nutzername ausgelesen und ihm vertraut, ohne ihn auf Authentizität zu prüfen. Alternativ ist es in manchen Fällen auch möglich, den Anmeldenamen mittels eines Intercepting-Proxies auf dem Weg zum Server abzuändern.
Sicherheits-Tipp:
Fat Clients sollten die Authentifizierung selbstständig durchführen und sich nicht implizit auf andere Komponenten wie beispielweise das Betriebssystem verlassen. Sofern eine Authentifizierung ohne explizite Eingabe eines Passworts gewünscht ist, kann beispielsweise auf eine Kerberos-Authentifizierung am Active Directory zurückgegriffen werden.
Es ist wichtig zu beachten, dass neben den genannten Schwachstellen noch viele weitere existieren können. Da jede Fat-Client-Anwendung unterschiedliche Funktionen aufweist, können auch neue Gefahren auftreten. Ein Pentest kann Klarheit schaffen und Ihnen dabei helfen, die Daten der Anwendung und des Servers effektiv zu schützen.
Sie möchten Ihre Fat-Client-Anwendung einer Prüfung unterziehen? Kontaktieren Sie uns, wir helfen Ihnen gern.
