7 Minuten Lesezeit (1379 Worte)

Sicherheitsanalyse von Anwendungsservern

Freitag, 15. März 2019

Webanwendungen erfreuen sich immer größer werdender Beliebtheit. Dies ist vor allem darin begründet, dass mithilfe vieler Frameworks die Möglichkeiten bezüglich Gestaltung und Funktionalitäten schier unendlich sind. Daher bietet Java in der Enterprise Edition (Java EE oder nun Jakarta EE) eine stabile Basis für performante und skalierbare Anwendungen jeglicher Art. Jedoch darf dabei eine zentrale Komponente nicht vernachlässigt werden: der Application Server. In diesem Artikel soll untersucht werden, inwiefern sich sicherheitstechnische Maßnahmen bei ausgewählten Application Servern aktivieren lassen bzw. welche Möglichkeiten der Hersteller bereitstellt.

Was ist ein Application Server

Ein Application Server stellt primär die Laufzeitumgebung für eine Java EE Anwendung dar [Q1]. Damit es möglich ist, mit dem Benutzer zu interagieren und auf einen Datenvorrat zuzugreifen, muss die Laufzeitumgebung der Java- Anwendung um weitere Elemente erweitert werden. Daher sind aus konzeptioneller Sicht drei Ebenen in einem Informationssystem vorhanden. Der Application Logic Layer befindet sich im Kern des Informationssystems. Diese Schicht ist dafür zuständig, die Geschäftslogik zu implementieren. Der Application Logic Layer ist somit geeignet, die Geschäftsprozesse eines Unternehmens abzubilden. In diesem Bereich ist die Laufzeitumgebung der Java-Anwendung zu finden. Für die Interaktion mit dem Benutzer ist der Presentation Layer verantwortlich. Dieser bereitet die verarbeiteten Daten aus dem Application Logic Layer entsprechend auf und übermittelt sie an den Client (z.B. Browser). Zusätzlich brauchen Informationssysteme häufig einen Datenvorrat. Dieser wird im Ressource Management Layer persistent gehalten. [Q2]

Welche Application Server gibt es auf dem Markt

Das Spektrum an am Markt angebotenen Anwendungsservern ist sehr breit gefächert. Während einige Application Server strengen Lizenzierungsmodellen unterliegen, sind viele Anwendungsserver unter Open-Source Lizenzen verfügbar und werden stetig von der Community weiterentwickelt. Eine Übersicht einiger populärer Modelle und Hersteller ist in Tabelle 1 aufgeführt.

Abb. 1: Übersicht über bekannte Application Server

Welche Schwachstellen sollten bei Application Servern geschlossen werden?

Alle oben genannten Anwendungsserver werden vom Hersteller mit Sicherheitsmaßnahmen versehen, um unbefugten Zugang zu sensiblen Daten und Ressourcen zu schützen. Jedoch gilt es zunächst zu klären, auf welche Sicherheitsmaßnahmen ein Administrator im Allgemeinen achten sollte. Dazu können Security Patterns verwendet werden, um die Schwachstellen in einer strukturierten Form vorzuhalten.

Security Patterns sollen helfen, immer wieder auftretende Schwachstellen so zu dokumentieren, dass sie anderen Entwicklern und Administratoren bei der Erstellung eines ganzheitlichen Sicherheitskonzepts unterstützen. Bei einer unzureichend durchdachten Konzeption von Software besteht die Gefahr, dass Sicherheitslücken mit erheblichem Angriffspotenzial entstehen. [Q3]

Benutzung einer gesicherten Verbindung

Ein Administrator eines Anwendungsservers sollte seinen Nutzern unbedingt eine gesicherte Verbindung anbieten. Dadurch stellt er sicher, dass keine sensiblen Daten von Dritten abgefangen und manipuliert werden können. Ein klassisches Beispiel hierfür ist die vertrauliche Benutzername- Passwort-Kombination eines Users. Ein Angreifer hat die Möglichkeit, mit einem speziellen Tool (zum Beispiel tcpdump) den Verkehr im Netzwerk abzuhören. Dadurch werden Schutzziele wie Vertraulichkeit und Integrität nicht mehr gewährleistet. Die Lösung für diese Schwachstelle besteht darin, eine TLS/SSL-geschützte Verbindung zu aktivieren. Voraussetzung hierfür ist jedoch, dass ein geeignetes Verschlüsselungsverfahren angewandt wird, um die Gefahr von Brute-Force-Angriffen zu minimieren.

