Bachelorarbeit. Sicherheitsanalyse eines webbasierten Applikationsservers am Beispiel eines JBoss (Version 5 und 7)

Transkript

1 Bachelorarbeit Sicherheitsanalyse eines webbasierten Applikationsservers am Beispiel eines JBoss (Version 5 und 7) Bachelor: Virgil Maro Fenzl Matrikelnummer: Fachbereich: Informatik Betreuer: Prof. Dr. Christoph Skornia Zweitkorrektor: Prof. Dr. Fritz Jobst Abgabedatum: 01. April 2013

2 Abstract Moderne Applikations-Frameworks wie die JBoss Enterprise Application Plattform finden ihre Anwendung in Betrieben aller Größenordnungen. Aufgrund unzureichender Absicherung der Anwendungen oder Lücken im Applikationsserver selbst ist die Ausnutzung von gegebenen Schwachstellen keine Seltenheit. Dies kann im schlimmsten Fall dem potentiellen Angreifer zu einem uneingeschränkten Serverzugriff verhelfen oder die Authentizität der Daten gefährden. Diesen Szenarien wird durch eine Verringerung der Angriffsoberfläche vorgebeugt. Diese Bachelorarbeit soll zeigen, welche Sicherheitsstandards Anwendungsserver erfüllen sollen und wie diese im Bezug auf den Server und den darauf laufenden Anwendungen umgesetzt werden können.

3 Vorwort Diese Arbeit behandelt die Sicherheit vom web-basierten Applikationsserver JBoss am Beispiel der Prüfungsterminplanung (PTP) der HS-Regensburg. Dabei wird im ersten Abschnitt die Installationsumgebung des Applikationsservers betrachtet, sein Schutzbedarf analysiert und aufgezeigt, welche Hilfsmittel zur Implementierung von Sicherheit dem Applikationsserver bereits standardmäßig als Module zur Verfügung stehen. Der zweite Abschnitt beinhaltet eine Analyse des neuen JBoss 7 und der aktuell vorhandenen Angriffsoberfläche (vor Entstehung dieser Arbeit), eine detaillierte Betrachtung von vorhandenem Code und Konfigurationen und Lösungen für Sicherheitsprobleme. Abschließend werden weiterführende Themen angeschnitten. Dabei wird die Anwendung einer binären Analyse mit und ohne Hilfsmittel erläutert, die Nutzung von Penetration Testing Tools angesprochen und Patch- bzw. Informationsmanagement betrachtet. Auch werden einige Angriffsstrategien in Bezug auf JBoss 5 aufgezeigt. Ich habe mich zu diesem Thema aufgrund einer sehr interessanten Vorlesung bei Prof. Dr. Jobst der Hochschule Regensburg entschieden. Diese behandelte die Programmierung von Software unter JBoss 5 und weckte durch eine Projektarbeit mein Interesse an der Sicherheit des angewandten Systems. Dieses Interesse brachte mich letztendlich zu der in der Hochschule betriebenen Software Prüfungsterminplanung. Im Laufe der Arbeit werde ich diese Software nur noch mit PTP abkürzen. Auch werde ich in den einzelnen Abschnitten darauf beispielhaft Bezug nehmen, um die Verbindung dieser Arbeit zu einem aktuell eingesetzten produktivem Programm aufzuzeigen. ii

4 Danksagung Ich bedanke mich für die Unterstützung bei Professor Dr. Skornia, welcher mich auf dem Weg dieser Bachelorarbeit begleitet hat! Ferner möchte ich Professor Dr. Jobst für die Lehre über den JBoss Application Server und die Vermittlung der Bachelorarbeit danken. Natürlich gilt mein Dank auch Prof. Dr. Löschel, ohne dessen Projekt der PTP diese Arbeit nicht zustande gekommen wäre. Auch möchte ich an dieser Stelle den Unternehmen Red Hat und HP dafür danken, dass sie uns ihre Enterprise-Produkte EAP 6.0 bzw. Fortify unentgeltlich zu Forschungszwecken zur Verfügung gestellt haben. iii

5 Inhaltsverzeichnis 1 Grundlagen Betriebssysteme Virtuelle Maschinen Umgebung Testsystem Grundschutz und ISO JBoss Application Server JBoss und Java Sicherheitsmechanismen Java Security API JBoss AS7 security subsystem Secure Socket Layer (SSL) Absicherung der Verwaltungsoberfläche Technisches Umfeld Organisatorisches Umfeld Eigene Untersuchungen Analyse des JBoss AS Angriffsoberfläche der PTP mit JBoss Portierung JBoss 5 zu EAP Lücken fertiger Softwarekomponenten Statische Codeanalyse Grundlagen statischer Codeanalyse Anwendung statischer Codeanalyse Schwachstellen im untersuchten Code Konzeptionelle Schwachstellen Standardkonfiguration Directory Listing Path Traversal iv

6 INHALTSVERZEICHNIS 3 Weitere Themen Binary Audit Metasploit und Armitage Patchstrategie Informationsstrategie Proof of Concept DeploymentFileRepository MBean store() Methode JMX-Console Cross Site Request Forgery Fazit 72 A Sicherheitslücken JBoss B Sicherheitslücken JBoss C Sicherheitslücken der PTP 76 Literaturverzeichnis 78 Erklärung 82 v

7 Kapitel 1 Grundlagen Zur Einschätzung von Sicherheit eines JBoss Application Servers (AS) muss dem Anwender klar sein, in welcher Umgebung (technisch und organisatorisch) der AS betrieben wird. Auch spielt die Wahl des Betriebssystems oder der Einsatz von virtuellen Maschinen eine Rolle. Zudem braucht der Anwender eine Einschätzung über den Schutzbedarf seines Servers und seinen Anwendungen. Hierfür gibt es spezielle Zertifizierungsrichtlinien, die in ISO27001 zusammengefasst sind. Um die Angriffsoberfläche möglichst klein zu halten, bietet JBoss Möglichkeiten zur Implementierung von Sicherheit, welche in diesem Abschnitt ebenfalls betrachtet werden. Anmk.: EAP 6.0 (Enterprise Application Platform 6.0, RedHat Support Version) entspricht in meinen Ausführungen dem JBoss 7 (Community Version) und umgekehrt. 1.1 Betriebssysteme Der JBoss Applikationsserver setzt auf die Java Enterprise Technologie auf [3, 21]. Da Java heute nicht nur weit verbreitet ist, sondern auch plattformunabhängig genutzt wird, ist es eine beliebte Basis für groß angelegte web-basierte Applikationen [3, 26]. 1

8 1.2 Virtuelle Maschinen Die zugrundeliegenden Betriebssysteme sind meist Unix- bzw. Linuxderivate oder auch Microsoft Windows. Prinzipiell läuft diese Server aber aufgrund seiner Bindung zu Java unter jedem OS, welches auch das passende JDK (für JBoss 5 JDK 1.5 oder 1.6 und für JBoss 7 JDK 1.6 oder 1.7) unterstützt. Im Falle der PTP wird von der Hochschule ein Windows Server 2003 eingesetzt. Betrieben wird dieser Server in einer virtuellen Maschine der Firma VMWare. 1.2 Virtuelle Maschinen Virtuelle Maschinen ermöglichen eine flexible Portabilität der Gastsysteme. Die Gastsysteme laufen dabei auf einer abstrakten Maschine. Die Anzahl verwendeter Prozessoren bzw. deren Kerne, Menge an Arbeitsspeicher und verbundene Peripherie kann dabei vom jeweiligen Benutzer neu festgelegt werden. Natürlich ist die Leistung dadurch von dem System abhängig, welches die virtuelle Maschine betreibt. VMWare [30] stellt für alle Gastsysteme sogenannte VMware Tools zur Verfügung. Diese stellen eine Erweiterung des Gastsystems dar, um eine Kompatibilität mit dem darunterliegenden System zu ermöglichen. Die PTP lässt sich also durch die Verwendung einer virtuellen Maschine ohne größere Konfigurationsänderungen zwischen Serversystemen kopieren oder auch in Kopie von Entwicklern zu Testzwecken verwenden. 1.3 Umgebung Testsystem Das Testsystem, auf welchem Analysen zu dieser Arbeit durchgeführt wurden, besteht aus einem PC des Security Labors der Hochschule und einem Notebook. Das Betriebssystem des PCs ist Windows 7 32Bit. Es hat folgende für den 2

9 1.3 Umgebung Testsystem Testeinsatz notwendige Programme installiert: Internet Explorer 9 Eclipse Juno Metasploit und Armitage JBoss GA (Standardinstallation) JBoss GA (konfigurierte Hochschulversion) EAP 6.0 (konfigurierte Hochschulversion inkl. Security Advisories) JDK 1.7 (Java Development Kit) JDK 1.6 (Java Development Kit). Das zum Test und Entwicklung verwendete Betriebssystem des Notebooks ist Windows 7 64Bit. Die für das Projekt verwendete Software entspricht dem des Security Labor PCs (aber ohne Metasploit und Armitage) mit folgenden Zusätzen: Internet Explorer 10 Firefox 19.0 Fortify Audit Workbench (statische Code Analyse) Juniper Network Connect (VPN zur Hochschule) LDAP Browser (Test von LDAP Anfragen und Darstellung der Ergebnisse) VMWare Player (virtuelle Maschinen) GSTool 4.5. Die verschiedenen JDK Versionen sind trotz der bekannten Sicherheitslücken von JDK 1.6 notwendig, da der JBoss GA nicht mit Java JDK 1.7 lauffähig ist. VMWare Player wird verwendet, da er es ermöglicht, die Hochschulversion so zu testen, wie sie in ihrer endgültigen Umgebung am Java Server der Hochschule betrieben wird. Die virtuelle Maschine hat als OS eine Windows Server

10 1.4 Grundschutz und ISO27001 Enterprise Edition. Diese enthält keine Entwicklungsumgebung, sondern betreibt die JBoss Server (mit JDK 1.6) und EAP 6.0 (mit JDK 1.7) im Standalone- Modus (ohne Eclipse). Applikationen werden hier per Weboberfläche deployed (auf Deutsch ausgebracht, Fehler werden so schneller erkannt als beim hot deployment, also dem direkten Kopieren ins Ausbringungsverzeichnis). Natürlich brauchen die ausgebrachten Anwendungen (z.b. die PTP) ihre eigenen Konfigurationsdateien auf den verschiedenen möglichen Plattformen, auf denen diese laufen. Dies liegt daran, dass einige Parameter abhängig von dem Ort auf der Festplatte sind (z.b. die Datei, die das gültige SSL-Zertifikat enthält oder der von der Anwendung verwendete temporäre Ordner). 1.4 Grundschutz und ISO27001 BSI-Grundschutz wurde herausgegeben vom Bundesamt für Sicherheit in der Informationstechnologie (BSI) und ist gegliedert in folgende Kataloge[5, 5]: Abbildung 1.1: Grundschutz Kataloge [5, 5] 4

11 1.4 Grundschutz und ISO27001 Der Grundschutz ist die Basis für alle Zertifizierungen von Behörden und anderen öffentlichen Institutionen. Der Grundschutzprozess läuft folgendermaßen ab: Abbildung 1.2: Grundschutz Prozess [5, 6] Anwendungen haben je nach Betriebsumfeld einen unterschiedlichen Schutzbedarf. Das Management von Sicherheit wird mit einem Information Security Management System (ISMS) durchgeführt [5, 2]. Dies ist notwendig, da Systeme [5, 6] per se unsicher sind wenn gesichert ohne kontinuierliche Anpassung unsicher werden. Um Informationssicherheitsmanagement international eindeutig zu definieren, wurde der Standard ISO27001 aus dem Grundschutz heraus geschaffen [7, 19]. Dieser Standard definiert, welche Schritte beim Design und der Implementierung einer sicheren Applikation notwendig sind und bedient sich dem Plan-Do-Check- Act-Modell, um die Aufgaben zu strukturieren. 5