Schutz des Anwendungsservers auf Betriebssystemebene

Um den Application Server weiter abzusichern, müssen die Daten und Ressourcen sowohl nach außen als auch nach innen geschützt werden. Letzteres soll dem Anwendungsserver auf Betriebssystemebene Schutz bieten. Dies bedeutet, dass Deployments, Konfigurationsdateien, Executables und andere wichtige Ressourcen des Application Servers nur einem bestimmten User zugänglich sind. Im Idealfall sollte der Anwendungsserver nur von einem speziell für die Ausführung vorgesehenen User ausgeführt werden. Sollten die Ressourcen nicht geschützt, sondern frei zugänglich sein, haben Angreifer mit Zugang zum Betriebssystem leichtes Spiel, die Aus- führung des Application Servers zu stören. Ferner können die Deployments weitere Rückschlüsse auf sensible Geschäftsprozesse preisgeben. Der Administrator muss daher zusätzlich ein durchdachtes Rechtekonzept erarbeiten, um unbefugten Zugriff zu vermeiden.

Deaktivieren von Standardanwendungen und veralteten Passwörter

Um eine schnelle Installation und anschließende Konfiguration des Anwendungsservers zu gewährleisten, setzen viele Anwendungsserver auf Benutzerfreundlichkeit. Dies setzen einige Modelle z.B. in einer ansprechenden GUI mit Installation-Wizard um. Nach der Erstkonfiguration sind diese Application Server sofort einsatzbereit und lassen das Deployment von benutzerdefinierten Anwendungen zu. Die Gefahr hierbei besteht darin, dass vorinstallierte Inhalte noch aktiviert und abrufbar sind. Deaktiviert der Administrator die vorinstallierten Anwendungen nicht oder ändert er keine Defaults, haben Angreifer auch hier eine Chance: Wenn die Standardanwendungen unter bekannten URLs abrufbar sind, können diese Rückschlüsse auf den Application Server und dessen Version geben. Das nutzen Angreifer aus, um gezielt nach Schwachstellen zu suchen. Ein Beispiel hierfür sind „Welcome-Pages", die dem Administrator eine erfolgreiche Installation bestätigen – und Angreifern Tür und Tor öffnen. Beide Anwendungsserver bieten jedoch Möglichkeiten, mit denen sich die Schwachstellen schnell und unkompliziert schließen lassen.

Vermeidung von Denial-of-Service-Attacken

Werden auf dem Anwendungsserver unternehmenskritische Anwendungen gehostet, gewinnt er zunehmend an Stellenwert im Unternehmen. Um den Geschäftsbetrieb aufrechtzuerhalten, muss das Informationssystem stets verfügbar sein. Schon kurze, ungeplante Downtimes können erhebliche finanzielle Schäden verursachen. Sollten keine technischen Störungen der Grund für eine Downtime sein, sind es womöglich Angreifer, die einen Denial-of-Service-Angriff durchführen. Dabei wird der Application Server mit einer hohen Zahl an Requests überschwemmt (SYN-Flood) und kann aufgrund begrenzter Kapazitäten die Anfragen nicht mehr beantworten. Die Folge ist ein nicht mehr erreichbarer Application Server. Daher muss der Administrator Sicherheitsmaßnahmen treffen, die den Zugriff auf den Anwendungsserver reglementieren oder gar verdächtige Anfragen blockieren.

Wie werden die Sicherheitsmaßnahmen aktiviert?

Wie die Sicherheitsmaßnahmen aktiviert werden, hängt stark vom Application Server ab. Bei einigen wenigen Anwendungsservern sind nahezu alle Konfigurationseinstellungen über eine grafische Oberfläche editierbar. Ein Paradebeispiel hierfür ist Oracle WebLogic (im Test Version 12cR2). Die benutzerfreundliche GUI hilft dem Administrator, die notwendigen Häkchen und Parameter zu setzen. Sollte der Administrator die Änderungen eher per Skript (automatisiert) durchführen wollen, ist dies mit dem WebLogic Scripting Tool (WLST) ebenfalls problemlos möglich. Damit kann mit wenigen Klicks eine TLS/SSLgeschützte Verbindung aktiviert werden. Aber Achtung: Nicht nur bei WebLogic sind hierfür Demo-Zertifikate hinterlegt, die ausschließlich für Testzwecke vorgesehen sind. In der Produktion sollten ausschließlich von einer seriösen Certification Authority (CA) signierte Zertifikate verwendet werden. Der Application Server WildFly (ehemals JBoss) von Red Hat bietet in Version 12.0.0 ähnliche Möglichkeiten, eine sichere Verbindung zu aktivieren. Jedoch muss hierfür das Konfigurationsfile editiert werden. Vor allem im Hinblick auf unerfahrene Administratoren ist hier mit einem Mehraufwand zu rechnen.

Was den Schutz auf Betriebssystemebene betrifft, sind die Sicherheitsmaßnahmen eher unabhängig vom Anwendungsserver zu aktivieren. Es ist sehr wichtig, dass Working-Directory mit entsprechenden Rechten zu versehen, damit Unbefugte keine Deployments oder Konfigurationsdateien manipulieren. Ferner sollten die Zugänge zum Betriebssystem (z.B. über SSH) auf die notwendigen User eingeschränkt werden, um bereits einen großen Angriffsvektor auszuschließen. Es sollte zudem darauf geachtet werden, dass dem Application Server stets genügend Systemressourcen zu Verfügung stehen und diese nicht durch andere Nutzer blockiert werden.

Sowohl WebLogic als auch WildFly stellen Standardanwendungen zu Verfügung, welche Informationen über die Version preisgeben. Wird eine WebLogic-Umgebung über den Konfigurationsassistenten mit Default-Werten erstellt, kann ein Angreifer mit einem einfachen Request die Administrationskonsole aufrufen und die Version erkennen. Der Application Server WildFly bietet an dieser Stelle sicherere Defaults. Die Administrationsoberfläche ist nicht von „überall" aus aufrufbar, sondern lediglich vom Host- System erreichbar. Jedoch bietet auch WildFly-Schwachstellen in diesem Angriffsvektor. Sendet der Angreifer bei unveränderten Defaults einen bestimmten Request an den Application Server, antwortet auch dieser mit einer Website, die Informationen zur Major-Version preisgibt. An dieser Stelle ist es unabdingbar, die unsicheren Defaults zu ändern.

Bei der Abwehr von Denial-of-Service-Attacken bieten beide Application Server gewisse Schutzmaßnahmen. Damit kann ein Administrator verschiedene Konfigurationseinstellungen bearbeiten und somit zum Beispiel die Processing-Time eines Requests verändern oder die maximale Größe eines eingehenden Requests bearbeiten. Um einen besseren Schutz zu gewährleisten, sollte jedoch Gebrauch von weiterer Software gemacht werden. Diese ist speziell darauf ausgelegt, DoS- bzw. DDoS-Angriffe zu erkennen und abzuwehren.

Um die stichprobenartige Bewertung der Application Server abzuschließen, lässt sich ein positives Fazit ziehen. Trotz einiger auf Standardeinstellungen basierender Schwachstellen, lassen sich die Anwendungsserver mit entsprechenden Änderungen in den Konfigurationseinstellungen gegen Angreifer absichern. Die dargestellten Security Patterns stellen jedoch keine vollständige Sammlung an möglichen Schwachstellen dar. Vielmehr sollten sie als initialer Bestandteil eines umfassenden Sicherheitskonzepts betrachtet werden, welches kontinuierlich weiterentwickelt werden muss. Nur so ist es möglich, die Gefahr von aktuellen Bedrohungen unter Kontrolle zu halten.