12 1.4 Grundschutz und ISO27001 Abbildung 1.3: Plan-Do-Check-Act Modell [5, 5] Das Plan-Do-Check-Act (P-D-C-A) Modell kann folgendermaßen zusammengefasst werden [7, 19]: Plane was notwendig ist, um ein Ziel zu erreichen (beinhaltet die Definition des Ziels). Führe die geplanten Schritte aus. Überprüfe, ob das was man erreicht hat, auch das erfüllt, wofür man es geplant hat und identifiziere Lücken oder Probleme (z.b. überprüfe, ob man die Ziele erreicht hat). Handle anhand der gesammelten Informationen der Planungsphase, indem die Lücken geschlossen oder die Leistung bzw. der Wirkungsgrad gesteigert werden. Einige Anforderungen müssen in einem Informationssicherheitsmanagementsystem erfüllt sein, um sicher handeln zu können [7, 20]: Dokumentenkontrolle (Ziel ist die Sicherstellung, dass alle Dokumente von den richtigen Personen erstellt und genehmigt wurden und dass der Personenkreis, der von den Dokumenten Kenntnis hat, nur die letzte genehmigte Version als Grundlage hat.) 6

13 1.4 Grundschutz und ISO27001 Kontrolle der Aufzeichnungen (Sicherstellung der Vertraulichkeit, Integrität und Verfügbarkeit) Interne Revision / Interner Audit (vor allem, um die Einhaltung zwischen den Systemanforderungen und der Arbeitspraxis zu überwachen) Management Review (Überprüfung des Fortschritts der Projektimplementierung und der Wirksamkeit des ISMS). Mit diesem grundlegenden Wissen über Grundschutz und ISO27001 ist es möglich, eine Anwendung, wie sie z.b. für den JBoss entwickelt wurde, auf die Einhaltung des Standards zu prüfen. Hierfür nimmt man zuerst eine Risiko Analyse vor [7, 24]. Dabei muss eine Liste von allem erstellt werden, was für eine Organisation wertvoll ist, einschließlich Informationen, Informationsverarbeitung, Lagerausrüstung (alle Server, Computer, Laptop, PDA, Handys), Angestellte, Gebäude, usw. All diese Sachen (oder Gruppen davon) müssen einer Risikoanalyse unterzogen werden. Der Wert jeder Sache wird nach den folgenden drei Sicherheitsattributen geschätzt [7, 24]: Vertraulichkeit Integrität Verfügbarkeit Das mögliche Risiko wird folgendermaßen eingeschätzt: Risiko = Wahrscheinlichkeit x Wirkung [7, 25] 7

14 1.4 Grundschutz und ISO27001 Folgende Grafik erläutert diesen Umstand noch näher: Abbildung 1.4: Wahrscheinlichkeit x Wirkung [7, 26] Das Hauptziel eines ISMS ist das Management aller Risiken bei einem gleichbleibenden Maß an Kontrolle und daher ist dies die Stelle, an welcher das Management entscheiden muss, welches Level an Risiko annehmbar ist [7, 26]. Wenn ein Risiko erkannt wird, hat das Management folgende Möglichkeiten [7, 27]: 1. Maßnahmen durchführen, um das Risiko zu vermindern (Maßnahmen werden ISO27001 im Anhang A entnommen). 2. Das Risiko akzeptieren. 3. Das Risiko vermeiden, indem ein Work-Around gefunden wird. 4. Das Unternehmensrisiko einem Versicherer oder Lieferanten übertragen. Natürlich lässt sich der komplette Prozess des Grundschutzes bzw. ISO27001 nur abbilden, wenn ein umfassendes Wissen hierfür vorhanden ist. Ein Tool zur Unterstützung dieses Prozesses ist das GSTool (aktuell in Version 4.5) [13], welches Betrieben helfen soll, diesen Prozess in Software abzubilden. 8

15 1.5 JBoss Application Server Im Falle der Prüfungsterminplanungsplattform würde eine solche Analyse daher den Rahmen dieser Bachelorarbeit sprengen. 1.5 JBoss Application Server Der JBoss Application Server ist ein Produkt der Firma Red Hat. Dieser existiert in 2 Versionen: Einer Open-Source Community-Version ( ) und einer Red Hat Support-Version ( Die Versionen unterscheiden sich in Folgendem: Abbildung 1.5: Unterschiede Community und RedHat Version [16] Der Name der aktuellen Community Version lautet JBoss 7, der Name der aktuellen Red Hat Version lautet Enterprise Application Platform 6, kurz EAP 6. 9

16 1.5 JBoss Application Server Die Installation verläuft folgendermaßen: 1. Installation des Java Development Kit 7 (JDK7) 2. Installation des JBoss 7 (Hier gab es auf dem Testsystem bei dem Installer Probleme, wogegen die gepackten Binaries problemfrei liefen.) 3. Installation der Eclipse Umgebung (für Entwicklung) 4. Installation des JBoss Plugin für Eclipse. Natürlich müssen im Anschluss die Installationen noch konfiguriert werden, was von der Serverumgebung abhängig ist [3, 9]. Anwendungen werden in EAR (Enterprise Archive) oder WAR (Web Application Archive) Dateien gepackt und werden z.b. im Standalone-Modus des Servers durch Kopieren in das Verzeichnis JBOSS-ROOT/standalone/deployments ausgebracht (je nach Konfiguration automatisch oder manuell möglich) [3, ]. Seit EAP 6 gibt es für den Admin eine neue Weboberfläche mit dem Namen Admin Console (bei Versionen von JBoss 4 bis JBoss 6 war diese noch die jmxconsole). Die alte jmx-console wurde verwendet um den Wert von MBeans auszulesen, welche das Backbone des Application Servers waren. Diese Oberfläche hat allerdings eine Menge Speicher verbraucht, was den Server träge wirken lies. Die neue AS7 Admin Console dagegen wird unterstützt von dem Google Web Toolkit, welches die HTTP Management API zur Konfiguration eines Servers nutzt. Zugegriffen wird auf die Oberfläche via und wird konfiguriert in der standalone.xml [3, 197]. 10

17 1.5 JBoss Application Server Abbildung 1.6: Admin Console, Screenshots aus Testumgebung Support und somit auch Sicherheitsupdates gibt es nur bei der EAP-Version. Welche Version letztendlich wie lange gewartet wird, ist der folgenden Grafik zu entnehmen: Abbildung 1.7: Wartung Community und RedHat Version [16] Aus den dargelegten Gründen ist ausschließlich die Enterprise-Version für den Einsatz im vorliegenden Szenario (PTP) geeignet. Insbesondere die Verarbeitung von personenbezogenen Daten erfordert diese Sicht. 11

18 1.6 JBoss und Java Sicherheitsmechanismen 1.6 JBoss und Java Sicherheitsmechanismen Die folgenden Überlegungen sind für die PTP nicht relevant, da diese vor der Entstehung dieser Bachelorarbeit bereits implementiert waren. Dennoch sollte sich jede Anwendung, welche auf dem Anwendungsserver läuft, dieser Mechanismen bedienen. JBoss und Java bieten dem Programmierer bereits von Grund auf einige Sicherheitsmechanismen, denen er sich zur Absicherung des Servers und der Anwendung bedienen kann [3, 273]. Diese wären unter anderem: Java Security API JBoss AS7 Security Subsystem SSL (Secure Sockets Layer) Mit der Anwendung dieser kann der Programmierer z.b. sichere Login Module schreiben oder Verwaltungsoberflächen absichern Java Security API Java EE Security Services stellt einen robusten und einfach konfigurierbaren Sicherheitsmechanismus zur Authentifizierung von Nutzern und Zugriffsautorisierung zu Anwendungsfunktionen und der damit verbundenen Daten zur Verfügung [3, 274]. 12

19 1.6 JBoss und Java Sicherheitsmechanismen Folgende Grafiken stellen den Prozess der Authentifizierung und Autorisierung dar: Abbildung 1.8: Authentifizierung [3, 274] Abbildung 1.9: Autorisierung [3, 274] In Java EE stellen Komponenten 2 Arten von Sicherheit zur Verfügung [3, 275]: deklarative programmierbare Deklarative Sicherheit bedeutet die Verwendung von Ausbringungsdeskriptoren und/oder Annotationen. Programmierbare Sicherheit ist in Anwendungen eingebaut und wird verwendet, um Sicherheitsentscheidungen zu treffen. Ein Beispiel hierfür wäre, ob der Nutzer, der auf eine Ressource zugreift, auch die Rechte auf diese Ressource hat. Dieser Call würde bei einer JSP (Java Server Page) so lauten: isuserinrole(). 13

20 1.6 JBoss und Java Sicherheitsmechanismen JBoss AS7 security subsystem JBoss Sicherheit ist eine Erweiterung des Anwendungsservers und ist standardmäßig integriert [3, 276]. < extension module =" org. jboss.as. security "/> Durch die Definition eigener Sicherheitsmangagementoptionen liesen sich z.b. die standard Authentifizierungs- bzw. Autorisierungsmanager mit eigenen Implementierungen überschreiben. Dies wird am einfachsten durch das Überschreiben von Security Domänen bewerkstelligt. Diese prüfen, ob die notwendigen Parameter für gewollte Operationen gesetzt sind. Wichtige Module sind hier u.a. Identity, Ldap, UserRoles, Kerberos, RoleMapping, Database und Certificate [3, 277] Modulbeispiel am UserRoles Login Modul Dieses Modul basiert auf 2 Dateien [3, 279]: users.properties beinhaltet eine Liste an Benutzernamen und Passwörtern roles.properties beinhaltet die Assoziation zwischen Benutzern und Rollen Eine Standardkonfiguration (z.b. in JBOSS HOME/standalone/configuration) würde so aussehen: <security - domain name =" basic " cache - type =" default "> < authentication > <login - module code =" UsersRoles " flag =" required "> <module - option name =" usersproperties " value ="${ jboss. server. config. dir }/ users. properties "/> <module - option name =" rolesproperties " value ="${ jboss. server. config. dir }/ roles. properties "/> </ login - module > </ authentication > </ security - domain > 14

21 1.6 JBoss und Java Sicherheitsmechanismen Die Dateien users.properties und roles.properties würden folgendes beinhalten: users.properties admin = admin roles.properties admin = Manager Secure Socket Layer (SSL) JBoss AS benutzt die Java Secure Socket Extension (JSSE), welche im J2SE integriert ist und die SSL/TLS Kommunikation steuert [3, 296]. Folgender Codeausschnitt erzwingt in der PTP die Verwendung von SSL über HTTP: < security - constraint > <web - resource - collection > <web - resource - name > ProtectedContext </web - resource - name > <url - pattern >/* </url - pattern > </web - resource - collection > <user -data - constraint > < transport - guarantee > CONFIDENTIAL </ transport - guarantee > </user -data - constraint > </ security - constraint > Benötigt wird ein von einer CA unterzeichnetes Zertifikat, welches durch einen certificate-signing request (CSR) generiert werden kann. Dieses muss nach Erstellung in den JBoss importiert werden. Anschließend muss noch die Connector Information in der Serverkonfigurationsdatei (im Falle der PTP standalone.xml) eingetragen werden: < subsystem xmlns =" urn : jboss : domain : web :1.0 " default - virtualserver =" default - host "> < connector name =" http " protocol =" HTTP /1.1 " socket - binding =" https " scheme =" https " secure =" true "> 15

22 1.6 JBoss und Java Sicherheitsmechanismen <ssl key - alias =" as7book " password =" mypassword " certificate - keyfile =" jboss. keystore " cipher - suite =" ALL " protocol =" TLS "/>.... </ connector > </ subsystem > Absicherung der Verwaltungsoberfläche Einer der wichtigsten Schritte zur Absicherung des Servers ist die Sicherung der Verwaltungsoberfläche. Um die Sicherung zu aktivieren, muss in der Konfigurationsdatei in dem Bereich der security-realms ein Security Realm gesetzt werden, wie folgender Quellcodeausschnitt zeigt [3, 291]: < management > <security - realms > <security - realm name =" ManagementRealm "> < authentication > < properties path ="mgmt - users. properties " relative -to=" jboss. server. config. dir "/> </ authentication > </ security - realm > </ security - realms > < management - interfaces > <native - interface security - realm =" ManagementRealm "> <socket - binding native =" management - native "/> </ native - interface > <http - interface security - realm =" ManagementRealm "> <socket - binding http =" management - http "/> </http - interface > </ management - interfaces > </ management > Bei der Standardkonfiguration werden die Einstellungen in der Datei mgmt-users gespeichert. 16

23 1.7 Technisches Umfeld Nutzer können durch folgendes Skript angelegt werden (für Windows): add - user. bat username password realm Der Wert Realm ist optional. Wenn dieser nicht gesetzt ist, wird der Standardwert angenommen. 1.7 Technisches Umfeld Die Anwendung PTP wird in einer virtuellen Maschine betrieben (mit dem OS Windows Server 2003). Die zur Virtualisierung verwendete Software ist VMWare ESXi 4.0. Der Server, auf dem die virtuelle Maschine betrieben wird, ist ein Dell Power Edge 2970 und ist physikalisch abgeschlossen im Serverraum gesichert. Auf dem Server laufende Datenbankinstanzen laufen nur lokal. Somit ist kein Zugriff per Netzwerk möglich. Abbildung 1.10: Technisches Umfeld, eigene Darstellung Ansonsten ist der Server im Netz der Hochschule durch geöffnete Ports und Netzwerkfreigaben erreichbar. Über das Internet ist der Server nur an Port 80 bzw. 443 erreichbar und wird durch eine Firewall des Rechenzentrums abgeschirmt. 17

24 1.8 Organisatorisches Umfeld 1.8 Organisatorisches Umfeld Der Leiter des Projekts PTP ist Professor Dr. Löschel. Für technische Belange wie Serverbetrieb und Patches ist Hr. Lutz zuständig. Die Bearbeitung von Programmcode und Bugfixing ist aktuell meine (Hr. Fenzl) Aufgabe. Der Datenschutzbeauftragte der Hochschule ist Hr. Buberger vom Rechenzentrum. Er ist für den Schutz personenbezogener Daten zuständig. Etwa 2 Monate vor der Prüfungsphase wird die PTP aktiviert (erst für Professoren und anschließend für Studenten). Für das Einspielen von Updates wird normal etwa 1 Monat vor der Aktivierung der PTP eingeplant. Diese umfassen Codeänderungen, Erweiterungen, Konfigurationen am Server und Patches. 18

25 Kapitel 2 Eigene Untersuchungen Im folgenden Abschnitt werden meine eigenen Untersuchungen am Applikationsserver dargestellt. Dabei wird sowohl auf das Framework, die Angriffsoberfläche, Portierung, Lücken verwendeter Komponenten, als auch auf statische Codeanalyse, konzeptionelle Schwachstellen und mögliche Maßnahmen zur Absicherung eingegangen. Es werden vorhandene Lücken analysiert und dargestellt, wie wahrscheinlich ein möglicher Angriff eintreten kann. Eine Einschätzung, wie hoch der damit verbundene mögliche Schaden ist (siehe 1.4 Grundschutz und ISO27001) soll hierbei nicht gegeben werden. 2.1 Analyse des JBoss AS An dieser Stelle ist vor allem der Blick auf die aktuelle AS Version notwendig, da es kontinuierlich Entwicklungen zwischen den einzelnen Versionen gab und eine komplette Analyse aller Versionen den Rahmen dieser BA sprengen würde. JBoss 7 besitzt im Vergleich zu seinen Vorgängerversionen einen neuen Kernel, welcher auf 2 Projekten basiert [3, 8]: JBoss Modules: Zuständig für das Laden der Resourcen, vergleichbar mit ei- 19

26 2.1 Analyse des JBoss AS nem dünnen Bootstrap Wrapper zur Ausführung einer Anwendung in einer modularen Umgebung. Modular Service Container (MSC): Macht es einfach Services zu verwalten und sie zu installieren. Auch wird die Resource Injection bei Services und Abhängigkeitsmanagement zwischen Services geregelt. Abbildung 2.1: Aufbau neuer JBoss 7 Kernel [3, 8] Durch diesen neuen Kernel werden geringere Ladezeiten und eine kleinere Angriffsoberfläche erreicht. Um den Server zu betreiben wird eine installierte JVM (Java Virtual Machine) Umgebung vorausgesetzt, deren Installationspfad per Systemvariable (Teil der Umgebungsvariablen) JAVA HOME gesetzt sein muss (das Startskript des JBoss referenziert diese direkt). JBoss 7 läuft hierbei sowohl mit Java 6 als auch Java 7, jedoch ist aus Sicherheitsgründen immer der Einsatz der letzten Version von Vorteil. Der Server selbst muss natürlich installiert werden (entweder mit dem Installer oder per Entpacken aus einer.zip Datei) und wenn auf dem Rechner eine Entwicklung notwendig ist, empfiehlt sich auch die Installation von Eclipse 20

27 2.2 Angriffsoberfläche der PTP mit JBoss 5 mit JBoss Tools und einem Browser zur Darstellung. Gestartet wird die Installation durch das Skript standalone.bat (Windows) bzw. standalone.sh (Linux). Konfigurationen für den Standalone-Betrieb werden in der standalone.conf vorgenommen. Die Dateistruktur des Servers sieht folgendermaßen aus: Abbildung 2.2: Dateistruktur des JBoss 7 [3, 19] Komponenten können aus dem Dateisystem geladen und aktiviert werden, wenn sie vom Nutzer gebraucht werden [3, 26]. 2.2 Angriffsoberfläche der PTP mit JBoss 5 Die ursprüngliche Konfiguration des JBoss GA (Community Version) lief in einer virtuellen Maschine (VMWare) auf einem Java-Server der Hochschule. Das OS war Windows Server 2003 und die verwendete Java Version 1.6. Der Java-Server ist durch eine Firewall von der Außenwelt getrennt. 21

28 2.2 Angriffsoberfläche der PTP mit JBoss 5 Aufgrund bekannter Schwachstellen in Java 1.6 war es nötig, dieses auf 1.7 upzudaten. JBoss GA hat in der Grundinstallation einige Lücken, wie heute bekannt ist. Dieser wurde aufgrund des mangelnden Supports seitens Red Hat nur in der Lizenzversion (damals Enterprise Application Platform 5) mit Patches versorgt. Folgende Lücken waren daher ohne Upgrade nicht gepatcht: Tabelle 2.1: Bekannte Lücken von JBoss GA Typ der CWE CVSS CVE Exploit- Veröffentlicht Schwachstelle Stärke bar Permissions, CWE CVE ja 01/14/2012 Privileges, and Access Control Input Validation CWE CVE ja 07/14/2011 Resource CWE CVE ja 01/05/2012 Management Errors Permissions, CWE CVE ja 07/27/2011 Privileges, and Access Control Permissions, CWE CVE ja 07/27/2011 Privileges, and Access Control Design Error CVE ja 02/17/2011 Input Validation CWE CVE ja 12/30/2010 Cross-site request forgery CWE CVE ja 03/02/2007 Diese Lücken haben folgende Auswirkungen (teilweise gekürzte CVE Beschreibungen) und können meist (wenn angegeben) auch ohne offiziellen Patch geschlossen werden: 22

29 2.2 Angriffsoberfläche der PTP mit JBoss 5 CVE [35] The HTTP Digest Access Authentication implementation in Apache Tomcat 5.5.x before , 6.x before , and 7.x before does not have the expected countermeasures against replay attacks, which makes it easier for remote attackers to bypass intended access restrictions by sniffing the network for valid requests, related to lack of checking of nonce (aka server nonce) and nc (aka nonce-count or client nonce count) values. Patchstrategie: Upgrade der Tomcat 5,6,7 Pakete durchführen or Anwenden des offiziellen Red Hat Patches CVE [38] Apache Tomcat 5.5.x before , 6.x before , and 7.x before , when sendfile is enabled for the HTTP APR or HTTP NIO connector, does not validate certain request attributes, which allows local users to bypass intended file access restrictions or cause a denial of service (infinite loop or JVM crash) by leveraging an untrusted web application. Patchstrategie: Upgrade der Tomcat 5,6,7 Pakete durchführen oder Anwenden des offiziellen Red Hat Patches CVE [39] Apache Tomcat before , 6.x before , and 7.x before computes hash values for form parameters without restricting the ability to trigger hash collisions predictably, which allows remote attackers to cause a denial of service (CPU consumption) by sending many crafted parameters. Patchstrategie: Upgrade der Tomcat 5,6,7 Pakete durchführen oder Anwenden des offiziellen Red Hat Patches 23

30 2.2 Angriffsoberfläche der PTP mit JBoss 5 CVE [37] jboss-seam.jar in the JBoss Seam 2 framework 2.2.x and earlier, as distributed in Red Hat JBoss Enterprise SOA Platform CP05 and 5.1.0; JBoss Enterprise Application Platform (aka JBoss EAP or JBEAP) 4.3.0, CP09, and 5.1.1; and JBoss Enterprise Web Platform 5.1.1, does not properly restrict use of Expression Language (EL) statements in FacesMessages during page exception handling, which allows remote attackers to execute arbitrary Java code via a crafted URL to an application. NOTE: this vulnerability exists because of an incomplete fix for CVE CVE [36] Boss Seam privilege escalation caused by EL interpolation in Faces- Messages (for EAP/SOA 5.1). Patchstrategie: Anwenden des offiziellen Red Hat Patches CVE [34] Impact: Remote code execution Affected Software/OS: java sun on opensuse 11.2, opensuse 11.3 JBossweb update fixing JDK double bug (for EAP/EWP 5.1) Patchstrategie: Installation des java ibm Sicherheitspatches oder Anwenden des offiziellen Red Hat Patches CVE [33] JBoss Remoting Denial-Of-Service Patchstrategie: Anwenden des offiziellen Red Hat Patches 24

31 2.2 Angriffsoberfläche der PTP mit JBoss 5 CVE [32] Cross-site request forgery (CSRF) vulnerability in jmx-console/htmladaptor in JBoss allows remote attackers to perform privileged actions as administrators via certain MBean operations, a different vulnerability than CVE Für JBoss 7 bzw. die Red Hat Enterprise Application Platform 6.0 sind bislang nur wenige Probleme bekannt, da das Framework noch jung ist. Bisherige Analysen lassen das System allerdings sicherer, als die Vorgängerversionen erscheinen (was u.a. an dem von Grund auf neuem Kern des Frameworks liegen mag). Allerdings hatte eine native Komponente, OpenSSL, in der Releaseversion folgende Schwachstellen [24]: CVE : DTLS plaintext recovery attack CVE : double-free in policy checks CVE : uninitialized SSL 3.0 padding CVE : SGC restart DoS attack CVE : CMS and PKCS# 7 Bleichenbacher attack CVE : mime param cmp NULL dereference crash CVE : asn1 d2i read bio integer errors leading to buffer overflow CVE : record length handling integer underflow Sowohl EAP als auch das freie JBoss 7 sind hier patchbar. Besitzer der EAP 6.0 können den offiziellen Patch hier laden und die alten Dateien überschreiben: softwareid=15873& product=appplatform& version=6.0.0& downloadtype= securitypatches 25

32 2.3 Portierung JBoss 5 zu EAP 6.0 Community Version Nutzer haben die Möglichkeit OpenSSL selbst zu kompilieren oder betriebssystemabhängige Binaries zu laden und in ihre JBoss Version zu integrieren. Die Binaries sind hier zu finden: Portierung JBoss 5 zu EAP 6.0 Da einige Lücken bereits in JBoss 7 (Community Version) bzw. EAP 6.0 (Red Hat Lizenz Version) geschlossen wurden und die aktuelle Version allgemein als sicher gilt, war die Portierung des Systems ein wichtiger Schritt in Richtung Security. Der offizielle Guide hierzu ist ziemlich umfangreich und hier einzulesen: application+from+as5+or+as6+to+as7 Bei meiner Vorgangsbeschreibung wird bei der Angabe von APP-ROOT Bezug auf den jeweiligen Pfad, in dem die PTP auf dem jeweiligen Entwickler PC liegen kann, genommen. Im Fall der PTP waren die folgenden Schritte notwendig: JBoss 7 lädt seine Libraries anders als JBoss 5, daher war es notwendig, alle Libraries, die vorher im Library Verzeichnis des JBoss Servers oder in anderen Verzeichnissen der Applikation waren, nach APP-ROOT/webapp/WEB-INF/lib/ zu kopieren. Diese Libraries waren servlet-api, slf4j-api, slf4j-jboss-logging. Anschließend mussten folgende Dateien angepasst werden: APP-ROOT/src/ptp/ptp.properties (lokale Pfade, SSL, etc.) APP-ROOT/ant/build.properties (Buildpfade, Anwendungsname, etc.) 26

33 2.3 Portierung JBoss 5 zu EAP 6.0 An dieser Stelle kann man das Projekt in Eclipse (oder einer anderen IDE) öffnen und hat hier alle Libraries aus APP-ROOT/webapp/WEB-INF/lib/ und APP- ROOT/lib/, die JBoss Runtime und die JRE 7 bzw. JDK 1.7 (funktionieren beide) in den Build Pfad einzutragen. Im nächsten Schritt müssen alle Abhängigkeiten aufgelöst werden, um Class Not Found Exceptions vorzubeugen. Hier hilft das Tool Tattletale [27]. Diesem übergibt man entweder die fertige.war (erzeugt mit Ant), oder das APP-ROOT Verzeichnis. Daraus erzeugt Tattletale einen umfangreichen Report. Die gewonnenen Erkenntnisse kann man dann entweder in der MANIFEST.MF der Anwendung eintragen, oder wie im Fall der PTP in einer jboss-deployment-structure.xml. Interessant ist, dass in diesem Report für Systemmodule nur <module name =" system " /> angegeben wird. Dies führt u.a. zu einer Fehlermeldung, dass MAIN nicht geladen werden kann, was vom wahren Problem ablenkt, da Tattletale stattdessen (im Fall der PTP) nur SSL vermisst, welches aber mit folgender Notation eingetragen werden muss: <system > <paths > <path name =" com / sun / net / ssl / internal / ssl "/> </ paths > </ system > Die gesamte jboss-deployment-structure.xml sieht damit folgendermaßen aus: <? xml version =" 1.0 "?> <jboss - deployment - structure > < deployment > < dependencies > < module name =" javax. activation. api "/> < module name =" javax. annotation. api "/> < module name =" javax. ejb. api "/> 27

34 2.4 Lücken fertiger Softwarekomponenten < module name =" javax.el.api "/> < module name =" javax. jms. api "/> < module name =" javax. persistence. api "/> < module name =" javax. servlet. jsp. api "/> < module name =" javax. servlet. jstl. api "/> < module name =" org. apache. commons. lang "/> < module name =" org. jboss. logging "/> <system > <paths > <path name =" com / sun / net / ssl / internal / ssl "/> </ paths > </ system > </ dependencies > </ deployment > </ jboss - deployment - structure > Auch gab es noch einige Anpassungen auf Serverseite, diese sollen aber an dieser Stelle nicht erläutert werden, da hier nur die Anpassung an der Anwendung dargestellt wird und für Serveranpassungen Hr. Lutz zuständig ist. 2.4 Lücken fertiger Softwarekomponenten Nicht nur der JBoss Server und die darauf laufenden Anwendungen bieten dem Angreifer nutzbare Schwachstellen. Oftmals werden auch Lücken von verwendeten Softwarekomponenten wie dem Betriebssystem oder Java genutzt, um einen erfolgreichen Angriff auszuführen. Ein bekanntes Beispiel sind die folgenden JDK Lücken [18]: CVE : Zugriffsrechte für Klassen- und Objektattribute werden nicht immer überprüft, führt zu Durchbrechung der Grenzen der Java- Sandbox. CVE : manipulierte Schriftdatei könnte die JVM abstürzen lassen oder ihren Speicherbereich manipulieren, führt zum Absturz der JVM oder 28

35 2.5 Statische Codeanalyse dem Ausführen von beliebigen Code mit Rechten der VM. CVE : unkontrollierter Zugriff auf bestimmte Bedienelemente von Swing, führt zum Absturz der JVM oder Umgehung von Sandbox-Einschränkungen. CVE : Bug CORBA-Implementierung, selbe Folgen wie CVE Patches stehen meist schnell bereit und müssten unverzüglich von den Administratoren eingespielt werden, um eine sichere Umgebung für den AS zu gewährleisten. Leider ist dies mit Aufwand verbunden und oft auch mit einem kurzzeitigen Ausfall der auf dem Server laufenden Anwendungen (aufgrund Serverneustart). Daher bestehen solche Sicherheitslücken oft länger und sind ein beliebtes Ziel für Angreifer. Auch weitere auf dem Server laufende Programme können Sicherheitslücken haben. Daher empfiehlt es sich bei Servern immer nur die notwendigsten Programme, Dienste und Services zu verwenden, um die Angriffsoberfläche möglichst gering zu halten. 2.5 Statische Codeanalyse Statische Analyse ist ein wichtiger Bestandteil für Organisationen, um zu garantieren, dass der verwendete Quellcode möglichst frei von angreifbaren Schwachstellen ist. Diese Analyse wird je nach Wissen des Auditors sowohl zu Fuß, als auch mit unterstützenden Tools vollzogen. Eines dieser Tools ist Fortify von HP Grundlagen statischer Codeanalyse Wie ein solcher Analysezyklus aufgebaut ist, sollen die folgenden 4 Schritte vermitteln [1, 48]: 1. Ziele festlegen: Soll nur auf Sicherheitlücken geprüft werden, oder sollen auch weitere Schwachstellen im Code analysiert werden? 29

36 2.5 Statische Codeanalyse 2. Ein statisches Analyse Tool ausführen: Dieses unterstützt den Programmierer über das eigene Wissen hinaus, Schwachstellen zu identifizieren. 3. Code analysieren und bewerten: Dies kann mit Unterstützung des Tools geschehen, aber auch eigene Erfahrung und weitere Quellen mit einbeziehen. 4. Lösungen für Lücken schaffen und implementieren. Dabei ist folgende Regel besonders zu beachten: Steer Clear of the Exploitability Trap [1, 54] Diese Exploitablility Trap ist besonders gefährlich, da die Entwicklung von Exploits sehr zeitintensiv und an die Erfahrung des Entwicklers gebunden ist. Daher gilt immer: Wenn ein Code nicht offensichtlich sicher ist, muss er sicher gemacht werden! Folgende Arbeitsschritte durchlaufen Static Analysis Tools wie Fortify [1, 71]: Der Code wird akzeptiert. Ein Modell, welches das Programm repräsentiert, wird erstellt. Das Modell wird anhand von Sicherheitswissen analysiert. Die Analyse wird abgeschlossen und die Ergebnisse werden dem Nutzer präsentiert. 30

37 2.5 Statische Codeanalyse Grafisch dargestellt sieht das dann so aus: Abbildung 2.3: Blockdiagramm für ein statisches Analysetool [1, 71] Die Aufgabe des statischen Analysetools zur Erstellung eines Modells (welches dann analysiert werden kann) ist den Code in einen Satz von Datenstrukturen umzuwandeln, welche den Code repräsentieren [1, 72]. Dabei werden z.b. folgende Compiler-Techniken angewendet: Lexikalische Analyse: Das Umwandeln von Code in eine Reihe von Token und das Weglassen von unwichtigen Merkmalen [1, 72] Parsen: Abgleich der Token, Erstellung eines Parserbaums [1, 73] Abstract Syntax bzw. Abstract Syntax Tree (AST): Ähnlich wie Parserbaum, aber seine Knoten im Baum sind direkt von den Erzeugungsregeln der Grammatik abgeleitet[1, 74-75]. Semantische Analyse: Bei Erstellung des AST wird eine Symboltabelle erstellt, durch die Typ Prüfung ermöglicht wird [1, 76]. Tracking Control Flow: Anhand eines Control Flow Graphen wird jeder mögliche Programmablauf dargestellt [1, 77-78]. Tracking Dataflow: Durchlaufen der Control Flow Graphen von Funktionen und Aufzeichnung, wo Datenwerte erstellt werden und wo sie benutzt werden [1, 80]. Taint Propagation: Herausfinden, wo Daten das Programm betreten und wie die Daten sich durch das Programm bewegen. Dies ist der Schlüssel für 31

38 2.5 Statische Codeanalyse die Identifikation von vielen Eingabevalidierungs- und Darstellungsschwachstellen [1, 82]. Pointer Aliasing: Herausfinden, welche Pointer möglicherweise den selben Speicherplatz referenzieren [1, 82]. Es gibt verschiedene Analysealgorithmen, um unter unterschiedlichen Umständen und Bedingungen besser die Gefahr von schadhaftem Code einschätzen zu können [1, 83]. Das Prüfen von Assertions (Behauptungen) [1, 84] ist eine einfache Möglichkeit, um Sicherheitseigenschaften zu prüfen. Wenn das Programm garantiert, dass diese nicht fehlschlagen können, ist auch keine Schwachstelle vorhanden. Eine lokale Analyse nutzt Wissen über Assertions und teilt das Programm in kleine Abschnitte ein, in denen sich das Ergebnis von Assertions nicht verändert und eliminiert falsche Pfade, welche nicht ausgeführt werden können, da sie logischerweise inkonsistent sind [1, 85-88]. Die einfachste Vorgehensweise für eine globale Analyse ist Probleme zu ignorieren und anzunehmen, dass alle Probleme sich selbst belegen, wenn das Programm Funktion für Funktion untersucht wird. Diese Annahme ist schlecht für viele Sicherheitslücken, da es oft notwendig ist, über die Grenzen von Funktionen hinwegzusehen [1, 91]. Verschiedene Ansätze werden für eine umfassende globale Analyse verwendet. Der ehrgeizigste Ansatz ist die Analyse des kompletten Programms mit dem Ziel jede Funktion so weit zu analysieren, dass man ein umfassendes Wissen über den Kontext der aufrufenden Funktionen erlangt [1, 92]. Um die Analyse durchführen zu können, müssen Regeln festgelegt werden. Je nach Software, welche den Anwender bei der statischen Analyse unterstützt, wird bereits ein Satz an Regeln mitgeliefert, die editiert und erweitert werden können. Im Fall der PTP wird der Standardregelsatz von Fortify verwendet. Das Ergebnis der statischen Analyse ist ein Bericht, welcher alle gefundenen Sicherheitslücken auflistet, sie beschreibt und die Stelle im Code angibt, an der die 32

39 2.5 Statische Codeanalyse jeweilige Lücke auftritt. Ein Auditor erwartet mindestens folgende Elemente in dem Bericht [1, 106]: Gruppierung und Sortierung der Ergebnisse Eliminierung von ungewollten Ergebnissen Erklärung der Bedeutung von Ergebnissen. Fortify erzeugt zudem ein Diagramm, welches alle Funktionen mit Bezug auf den Code aufzeigt, durch den eine Schwachstelle erzeugt wird und wo sich diese Schwachstelle negativ auswirkt. Folgender Screenshot zeigt die Oberfläche von Fortify: Abbildung 2.4: Fortify Diagrammansicht, Screenshot aus Testumgebung Anwendung statischer Codeanalyse Die Werte der folgenden Tabelle stammen aus Fortify und geben den Typ der Verwundbarkeit, die Verwundbarkeit selbst, wie groß der Schaden durch einen 33

40 2.5 Statische Codeanalyse Angriff einzuschätzen ist, wie wahrscheinlich ein Angriff erfolgreich ausgeführt wird und wie häufig diese Verwundbarkeit in der PTP gefunden wurde, an. Tabelle 2.2: Durch statische Codeanalyse identifizierte Lücken Typ der Verwundbarkeit Verwundbarkeit Stärke Wahr- schein- lichkeit Menge - Infinite rekursive loop Security Features, Data Flow Privacy Violation Input Validation and Representation, Data Flow Input Validation and Representation, Data Flow Input Validation and Representation, Data Flow Input Validation and Representation, Data Flow API Abuse, Control Flow Time and State, Structural Input Validation and Representation, Control Flow Encapsulation, Data Flow Encapsulation, Structural Environment, Configuration API Abuse, Semantic Encapsulation, content Cross-Site Scripting: Reflected Path Manipulation LDAP Injection LDAP Manipulation Multiple Stream Commits Race Condition: Format Flaw Missing XML Validation System Information Leak HTML Comment in JSP Excessive Session Timeout Unchecked Return Value Cross-Site Request Forgery 34

41 2.5 Statische Codeanalyse Schwachstellen im untersuchten Code Anm.: Aufgrund des zur statischen Analyse verwendeten Tools Fortify sind einige Beschreibungen in diesem Abschnitt aus diesem Tool (übersetzt) entnommen und zusammengefasst. Auch sind einige Problemlösungsvorschläge aus Fortify übernommen. Dieses Wissen wird direkt auf die Sicherheitslücken der PTP angewandt (mit Codebeispielen). Aufgrund der Art der verwendeten Informationsquelle wird nur hier [2] darauf verwiesen und die Quelle jeweils an den Überschriften der Unterabschnitte, die Material (Text oder Code) aus Fortify verwenden, angegeben. Zusätzlich verwendete Quellen werden wie gewohnt direkt bei der Verwendung angegeben Unendliche rekursive Schleife In der Datei ptp.util.xml.detailsnode existieren folgende Funktionen: public void setvalue ( final Boolean value ) { setvalue ( new Boolean ( value )); } public void setvalue ( final String name, final Boolean value ) { setvalue (name, new Boolean ( value )); } Dieser Code würde sich unendlich lange selbst aufrufen und damit einen Denial of Service verursachen Privacy Violation [2] Verletzungen der Privatheit treten auf, wenn: Private Nutzerinformationen in den Programmfluss eintreten. Die Daten auf eine externen Ort geschrieben werden, wie die Konsole, das Dateisystem oder das Netzwerk. 35

42 2.5 Statische Codeanalyse Im Fall der PTP werden Daten zu error() in der Datei XmlDataManager.java durchgereicht. Diese Daten enthalten die Supervisor ID, welche als personenbezogene Information zu betrachten ist. logger. error (" Supervisor infos for " + s. getid () + " couldn t be hot replaced "); Private Daten sollten nur dargestellt werden, wenn dies wirklich notwendig ist. Anwendungen, Prozesse und Mitarbeiter sollten keinen Zugriff auf private Daten haben, wenn Zugriffe nicht essentiell für die Aufgaben sind, die sie ausführen. Im Umfeld der PTP stellt diese Verletzung der Privatheit kein größeres Problem dar, denn die Supervisor ID ist hierfür nicht sensibel genug. Wenn aber Informationen wie Matrikelnummern (in der PTP die ID der Studenten) in Kombination mit Namen an einen Logger übergeben werden würden, wäre dieser Fehler als kritisch zu betrachten Cross-Site Scripting: Reflected [2] Cross-Site Scripting (XSS) Angriffe gehören zu den verbreitesten Angriffen auf Web-Frameworks. Diese treten auf, wenn: Daten in einer Webapplikation ankommen, die aus einer nicht vertrauenswürdigen Quelle stammen. Im Fall der Reflected XSS ist die nicht vertrauenswürdige Quelle typischerweise ein Web Request. Daten im dynamischen Inhalt enthalten sind, der zu einem Web Nutzer ohne Validierung nach gefährlichem Code geschickt wird. Im Fall der PTP werden Daten bei print() in der additional.jspx und der grouping.jspx verschickt. Der gefährliche Inhalt, der zum Web Browser geschickt wird, nimmt oft die Form eines JavaScript Segments an, kann aber auch HTML, Flash oder eine andere Art von Code beinhalten, die der Browser ausführen könnte. 36

43 2.5 Statische Codeanalyse Die Breite an Angriffen, die auf XSS basieren, ist quasi nicht begrenzt. Sie nutzen meist die Übertragung von privaten Daten wie Cookies oder anderen Session Informationen zum Angreifer aus, leiten das Opfer zu Web Inhalten weiter, die vom Angreifer kontrolliert werden, oder führen andere bösartige Operationen auf dem PC des Nutzers aus. Sowohl die additional.jspx, als auch die grouping.jspx der PTP nutzen in ihrem print() die Funktion getstring() der Datei Util.java. Diese sieht folgendermaßen aus: public static String getstring ( Object value ) { if ( value == null ) { return ""; } if ( value instanceof String ) { return ( String ) value ; } return value. tostring (); } Wie man diesem Listing entnehmen kann, wird aus einem Objekt ein String geschaffen und zurückgegeben. Dieses Objekt wird allerdings ohne jegliche Überprüfung akzeptiert, lediglich ein leerer String wird separat abgehandelt. Eine Möglichkeit zur Absicherung dieses Codefragments wäre die Einführung einer Regular Expression, die nur erlaubte Strings zulässt. Eine Funktion, wie diese in Util.java an mehreren Stellen ihre Verwendung findet, sollte Strings vor ihrer Rückgabe von möglichem Schadcode bereinigen [22] public static String sanitize ( String string ) { return string. replaceall ("(?i)<script.*? >.*? </ script.*? >", "")// Fall1. replaceall ("(?i) <.*? javascript :.*? >.*? </.*? > ", "")// Fall2. replaceall ("(?i) <.*?\\ s+on.*? >.*? </.*? > ", "");// Fall3 } Die Anwendung der Funktion sanitize(string string) im XSS anfälligen Code sieht so aus: 37

44 2.5 Statische Codeanalyse public static String getstring ( Object value ) { if ( value == null ) { return ""; } if ( value instanceof String ) { return sanitize (( String ) value ); } return sanitize ( value. tostring ()); } Path Manipulation [2] Path Manipulation Fehler treten auf, wenn die zwei folgenden Bedingungen erfüllt sind: Ein Angreifer kann einen Pfad angeben, der in einer Operation auf dem Dateisystem verwendet wird. Indem der Angreifer die Resource angeben kann, bekommt er Möglichkeiten, die ihm sonst verwehrt wären. Zum Beispiel könnte das Programm dem Angreifer die Möglichkeit geben, spezifische Dateien zu überschreiben oder mit einer Konfiguration zu arbeiten, die vom Angreifer kontrolliert wird. Im Fall der PTP könnte ein Angreifer die config.xml überschreiben, welche das Programm dann manipuliert. GeneralBean.java, AdminBean.java oder PathValidation.java laden unter Verwendung der loadproperties() Funktion der Util.java die Property Datei, um Konfigurationswerte wie grundlegende Applikationspfade oder Systemmodule zu setzen. Der Angriffsvektor der Path Manipulation ist in der PTP sehr gering. Nur unter 2 Umständen wäre es möglich, diese umzusetzen: 38

45 2.5 Statische Codeanalyse Der Angreifer hat Zugriff auf das SVN und ändert unbemerkt Property Werte, mit anschließendem Commit. Der Angreifer erstellt die.war der Anwendung neu mit einer manipulierten config.xml und schafft es, die bestehende Serverversion durch diese Version zu ersetzen LDAP Injection [2] LDAP Injection Fehler treten auf, wenn die zwei folgenden Bedingungen erfüllt sind: Daten werden ins Programm von einer nicht vertrauenswürdigen Quelle geladen (z.b. Nutzereingabe). Die Daten werden genutzt um dynamisch einen LDAP Filter zu erstellen. Im Fall der PTP tritt dies auf, wenn in den LDAP Modulen AuthenticateADS und AuthenticateLDAP die Funktion authenticate() aufgerufen wird. Dort wird eine Usereingabe übernommen, ohne sie auf böswilligen Inhalt zu überprüfen. final String filter = "( samaccountname =" + username + ")"; NamingEnumeration < SearchResult > ne = ctx. search ( basedn, filter, ctls ); Auf diese Weise kann die Anfrage am LDAP-Server manipuliert werden und es kann zu ungewollten Ergebnissen kommen. Unter normalen Umständen würde in diesem Codebeispiel ein Nutzer mit einem Namen abc gefiltert werden. Allerdings, da der Filter dynamisch erstellt wird, indem ein basedn String und ein Benutzereingabe String verbunden werden, verhält sich die Abfrage nur richtig, wenn samaccountname nicht LDAP Metazeichen enthält. Wenn ein Angreifer z.b. einen String abc123456)( objectclass=*) als username eingäbe, würde die Abfrage folgendermaßen aussehen: (samaccountname=abc123456)( objectclass=*) 39

46 2.5 Statische Codeanalyse Je nachdem, mit welchen Rechten die Abfrage ausgeführt wird, führt die zusätzliche (objectclass=*) Bedingung dazu, dass der Filter mit allen Einträgen in dem Verzeichnis verglichen wird und der Angreifer Informationen über den gesamten Benutzerstamm erhält. Die Intensität des Angriffs betrifft dabei alle Einträge, auf die ein Benutzer, der die LDAP-Abfrage ausführt, zugreifen kann. In der PTP konnte bislang keine Kombination gefunden werden, welche die Lücke aushebelt. Aber es war möglich, seine eigene Kennung mit LDAP-Metazeichen zu versehen und dennoch eine erfolgreiche Anmeldung durchzuführen (mit korrektem Passwort). Ein Beispiel hierfür: fev32461 )( objectclass =* Um LDAP-Angriffe zu vermeiden, empfiehlt OWASP die Anwendung der folgenden 2 Funktionen, welche wie folgt in der PTP integriert sind: package ptp. filter ; public class LdapFilter { public static String escapedn ( String name ) { StringBuffer sb = new StringBuffer (); if (( name. length () > 0) && (( name. charat (0) == ) ( name. charat (0) == # ))) { sb. append ( \\ ); // add the leading backslash if needed } for ( int i = 0; i < name. length (); i ++) { char curchar = name. charat (i); switch ( curchar ) { case \\ : sb. append (" \\\\ "); break ; case, : sb. append ("\\,"); break ; case + : sb. append (" \\+ "); 40

47 2.5 Statische Codeanalyse break ; case " : sb. append (" \\\" "); break ; case < : sb. append ("\\ <"); break ; case > : sb. append ("\\ >"); break ; case ; : sb. append (" \\; "); break ; default : sb. append ( curchar ); } } if (( name. length () > 1) && ( name. charat ( name. length () - 1) == )) { sb. insert (sb. length () - 1, \\ ); } return sb. tostring (); } public static final String escapeldapsearchfilter ( String filter ) { StringBuffer sb = new StringBuffer (); for ( int i = 0; i < filter. length (); i ++) { char curchar = filter. charat (i); switch ( curchar ) { case \\ : sb. append (" \\5 c"); break ; case * : sb. append (" \\2 a"); break ; case ( : sb. append (" \\28 "); 41

48 2.5 Statische Codeanalyse break ; case ) : sb. append (" \\29 "); break ; case \ u0000 : sb. append (" \\00 "); break ; default : sb. append ( curchar ); } } return sb. tostring (); } } LDAP Manipulation [2] LDAP Manipulation ähnelt sehr der Funktionsweise von LDAP Injection und kann ebenfalls durch Input Validierung vermieden werden. Der Unterschied zur Injection besteht darin, dass die Daten nicht zur Erstellung eines LDAP Filters genutzt, sondern außerhalb der Filter Zeichenkette in einem dynamischen LDAP Befehl verwendet werden. Es wird also die Bedeutung der LDAP Anweisung verändert oder ein beliebiger LDAP Befehl ausgeführt. Im Falle der PTP löst sich das Problem mit dem gleichen Quellcode, der auch bei der LDAP Injection aufgerufen wird. Der Aufruf sieht folgendermaßen aus: // Filter Username and Password for LDAP Metacharacters username = ptp. filter. LdapFilter. escapedn ( username ); username = ptp. filter. LdapFilter. escapeldapsearchfilter ( username ); password = ptp. filter. LdapFilter. escapedn ( password ); 42

49 2.5 Statische Codeanalyse password = ptp. filter. LdapFilter. escapeldapsearchfilter ( password ); Code Correctness: Multiple Stream Commits [2] Einen HttpServletRequest weiterzuleiten, eine HttpServletRespone umzuleiten, oder den Output Stream eines Servlet Buffers zu leeren führt zu einem Commit eines damit verbundenen Streams. Jede anschließende Rücksetzung des Buffers oder Stream Commits, wie ein zusätzliches Leeren des Buffers oder Umleitung resultiert in einer IllegalStateException. Des Weiteren erlauben Java Servlets Daten, dass sie zum Antwort Stream geschrieben werden, indem sie entweder den ServletOutputStream oder den Print- Writer verwenden, aber nicht beide. Indem sie getwriter() aufrufen, nachdem sie bereits getoutputstream() aufgerufen haben, oder Vice Versa, wird ebenso eine IllegalStateException erzeugt. Im Fall der PTP wurde der Stream bereits zuvor von einer Funktion sendredirect() auf Zeile 64 committed (Datei ApplicationFilter.java). Durch eine ungeschickte Schachtelung von 2 try/catch Blöcken kann daher auftreten, dass die folgenden Funktionen beide aufgerufen werden: httpresponse. sendredirect ( httprequest. getcontextpath () + "/ view / application / start. jsf "); // im Code unter diesem Redirect passiert evtl. ein Fehler und aus dem unterliegenden catch - Block wird folgender Redirect zusätzlich aufgerufen httpresponse. sendredirect ( httprequest. getcontextpath () + "/ view / error. jsf "); Zur Laufzeit verhindert eine IllegalStateException, dass der Antwort Handler seine Aufgabe zu Ende führt und seine Antwort verwirft. Dies kann Serverinstabilität verursachen, was ein Zeichen für unsauber implementierte Servlets ist. Als Empfehlung gilt darauf zu achten, dass keine weiteren Änderungen am Stream gemacht werden, nachdem er committed wird. 43

50 2.5 Statische Codeanalyse Race Condition: Format Flaw [2] Die Methoden parse() und format() in java.text.format beinhalten eine Race Condition, die dazu führen kann, dass ein Nutzer die Daten des anderen Nutzers sehen kann. Eine Lösung des Problems stellt die Synchronisation dar. In dem Fall der PTP müsste also public String debug () { return "id: " + dfparse. format (id); } synchronisiert werden. Folgende 2 Möglichkeiten wären korrekt: public synchronized String debug () { return "id: " + dfparse. format (id); } public String debug () { synchronized ( dfparse ){ return "id: " + dfparse. format (id); }} Missing XML Validation [2] Die meisten erfolgreichen Angriffe beginnen mit einer Verletzung der Annahme des Programmierers, dass gewisse Angriffsszenarien nicht eintreten. Indem ein XML akzeptiert wird, ohne es gegen eine DTD oder ein XML Schema zu verifizieren, lässt der Programmierer eine Tür für Angreifer offen und beugt nicht gegen unerwartete, unsinnige oder gefährliche Eingaben vor. Es ist einem XML Parser nicht möglich, alle Elemente eines Dokumentinhaltes zu validieren, da er nicht die komplette Semantic (Struktur) der Daten versteht. 44

51 2.5 Statische Codeanalyse Allerdings kann der Parser einen vollständigen und gründlichen Test der Dokumentenstruktur machen und daher garantieren, dass der Code, der das Dokument abarbeitet, wohlgeformt ist. Im Fall der PTP ist diese Validierung nicht aktiviert (siehe z.b. PtpConfigParser.java in der Zeile 451): final DocumentBuilderFactory factory = DocumentBuilderFactory. newinstance (); final DocumentBuilder builder = factory. n ewd oc um en tb ui ld er (); final Document document = builder. parse ( is); Es ist wichtig, die Validierung immer zu aktivieren, wenn ein XML Parser oder eine Parser Factory erstellt wird. Wenn das Aktivieren der Validation Probleme verursacht, weil die Regeln für die Definition eines wohlgeformten Dokuments unbekannt sind, stehen die Chancen gut, dass es Sicherheitsfehler in der Nähe gibt. Eine Empfehlung von Fortify zur Lösung des Problems bei der DocumentBuilderFactory sieht so aus: // javax. xml. parsers. DocumentBuilderFactory factory. setvalidating ( true ); System Information Leak [2] Eine Informationslücke tritt auf, wenn Systemdaten oder Debugginginformationen das Programm durch einen Output Stream oder eine Logging Funktion verlassen. Je nach Systemkonfiguration kann diese Information auf eine Konsole ausgegeben, in eine Logdatei geschrieben oder einem Remote-Nutzer ausgesetzt werden. In einigen Fällen gibt die Fehler Nachricht dem Angreifer genaue Informationen, bei welcher Art von Angriff das System verwundbar ist. Zum Beispiel kann eine Datenbankfehlermeldung zeigen, ob ein System verwundbar für einen SQL 45

52 2.5 Statische Codeanalyse Injection Angriff ist. Andere Fehlermeldungen können genauere Hinweise auf die Systemkonfiguration geben. try {... } catch ( Exception e) { e. printstacktrace (); } Diese Lücke ist z.b. in der Funktion sendapplicationstat () in der PtpApplication.java der PTP zu finden. Dabei könnte die Funktion printstacktrace() Informationen über den Typ des Betriebssystems, die installierten Anwendungen und die Sorgfalt der Administratoren bei der Konfiguration des Programms geben. Im Allgemeinen gilt es immer Sicherheit im Hinterkopf zu behalten, wenn Fehlermeldungen im Programm ausgegeben werden sollen. Gerade in Produktivumgebungen sollten kurze Nachrichten detaillierten Fehlermeldungen bevorzugt werden. Spuren von Debugging tauchen oft an Orten auf, die einem vorher nicht klar waren (z.b. in HTML Kommentaren einer Fehlerseite). Sogar kurze Fehlermeldungen, die keine Stack Traces oder Database Dumps zeigen, können dem Angreifer potentiell helfen. Beispielsweise kann eine Access Denied Meldung zeigen, dass eine Datei oder Benutzer im System existiert System Information Leak: HTML Comment in JSP [2] Wie schon im Abschnitt System Information Leak geht es hier um Informationen, die einem potentiellen Angreifer bei der Vorbereitung seines Angriffs unterstützen können. Da diese Informationen hier direkt als HTML Kommentare vorliegen, sind sie die einfachste Informationsquelle für einen Angreifer über eine dynamisch generierte Webseite. Beispielsweise würde folgender Kommentar detaillierte Informationen über wichtige Beans des Programms geben: 46

53 2.5 Statische Codeanalyse <!-- div > <h: outputlabel for =" groupmay " value ="#{ bundle. groupingcanfold }" styleclass =" labelbig " / > <h: inputtextarea id=" groupmay " value ="#{ suvgroupingbean. canfold }" rendered =" #{! readonly }" /> <t: div styleclass =" outtextarea " rendered ="#{ readonly }" >#{ suvgroupingbean. canfold } </t:div > <h: message for =" groupmay " /> </div --> Die einfachste Lösung hier: Die HTML Kommentare durch JSP (Java Server Pages) Kommentare ersetzen (diese werden nicht zum Nutzer übertragen). Diese sehen folgendermaßen aus: // JSP Kommentare <%-- Diese Kommentare werden nicht übertragen --% > // HTML Kommentare <!-- Diese Kommentare werden übertragen -- > J2EE Misconfiguration: Excessive Session Timeout [2] Je länger eine Session offen bleibt, desto größer das mögliche Zeitfenster, das ein Angreifer hat, um Benutzerkonten zu gefährden. Während eine Session aktiv bleibt, könnte es einem Angreifer möglich sein, per Brute Force an das Passwort eines Nutzers zu gelangen, einen wireless Verschlüsselungsschlüssel zu knacken oder eine Session von einem offenen Browser zu übernehmen. Längere Session Timeouts können auch verhindern, dass Speicher freigegeben wird und können am Ende einen Denial of Service auslösen, wenn eine genügend große Zahl an Sessions erstellt wird. Wenn ein Session Timeout 0 oder kleiner als 0 ist, dann läuft die Session niemals ab. Wenn kein <session-timeout> Tag für alle Sessions der Web Applikation definiert ist, dann ist es Aufgabe des Container, den Default-Timeout zu setzen. Empfohlen ist von Fortify ein Timeout von 30 Minuten oder weniger. 47

54 2.5 Statische Codeanalyse Dieser lässt sich folgendermaßen setzen: <session - config > <session - timeout >30 </ session - timeout > </ session - config > Diese Konfiguration muss in der web.xml eingetragen werden Unchecked Return Value [2] Die Methode jsfforward() in JSFUtil.java ignoriert den Wert, der von getrenderresponse() in Zeile 151 zurückgeliefert wird, was dazu führen könnte, dass das Programm unerwartete Zustände und Bedingungen übersehen könnte. facescontext. getrenderresponse (); Beispielsweise könnte der facescontext null sein, was einen unerwarteten Zustand bedeuten würde. Dem wäre mit der folgenden einfachen Überprüfung vorzubeugen: if( facescontext == null ) throw new NullPointerException (" Faces context cannot be null "); Cross-Site Request Forgery [2] Eine Cross-Site Request Forgery (CSRF) Verwundbarkeit tritt auf, wenn: 1. Eine Web-Applikation Session Cookies benutzt. 2. Die Anwendung auf einen HTTP Request reagiert, ohne zu überprüfen, ob die Anfrage mit dem Wissen Benutzers gemacht wurde. Im Fall der PTP werden in verschiedenen Dateien HTTP Requests durch Formulare generiert, die ihren POST ausführen. Wenn der Request keine Nonce beinhaltet, die seine Herkunft beweist, dann 48

55 2.5 Statische Codeanalyse führt der Code den Request aus und ist verwundbar für einen CSRF-Angriff. Dies bedeutet, dass eine Web Applikation, die Session Cookies benutzt, spezielle Vorkehrungen treffen muss, um abzusichern, dass kein Angreifer Benutzer austrickst, falsche Requests abzuschicken. Aufgrund der Komplexität des Angriffs und der verschiedenen möglichen Lösungsstrategien soll folgendes Beispiel ein Gefühl für einen möglichen CSRF-Angriff vermitteln. Einfaches Beispiel zur Einführung in die CSRF-Attacke: Nehmen wir folgende Seite als gegeben an: <form method =" POST " action ="/ new_user " > Name of new user : <input type =" text " name =" username "> Password for new user : < input type =" password " name =" user_passwd " > <input type =" submit " name =" action " value =" Create User "> </form > Im Gegenzug könnte ein Angreifer folgende Webseite aufsetzen: <form method =" POST " action =" http :// www. example. com / new_user "> <input type =" hidden " name =" username " value =" hacker "> <input type =" hidden " name =" user_passwd " value =" hacked "> </form > <script > document. usr_form. submit (); </ script > Wenn ein Administrator die bösartige Seite besucht, während er für die eigene Seite eine aktive Session offen hat, wird er unwissentlich einen Account für den Angreifer erstellen. Dies wird als CSRF-Angriff bezeichnet. Dies ist möglich, weil die Anwendung keinen Weg hat, die Herkunft der Anfrage zu bestimmen. Jede Anfrage könnte eine legitime Aktion sein, die der Nutzer ausgewählt hat, oder eben eine gefälschte Aktion, die von einem Angreifer aufgesetzt wurde. Der Angreifer sieht die Webseite nicht, die von dem gefälschten Request generiert wurde, daher ist diese Angriffstechnik nur nützlich für Anfragen, die den Status der An- 49

56 2.5 Statische Codeanalyse wendung verändern. Die meisten Web Browser senden einen HTTP Header, auch Referrer genannt, zusammen mit jedem Request. Der Referrer Header sollte die URL der Bezugsseite enthalten, aber Angreifer können ihn abändern, womit der Referrer Header nicht sinnvoll für die Bestimmung der Herkunft einer Anfrage ist. Als Empfehlung gilt laut Fortify, dass Anwendungen, die Session Cookies nutzen, eine Art Information in jedem POST Formular enthalten müssen, welche der Back-End Code benutzen kann, um die Herkunft des Requests zu bestimmen. Eine Möglichkeit dies zu realisieren ist einen Random Request Identifier in jedem Formular einzuschlißen. Damit wäre die Lösung für dieses Beispielproblem etwa so: <form method =" POST " action ="/ new_user " > Name of new user : <input type =" text " name =" username "> Password for new user : < input type =" password " name =" user_passwd " > <input type =" submit " name =" action " value =" Create User "> <input type =" hidden " name =" req_id " value ="87 ae34d92ba7a1 "> </form > Dann kann die Hintergrundlogik den Request Identifier überprüfen, bevor sie den Rest der Formulardaten abarbeitet. Der Request Identifier kann bei jedem neuen Formular anders (also durch unique Zufallswerte) oder bei allen Formularen einer bestimmten Session gleich sein. Dabei gilt, je schwerer der Identifier zu raten ist, desto schwerer ist es für einen Angreifer, einen erfolgreichen CSRF Angriff auszuführen. Solch ein Identifier ist z.b. der ViewState Wert von JSF. Dieser Wert ist allerdings in der Standardkonfiguration bei Versionen vor JSF 2.1 leicht ratbar und daher unsicher. Wie man als Anwender diesen Wert dennoch gegen CSRF nutzen kann, wird in Lösungsansatz 3 erleutert. Anmk.: Die PTP nutzt JSF in Version 1.1 (MyFaces Implementierung). 50

57 2.5 Statische Codeanalyse Einschub: Was ist ein ViewState? [29] In JSF wird mit jeder Seite ein ViewState verbunden, der bei jeder Übertragung mitgegeben wird. Der Grund für den ViewState ist, dass HTTP ein zustandsloses Protokoll ist. Der Zustand der Komponenten, z.b. während Abfragen ausgeführt werden, muss erhalten bleiben. Dabei kann der ViewState Wert sich zwischen Abfragen ändern, da Elemente wie UIInput hinzugefügt oder geändert werden können. Der ViewState wird in 2 Teile aufgeteilt: 1. Struktur der Komponenten 2. Zustand der Komponenten, z.b. aktiviert/deaktiviert, ausgewähltes Item, neue eingegebene Werte, etc. Diesen ViewState Wert kann man entweder am Server oder am Client speichern. Löesungsansätze für die PTP Im Falle der PTP gibt es 3 Lösungsansätze, welche abhängig von verwendeter JSF Version und Implementierung verwendet werden können. Aufgrund der unterschiedlich hohen Komplexität und der damit erreichten Sicherheit wird hier erst die sicherste, aber auch rechenintensivste Lösung beschrieben, danach ein allgemeiner Ansatz und zu guter Letzt die naheliegenste Implementierung. Lösungsansatz 1: Der aufwendigste Ansatz ist die Implementierung einer Custom Komponente für JSF. Diese Komponente erzeugt serverseitig ein Token und bindet dieses in alle JSF Seiten ein. Bei Anfragen an den Server wird dieses Anti-CSRF Token überprüft. Ab JSF 2.0 kann der Programmierer ein solches Modul (z.b. customtag.xml) einfach bei der web.xml der vorhandenen Anwendung registrieren und anschließend verwenden. 51

58 2.5 Statische Codeanalyse Vor JSF 2.0 (damit auch das verwendete JSF 1.1) ist diese Einbindung von Custom Komponenten sehr aufwendig und benötigt zusätzliche vorgeschriebene Klassen [10]: UIComponent Class Renderer Class UI Component Tag Class Tag Library Descriptor File Associated helper classes. Diese Menge an Klassen macht Änderungen am Code schwierig und unübersichtlich. Folgendes Beispiel zeigt die Realisierung eines solchen Anti-CSRF Token (angelehnt an Quelle [23]): Der Server erstellt zentral per SessionListener einen Token und heftet ihn an die Session an. Dieser Token enthält einen verschlüsselten zufallsgenerierten Wert. Den Algorithmus hierfür kann der Nutzer selbst bestimmen. Hierfür ist es sinnvoll integrierte Javafunktionen zur Erzeugung wahrer Zufallswerte zu verwenden [14]. Beispiele für die Erzeugung wahrer Zufallswerte in Java werden hier angeboten: Wenn der Nutzer dann eine Seite mit einem form Element aufruft, wird dort durch die Klasse CSRFForm (die von HtmlForm erbt) bei allen Formularen durch die Klasse CSRFTokenInput ein input Element eingefügt, welches nicht dargestellt wird und einen serverseitig erstellten Zufallswert enthält. Dieses sieht folgendermaßen aus: <input type =" hidden " name =" j_idt7 : j_idt7_csrftoken " value =" 0 c776040ff77d3af5acce4d4c59a51411eb960bd " /> Beim Abschicken des Wertes wird am Server dieser Wert decodiert und mit dem ursprünglichen Zufallswert abgeglichen. Erst wenn die Werte als gleich verifiziert 52

59 2.5 Statische Codeanalyse werden, wird der Programmverlauf fortgesetzt, ansonsten wird Fehlerbehandlung betrieben (z.b. Error Seite). Die Implementierung hierzu in Ausschnitten (ohne Dateien zur Registrierung der Komponenten): public class CSRFSessionListener implements HttpSessionListener public void sessioncreated ( HttpSessionEvent event ) { HttpSession session = event. getsession (); String randomid = generaterandomid (); session. setattribute ( CSRFTokenInput. CSRFTOKEN_NAME, randomid ); } private String generaterandomid () { try { // Sichere Zufallszahl erzeugen, diese Operation dauert und wird nur ausgeführt bei der Erzeugung der Anwendung SecureRandom prng = SecureRandom. getinstance (" SHA1PRNG ") ; String randomnum = new Integer ( prng. nextint () ). tostring (); MessageDigest sha = MessageDigest. getinstance (" SHA -1"); byte [] result = sha. digest ( randomnum. getbytes ()); // Encodiertes Resultat zurückgeben // Methode hexencode wird aufgrund ihrer trivialen Funktion hier nicht dargestellt return hexencode ( result ); } catch ( NoSuchAlgorithmException ex ) { return ex. tostring (); } } } public class CSRFForm extends HtmlForm 53

60 2.5 Statische Codeanalyse public void encodebegin ( FacesContext context ) throws IOException { // neuer Token wird erzeugt CSRFTokenInput csrftoken = new CSRFTokenInput (); // ClientId wird gesetzt csrftoken. setid ( this. getclientid ( context ) + " _CSRFToken ") ; // Komponente wird zum Formular hinzugefügt getchildren ().add ( csrftoken ); super. encodebegin ( context ); } } public class CSRFTokenInput extends UIComponentBase { public static final String CSRFTOKEN_NAME = " csrftoken public void encodeend ( FacesContext context ) throws IOException { // Session holen ( ohne eine neue zu erzeugen ) HttpSession session = ( HttpSession ) context. getexternalcontext (). getsession ( false ); // Das Token aus der Session holen String token = ( String ) session. getattribute ( CSRFTOKEN_NAME ); // In die Antwort das Component HTML schreiben ( input ) ResponseWriter responsewriter = context. ge trespo nsewri ter (); responsewriter. startelement (" input ", null ); responsewriter. writeattribute (" type ", " hidden ", null ); responsewriter. writeattribute (" name ", ( getclientid ( context )), " clientid "); responsewriter. writeattribute (" value ", token, CSRFTOKEN_NAME ); responsewriter. endelement (" input "); public void decode ( FacesContext context ) { // ClientId der Komponente holen 54

61 2.5 Statische Codeanalyse String clientid = getclientid ( context ); // auf das versteckte Feld zugreifen ExternalContext external = context. getexternalcontext (); Map requestmap = external. getrequestparametermap (); String value = String. valueof ( requestmap. get ( clientid )); // Auf die Session zugreifen und das Token holen HttpSession session = ( HttpSession ) context. getexternalcontext (). getsession ( false ); String token = ( String ) session. getattribute ( CSRFTOKEN_NAME ); // Überprüfen ob das Token vorhanden ist if ( value == null "". equals ( value )) { throw new RuntimeException (" CSRFToken is missing!"); } // Überprüfen, ob die Werte gleich sind if (! value. equalsignorecase ( token )) { throw new RuntimeException (" CSRFToken does not match!"); } } } Lösungsansatz 2: Ein weiterer Weg zur Überprüfung, ob die verwendete Seite manipuliert wurde, ist die Abfrage des ViewState-Wertes, welcher bereits von JSF als hidden-feld in jedem Formular integriert ist. Die Sicherheit dieses Verfahrens ist bei clientseitiger ViewState-Speicherung ohne Verschlüsselung fragwürdig, da dieser Wert nach einem bestimmten Muster aufgebaut ist und vor JSF 2.1 nur inkrementell erhöht wird. Ab JSF 2.1 ist dieser Wert auch CSRF sicher [23], da er hier durch Zufallswerte erzeugt wird und diese eine gewisse Hürde für einen potentiellen Angreifer darstellen. Folgender Code ist an diese Quelle [15] angelehnt. Bei der Enterprise Application Platform ist für den Eingriff in den Lebenszyklus von JSF ein PhaseListener die Komponente der Wahl. Mit einem solchen kann man nach Registrierung in der faces-config.xml diverse Operationen in allen Phasen des Lebenszyklus ausführen. Die Registrierung sieht 55

62 2.5 Statische Codeanalyse folgendermaßen aus: < lifecycle > <phase - listener > ptp. filter. CSRFListener </ phase - listener > </ lifecycle > Der Listener selbst funktioniert dann folgendermaßen: public class CSRFListener implements PhaseListener { private static final long serialversionuid = L; // Wir erzeugen ein Pattern, welches dem der erzeugten StateView entspricht private static final Pattern VIEW_STATE_PARAMETER_PATTERN = Pattern. compile ( Pattern. quote ( UIViewRoot. UNIQUE_ID_PREFIX ) + "\\d+"); // Die Phase, in die wir eingreifen ist die Neuerzeugung der View, also dem Laden nach Absenden des public PhaseId getphaseid () { return PhaseId. RESTORE_VIEW ; public void beforephase ( PhaseEvent event ) { // Der aktuelle Context wird geladen FacesContext facescontext = event. getfacescontext (); ExternalContext externalcontext = facescontext. getexternalcontext (); // Der aktuelle ViewState wird in einen String gespeichert String viewstate = externalcontext. getrequestparametermap ().get ( ResponseStateManager. VIEW_STATE_PARAM ); // Der ViewState wird mit dem Pattern, wenn vorhanden verglichen if ( viewstate!= null ) { if (! VIEW_STATE_PARAMETER_PATTERN. matcher ( viewstate ). matches ()) { // Wenn das Pattern nicht stimmt, wird die aktuelle Seite gestoppt und versucht einen Fehler zu schicken facescontext. responsecomplete (); 56

63 2.5 Statische Codeanalyse HttpServletResponse response = ( HttpServletResponse ) externalcontext. getresponse (); try { response. senderror ( HttpServletResponse. SC_INTERNAL_SERVER_ERROR, " Bad view id pattern!"); } catch ( IOException e) { throw new FacesException ( e. getmessage (), e); } }}}} Lösungsansatz 3: Der leichteste Ansatz zur Sicherung gegen CSRF bei Verwendung einer alten JSF-Library ist die Anwendung von serverseitiger ViewState-Speicherung und Verschlüsselung dieser (mit ausreichend sicherem Algorithmus und genügend langem Schlüssel). OWASP empfiehlt diese Methode auf seinem Cheatsheet für ASP.NET [19] und da JSF mit JBoss einen sehr an den ViewState von ASP.NET angelehnten Ansatz mit sich bringt, lässt sich diese Methode auch gut in der JSF-Umgebung einsetzen. Im Fall der PTP liefert diese Möglichkeit die MyFaces Implementierung von JSF in der Version 1.1. Diese ermöglicht die Steuerung des ViewState-Parameters und frägt die verschlüsselten Werte intern bei Bedarf wieder ab. Konfiguriert werden diese Parameter in der web.xml und sehen bei der PTP folgendermaßen aus: <context - param > // Verschlüsselung aktivieren <param -name > org. apache. myfaces. USE_ENCRYPTION </ param -name > <param - value >true </ param - value > </ context - param > <context - param > // Verschlüsselungsalgorithmus <param -name > org. apache. myfaces. algorithm </ param -name > <param - value > Blowfish </ param - value > </ context - param > <context - param > 57

64 2.6 Konzeptionelle Schwachstellen // Gibt den Schlüssel an ( Base64 enkodiert ) um den geheimen Schlüssel für die Verschlüsselung zu initiieren <param -name > org. apache. myfaces. secret </ param -name > <param - value > aus Sicherheitsgründen entfernt </ param - value > </ context - param > <context - param > // Definiert, ob auf Server oder Client gespeichert wird <param -name > javax. faces. STATE_SAVING_METHOD </ param -name > <param - value > server </ param - value > </ context - param > 2.6 Konzeptionelle Schwachstellen Standardkonfiguration JBoss in der Standardkonfiguration zu betreiben, also ohne Admin-Passwort, mit ungeschützter JMX-Console, ungeschützter Web-Console oder ungeschützter Admin-Console ist nicht ungefährlich. In der Anwendung PTP bestand dieses konzeptionelle Problem nie, da der Admin hier von Beginn an aus Sicherheitsgründen alle nach außen verfügbaren Dienste mit einem Passwort versehen hat. CVE [31] Die Standardkonfiguration von JBoss 5 beschränkt nicht den Zugriff auf die Konsole und das Web Management Interface, was entfernten Angreifern erlaubt, die Authentifizierung zu umgehen und administrativen Zugriff durch direkte Anfragen zu erhalten. Da dies der bekannteste Fehler in der Konfiguration von JBoss ist, wird sogar in der Community ein Wiki angeboten, welches erklärt, wie man die Konfiguration anpasst. 58

65 2.6 Konzeptionelle Schwachstellen Diese Lücke gibt es in allen Versionen von JBoss 4 und JBoss 5 und wurde erst in JBoss 7 behoben. Die Quelle [17] zeigt sogar ein vorgefertigtes Metasploit Modul, um diese Lücke gezielt auszunutzen. Auch basieren einige Angriffsstrategien, wie sie im Abschnitt 3.5 Proof of Concept erläutert werden, auf dieser Schwachstelle Directory Listing Directory Listing sollte im Produktivsystem bei Anwendungsservern wie dem JBoss stets deaktiviert sein. Bei einer aktiven Verzeichnisbaumauflistung spricht man von einer Fehlkonfiguration im Bereich der Sicherheit [26]. Wenn Angreifer entdecken, dass sie Verzeichnisse auflisten können, können folgende Szenarien auftreten (Ausschnitt): Angreifer finden alle Dateien. Angreifer laden alle kompilierten Java Klassen herunter, um per Reverse Engineering an den Code zu kommen. Angreifer entdecken mit Leichtigkeit weitere Lücken in der Anwendung. Da die Auflistung von Verzeichnissen im Browser meist direkt zu der Navigation durch die gesamte Verzeichnisstruktur im Browser führt, besteht hier auch die sogenannte Path Traversal Lücke. Die Navigation durch die Applikation war im Fall der PTP aber nicht nur durch die Darstellung im Browser möglich, sondern auch durch direkte Pfadangaben in der Adresszeile (welches Vorwissen über die Applikation erfordert, aber leicht zu erraten ist, da standardmäßige Bezeichnungen für die Ordnerstruktur vergeben sind). In JBoss 5 ist Directory Listing standardmäßig aktiv, in JBoss 7 standardmäßig inaktiv. In beiden Applikationsservern lässt sich die Standardkonfiguration hierfür ändern. 59

66 2.6 Konzeptionelle Schwachstellen Path Traversal Das Ziel eines Path Traversal Angriffs ist es, Zugriff auf Dateien und Verzeichnisse zu erhalten, die außerhalb des Web Root Verzeichnisses liegen. Indem die Anwendung durchsucht wird, sucht der Angreifer nach absoluten Pfaden zu gespeicherten Dateien. Durch Manipulation der diese Dateien referenzierenden Variablen mit sogenannten dot-dot-slash (../) Abfolgen und Variationen, kann es ihm gelingen, willkürlich auf Dateien und Verzeichnisse, die auf dem Dateisystem gespeichert sind, zuzugreifen. Dies schließt Anwendungsquellcode, Konfigurationsdateien und Systemdateien ein, deren Zugriff vom System beschränkt wird. Der Angreifer nutzt hierbei../ Zeichenfolgen, um bis zum Rootverzeichnis zu gelangen. [20] Um diesen Zugriff zu verhindern, muss die Anwendung oder der Server überprüfen, ob der Nutzer für die angeforderte Seite genügend Rechte besitzt. Die Implementierung einer Lösungsmöglichkeit im Falle der PTP sieht folgendermaßen aus: Im Paket ptp.filter liegen hierfür 2 Klassen, die dafür sorgen, dass Personen ohne passende Rechte keinen Zugriff auf JSP (Java Server Page) Seiten bekommen. Benutzer, die Path Traversal ausnutzen, geben direkt in der Adresszeile ihres Browsers einen bekannten Pfad ein, der eine gültige JSP-Seite aufruft. Auf diese Weise würden die Nutzer die vorgegebenen Links der Applikation ignorieren und haben dadurch die Möglichkeit, unbefugte Seiten zu betrachten. Wenn ein Nutzer mit ungenügenden Rechten versucht, eine Seite zu öffnen, wird er auf eine Error 404 Seite umgeleitet. Die Module, welche für diese Filterung sorgen sind: AuthenticationFilterAdmin AuthenticationFilterSupervisor. Diese funktionieren folgendermaßen (am Beispiel der Adminseite): 60

67 2.6 Konzeptionelle public void dofilter ( ServletRequest req, ServletResponse resp, FilterChain chain ) throws IOException, ServletException { HttpServletRequest httpreq = ( HttpServletRequest ) req ; HttpSession session = httpreq. getsession (); String isrole = " null "; AuthUser user = PtpSession. getauthenticateduser ( session ); if ( user!= null ) { // User hat Rolle isrole isrole = user. getuserroles (). tostring (). trim (); } // User sollte die Rolle shouldrole zum Zugriff der Seite haben String shouldrole = "[" + UserRole. ADMINISTRATOR. tostring (). trim () + "]"; // Wenn die Rollen nicht gleich sind wird umgeleitet, sonst wird der nächste anstehende Filter abgearbeitet if (! isrole. equalsignorecase ( shouldrole )){ (( HttpServletResponse ) resp ). sendredirect ("/ ptp / view / error. jsf "); } else { chain. dofilter (req, resp ); } } Die Filter wurden folgendermaßen in der web.xml der PTP registriert (der Filter für den Admin im Beispiel): <filter > <filter - name > AuthenticationFilterAdmin </ filter - name > <filter - class > ptp. filter. AuthentifactionFilterAdmin </ filter - class > </ filter > <filter - mapping > <filter - name > AuthenticationFilterAdmin </ filter - name > <url - pattern >/ view / admin /* </url - pattern > </ filter - mapping > 61

68 Kapitel 3 Weitere Themen In diesem letzten Abschnitt werden einige weiterführende komplexe Themen angeschnitten, wie die binäre Analyse von Code und Penetration Testing. Auch wird auf Vorbeugung eingegangen, also woher die für die PTP Anwendung beauftragten Personen ihre Informationen über mögliche Lücken erhalten und wie häufig welche Patches installiert werden. 3.1 Binary Audit Nicht immer hat man beim Sicherheitsaudit den Quellcode zur Hand. Auch Drittsoftware kann Schwachstellen mit sich bringen, welche einen Angreifer unbefugte Aktionen am System ausführen lassen. Neben dem Test für Sicherheitslücken gibt es für Organisationen noch weitere Gründe, solche Tests durchzuführen, wie die Grafik 3.1 zeigt. 62

69 3.1 Binary Audit Abbildung 3.1: Gründe für Binary Security Audit [6, 663] Die Aufgaben, welche in den einzelnen Szenarios auszuführen sind, lassen sich folgendermaßen beschreiben [6, 663]: Detecting and neutralizing viruses and malware: Detect, analyze, or neutralize (clean) malware, viruses, spyware, and adware Testing cryptographic algorithms for weaknesses: Test the level of data security provided by a given cryptographic algorithm by analyzing it for weaknesses Testing digital rights management or license protection (antireversing): Protect software andmedia digital rights through application and testing of antireversing techniques Auditing the security of program binaries: Audit a programfor security vulnerabilitieswithout access to the source code by scanning instruction sequences for potential exploits Um auf den Code rückschließen zu können, müssen sogenannte Decompiling- und Disassembling-Techniken angewendet werden. 63

70 3.1 Binary Audit Disassembling muss angewandt werden, um menschenunlesbaren Maschinencode wieder in menschenlesbaren Maschinencode (den sogenannten Assembler) umzuwandeln (im Falle von Java z.b. mit javap). Decompiling dagegen rekonstruiert wieder den Quellcode (natürlich entsteht nur eine Interpretation). Ein solcher Decompiler für JAVA wäre z.b. Jad (dieser kann z.b. hier geladen werden, da die Entwicklerseite nicht mehr existiert) in Kombination mit der GUI FrontEnd Plus 3.2. Abbildung 3.2: Oberfläche FrontEnd Plus mit JAD [6, 671] Nach dem Decompiling können wieder statische Analysemechanismen angewandt werden, um die Security zu analysieren. OWASP empfiehlt zur binären Analyse die folgenden 2 Tools, die zusätzlich zu dem Disassembling und Decompiling Analysen auf bekannte Schwachstellen durchführen. Somit kombinieren sie die statische und dynamische Analyse. 1. Veracode [28] 64

71 3.2 Metasploit und Armitage 2. BugScam IDC Package [9]. 3.2 Metasploit und Armitage Viele Schwachstellen von Anwendungen, Betriebssystemen oder Servern sind bekannt. Häufig hilft nur ein Update auf die neueste verfügbare Version. Da aber auch einige Lücken erst spät geschlossen werden und viele Anwender bzw. Administratoren aus Zeitgründen nicht jede Anwendung sofort immer auf den neuesten Stand bringen, sind viele dieser Schwachstellen durch präparierte Exploits ausnutzbar. Das Schreiben von Exploits ist aufgrund der Komplexität der Aufgabe sehr zeitaufwendig. Da an dieser Stelle nicht ständig das Rad neu erfunden werden soll, gibt es heute Frameworks, die eben solche Exploits mit vielen zusätzlichen, nützlichen Funktionen zusammenfassen. Hierbei ist zu sagen, dass die Anwendung solcher Frameworks nicht nur den Angreifern vorbehalten ist, sondern gerade Programmierer diese nutzen können, um zu testen, ob ihre Anwendungen anfällig für solche bekannten Hebelmechanismen sind. Somit soll dies hier anhand von Metasploit (Exploit Framework) und Armitage (GUI für Metasploit) beispielhaft dargestellt werden. Dabei wird nur auf die grundlegende Funktionsweise der Anwendung eingegangen. Ein wirklich ernsthaftes Aushebeln der Sicherheitsmechanismen des Umfelds der PTP würde hierbei den Rahmen der Bachelorarbeit sprengen. Im Test wurde das Metasploit Framework Version 4.4 und Armitage verwendet (4.4 enthält Armitage, ab Version 4.5 hat Metasploit eine kostenpflichtige GUI). Wie in folgendem Screenshot 3.3 zu sehen ist, lautet die IP des anzugreifenden PC s Dies liegt daran, dass Armitage nicht localhost bzw direkt scannen kann und dafür eine alternative Adresse zur Verfügung gestellt werden musste. 65

72 3.2 Metasploit und Armitage Abbildung 3.3: Armitage, Screenshot aus Testumgebung Ein Angriff funktioniert mit folgenden einfachen Schritten: 1. Bei Add Hosts eingeben, wenn die anzugreifende Anwendung auf localhost installiert ist. Ist der anzugreifende PC nicht localhost, so kann mit nmap ein Scan in einem selbst definierbaren IP-Bereich durchgeführt werden. 2. Attacks ->Find Attacks auswählen 3. Angriff ausführen, indem man den anzugreifenden Host auswählt und den gewollten Angriff per Mausklick ausführt (rechte Maustaste, Attack auswählen). 4. Alternativ zu Schritt 3 kann man auch links in der Leiste einen Exploit auswählen und per Drag-And-Drop auf den anzugreifenden PC ziehen. Im Falle von JBoss Exploits wäre dies unter Exploit->Multi->Http->JBoss ->... 66