Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet
Werbung
Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Konfiguration und Tests Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 (0) 1888 9582 0 E-Mail: [email protected] Internet: http://www.bsi.bund.de © Bundesamt für Sicherheit in der Informationstechnik 2006 Bundesamt für Sicherheit in der Informationstechnik Seite 2 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Inhaltsverzeichnis Inhaltsverzeichnis 1. EINLEITUNG........................................................................................................... 9 2. INSTALLATION DER DEBIAN 3.1 SARGE BASISPLATTFORM........................ 11 2.1 Vorbereitung einer virtuellen Maschine....................................................................................................... 12 2.2 Installation von Debian 3.1 Sarge in der virtuellen Maschine....................................................................23 2.3 Installation der zu testenden Anwendungen................................................................................................ 28 2.4 Replikation von virtuellen Maschinen.......................................................................................................... 29 3. INSTALLATION DER SOFTWAREKOMPONENTEN.......................................... 31 3.1 Java Software Design Kit (SDK, Version 1.5.0_05).....................................................................................32 3.2 Apache Webserver (Version 2.0.54).............................................................................................................. 33 3.3 Jakarta Tomcat Servlet Container (Version 5.5.9)......................................................................................35 3.4 Jakarta Tomcat Connector Modul mod_jk (Version 1.2.14)..................................................................... 39 3.4.1 Apache-Konfigurationsdatei httpd.conf.................................................................................................... 40 3.4.2 Tomcat Konfigurationsdatei server.xml.................................................................................................... 41 3.4.3 Apache-Konfigurationsdatei workers.properties.......................................................................................43 3.5 Installation des MySQL-Connectors/J..........................................................................................................45 3.6 Installationen für die JNDI-Konnektivität................................................................................................... 46 3.7 Installation der Logging-Komponenten........................................................................................................46 3.8 Einrichtung des lokalen DNS-Servers...........................................................................................................47 3.9 Werkzeuge für Penetrationstests...................................................................................................................51 3.9.1 SPIKE........................................................................................................................................................ 51 3.9.2 Benutzung von SPIKE...............................................................................................................................51 3.9.3 Ethereal...................................................................................................................................................... 54 3.9.4 OpenSSL....................................................................................................................................................54 3.10 Werkzeuge für statische Tests..................................................................................................................... 55 3.10.1 Flawfinder und Splint für C.....................................................................................................................55 3.10.2 Findbugs für Java.....................................................................................................................................57 3.10.3 Java-Dokumentation................................................................................................................................ 60 Seite 3 (von 187) Bundesamt für Sicherheit in der Informationstechnik Inhaltsverzeichnis Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 4. EINRICHTUNG DER AUTHENTISIERUNGSINFORMATIONEN..........................61 4.1 Einrichtung von Test-Benutzerkonten auf Betriebssystemebene...............................................................61 4.2 Einrichtung von Test-Benutzerkonten für die Web-Authentisierung....................................................... 61 4.3 Initialisierung der tomcat_users.xml Datei.................................................................................................. 62 4.4 Initialisierung der MySQL-Datenbank mit den Authentisierungsinformationen....................................63 4.5 Initialisierung der LDAP-Datenbank mit den Authentisierungsinformationen.......................................64 4.6 Konfiguration des LDAP-Browsers gq......................................................................................................... 68 4.7 Erzeugung einer CA und Generierung von SSL-Server- und Client-Zertifikaten.................................. 71 4.7.1 Installation einer Certification Authority (CA)......................................................................................... 71 4.7.2 Erzeugung eines SSL Server-Zertifikats (Tomcat)................................................................................... 73 4.7.3 Erzeugung eines SSL Server-Zertifikats (Apache)................................................................................... 76 4.7.4 Erzeugung von Client-Zertifikaten............................................................................................................78 5. DURCHFÜHRUNG DER TESTS........................................................................... 84 5.1 Funktionale Tests der Sicherheitsfunktionen von Tomcat......................................................................... 84 5.1.1 Funktionale Tests für die Authentisierung................................................................................................ 84 5.1.1.1 Ergebnisse zu Test1............................................................................................................................86 5.1.1.1.1 T1: HTTP Connector, BASIC-Authentisierung, Memory Realm.............................................. 87 5.1.1.1.2 T2: HTTP Connector, BASIC-Authentisierung, JDBC Realm.................................................. 88 5.1.1.1.3 T3: HTTP Connector, BASIC-Authentisierung, JNDI Realm................................................... 88 5.1.1.1.4 T4: HTTP Connector, DIGEST-Authentisierung, Memory Realm............................................89 5.1.1.1.5 T5.1: HTTP Connector, FORM-Authentisierung, Memory Realm........................................... 89 5.1.1.1.6 T5.2: HTTP Connector, FORM-Authentisierung, JDBC Realm............................................... 90 5.1.1.1.7 T5.3: HTTP Connector, FORM-Authentisierung, JNDI Realm................................................ 91 5.1.1.1.8 T6: HTTPS Connector, Client Zertifikat Authentisierung, Memory Realm.............................. 91 5.1.1.1.9 T7: AJP1.3 Connector, BASIC-Authentisierung, Memory Realm............................................ 92 5.1.1.1.10 T8: AJP1.3 Connector, DIGEST-Authentisierung, Memory Realm........................................92 5.1.1.1.11 T9: AJP1.3 Connector, FORM-Authentisierung, Memory Realm...........................................93 5.1.1.1.12 T10: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory Realm................ 93 5.1.1.2 Ergebnisse zu Test2............................................................................................................................93 5.1.1.2.1 T11: HTTP Connector, BASIC-Authentisierung, Memory Realm............................................ 93 5.1.1.2.2 T12: HTTP Connector, DIGEST-Authentisierung, Memory Realm..........................................94 5.1.1.2.3 T13.1: HTTP Connector, FORM-Authentisierung, Memory Realm......................................... 94 5.1.1.2.4 T13.2: HTTP Connector, gemischte BASIC- und FORM-Authentisierung, Memory Realm... 96 5.1.1.2.5 T14: HTTPS Connector, Client Zertifikat Authentisierung, Memory Realm............................ 97 5.1.1.2.6 T15: AJP1.3 Connector, BASIC-Authentisierung, Memory Realm........................................ 100 5.1.1.2.7 T16: AJP1.3 Connector, DIGEST-Authentisierung, Memory Realm......................................100 5.1.1.2.8 T17.1: AJP1.3 Connector, FORM-Authentisierung, Memory Realm......................................100 5.1.1.2.9 T17.2: AJP Connector, gemischte BASIC- und FORM-Authentisierung, Memory Realm.... 100 5.1.1.2.10 T18: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory Realm.............. 100 5.1.1.3 Ergebnisse zu Test3..........................................................................................................................101 5.1.1.3.1 T19.1: HTTP Connector, BASIC-Authentisierung, Memory Realm....................................... 101 5.1.1.3.2 T19.2: HTTP Connector, BASIC-Authentisierung, JDBC Realm...........................................101 5.1.1.3.3 T19.3: HTTP Connector, BASIC-Authentisierung, JNDI Realm............................................ 102 Bundesamt für Sicherheit in der Informationstechnik Seite 4 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Inhaltsverzeichnis 5.1.1.3.4 T20: HTTP Connector, DIGEST-Authentisierung, Memory Realm........................................102 5.1.1.3.5 T21: HTTP Connector, FORM-Authentisierung, Memory Realm.......................................... 102 5.1.1.3.6 T22: HTTPS Connector, Client Zertifikat Authentisierung, Memory Realm.......................... 103 5.1.1.3.7 T23.1: AJP1.3 Connector, BASIC-Authentisierung, Memory Realm..................................... 103 5.1.1.3.8 T23.2: AJP1.3 Connector, BASIC-Authentisierung, JDBC Realm......................................... 104 5.1.1.3.9 T23.3: AJP1.3 Connector, BASIC-Authentisierung, JNDI Realm.......................................... 104 5.1.1.3.10 T24: AJP1.3 Connector, DIGEST-Authentisierung, Memory Realm....................................104 5.1.1.3.11 T25: AJP1.3 Connector, FORM-Authentisierung, Memory Realm.......................................105 5.1.1.3.12 T26: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory Realm.............. 105 5.1.2 Funktionale Tests für die Zugriffskontrolle ........................................................................................... 106 5.1.2.1 Tests der Zugriffsrechte auf dem Niveau der Java Virtual Machine............................................... 106 5.1.2.1.1 T27 Tomcat beenden................................................................................................................ 107 5.1.2.1.2 T28 neuen Prozess starten.........................................................................................................108 5.1.2.1.3 T29 Netzwerk-Socket öffnen und Daten übertragen................................................................109 5.1.2.1.4 T30.1 Lesen innerhalb des Bereichs der Web-Anwendung..................................................... 109 5.1.2.1.5 T30.2 Schreiben innerhalb des Bereichs der Web-Anwendung...............................................110 5.1.2.1.6 T30.3 Löschen innerhalb des Bereichs der Web-Anwendung................................................. 111 5.1.2.1.7 T30.4 Ausführen innerhalb des Bereichs der Web-Anwendung..............................................112 5.1.2.1.8 T31 Lesen / Schreiben / Löschen / Ausführen außerhalb der Web-Anwendung.....................112 5.1.2.1.9 T32 Zugriff auf Tomcat-eigene Komponenten.........................................................................113 5.1.2.2 Tests der Zugriffsrechte auf dem Niveau von Webanwendungen...................................................114 5.1.2.2.1 T33.1 HTTP Connector, Zugriff auf eine geschützte JSP-Seite...............................................115 5.1.2.2.2 T33.2 AJP13 Connector, Zugriff auf eine geschützte JSP-Seite..............................................116 5.1.2.2.3 T34.1 HTTP Connector, Zugriff auf ein geschütztes Verzeichnis .......................................... 116 5.1.2.2.4 T34.2 AJP13 Connector, Zugriff auf ein geschütztes Verzeichnis ......................................... 116 5.1.2.2.5 T35 Schutz einzelner HTTP-Methoden vor anonymen Zugriffen........................................... 116 5.1.2.3 Tests der Zugriffsrechte auf dem Niveau von Valves......................................................................119 5.1.2.3.1 T36.1 HTTP Connector, verbotene Anfragen mit IP-Adresse des Clients.............................. 121 5.1.2.3.2 T36.2 AJP13 Connector, verbotene Anfragen mit IP-Adresse des Clients..............................121 5.1.2.3.3 T37 Erlaubte Anfragen mit IP-Adresse des Clients................................................................. 122 5.1.2.3.4 T37.1 HTTP Connector, erlaubte Anfragen mit IP-Adresse des Clients................................. 122 5.1.2.3.5 T37.2 AJP13 Connector, erlaubte Anfragen mit IP-Adresse des Clients.................................123 5.1.2.3.6 T38 / T 39 HTTP bzw. AJP13 Connector, verbotene / erlaubte Anfragen mit Hostname des Clients...................................................................................................................................................... 123 5.1.2.4 Protokollierung.................................................................................................................................127 5.1.2.4.1 T40 Kontrolle der Log-Datei für eine <Logger>-Komponente............................................... 128 5.1.2.4.2 T41 Protokollierung mit Access Log Valve............................................................................. 129 5.1.2.5 Zuverlässigkeit der Dienstleistung................................................................................................... 129 5.1.2.5.1 T42 Failover beim Ausfall einer Tomcat-Instanz.....................................................................130 5.1.2.5.2 T43 Persistente Sessions beim Herunterfahren........................................................................ 131 5.1.2.6 Verschlüsselung............................................................................................................................... 132 5.1.2.6.1 T44 SSL mit Null-Cipher......................................................................................................... 132 5.1.2.6.2 T45 SSL mit schwacher Verschlüsselung................................................................................ 133 5.1.2.6.3 T46 SSLv2, SSLv3 oder TLS...................................................................................................133 5.1.2.7 Datenschutz...................................................................................................................................... 136 5.1.2.7.1 T47 / T48 Datenschutz-bezogene Analyse der Ergebnisse aus Tests T40 und T41................ 136 5.1.2.8 Minimale Rechtevergabe..................................................................................................................137 5.1.2.8.1 T49 Ausführung von Tomcat als nicht-privilegierter Benutzer............................................... 138 5.2 Penetrationstests - Vorgehensweise.............................................................................................................138 5.2.1 Angriffsszenarien.....................................................................................................................................138 5.2.2 Beispielanwendungen.............................................................................................................................. 139 Seite 5 (von 187) Bundesamt für Sicherheit in der Informationstechnik Inhaltsverzeichnis Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 5.3 HTTP-Connector: Angriffe von einem HTTP-Client............................................................................... 140 5.4 AJP-Connector ohne SSL-Client-Authentisierung....................................................................................141 5.4.1 Angriffe eines maliziösen HTTP-Clients................................................................................................ 141 5.4.1.1 Vorgehensweise............................................................................................................................... 141 5.4.1.2 Bewertungskriterien......................................................................................................................... 143 5.4.1.3 Ergebnis............................................................................................................................................143 5.4.2 Angriffe einer maliziösen Web-Anwendung...........................................................................................148 5.4.2.1 Vorgehensweise............................................................................................................................... 148 5.4.2.2 Bewertungskriterien......................................................................................................................... 151 5.4.2.3 Ergebnis............................................................................................................................................152 5.5 AJP Connector mit SSL Client Authentisierung....................................................................................... 152 5.5.1 Funktionsweise des Systems....................................................................................................................153 5.5.2 Angriffe....................................................................................................................................................158 5.5.2.1 Testfälle............................................................................................................................................ 158 5.5.2.2 Vorgehensweise............................................................................................................................... 159 5.5.2.3 Bewertungskriterien......................................................................................................................... 160 5.5.2.4 Ergebnis............................................................................................................................................161 5.6 Quellcode-Analysen.......................................................................................................................................163 5.6.1 Automatische Überprüfung des Quellcodes............................................................................................ 163 5.6.2 Manuelle Überprüfung des Quellcodes................................................................................................... 164 5.6.3 Umfang der Quellcode-Analyse.............................................................................................................. 167 5.6.3.1.1 T91/T94 Automatische und manuelle Prüfung des Quellcode.................................................168 5.6.3.1.2 T92 Manuelle Sichtung der Schnittstelle zu JSSE (SSL).........................................................172 5.6.3.1.3 T93 Manuelle Sichtung der Authentisierungsmethoden.......................................................... 173 6. EMPFEHLUNGEN UND MASSNAHMEN........................................................... 176 6.1 Allgemeine Maßnahmen bzw. Maßnahmen auf Betriebssystemebene....................................................176 6.1.1 Dateiberechtigungen und -zuordnung..................................................................................................... 176 6.1.2 Passworte für die Benutzer / Webanwendung.........................................................................................177 6.1.3 Passwort des JAVA Zertifikatspeichers.................................................................................................. 177 6.1.4 Host-basierte Firewall (netfilter / iptables)..............................................................................................178 6.1.5 Gesicherte Kommunikation..................................................................................................................... 178 6.1.6 Eingeschränkte Laufzeitumgebung (chroot)........................................................................................... 179 6.1.7 Nutzung von erweiterten Zugriffsschutzmechanismen unter SELinux...................................................179 6.2 Maßnahmen beim Apache Webserver.......................................................................................................179 6.2.1 Zugriffsberechtigungen........................................................................................................................... 180 6.2.2 Watchdog-Funktionalität......................................................................................................................... 180 6.3 Maßnahmen beim Jakarta Tomcat Servlet Container............................................................................. 180 6.3.1 Installation unter einem Tomcat Benutzer...............................................................................................180 6.3.2 Shutdown-Port......................................................................................................................................... 181 6.3.3 Logging....................................................................................................................................................181 6.3.4 Manager und Admin Webanwendungen................................................................................................. 182 6.3.5 Zugriffsbeschränkungen.......................................................................................................................... 183 6.3.6 Tests der Konfiguration........................................................................................................................... 183 6.3.7 Verschlüsselte Verbindung (SSL)........................................................................................................... 184 6.3.8 Anbindung einer Datenbank per JDBC...................................................................................................185 Bundesamt für Sicherheit in der Informationstechnik Seite 6 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Inhaltsverzeichnis 6.3.9 Anbindung einer Datenbank per JNDI.................................................................................................... 185 6.3.10 Single-Sign-On...................................................................................................................................... 185 7. WEITERE PUNKTE / BUGS / VERBESSERUNGSMÖGLICHKEITEN.............. 186 8. ABKÜRZUNGEN................................................................................................. 187 9. WICHTIGE SHELL-VARIABLEN, VERZEICHNISSE UND DATEIEN................ 188 10. REFERENZEN................................................................................................... 189 10.1 Web-Referenzen (Stand 30.11.2005)......................................................................................................... 189 Seite 7 (von 187) Bundesamt für Sicherheit in der Informationstechnik Inhaltsverzeichnis Bundesamt für Sicherheit in der Informationstechnik Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Seite 8 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einleitung 1. Einleitung Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat eine Sicherheits­ untersuchung des Open Source Jakarta Tomcat durchführen lassen. Diese Untersuchung teilt sich in mehrere Projektphasen auf. Dieses Dokument beschreibt die durchgeführten Tests und Analysen sowie die Installation des dazugehörigen Testsystems. Die durchzuführenden Tests wurden in einer früheren Projektphase im Dokument „Feinkonzept zur Sicherheitsuntersuchung des Apache Tomcat Servlet Containers“ fest­ gelegt. Dieses frühere Dokument wird im weiteren unter [Tomcat Fein.] referiert. Es ist für das Verständnis des jetzigen Dokuments nicht erforderlich, da die Beschreibung der Testfälle 1:1 übernommen wurde, aber dennoch eine empfehlenswerte Lektüre. Der Umfang des Dokuments liegt begründet in dem Streben nach: 1. Nachvollziehbarkeit und Reproduzierbarkeit der Testergebnisse und 2. Rückverfolgbarkeit der Testergebnisse zu den Testbeschreibungen des Feinkonzepts. Dieses Dokument stellt im ersten Schritt die Vorgehensweise bei der VMware-basierten Installation eines Debian 3.1 Sarge Linux Betriebssystems (basierend auf der Debian 3.1 Linuxtag 2005 Edition Installations-DVD) zum Zweck der Sicherheitsuntersuchung von Tomcat zusammen. Im zweiten Schritt wird die Installation und Konfiguration • des Webservers Apache (Version 2.0.54) • des Servlet-Containers1 Tomcat (Version 5.5.9) • des Connectors mod_jk (Version 1.2.14.1) sowie die Durchführung der damit durchgeführten und [Tomcat Fein.] zusammengestellten Tests beschrieben. Abschließend werden Empfehlungen für die sichere Konfiguration zum Betrieb von Tomcat gegeben. In diesem Dokument verwendete Notation Dieses Dokument verwendet die folgende Regeln zur Darstellung und Hervorhebung: • 1 Hinweis: die Zeichenvorlage Hinweis kommt am Anfang von Absätzen zum Einsatz, die als ganzes hervorzuheben sind. Der optische Effekt bleibt somit minimal. Ein Servlet Container dient als Laufzeitumgebung für Java Servlets [Sun Servlets] bzw. Java Server Pages [Sun JSP]. Der Container ist die Schnittstelle zwischen den Webserver und den Servlets, die sich in dem Container befinden. Der Container lädt, initialisiert und führt die Servlets aus. Der Container ordnet einer ankommenden Anfrage einem Servlet zu und leitet diese Anfrage an das Servlet weiter. Das Servlet bearbeitet die Anfrage, ggf. unter Einbeziehung weiterer Hintergrundapplikationen, und erzeugt eine Antwort. Der Container leitet diese Antwort an den Webserver weiter, der sie dann an den Web-Client (z. B. Browser) übermittelt. Seite 9 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einleitung Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • Dateinamen, Konfigurationsvariablen, Kommandos, Programm-generierte Ausgaben im Fließtext werden in der Zeichenvorlage Code dargestellt (in der Praxis oft als Fixed-Width Font [z. B. Courier], hier Kursiv)2 • Listing 1: Als Überschrift oder zur Namensgebung für längere Abschnitte aus Scripts bzw. Konfigurationsdateien. Tabellen und Abbildungen werden dagegen unterhalb der Tabelle bzw. Abbildung beschriftet. Für ganze Scripts wird die Absatzvorlage Code eingesetzt (auch möglichst als Fixed-Width Font, z. B. Courier). Die kleinerere Schriftgröße wird zur Vermeidung von automatischen Zeilenumbrüchen bei den z. T. sehr langen Zeilen verwendet. • Zwischenüberschriften werden durch Fettdruck und vertikalen Abstand vom umgebenden Text getrennt, aber im Gegensatz zu Überschriften nicht nummeriert. • Literaturverweise auf das Literaturverzeichnis in Abschnitt 10 am Ende des Dokuments werden in eckigen Klammern angegeben, z. B. als [Tomcat Fein.]. Davor befindet sich in Abschnitt 8 ein Abkürzungsverzeichnis. • URLs auf Webseiten im Internet werden in der Fußnoten angegeben. Der Fließtext bleibt lesbar. • Lange Datei- bzw. Verzeichnisnamen werden teilweise in Fußnoten verlegt, wobei der Fließtext eine eindeutige Kurzform enthält – meist ohne Verzeichnis. Gegen Ende dieses Dokuments findet der Leser eine Zusammenstellung einiger stets wiederkehrender Shellvariablen, Dateinamen und dazugehörige Verzeichnisse. • URLs auf Webseiten / -Applikationen innerhalb der Testumgebung werden mit der Zeichenvorlage URL Intern formatiert. Diese sind nur bei aufgebauter Testumgebung nutzbar. Hinweis: derzeit werden die Formatvorlagen Code / URL Intern farbig hinterlegt, um die Stellen des Auftretens entsprechenden Textes leicht zu identifizieren, bis sich ein möglichst vielen Lesern gefälliges Format herauskristallisiert. 2 Treten derartige Texte in Fußnoten auf, so wird die Zeichenvorlage Fußnote_Code verwendet. Bundesamt für Sicherheit in der Informationstechnik Seite 10 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Debian 3.1 Sarge Basisplattform 2. Installation der Debian 3.1 Sarge Basisplattform Um eine flexible Testumgebung zu erhalten, werden sämtliche Installationen in virtuellen Maschinen vorgenommen. Zur Schaffung einer einheitlichen Arbeitsplattform wird zunächst ein Prototyp der virtuellen Maschine erstellt, der dann bei Bedarf repliziert werden kann. Zum Einsatz kommt ein VMware GSX Server3 Version 3.1.0 Build 9089 auf einer Novell-SuSE4 Professional Linux 9.3 Host-Plattform (Rechner bigmama) zur Realisierung der virtuellen Maschinen, die selbst auf dem Debian5 3.1 Sarge Linux Betriebssystem aufsetzen. Eine Übersicht über das gesamte Testsystem gibt die folgende Abbildung: W e b b r o w s e r 1 9 b 2 . i 1 g 6 m 8 . 1 a 1 m 8 . 1 a / 2 6 ( V M w a r e H o s t ) D o m a i n : e x t e r n a l . d e v i r t u e l l e r R o u t e r D o m a i n : b s i t o m c a t . d e F I n i r t e e r w n a e l t l / t e m p l 1 a 9 t 2 e . 1 6 8 . 1 1 8 . 1 0 0 / 2 6 t o m c a t 1 h 9 2 o . 1 s 6 t 8 . 1 1 8 . 1 0 1 / 2 6 ( v i r t u e l l e M ( v a i s r t c u h e i n l l e e ) M a s c h i n e ) W e b b r o w s e r T o m c a t , A p a c h e D N M S y , S L Q D L A P , ( + B a s i s i n s t a l l a t i o n ) W e b b r o w s e r Abbildung 2.1: Architektur des Testsystems Das VMware-Hostsystem (bigmama) beherbergt die virtuellen Maschinen. Das Aufsetzen der virtuellen Maschine template wird im folgenden Abschnitt beschrieben. Sie dient als Referenzplattform und Ausgangspunkt zur Erzeugung weiterer virtueller Maschinen durch 3 4 5 http://www.vmware.com http://www.novell.com/de-de/products/linuxprofessional/ http://www.debian.org Seite 11 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Debian 3.1 Sarge Basisplattform Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Replikation. Die Konfigurationen und Tests werden anschließend auf der so erzeugten Systemkopie tomcathost durchgeführt. 2.1 Vorbereitung einer virtuellen Maschine Nach dem Login auf dem VMware Server (bigmama) wird die VMware Virtual Console in einem Konsolenfenster mit dem Kommando vmware geöffnet. Abbildung 2.2: VMware Virtual Machine Console Um später eine Textkonsolenumschaltung der in den virtuellen Maschinen laufenden LinuxSystemen zu ermöglichen (per Ctrl-Alt-Fn)6, wird der VMware Hot-Key von Ctrl-Alt auf ShiftCtrl-Alt umgestellt (Menü Edit → Preferences, Reiter Hot-Keys) und VMware anschließend beendet und neu gestartet. 6 Fn entspricht einer der Funktionstasten F1 ... F6 auf der Tastatur, über Ctrl-Alt-F7 wird auf die grafische X Window Benutzeroberfläche umgeschaltet. Bundesamt für Sicherheit in der Informationstechnik Seite 12 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Debian 3.1 Sarge Basisplattform Abbildung 2.3.: Änderung des VMware Hot-Keys Über den Eintrag „New Virtual Machine“ wird zunächst eine Debian 3.1 Sarge Basisplattform erzeugt, die durch Replikation wieder verwendet werden kann. Die Schritte zur Einrichtung der virtuellen Maschine sind wie folgt: Es soll eine anwendungsspezifische Konfiguration der virtuellen Maschine erfolgen (Abbildung 2.4). Seite 13 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Debian 3.1 Sarge Basisplattform Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 2.4.: Auswahl des Konfigurationstyps: Custom Es erfolgt die Festlegung des zu installierenden Betriebssystems (Abbildung 2.5). Bei der Debian 3.1. Sarge Installation soll ein Kernel der 2.6.x Serie verwendet werden. Abbildung 2.5.: Auswahl des Gast-Betriebssystems innerhalb der virtuellen Maschine Die Pfade für die Ablage der VMware Dateien der virtuellen Maschine werden in dem in Abbildung 2.6 dargestellten Fenster definiert. Bundesamt für Sicherheit in der Informationstechnik Seite 14 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Debian 3.1 Sarge Basisplattform Abbildung 2.6.: Name und Pfade der Dateien der virtuellen Maschine Die neu erstellte virtuelle Maschine wird für den Zugriff durch mehrere Benutzer (auf der VMware Host-Plattform) freigegeben (Abbildung 2.7). Abbildung 2.7.: Zugriffsberechtigungen zur virtuellen Maschine Seite 15 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Debian 3.1 Sarge Basisplattform Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Die virtuelle Maschine soll beim Hochfahren der VMware Host-Plattform nicht automatisch gestartet und beim Herunterfahren automatisch angehalten werden (Abbildung 2.8). Abbildung 2.8.: Start- und Shutdown-Optionen Die virtuelle Maschine wird mit einem Speicher von 256 MB konfiguriert (Abbildung 2.9). Bundesamt für Sicherheit in der Informationstechnik Seite 16 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Debian 3.1 Sarge Basisplattform Abbildung 2.9.: Speicherkonfiguration der virtuellen Maschine Um die virtuellen Maschinen (zur Nachbildung eines Multi-Host-Szenarios) untereinander vernetzen zu können und ggf. externe Internet-Zugriffe über den VMware-Host als Router durchführen zu können, wird das Netzwerk im NAT-Modus (Network Address Translation) konfiguriert (Abbildung 2.10). Abbildung 2.10.: Netzwerkkonfiguration der virtuellen Maschine Seite 17 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Debian 3.1 Sarge Basisplattform Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 2.11.: Art des I/O-Adapters der virtuellen Maschine Die virtuelle Maschine soll eine SCSI-Festplatte mit einer Größe von 1,5 GB zur Aufnahme des Betriebssystems und der Nutzerdaten simulieren (Abbildung 2.11 ... Abbildung 2.14). Bundesamt für Sicherheit in der Informationstechnik Seite 18 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Debian 3.1 Sarge Basisplattform Abbildung 2.12.: Einrichtungsoptionen für die simulierte Festplatte Abbildung 2.13.: Art der Festplatte der simulierten virtuellen Maschine Seite 19 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Debian 3.1 Sarge Basisplattform Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 2.14.: Größe der simulierten Festplatte Bundesamt für Sicherheit in der Informationstechnik Seite 20 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Debian 3.1 Sarge Basisplattform Abbildung 2.15.: VMware Konsolenfenster für die neu eingerichtete virtuelle Maschine Nachfolgend werden ggf. noch weitere Parameter der virtuellen Maschine spezifiziert, falls die Standardeinstellungen der VMware-Umgebung für den geplanten Einsatz nicht geeignet sind. Es handelt sich dabei um Einstellungen • zum DVD-Laufwerk (hier ist bei der in der VMware-Umgebung vorhandenen Hardware der Eintrag „legacy emulation“ zu aktivieren) • zum Floppy-Disk-Laufwerk • zur Netzwerkkarte Sobald diese Einstellungen angepasst sind, kann die neu erstellte virtuelle Maschine zum ersten Mal gebootet werden, um die Installation von Debian 3.1 Sarge von DVD aus vorzunehmen. 2.2 Installation von Debian 3.1 Sarge in der virtuellen Maschine Die nachfolgende Zusammenstellung der Installationsschritte eines Debian 3.1 Sarge Linux kann – unabhängig von den zuvor beschriebenen VMware Einstellungen – verwendet werden, um eine paketreduzierte Installationsplattform für den Einsatz des Tomcat Servlet Containers zu schaffen. Die Installation beginnt wie üblich mit dem Booten der virtuellen Maschine (bzw. des Rechners, auf dem diese Plattform installiert werden soll) vom Debian 3.1 Sarge Installationsmedium. Seite 21 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Debian 3.1 Sarge Basisplattform Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Zur Installation des Kernels 2.6.x wird beim ersten Debian Bootprompt der Parameter • linux26 verwendet. Weitere Parameter bei der Installation: • Sprache: Deutsch • Land oder Gebiet: Deutschland • Tastaturlayout: Deutsch • Rechnername: debian-template • Domänenname: tomcattest • Partitionierung der virtuellen Festplatte SCSI1 (0,0,0) (sda) – 1.6 GB: • Partition 1: primary, 1.35 GB, Mountpoint /, Filesystem ext3 • Partition 2: primary, 255 MB, swap Es erfolgt die Installation des Debian Grundsystems. • Installation des GRUB-Bootloaders im Master Boot Record der virtuellen Maschine Entnahme der Installations-DVD und Reboot der neu installierten virtuellen Maschine. Konfiguration des Debian-Grundsystems 7 • Hardware-Uhr auf GMT eingestellt: nein • Zeitzone: Europa/Berlin • Root-Passwort: vmware • Anlegen eines Benutzerkontos: Selektion abbrechen ausführen • apt konfigurieren (dazu die Debian 3.1 Sarge Installations-DVD wieder ins Laufwerk einlegen, nach dem Einlesen der DVD erfolgt die folgende Abfrage): • Zugriffsmethode für apt auf das Paketarchiv: cdrom • Weitere Installations-CDs: nein • Weitere apt-Quellen hinzufügen: nein • Nutzung der Sicherheitsupdates von security.debian.org7: ja (zur Installation der seit der Fertigstellung der Installations-DVD hinzugekommenen Sicherheits­ updates des Betriebssystems) http://security.debian.org Bundesamt für Sicherheit in der Informationstechnik Seite 22 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • Pakete auswählen und installieren: • Manuelle Auswahl • • Installation der Debian 3.1 Sarge Basisplattform hier wird zunächst die Standardvorgabe an Paketen (keine Modifikation der Paketliste) nachinstalliert, bevor in einem späteren Schritt noch Anwenderspezifizierte Pakete ergänzt werden Konfiguration vor der Installation • SSH: nur SSH Protokoll Version 2 erlauben • ssh-keysign: mit SUID Bit installieren • sshd Server: starten Anschließend werden zunächst die Standardpakete nachinstalliert (von der InstallationsDVD, oder, falls für diese Pakete bereits Security Updates vorhanden sind, direkt von der Debian Security Webseite). Nach Abschluss dieses Installationsschrittes sind 314 MB auf der Festplatte belegt. • Im nächsten Schritt wird die Konfiguration des Grundsystems abgeschlossen und es erfolgt ein root-Login im Grundsystem • Mit dem Installationswerkzeug aptitude werden nun noch weitere benötigte Pakete nachinstalliert (Editoren, Webbrowser, minimale X-Window Umgebung, Netzwerk­ diagnose). Dazu werden die unten genannten Pakete manuell selektiert. Pakete, von denen die selektierten abhängen, werden dabei automatisch mit installiert: • Kategorie nicht installierte Pakete: • • in Kategorie devel – main: • ant • ant-doc • autoconf • cvs in Kategorie doc – main: • • bind9-doc in Kategorie editors – main: • emacs21 • vim-full Seite 23 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Debian 3.1 Sarge Basisplattform • in Kategorie libdevel – main: • • • • • libssl-dev (zur Übersetzung von mod_ssl für Apache) in Kategorie misc – main: • mysql-client (zum Test der JDBC-basierten Authentisierung) • mysql-server (zum Test der JDBC-basierten Authentisierung) in Kategorie net – main: • bind9 (zum Aufsetzen eines lokalen DNS-Servers) • gq (LDAP Browser) • ldap-utils (zum Test der LDAP-basierten Authentisierung) • slapd (zum Test der LDAP-basierten Authentisierung) • rsync • tcpdump in Kategorie utils – main: • bzip2 • openssl in Kategorie web – main: • • Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers mozilla-firefox in Kategorie x11 – main: • desktop-base iceconf • icepref • icewm • x-window-system (In einer reinen Server-Umgebung ohne grafische Benutzeroberfläche kann bei der Installation auf die Pakete der beiden letzten Kategorien web bzw. x11 verzichtet werden) Die Abfragen zur Konfiguration werden wie folgt beantwortet: • CVS Repository-Wurzelverzeichnis: /var/lib/cvs Bundesamt für Sicherheit in der Informationstechnik Seite 24 (von 187) Installation der Debian 3.1 Sarge Basisplattform Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • CVS Repository: anlegen • CVS-pserver starten: nein • libpango - entrust font management to defoma: ja • x-ttcidfont-conf TrueType font handling backend: freetype • Konfiguration von slapd (wird zum Test LDAP-basierter Authentisierung benötigt) • • • Domänenname: bsitomcat.tsi-itcsec.de • Organisationsname: BSI-Tomcat TSI ITC-Security • Admin-Passwort: vmware • LDAPv2 Protokoll erlauben: nein Konfiguration von xserver-xfree86 (diese Schritte würden in einer reinen ServerUmgebung ohne grafische Benutzeroberfläche entfallen) • Grafikkarte automatisch erkennen: ja • Kernel-Framebuffer Schnittstelle verwenden: ja • XKB-Regelsatz: xfree86 • Tastaturoptionen: - keine - • Maus automatisch erkennen: ja • Mausanschluss: /dev/input/mice • Monitor automatisch erkennen: ja • LCD-Monitor: ja • Monitor-Konfiguration: medium • Monitor-Auflösung: 1024x768, 60 Hz • verwendete Video-Modi: 1024x768, 800x600, 640x480 • Farbtiefe: 16 bit8 Konfiguration von xprint-common • 8 Standard Druckerauflösung (dpi): 600 Die ursprünglich hier vorgegebenen 24 bit Farbtiefe müssen entsprechend den Einstellungen der Farbtiefe auf dem VMware-Hostrechner angepasst werden. Daher wurde der Parameter „DefaultDepth“ in der Datei /etc/X11/XF86config4 von ursprünglich 24 auf 16 bit geändert. Seite 25 (von 187) Bundesamt für Sicherheit in der Informationstechnik Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Debian 3.1 Sarge Basisplattform Es erfolgt die Installation der übrigen Pakete von DVD bzw. aus den heruntergeladenen Paketen des Debian Security Servers. Nach Abschluss dieses Installationsschrittes sind 600MB auf der Festplatte belegt. Weitere manuelle Konfigurationsänderungen: • /etc/inittab: durch die Tastenkombination Ctrl-Alt-Del wird ein Shutdown-Halt (statt Reboot) ausgeführt, um die virtuelle Maschine gezielt anhalten zu können. 2.3 Installation der zu testenden Anwendungen Im nächsten Schritt werden die benötigten Anwendungspakete für eine Installation innerhalb der virtuellen Maschinen übertragen (per Web-Download bzw. aus einem lokalen SoftwareRepository per scp). Zur Vereinheitlichung wird von folgenden Voraussetzungen ausge­ gangen (eine detaillierte Beschreibung der Installationsschritte wird in Abschnitt 3 gegeben): • die heruntergeladenen Pakete werden unter /root/bsi_tomcat abgelegt • um mit möglicherweise bereits installierten Paketen (z. B. aus der entsprechenden Linux-Distribution) keine Konflikte zu erzeugen, werden die Installationen unter dem Verzeichnis /opt durchgeführt. Soweit erforderlich erfolgt die Übersetzung der Soft­ warepakete unterhalb des Verzeichnisses /root/bsi_tomcat. Somit befinden sich nach Abschluss der Installation die verschiedenen Softwarepakete in den folgenden Unterverzeichnissen (soweit auf der jeweiligen virtuellen Maschine vorhanden): • Java SDK 1.5.0_05: /opt/jdk1.5.0_05 (nachfolgend auch als $JAVA_HOME bezeichnet) Das Skript /root/bsi_tomcat/install_jdk5.sh führt die Installation des Java Software Design Kits aus. • Apache 2.0.54: /opt/httpd-2.0.54 (nachfolgend auch als $HTTPD_HOME oder $APACHE_INSTALL bezeichnet) Das Skript /root/bsi_tomcat/install_apache.sh übersetzt und installiert Webserver. • Jakarta Tomcat: /opt/jakarta-tomcat-5.5.9 $CATALINA_HOME bezeichnet) den Apache (nachfolgend auch als Das Skript /root/bsi_tomcat/install_tomcat.sh entpackt die Binärversion des Jakarta Tomcat Servlet Containers. • Jakarta Tomcat Connector (mod_jk): Das Connector-Modul (mod_jk.so) befindet sich nach der Installation im Unterverzeichnis modules der Apache-Installation. Die Übersetzung und Installation /root/bsi_tomcat/install_mod_jk.sh des Bundesamt für Sicherheit in der Informationstechnik Connector-Moduls erfolgt mit dem Skript Seite 26 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • Installation der Debian 3.1 Sarge Basisplattform MySQL Database Java Connector: Das zur Verbindung mit der MySQLDatenbank benötigte Java Archiv mysql-connector-java-3.1.10-bin.jar wird in das common/lib Unterverzeichnis der Jakarta Tomcat Installation kopiert. Das Skript /root/bsi_tomcat/install_mysqlj.sh führt die Installation des MySQL Connectors aus. • Log4J und commons-logging: zum Logging in Tomcat wird je ein jar-Archiv in das common/lib Unterverzeichnis der Jakarta Tomcat Installation kopiert sowie eine Konfigurationsdatei common/classes/log4j.properties erzeugt. Skript /root/bsi_tomcat/install_logging_components.sh führt die Installation der Logging-jarArchive aus. Eine Konfiguration dieser Softwarekomponenten erfolgt zunächst nicht. Nach Abschluss der allgemeinen Installation / Konfiguration wird die virtuelle Maschine zur Erzeugung einer Arbeitskopie heruntergefahren (shutdown -h now). 2.4 Replikation von virtuellen Maschinen Zur Realisierung mehrerer virtueller Hostinstanzen kann die zuvor erstellte virtuelle Maschine beliebig oft repliziert und nebenläufig betrieben werden. Die Replikation von virtuellen Maschinen für weitere Arbeiten erfolgt in zwei Stufen: • Auf Betriebssystemebene wird das Verzeichnis mit den Dateien der virtuellen Maschine (Festplattenimage der virtuellen Maschine, Konfigurationsdateien) kopiert: cp -rp Debian_3.1_template Debian_3.1_host<n> • Anschließend muss die Kopie der VMware Konsole noch bekannt gemacht werden (Schritte in Abbildungen 2.16 … 2.18) Abbildung 2.16.: Suche der neuen virtuellen Maschine mit dem „Browse“ Button Seite 27 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Debian 3.1 Sarge Basisplattform Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 2.17.: Auswahl der .vmx-Datei zur selektierten virtuellen Maschine Abbildung 2.18.: Anpassung des Namens der virtuellen Maschine Alternativ kann das von VMware selbst bereitgestellte Duplikationsverfahren angewendet werden. Bundesamt für Sicherheit in der Informationstechnik Seite 28 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 3. Installation der Softwarekomponenten In den nachfolgenden Abschnitten wird die Installation der für den Test benötigten Softwarekomponenten beschrieben. Es handelt sich dabei um • das Java Software Design Kit (Binärpaket) • den Apache Webserver (Quellcodepaket) • den Jakarta Tomcat Servlet Container (Binärpaket) • den Jakarta Tomcat Connector mod_jk (Quellcodepaket) • den MySQL-Connector/J zur Datenbankanbindung (Binärpaket) • die Log4j und commons-logging Software (Binärpakete) Soweit es sich um Binärpakete handelt (Java SDK, Jakarta Tomcat Servlet Container, MySQL-Connector/J), werden diese direkt installiert. Quellcodepakete werden zunächst übersetzt und dann installiert. In der Testinstallation wird die oben genannte Software nach Bezug von den Entwickler-Webseiten nachinstalliert. Seite 29 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Vergleichbare Softwarekomponenten aus der Linux-Distribution sind in der Testinstallation nicht vorhanden. Um anderen Nutzern eine vergleichbare Installation zu ermöglichen, werden sämtliche Softwarekomponenten unter dem Verzeichnis /opt installiert, sodass es zu keinen Konflikten mit möglicherweise an anderer Stelle installierten Softwarepaketen aus der von diesen Nutzern verwendeten Linux-Distribution kommen sollte. Die unten im Text aufgeführten install_*.sh Shell-Skripts wurden für die Reproduzierbarkeit der Installationsschritte erstellt und eingesetzt. 3.1 Java Software Design Kit (SDK, Version 1.5.0_05) Der Java-basierte Jakarta Tomcat Servlet Container benötigt zur Ausführung die Installation eines Java Software Design Kits (SDK). Die für die beschriebenen Untersuchungen verwendete aktuelle Version 1.5.0 Update 05 ist für Linux-Plattformen zum Download erhältlich von Sun Microsystems, Inc.9 Die Installation erfolgt nach dem Download als Nutzer root mit folgendem Installationsskript install_jdk5.sh: Listing 2: Installationsskript install_jdk5.sh #!/bin/bash # where we can find the installation packages / sources: SW_REPOSITORY="/root/bsi_tomcat" # where to install: INSTALL_BASE="/opt" #----------------------------------------------------------------# Install the Java 1.5.0_05 SDK cd ${INSTALL_BASE} chmod u+x ${SW_REPOSITORY}/j2se_5/jdk-1_5_0_05-linux-i586.bin ${SW_REPOSITORY}/j2se_5/jdk-1_5_0_05-linux-i586.bin #----------------------------------------------------------------# -- eof -#----------------------------------------------------------------- Hierdurch wird das Java Software Design Kit unter dem Verzeichnis /opt/jdk1.5.0_05 ($JAVA_HOME) installiert. Da die von der jeweiligen Linux-Distribution mitgelieferten Java SDK Installationen üblicherweise in die /usr, /etc, ... Verzeichnisse integriert werden, ergibt sich durch die Installation unter /opt kein Konflikt. Gegebenenfalls ist zur Nutzung dieser Java SDK Installation beim Setzen der Suchpfade und Java-Environment-Variablen die geänderte Lage zu berücksichtigen. Feststellung: Eine Durchsicht der Java SDK Installation hat ergeben, dass sämtliche Dateien unter Benutzer:Gruppe root:root installiert werden. Weder die Gruppe noch andere (World) haben Schreibberechtigungen auf die installierten Dateien und es sind weder SUID (Set User ID) noch SGID (Set Group ID) Bits in den installierten Dateien gesetzt, sodass Modifikationen an den installierten Dateien nur durch den Benutzer root10 vorgenommen werden können. 9 10 http://java.sun.com/j2se/1.5.0/download.jsp bzw. durch andere Benutzer, die temporär root Berechtigungen erlangen können (z. B. per su oder sudo Kommando) Bundesamt für Sicherheit in der Informationstechnik Seite 30 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Nach Abschluss der Installation sollte das Passwort des globalen Java CA-Zertifikat­ speichers von der Standardeinstellung changeit geändert werden (s. Abschnitt 6.1.3). Dies gilt insbesondere bei der Verwendung von Client-Zertifikat-basierten Authentisierungs­ verfahren in Tomcat Webanwendungen. 3.2 Apache Webserver (Version 2.0.54) Für den Apache Webserver wird aus der Quelltextversion, die von der EntwicklerWebsseite11 heruntergeladen werden kann, eine Standardinstallation durchgeführt. Hierzu werden die Quelltexte übersetzt und die Binärversion der Programme sowie die Konfigurations- und Dokumentationsdateien aus Gründen der Vermeidung von Konflikten mit möglicherweise aus der Linux-Distribution installierten Apache Webserver Software unter dem Verzeichnis /opt/httpd-2.0.54 ($APACHE_INSTALL) installiert. Die Installation erfolgt als Nutzer root mit dem Skript install_apache.sh: Listing 3: Installationsskript install_apache.sh #!/bin/bash # where we can find the installation packages / sources: SW_REPOSITORY="/root/bsi_tomcat" # where to install: INSTALL_BASE="/opt" APACHE_INSTALL="${INSTALL_BASE}/httpd-2.0.54" #--------------------------------------------------------------------# install the apache web server cd ${SW_REPOSITORY}/apache rm -rf ${SW_REPOSITORY}/apache/httpd-2.0.54 tar xvfz ${SW_REPOSITORY}/apache/httpd-2.0.54.tar.gz cd ${SW_REPOSITORY}/apache/httpd-2.0.54 ./configure --prefix=${APACHE_INSTALL} --enable-ssl && \ make && \ make install #--------------------------------------------------------------------# configuration for apache - tomcat cooperation: # ${APACHE_INSTALL}/conf/httpd.conf # ${APACHE_INSTALL}/conf/ssl.conf cd ${APACHE_INSTALL}/conf ln -s ${INSTALL_BASE}/jakarta-tomcat-5.5.9/conf/workers.properties mkdir ${APACHE_INSTALL}/conf/ssl.crt mkdir ${APACHE_INSTALL}/conf/ssl.key # copy the apache webserver certificate / key to these directories # #--------------------------------------------------------------------#--------------------------------------------------------------------# to start Apache with SSL support: # # ${APACHE_INSTALL}/bin/apachectl -f ${APACHE_INSTALL}/conf/httpd.conf -DSSL # 11 http://httpd.apache.org/ Seite 31 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers #--------------------------------------------------------------------# -- eof -#--------------------------------------------------------------------- Feststellung: Eine Durchsicht der Apache Webserver Installation hat ergeben, dass die Dateien überwiegend unter Benutzer:Gruppe root:root, teilweise aber auch unter dem auf dem Testsystem nicht vorhandenen Benutzer:Gruppe 1000:1000 (es sind dies überwiegend die Dateien in den Verzeichnissen error, htdocs, icons, include, sowie manual) installiert werden. Weder die Gruppe noch andere (World) haben Schreibberechtigungen auf die installierten Dateien und es sind weder SUID (Set User ID) noch SGID (Set Group ID) Bits in den installierten Dateien gesetzt, sodass Modifikationen an den installierten Dateien nur durch den Benutzer root12 bzw. teilweise durch den auf dem System nicht vorhandenen Nutzer 1000 vorgenommen werden können. Zum grundlegenden Test der erfolgreichen Installation kann der Apache Webserver zunächst für den Betrieb ohne HTTPS-Verbindungsunterstützung mit dem Kommando APACHE_INSTALL=/opt/http-2.0.54 && \ ${APACHE_INSTALL}/bin/apachectl -f ${APACHE_INSTALL}/conf/httpd.conf gestartet werden. Um HTTPS-Verbindungen zum Webserver freizugeben, ist das letztgenannte Kommando mit der Option -DSSL aufzurufen. Hierzu müssen zuvor ggf. noch weitere Konfigurationen in der Datei $APACHE_INSTALL/conf/ssl.conf vorgenommen sowie Server-Zertifikat und zugehöriger privater Schlüssel installiert werden (s. Abschnitt 4.7.3). Mit einem Webbrowser kann nun die URL http://127.0.0.1:80 geöffnet werden und sollte zu folgender Webseite führen: 12 bzw. durch andere Benutzer, die temporär root Berechtigungen erlangen können (z. B. per su oder sudo Kommando) Bundesamt für Sicherheit in der Informationstechnik Seite 32 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 3.1.: Test-Startseite des Apache Webservers Es ist zu beachten, dass es sich hierbei wegen der noch durchzuführenden Tests um einen völlig unkonfigurierten Webserver handelt. Dieser sollte, um erhebliche Sicherheitsprobleme zu vermeiden, so nicht für einen Zugriff z. B. aus dem Internet freigeschaltet werden. 3.3 Jakarta Tomcat Servlet Container (Version 5.5.9) Die Installation des Jakarta Tomcat Servlet Containers erfolgt nach dem Download des Binärpaketes von der Entwickler-Webseite13 als Nutzer root mit dem Installationsskript install_tomcat.sh: Listing 4: Installationsskript install_tomcat.sh #!/bin/bash # where we can find the installation packages / sources: SW_REPOSITORY="/root/bsi_tomcat" # where to install: INSTALL_BASE="/opt" #--------------------------------------------------------------------# Install the binary package of jakarta-tomcat 5.5.9 cd ${INSTALL_BASE} tar xvfpz ${SW_REPOSITORY}/jakarta_tomcat/jakarta-tomcat-5.5.9.tar.gz #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # --- optionally: install the jsvc tool for running tomcat as daemon 13 http://jakarta.apache.org/site/downloads/downloads_tomcat.html Seite 33 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers cd ${INSTALL_BASE}/jakarta-tomcat-5.5.9/bin tar xvfpz jsvc.tar.gz cd jsvc-src autoconf ./configure --with-java=${INSTALL_BASE}/jdk1.5.0_05 make cp jsvc .. cd .. #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # --- optionally: install the admin package tar xvfpz ${SW_REPOSITORY}/jakarta_tomcat/jakarta-tomcat-5.5.9-admin.tar.gz #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # environment variables definitions cat > ${INSTALL_BASE}/jakarta-tomcat-5.5.9/bin/setenv.sh <<EOF ###################################################################### # environment variables for tomcat ###################################################################### export export export export JAVA_HOME="${INSTALL_BASE}/jdk1.5.0_05" JRE_HOME="${INSTALL_BASE}/jdk1.5.0_05/jre" CATALINA_HOME="${INSTALL_BASE}/jakarta-tomcat-5.5.9" CATALINA_BASE="${INSTALL_BASE}/jakarta-tomcat-5.5.9" ###################################################################### # -- eof -###################################################################### EOF #--------------------------------------------------------------------# to start tomcat: # # ${INSTALL_BASE}/jakarta-tomcat-5.5.9/bin/catalina.sh start # #--------------------------------------------------------------------#-------------------------------------------------------------------# -- eof -#--------------------------------------------------------------------- Neben der eigentlichen Installation wird die Datei $CATALINA_HOME/bin/setenv.sh erzeugt, mit der die Suchpfade zum Java SDK bzw. zur Tomcat Installation gesetzt werden. Um den Jakarta Tomcat Servlet Container als Daemon zu nutzen, muss das im TomcatBinärpaket vorhandene Tool jsvc für das Ziel-Betriebssystem übersetzt werden. Mit Hilfe von jsvc -user ist es auch möglich, den Jakarta Tomcat Servlet Container als non-root Benutzer auszuführen, auch wenn privilegierte Ports (1 .. 1023) verwendet werden. Feststellung: Eine Durchsicht der Apache Webserver Installation hat ergeben, dass sämtliche Dateien unter Benutzer:Gruppe root:root installiert werden. Weder die Gruppe noch andere (World) haben Schreibberechtigungen auf die installierten Dateien und es sind weder SUID (Set User ID) noch SGID (Set Group ID) Bits in den installierten Dateien gesetzt, sodass Modifikationen an den installierten Dateien nur durch den Benutzer root14 vorgenommen werden können. 14 bzw. durch andere Benutzer, die temporär root Berechtigungen erlangen können (z. B. per su oder sudo Kommando) Bundesamt für Sicherheit in der Informationstechnik Seite 34 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Zum Test der erfolgreichen Installation kann der Jakarta Tomcat Servlet Container nun mit dem Kommando INSTALL_BASE=/opt && \ ${INSTALL_BASE}/jakarta-tomcat-5.5.9/bin/catalina.sh start gestartet werden. Mit einem Webbrowser kann nun die URL http://127.0.0.1:8080 geöffnet werden und sollte zu folgender Tomcat-Start-Webseite führen: Abbildung 3.2.: Test-Startseite des Jakarta Tomcat Servlet Containers In dieser Betriebsart arbeitet der Jakarta Tomcat Servlet Container selbst als HTTP-Server und kann somit über seinen HTTP-Connector direkt per HTTP angesprochen werden (entsprechend dem Einsatzszenario 1 aus [Tomcat Fein.]). Auch hier gilt wie im Fall des zuvor beschriebenen Basistests der Installation des Webservers Apache, dass diese Installation ohne weitere Konfiguration aus Sicherheitsgründen nicht für Zugriffe aus dem Internet freigeschaltet werden sollte. In den meisten Fällen wird man jedoch für die Bereitstellung der statischen Internetseiten einen dafür optimierten Webserver (wie z. B. Apache) verwenden (entsprechend den Einsatzszenarien 2 – 6 aus [Tomcat Fein.]). Um diesen in Verbindung mit dem Jakarta Tomcat Servlet Container nutzen zu können, wird ein Connector Modul benötigt, das im Seite 35 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Webserver die Kommunikation zwischen dem Webserver und dem Tomcat Servlet Container, die auf dem AJPv13 (Apache JServ Protocol version 1.3) basiert, abwickelt. Dessen Installation wird im folgenden Abschnitt beschrieben. Bundesamt für Sicherheit in der Informationstechnik Seite 36 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 3.4 Jakarta Tomcat Connector Modul mod_jk (Version 1.2.14) Da von der Entwickler-Webseite des Jakarta Tomcat Connector Moduls15 keine Binärversion für die in der Testumgebung gewählte Debian 3.1 Sarge Linux Version verfügbar ist, muss diese aus dem Quellcodepaket erzeugt werden. Hierfür ist das Installationsskript install_mod-jk.sh vorgesehen, das auf den Hinweisen der Connector-Modul-Dokumentation16 basiert: Listing 5: Installationsskript install_mod-jk.sh #!/bin/bash # where we can find the installation packages / sources: SW_REPOSITORY="/root/bsi_tomcat" # where to install: INSTALL_BASE="/opt" APACHE_INSTALL="${INSTALL_BASE}/httpd-2.0.54" #--------------------------------------------------------------------# prepare the mod_jk connector cd ${SW_REPOSITORY}/jakarta_tomcat tar xvfpz ${SW_REPOSITORY}/jakarta_tomcat/jakarta-tomcat-connectors-1.2.14.1-src.tar.gz cd ${SW_REPOSITORY}/jakarta_tomcat/jakarta-tomcat-connectors-1.2.14.1-src/jk/native ./configure --with-apxs=${APACHE_INSTALL}/bin/apxs && \ make && \ make install # installs mod_jk.so under ${APACHE_INSTALL}/modules/ #--------------------------------------------------------------------# configuration: # ${APACHE_INSTALL}/conf/httpd.conf: # # # ${APACHE_INSTALL}/conf/workers.properties: # copy / link from ${INSTALL_BASE}/jakarta-tomcat-5.5.9/conf/workers.properties # #--------------------------------------------------------------------# to start tomcat: # # ${INSTALL_BASE}/jakarta-tomcat-5.5.9/bin/catalina.sh start # # to start apache: # # ${APACHE_INSTALL}/bin/apachectl -f ${APACHE_INSTALL}/conf/httpd.conf # #--------------------------------------------------------------------# -- eof -#--------------------------------------------------------------------- 15 16 http://jakarta.apache.org/site/downloads/downloads_tomcat.html http://jakarta.apache.org/tomcat/connectors-doc/install/apache2.html Seite 37 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 1 Das erzeugte mod_jk.so Modul zur Einbindung in den Apache Webserver wird durch das Kommando make install im Skript automatisch in das Verzeichnis modules der Apache Installation kopiert. Es wird dort unter Benutzer:Gruppe root:root und ohne Schreibberechtigung für die Gruppe oder andere [World] installiert. Weitere Änderungen oder Ergänzungen in der Apache Installation werden automatisch nicht durchgeführt. Zur Nutzung des Connector Moduls sind in der Konfigurationsdatei $APACHE_INSTALL/conf/httpd.conf des Apache Webservers manuell entsprechende Einstellungen vorzunehmen, die ein dynamische Laden des Connector Moduls veranlassen, sowie die Datei $APACHE_INSTALL/conf/workers.properties zu erzeugen, wie dies im Folgenden beschrieben ist. 3.4.1 Apache-Konfigurationsdatei httpd.conf Zur Aktivierung des Connector Moduls im Apache Webserver sind entsprechende Eintra­ gungen in der Konfigurationsdatei $APACHE_INSTALL/conf/httpd.conf vorzunehmen. Dies sind einmal die Ladedirektive für das Connector Modul, die Konfigurationen des Loggings (JkLogStampFormat bzw. JkRequestLogFormat: welche Informationen werden protokolliert) und außerdem eine Deklaration sämtlicher Webanwendungen, die über das Connector Modul durch den Jakarta Tomcat Servlet Container bedient werden sollen (hierzu gehören die Tomcat-Dokumentation, die Standard-Administrationsapplikationen manager und admin sowie die 3 Webanwendungen simple_info(1|1a|2) für Authentisierungstests, s. S. 84): Listing 6: Auszug aus der Apache-Konfigurationsdatei httpd.conf ... <IfModule !mod_jk.c> LoadModule jk_module modules/mod_jk.so </IfModule> <IfModule mod_jk.c> JkWorkersFile "conf/workers.properties" JkLogFile "logs/mod_jk.log" JkLogLevel info 1. JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " JkRequestLogFormat "%w %V %T" # all requests are handled by worker bsi_ajp13_1 JkMount /tomcat-docs bsi_ajp13_1 JkMount /tomcat-docs/* bsi_ajp13_1 JkMount /admin bsi_ajp13_1 JkMount /admin/* bsi_ajp13_1 JkMount /manager bsi_ajp13_1 JkMount /manager/* bsi_ajp13_1 JkMount /simple_info1 bsi_ajp13_1 JkMount /simple_info1/* bsi_ajp13_1 JkMount /simple_info1a bsi_ajp13_1 JkMount /simple_info1a/* bsi_ajp13_1 JkMount /simple_info2 bsi_ajp13_1 JkMount /simple_info2/* bsi_ajp13_1 </IfModule> ... Bundesamt für Sicherheit in der Informationstechnik Seite 38 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Softwarekomponenten Weiterhin hilfreich für die Zustandsanalyse des Apache Webservers im Rahmen der Untersuchungen ist die Freigabe der Statusinformationen, die dann über die URL http://127.0.0.1/server-status abgerufen werden können: ... ExtendedStatus On <Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from 127.0.0.1 </Location> ... Eine Beschränkung der Zugriffe auf den localhost (IP-Adresse 127.0.0.1) bzw. ggf. auf einen Management-Host ist aus Sicherheitsgründen sinnvoll, um Statusabfragen von anderen Hosts aus über das Netzwerk zu verhindern. 3.4.2 Tomcat Konfigurationsdatei server.xml Nachfolgend ist eine Basiskonfiguration für die Datei $CATALINA_HOME/conf/server.xml aufgeführt, in der beispielsweise festgelegt wird, über welche Ports die Kommunikation mit dem Jakarta Tomcat Servlet Container erfolgt. Darin sind • Port 8080 für direkte HTTP-Zugriffe auf den Tomcat Servlet Container (Szenario 1), • Port 8443 für direkte HTTPS-Zugriffe auf den Tomcat Servlet Container (zunächst noch ohne Client-Authentisierung. Mit dem unter $CATALINA_HOME/conf/.keystore abgelegten Server-Zertifikat und den später für die Client-Authentisierung verwen­ deten Zertifikaten der Certification Authorities (CAs), die zur Signierung der ClientZertifikate verwendet wurden, in $CATALINA_HOME/conf/truststore), • Port 8009 für AJP (Apache JServ Protocol) Anfragen des Apache Webserver (über das mod_jk Connector Modul) an den Jakarta Tomcat Servlet Container (Szenarien 2 - 6) und • Port 8005 (hier in Verbindung mit der gewählten Zeichenkette SHUTDOWN) zum Herunterfahren des Tomcat Servlet Containers17 vorgesehen. Weiterhin sind die für die verschiedenen Authentisierungsverfahren benötigten Einträge (für Memory Realm, JDBC Realm, JNDI Realm) bereits in der Datei vorhanden, jedoch durch XML-Kommentare bis auf den gerade zu testenden deaktiviert: Listing 7: Tomcat-Konfigurationsdatei $CATALINA_HOME/conf/server.xml <Server port="8005" shutdown="SHUTDOWN"> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/> <Listener className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener"/> <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener"/> <GlobalNamingResources> <Environment name="simpleValue" type="java.lang.Integer" 17 Zur Erhöhung der Sicherheit gegen Denial-of-Service Angriffe sollte überlegt werden, ob dieser Port überhaupt aktiviert werden sollte, siehe Abschnitt 6.3.2. Seite 39 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers value="30"/> <Resource auth="Container" description="User database that can be updated and saved" name="UserDatabase" type="org.apache.catalina.UserDatabase" pathname="conf/tomcat-users.xml" factory="org.apache.catalina.users.MemoryUserDatabaseFactory"/> </GlobalNamingResources> <Service name="Catalina"> <Connector port="8080" redirectPort="8443" minSpareThreads="25" connectionTimeout="20000" maxSpareThreads="75" maxThreads="150" maxHttpHeaderSize="8192"> </Connector> <Connector port="8443" minSpareThreads="25" connectionTimeout="20000" maxSpareThreads="75" maxThreads="150" maxHttpHeaderSize="8192" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="conf/.keystore" keystorePass="vmware" truststoreFile="conf/truststore" truststorePass=“vmware“> </Connector> <Connector port="8009" redirectPort="8443" protocol="AJP/1.3"> </Connector> <Engine defaultHost="localhost" name="Catalina"> <!-use XML comments to de-/activate the relevant section ################################################## # for MemoryRealm: ################################################## --> <Realm className="org.apache.catalina.realm.MemoryRealm"/> <!-################################################## # for JDBCRealm: ################################################## <Realm className="org.apache.catalina.realm.JDBCRealm" debug="99" driverName="org.gjt.mm.mysql.Driver" connectionURL="jdbc:mysql://localhost/authority?user=jdbcuser&amp;password=jdbcpass" userTable="users" userNameCol="user_name" userCredCol="user_pass" userRoleTable="user_roles" roleNameCol="role_name" /> Bundesamt für Sicherheit in der Informationstechnik Seite 40 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers ################################################## # for JNDIRealm: ################################################## <Realm className="org.apache.catalina.realm.JNDIRealm" debug="99" connectionURL="ldap://localhost:389" userPattern="uid={0},ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de" roleBase="ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=de" roleName="cn" roleSearch="(uniqueMember={0})" digest="MD5" /> ################################################## --> <Host appBase="webapps" name="localhost"> </Host> </Engine> </Service> </Server> 3.4.3 Apache-Konfigurationsdatei workers.properties Weiterhin sind in der Datei $CATALINA_HOME/conf/workers.properties einige Anpassungen vorzunehmen. Diese Anpassungen betreffen im Wesentlichen spezifische Pfade der jeweiligen Installation. Die minimale verwendete Konfigurationsdatei sieht nach Entfernung zahlreicher Kommentare und weiterer zunächst nicht benötigter Direktiven wie folgt aus: Listing 8: Apache-Konfigurationsdatei $CATALINA_HOME/conf/workers.properties ##################################################################### # workers.properties.minimal ##################################################################### # # This file provides minimal jk configuration properties needed to # connect to Tomcat. # workers.tomcat_home=/opt/jakarta-tomcat-5.5.9 workers.java_home=/opt/jdk1.5.0_05 ##################################################################### # The workers that jk should create and work with # worker.list=bsi_ajp13_1 # # Defining a worker named bsi_ajp13_1 and of type ajp13 # Note that the name and the type do not have to match. # worker.bsi_ajp13_1.type=ajp13 worker.bsi_ajp13_1.host=localhost worker.bsi_ajp13_1.port=8009 ##################################################################### # -- eof -##################################################################### Am günstigsten ist für eine Bereitstellung identischer Dateien für den Apache Webserver wie für den Jakarta Tomcat Servlet Container, wenn diese Datei im System nur einmal Seite 41 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers vorhanden ist (z. B. im Tomcat-Konfigurationsverzeichnis $CATALINA_HOME/conf, auf die dann aus dem Apache Konfigurationsverzeichnis $APACHE_INSTALL/conf per Soft-Link verwiesen wird). Anschließend kann der Apache Webserver mit dieser geänderten Konfiguration wieder gestartet werden und als Funktionstest die Tomcat-Dokumentation über den Apache Web­ server mit der URL http://127.0.0.1/tomcat-docs/ aufgerufen werden. Dies sollte im Erfolgsfall zu folgendem, dem des direkten Abrufs dieser Webseite über Tomcat entsprechenden Ergebnis, d. h. ohne die Verwendung des Apache Webservers über die URL http://127.0.0.1:8080/tomcat-docs/, führen: Abbildung 3.3.: Aufruf der Tomcat-Dokumentation über den Apache Webserver (http-Standard-Port) und den mod_jk-Connector. Zur Nutzung der Tomcat admin18 und manager Applikationen wird die Datei $CATALINA_HOME/conf/tomcat-users.xml modifiziert, die im Rahmen der Memory Realmbasierten Authentisierung verwendet wird19: 18 Bestandteil des jakarta-tomcat-5.5.9-admin.tar.gz Paketes und inzwischen nicht mehr im Tomcat Paket selbst enthalten. Bundesamt für Sicherheit in der Informationstechnik Seite 42 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Listing 9: Tomcat-Benutzer-Definitionsdatei $CATALINA_HOME/conf/tomcat-users.xml <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="admin"/> <role rolename="manager"/> <role rolename="user1"/> <role rolename="user2"/> <user username="memadmin" password="vmware" roles="admin"/> <user username="memadminhash" password="92963abd36c896b93a36b8e296ff3387" <user username="memmanager" password="vmware" roles="manager"/> <user username="memmanagerhash" password="92963abd36c896b93a36b8e296ff3387" <user username="memuser1" password="vmware" roles="user1"/> <user username="memuser1hash" password="92963abd36c896b93a36b8e296ff3387" <user username="memuser2" password="vmware" roles="user2"/> <user username="memuser2hash" password="92963abd36c896b93a36b8e296ff3387" </tomcat-users> roles="admin"/> roles="manager"/> roles="user1"/> roles="user2"/> 3.5 Installation des MySQL-Connectors/J Zum Test von Verbindungen des Tomcat Servlet Containers mit dem MySQL-DBMS (beispielsweise zur Authentisierung mit Hilfe von in der Datenbank abgelegten Nutzern bzw. Passworten sowie deren zugeordnete Rollen) wird der MySQL-Connector/J benötigt. Dieser MySQL-Connector/J kann derzeit in der Produkt-Version 3.1 von der Entwickler-Webseite 20 heruntergeladen werden. Die Installation erfolgt dann mit Hilfe des Skriptes install_mysqlj.sh: Listing 10: Installationsskript install_mysqlj.sh #!/bin/bash # where we can find the installation packages / sources: SW_REPOSITORY="/root/bsi_tomcat" # where to install: INSTALL_BASE="/opt" #--------------------------------------------------------------------# Install the binary package of mysql-connector/j3.1 cd ${SW_REPOSITORY} tar xvfpz ${SW_REPOSITORY}/mysql-connector-java-3.1.10.tar.gz # copy the non-debug version of the connector jar # to common/lib (which makes it available for both tomcat as well # as for web applications cp -p mysql-connector-java-3.1.10/mysql-connector-java-3.1.10-bin.jar \ ${INSTALL_BASE}/jakarta-tomcat-5.5.9/common/lib 19 20 Für einen Produktiveinsatz des Jakarta Tomcat Servlet Containers sind natürlich die Standardvorgaben für die Passwörter auf sinnvolle Werte gemäß den jeweils vor Ort geltenden Passwortrichtlinen zu ändern. Die zum Test der verschiedenen Authentisierungsmethoden verwendeten Benutzernamen und Passworte sind in Abschnitt 4 zusammengestellt. http://www.mysql.com/products/connector/j/ Seite 43 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers #--------------------------------------------------------------------# -- eof -#--------------------------------------------------------------------- 3.6 Installationen für die JNDI-Konnektivität Eine Nachinstallation von JNDI-Komponenten (wie in der Tomcat Dokumentation ange­ geben) ist zur Nutzung mit OpenLDAP bei der verwendeten Tomcat Version und in Verbindung mit der installierten Java SDK Version 5 nicht mehr erforderlich. 3.7 Installation der Logging-Komponenten Eine Standardinstallation verfügt über ein Logging basierend auf den java.util.logging Klassen, die bereits im Java SDK enthalten sind. In der Tomcat Dokumentation wird auf eine alternative / optionale Logging-Möglichkeit hingewiesen, die auf den log4j Bibliotheken des Jakarta Projekts selbst stammen. Für das alternative log4j Logging aus Tomcat heraus werden mit dem Skript install_logging_components.sh zwei jar-Archive sowie eine Konfigurationsdatei installiert: Listing 11: Installationsskript install_logging_components.sh #!/bin/bash # where we can find the installation packages / sources: SW_REPOSITORY="/root/bsi_tomcat" # where to install: INSTALL_BASE="/opt" CATALINA_HOME="${INSTALL_BASE}/jakarta-tomcat-5.5.9" #--------------------------------------------------------------------# Unpack and install the required jar files to support logging cd ${SW_REPOSITORY} mkdir -p ${CATALINA_HOME}/common/lib tar -xvzOf logging-log4j-1.2.12.tar.gz \ logging-log4j-1.2.12/dist/lib/log4j-1.2.12.jar \ > ${CATALINA_HOME}/common/lib/log4j.jar # !! jar file without version number !! tar -xvzOf commons-logging-1.0.4.tar.gz \ commons-logging-1.0.4/commons-logging.jar \ > ${CATALINA_HOME}/common/lib/commons-logging.jar #--------------------------------------------------------------------# prepare the log configuration file mkdir -p ${CATALINA_HOME}/common/classes cat > ${CATALINA_HOME}/common/classes/log4j.properties <<EOF log4j.rootLogger=debug, R log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=${CATALINA_HOME}/logs/tomcat.log log4j.appender.R.MaxFileSize=10MB Bundesamt für Sicherheit in der Informationstechnik Seite 44 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers log4j.appender.R.MaxBackupIndex=10 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n log4j.logger.org.apache.catalina=DEBUG, R EOF #--------------------------------------------------------------------# -- eof -#--------------------------------------------------------------------- Die jar-Dateien befinden sich in den Binär-Installationspaketen • logging-log4j-1.2.12.tar.gz21 sowie • commons-logging-1.0.4.tar.gz22. Bei den dynamischen Tests wurde jedoch das Standard-Logging des Java SDK verwendet. Die oben aufgeführten Binär-Installationspakete werden jedoch von manchen Modulen explizit referenziert (beispielsweise Jasper), so dass sie bei einer Übersetzung des Quellcodes vorhanden sein müssen. 3.8 Einrichtung des lokalen DNS-Servers Um Tests der Zugriffsfilterfunktionen anhand der Host- oder Domänennamen aus der vorhandenen Testumgebung heraus durchführen zu können, wird ein lokaler Domain Name Service (DNS) Server aufgesetzt, der ausschließlich lokal im Testnetz (192.168.118.0/24) arbeitet und lokale Anfragen hieraus beantwortet. Dieser DNS-Server dient dazu, aus den beim Tomcat-Server eintreffenden IP-Adressen per Reverse DNS Lookup die zugehörigen Hostnamen für einen Vergleich mit den vordefinierten Mustern für die Zugriffsteuerung zu gewinnen. Für die Konfiguration des DNS-Servers wird davon ausgegangen, dass die beteiligten virtuel­ len Hosts (VH) bzw. der VMware Host (VM-Host) mit den folgenden statischen IP-Adressen konfiguriert sind (s. a. Abbildung 2.1): • tomcathost.bsitomcat.de (VH): 192.168.118.101/26 • template.bsitomcat.de (VH): 192.168.118.100/26 • bigmama.external.de (VM-Host): 192.168.118.1/26 Für den DNS-Server (tomcathost) werden die folgenden Dateien erzeugt bzw. geändert, die Datei /etc/resolv.conf wird auch auf auch auf der zweiten virtuellen Testmaschine (template) installiert. Diese Informationen werden nicht auf den VM-Host übertragen, um dessen Netzwerkeinbindung und Namensauflösung nicht zu beeinflussen. Daher sind Verbindungen von dieser Maschine zum Apache-Test-Webserver bzw. zu Tomcat über die IP-Adresse des Testrechners (tomcathost) zu adressieren. 21 22 erhältlich unter http://logging.apache.org/log4j/docs/download.html erhältlich unter http://jakarta.apache.org/site/downloads/downloads_commons-logging.cgi Seite 45 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Listing 12: DNS-Server-Konfigurationsdatei /etc/bind/named.conf: // // // // // // // This is the primary configuration file for the BIND DNS server named. Please read /usr/share/doc/bind9/README.Debian.gz for information on the structure of BIND configuration files in Debian, *BEFORE* you customize this configuration file. If you are just adding zones, please do that in /etc/bind/named.conf.local include "/etc/bind/named.conf.options"; // prime the server with knowledge of the root servers zone "." { type hint; file "/etc/bind/db.root"; }; // be authoritative for the localhost forward and reverse zones, and for // broadcast zones as per RFC 1912 zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "bsitomcat.de" { type master; file "/etc/bind/db.bsitomcat.de"; allow-query { 192.168.118.0/24; }; allow-transfer { none; }; allow-update { none; }; }; zone "external.de" { type master; file "/etc/bind/db.external.de"; allow-query { 192.168.118.0/24; }; allow-transfer { none; }; allow-update { none; }; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; zone "118.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168.118"; allow-query { 192.168.118.0/24; }; allow-transfer { none; }; allow-update { none; }; }; Bundesamt für Sicherheit in der Informationstechnik Seite 46 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers // zone "com" { type delegation-only; }; // zone "net" { type delegation-only; }; // From the release notes: // Because many of our users are uncomfortable receiving undelegated answers // from root or top level domains, other than a few for whom that behaviour // has been trusted and expected for quite some length of time, we have now // introduced the "root-delegations-only" feature which applies delegation-only // logic to all top level domains, and to the root domain. An exception list // should be specified, including "MUSEUM" and "DE", and any other top level // domains from whom undelegated responses are expected and trusted. // root-delegation-only exclude { "DE"; "MUSEUM"; }; include "/etc/bind/named.conf.local"; Listing 13: DNS-Server-Konfigurationsdatei /etc/bind/named.conf.options: options { directory "/var/cache/bind"; // // // // // If there is a firewall between you and nameservers you want to talk to, you might need to uncomment the query-source directive below. Previous versions of BIND always asked questions using port 53, but BIND 8.1 and later use an unprivileged port by default. // query-source address * port 53; // // // // If your ISP provided one or more IP addresses for stable nameservers, you probably want to use them as forwarders. Uncomment the following block, and insert the addresses replacing the all-0's placeholder. // forwarders { // 0.0.0.0; // }; auth-nxdomain no; notify no; # conform to RFC1035 }; Listing 14: DNS-Server-Zonenkonfigurationsdatei /etc/bind/db.bsitomcat.de: ; ; BIND data file for local bsitomcat.de. test domain ; $TTL 604800 ; @ IN SOA tomcathost.bsitomcat.de. postmaster.bsitomcat.de. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; local name server bsitomcat.de. IN NS localhost. ; ; hosts managed by our bsitomcat.de. dns server ; Seite 47 (von 187) Bundesamt für Sicherheit in der Informationstechnik Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Softwarekomponenten tomcathost.bsitomcat.de. debian-host1.bsitomcat.de. template.bsitomcat.de. IN A IN A IN A 192.168.118.101 192.168.118.101 192.168.118.100 Listing 15: DNS-Server-Zonenkonfigurationsdatei /etc/bind/db.external.de: ; ; BIND data file for local external.de. test domain ; $TTL 604800 ; @ IN SOA tomcathost.bsitomcat.de. postmaster.bsitomcat.de. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; local name server external.de. IN NS localhost. ; ; hosts managed by our external.de. dns server ; bigmama.external.de. IN A 192.168.118.1 gateway.external.de. IN A 192.168.118.2 Listing 16: DNS-Server-Reverse-Zonenkonfigurationsdatei /etc/bind/db.192.168.118: ; ; BIND data file for local bsitomcat.de. test domain ; $TTL 604800 ; 118.168.192.in-addr.arpa. IN SOA tomcathost.bsitomcat.de. postmaster.bsitomcat.de. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; local name server ; 118.168.192.in-addr.arpa. IN NS tomcathost.bsitomcat.de. ; ; hosts managed by our bsitomcat.de. dns server ; 101.118.168.192.in-addr.arpa. IN PTR tomcathost.bsitomcat.de. 100.118.168.192.in-addr.arpa. IN PTR template.bsitomcat.de. 1.118.168.192.in-addr.arpa. IN PTR bigmama.external.de. 2.118.168.192.in-addr.arpa. IN PTR gateway.external.de. Listing 17: Konfigurationsdatei zur Namensauflösung /etc/resolv.conf: search bsitomcat.de nameserver 192.168.118.101 Bundesamt für Sicherheit in der Informationstechnik Seite 48 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Softwarekomponenten Nach Einrichtung der Konfiguration kann der DNS-Server mit Hilfe des Kommandos /etc/init.d/named restart aktiviert werden. 3.9 Werkzeuge für Penetrationstests Die in diesem Dokument beschriebenen Penetrationstests werden mit Hilfe frei und kostenlos verfügbarer Werkzeuge durchgeführt. Diese Werkzeuge und deren Installation werden hier beschrieben. 3.9.1 SPIKE SPIKE ist ein frei verfügbares Fuzz-Testing-Werkzeug, mit dem bereits viele Implemen­ tierungsschwachstellen in Softwareprodukten entdeckt wurden. SPIKE arbeitet nach dem Prinzip des Fuzz-Testing. Einer Software-Komponente werden viele unterschiedliche Parameter übergeben, die inhaltlich stark von gewöhnlichen Parametern abweichen. Die Übergabeparameter sind dabei sowohl sehr lange Zeichen­ ketten, Zeichenketten mit Sonderzeichen und definierten Sonderzeichenkombinationen sowie sehr große positive oder negative Zahlen. Auch wenn man mit dem Funktionsprinzip von SPIKE (Fuzz-Testing) nicht alle Schwachstellen in Software-Produkten finden kann, so stellt die Verwendung von SPIKE dennoch eine gute Ergänzung innerhalb von Sicherheitsuntersuchungen, beispielsweise bei einer Source-Code-Analyse, dar. Bezugsquelle Zur Zeit der Penetrationstests war die Version 2.9 des SPIKE-Toolsets aktuell. SPIKE wird von der amerikanischen IT-Security Firma ImmunitySec hergestellt und kann im Internet23§ bezogen werden. Installation SPIKE wurde unterhalb des Ordners /root/bsi_tomcat installiert: debian-template:~/bsi_tomcat/pentests# tar zxf /tmp/SPIKE2.9.tgz.gz debian-template:~/bsi_tomcat/pentests# cd SPIKE/SPIKE/src/ debian-template:~/bsi_tomcat/pentests/SPIKE/SPIKE/src# ./configure && make 3.9.2 Benutzung von SPIKE Für die Verwendung von SPIKE als Fuzz-Tester bei HTTP-Protokollen wird die Erzeugung des SPIKE-Programms durch das Werkzeug makewebfuzz.pl erleichtert. Die einzelnen Schritte für das Fuzz-Testing teilen sich in die folgenden Punkte auf: • Netzwerkmitschnitt als Datei abspeichern, • SPIKE-Programm erzeugen, 23 http://www.immunitysec.com/downloads/SPIKE2.9.tgz Seite 49 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten • SPIKE-Programm kompilieren und • SPIKE-Programm ausführen. Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Netzwerkmittschnitt Voraussetzung für die Benutzung von SPIKE ist ein vorhandener Netzwerkmitschnitt des zu untersuchenden Netzwerkdienstes. Ein beispielhafter Netzwerkmitschnitt ist in Abbildung 3.4 dargestellt. Abbildung 3.4: Netzwerkmitschnitt einer HTTP-Anfrage Übersetzung zum C-Programm Mit dem SPIKE-Werkzeug makewebfuzz.pl wird nun aus dem Netzwerkmitschnitt automatisch eine Datei mit C-Source-Code erzeugt. Diese Datei trägt den Namen webfuzz.c und wird nach individueller Anpassung übersetzt und zur Ausführung gebracht. Unter der Voraussetzung, dass der HTTP-Netzwerkmitschnitt als Datei request.txt abgespeichert wurde, lautet der Befehl zur Erzeugung des SPIKE Programms webfuzz.c folgendermaßen: SPIKE_HOME=/root/bsi_tomcat/pentest/SPIKE/SPIKE/src cd $SPIKE_HOME ./makewebfuzz.pl request.txt >webfuzz.c Bundesamt für Sicherheit in der Informationstechnik Seite 50 (von 187) Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Der nachfolgende Source-Code zeigt einen Ausschnitt aus der Datei webfuzz.c, aus dem deutlich wird, wie man die Eigenschaften der einzelnen Bestandteile des Netzwerkprotokolls entweder als Variable oder als Konstante definieren kann. Variable Teile werden im Rahmen des Fuzz-Testings, in vielen Wiederholungen mit verschiedenen Inhalten gefüllt, konstante Teile jedoch nicht verändert. ... /*end webfuzzprelude.c */ s_setfirstvariable(); s_string("GET "); s_string("/simple_info1/index.jsp"); s_string(" HTTP/1.1"); s_string("\r\n"); s_string("Host: localhost\r\n"); s_string("User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/2 0050825 Firefox/1.0.4 (Debian package 1.0.4-2sarge3\r\n"); s_string("Accept: "); s_string("text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/pl ain;q=0.8,image/png,*/*;q=0.0"); s_string("\r\n"); s_string("Accept-Language: en-us,en;q=0.0\r\n"); s_string("Accept-Encoding: gzip,deflate\r\n"); s_string("Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.0\r\n"); s_string("Connection: close\r\n"); s_string("Authorization: "); s_string_variable("Basic bWVtd3VzZXI6dm13YXJl"); s_string("\r\n"); s_string("Pragma: no-cache\r\n"); s_string("Cache-Control: no-cache\r\n"); s_string("\r\n"); /*Done with Headers*/ s_string("\r\n"); s_block_start("post"); s_setfirstvariable(); s_block_end("post"); /* Start webfuzzpostlude.c */ if (spike_send_tcp(target,port)==0) { printf("Couldn't connect to host or send data!\r\n"); /*exit(-1);*/ ... Kompilation des C-Programms / Durchführen des Fuzz Testing Ist das Programm webfuzz.c so angepasst, wie man es für den jeweiligen Test benötigt, so wird das Programm kompiliert und zur Ausführung gebracht. SPIKE_HOME=/root/bsi_tomcat/pentest/SPIKE/SPIKE/src cd $SPIKE_HOME gcc -o webfuzz -I ../include/ spike.o listener.o hdebug.o tcpstuff.o spike_dcerpc.o base64.o udpstuff.o spike_oncrpc.o webfuzz.c ./webfuzz localhost 80 >ergebnis.txt In diesem Beispiel wird das Ergebnis der Fuzz-Tests in der Datei ergebnis.txt abgelegt. Seite 51 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 3.9.3 Ethereal Zum Erstellen der Netzwerkmitschnitte wurde das Programm Ethereal verwendet. Abbildung 3.5 zeigt eine beispielhafte Konfiguration von ethereal zum Mitschneiden des Netzwerkverkehrs auf Port 80/tcp (HTTP). Abbildung 3.5: Konfiguration von Ethereal für das Mitschneiden von HTTP 3.9.4 OpenSSL OpenSSL wird verwendet, um automatisiert SSL-verschlüsselte HTTP-Anfragen, im Folgenden HTTPS-Anfragen genannt, an den Webserver zu stellen. Die folgende Befehlskette führt eine automatisierte HTTPS-Anfrage durch. echo -e „GET / HTTP/1.0\r\n\r\n“ | openssl s_client -connect localhost:443 -quiet 2>/dev/null Die Zeichenkette „GET / HTTP/1.0 <zweimal Zeilenumbruch>“ ist die eigentliche HTTPAnfrage, die in SSL getunnelt wird. Der Parameter „localhost:443“ ist der Hostname und die Port-Nummer, unter welcher der SSL Webserver ansprechbar ist. Bundesamt für Sicherheit in der Informationstechnik Seite 52 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Softwarekomponenten Für die HTTPS-Anfragen, die während der Tests durchgeführt wurden, musste sich der HTTPS-Client mit einem SSL-Client-Zertifikat am SSL-Webserver authentisieren. Dies wurde durch folgendes Shell-Script umgesetzt. #!/bin/bash echo -e "GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n"|openssl s_client \ -connect localhost:443 -cert memuser10.pem \ -key memuser10.key \ -CAfile /root/bsitomcat_ca/ssl/ca/ca.pem \ -quiet 3.10 Werkzeuge für statische Tests Unter statischen Tests werden diejenigen verstanden, bei denen es im Gegensatz zu dynamischen Tests nicht zur Ausführung der untersuchten Software kommt. Source-CodeReviews und die Programmanalyse gehören zu den Methoden des statischen Testen, Penetrationstests zu denen des dynamischen Testen. 3.10.1 Flawfinder und Splint für C Sowohl flawfinder und splint sind in Debian als Pakete enthalten und werden daher beispielsweise über aptitude installiert. Beide lassen sich von der Kommandozeile aus aufrufen. Angenehmer wird deren Einsatz jedoch innerhalb des Texteditors emacs, weil dann die monierten Zeilen des Quellcode mit einem Mausklick angesprungen und begutachtet werden können. Die nächste Abbildung Seite 53 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten zeigt Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers ein Anwendungsbeispiel: Abbildung 3.6: splint, angewendet auf eine Datei, innerhalb von Emacs Bundesamt für Sicherheit in der Informationstechnik Seite 54 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Softwarekomponenten Diese Erleichterung erreicht man unter Verwendung des Compile-Modus von Emacs: C-u M-x compile Daraufhin ersetzt man den Vorschlag (den Aufruf von make) durch beispielsweise: splint +unixlib "-Du_int8_t=unsigned char" "-Du_int16_t=unsigned short" "-Du_int32_t=unsigned int" -DJK_PRODUCTION=1 jk_ajp14.c 3.10.2 Findbugs für Java Die wenigsten Werkzeuge sind fähig, unterschiedliche Programmiersprachen zu analysieren. Quellcode in Java lässt sich auch mit emacs, ergänzt durch spezielle Hilfspakete, bearbeiten. Manche werden jedoch die spezialisierte grafische Entwicklungsumgebung Eclipse24 vorziehen. Diese bietet viele winzige Schaltflächen und Aktionen, mit denen beispielsweise die Signatur einer Methode, die aktuelle Superklasse der Vererbungshierarchie oder auch die Kurzdokumentation zur Methode unter dem Mauszeiger eingeblendet werden können. Darüberhinaus stellt Eclipse Erweiterungsmechanismen zur Einbettung unabhängiger Module bereit. So unterstützt Eclipse nicht nur Java, sondern auch die Programmiersprache C++. Insbesondere aber lässt sich das Werkzeug findbugs25 in die Benutzeroberfläche von Eclipse integrieren. Daraufhin werden dessen Meldungen im gleichen Fenster angezeigt wie die sonstigen Meldungen des Java-Compilers. Dies zeigt folgende Abbildung: 24 25 http://www.eclipse.org/ http://findbugs.sourceforge.net/ Seite 55 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 3.7: Meldungen von Findbugs innerhalb von Eclipse Wir haben Eclipse in der während des Projekts aktuellen Version 3.1.1 direkt aus dem Internet26 bezogen, anstatt die in Debian enthaltene Version 3.0 zu verwenden. Aufgrund verschiedener in der Version 3.0 enthaltener Fehler können wir derzeit nur den Einsatz der Version 3.1 oder 3.1.1 empfehlen. Installiert wurde daraufhin nicht in ein zentrales Verzeichnis, sondern in ein Benutzerverzeichnis wie $HOME/eclipse/. Findbugs wird in Eclipse installiert, indem das Archiv de.tobject.findbugs_0.0.17.rc1.zip27 entgegen der Dokumentation nicht in das Verzeichnis eclipse/, sondern in das Unterverzeichnis eclipse/plugins/ extrahiert wird. Daraufhin erkennt Eclipse beim nächsten Start das Plugin und es kann in das Projekt einbezogen werden. Die nächste Abbildung zeigt, wie Findbugs gemäß dessen Dokumentation aktiviert wird. Innerhalb des Projektmenüs erscheint eine zusätzliche Schaltfläche. 26 27 http://www.eclipse.org/downloads/index.php http://sourceforge.net/project/showfiles.php?group_id=96405 Stichwort Eclipse Plugin Bundesamt für Sicherheit in der Informationstechnik Seite 56 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Installation der Softwarekomponenten Abbildung 3.8: Menü Projekt → Properties → FindBugs Es gibt noch weitere Werkzeuge für die Code-Analyse speziell für Java. Die meisten begnügen sich jedoch mit syntaktischen Analysen und Aufbereitungen. Datenflussanalysen kommen leider selten vor. Ein Beispiel einer einfachen Analyse ist das Erkennen von leeren Catch-Blöcken im Programmcode. Dessen Vorkommen weist auf fragwürdiges ExceptionHandling hin, denn damit werden die Fehlermeldungen des betroffenen Teils des Programms einfach unterdrückt und die Fehler bleiben so unerkannt. Dennoch soll das einigermaßen beliebte Werkzeug pmd28 erwähnt werden. Auch dieses Werkzeug kann helfen, Fehler in Programmen zu finden. Da wir bei unseren Sicherheits­ analysen aber eher an tiefer gehenden Analysen interessiert waren, kam dieses Werkzeug im Projekt nicht zum Einsatz. pmd arbeitet auf Ebene des Quellcode in Java, während findbugs den erzeugten Bytecode, also die .class-Dateien und auch die .jar-Archive für die JVM analysiert. Dies lässt unter­ schiedliche Anwendungsgebiete zu, die hier jedoch nicht von Bedeutung sind. 28 http://pmd.sourceforge.net/ Seite 57 (von 187) Bundesamt für Sicherheit in der Informationstechnik Installation der Softwarekomponenten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 3.10.3 Java-Dokumentation Für die Zwecke des Software-Review ist es ganz nützlich, die Dokumentation zum Java SDK ebenfalls zu installieren. Die gleiche Dokumentation ist ebenfalls online erreichbar29. Das nach Akzeptieren der Lizenzvereinbarung von Sun zum Download bereitgestellte Paket30 ist enorm groß (ca. 50 MB an Dokumentation, gepackt), dennoch sind in den HTML-Seiten zahlreiche Querverweise auf weitere Dokumente auf dem Webserver von Sun zu Java31 enthalten. Die Dokumentation zu den zahlreichen APIs ist nach Installation vollständig lokal verfügbar und enthält ebenfalls nützliche Dokumente zu JCE, JSSE, JAAS. Hinweis: Eclipse ist selbst ohne dieses Paket in der Lage, zu zahlreichen Methoden die Kurzdokumentation einzublenden. Darüber hinaus wurden für das Software-Review noch zahlreiche Online-Quellen verwendet, darunter die Online-Dokumentation zum Apache httpd32, zum Apache Portable Runtime (APR)33 und zu commons-logging für Java (JCL)34. 29 30 31 32 33 34 http://java.sun.com/j2se/1.5.0/docs/index.html http://java.sun.com/j2se/1.5.0/download.jsp#docs http://java.sun.com/ http://httpd.apache.org/docs/2.0/developer/ sowie http://docx.webperf.org/group__APACHE__CORE__LOG.html http://apr.apache.org/docs/apr/globals.html http://jakarta.apache.org/commons/logging/ Bundesamt für Sicherheit in der Informationstechnik Seite 58 (von 187) Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 4. Einrichtung der Authentisierungsinformationen 4.1 Einrichtung von Test-Benutzerkonten auf Betriebssystemebene Um die verschiedenen Tests nicht als Benutzer root durchführen zu müssen, werden mit Hilfe des Skriptes install_dusers.sh zwei Benutzer duser1 und duser2, jeweils mit dem LoginPasswort vmware, auf der Betriebssystemebene eingerichtet. Von diesen Benutzerkonten aus können die verschiedenen Webanwendungen per Browser aufgerufen werden, wobei je nach Test-Szenario verschiedene Web-Identitäten zum Einsatz kommen können, deren Einrichtung im folgenden Abschnitt beschrieben ist. 4.2 Einrichtung von Test-Benutzerkonten für die Web-Authentisierung Zum Test der verschiedenen Web-Authentisierungsvarianten wird ein konsistentes WebBenutzer-Schema verwendet. In eckigen Klammern [] sind dabei die im Feinkonzept [Tomcat Fein.] der Projektphase 1 sowie in den nachfolgenden Tabellen der durchgeführten Tests verwendete Kurzbezeichnung mit aufgeführt: • Memory Realm [User] • JDBC Realm in Verbindung mit einer MySQL-Datenbank [JDBC] • JNDI Realm in Verbindung mit einem OpenLDAP-Server [JNDI] Hierbei werden für jede Authentikationsvariante die Nutzer • admin (Rolle: admin) • manager (Rolle: manager) • user1 (Rolle: user1) • user2 (Rolle: user2) eingerichtet, wobei dem Web-Benutzernamen der Realm-Typ • mem: für Memory Realm • jdbc: für JDBC Realm • jndi: für JNDI Realm vorangestellt wird. Die Rollen admin bzw. manager werden in Verbindung mit den den Tomcat-Administrationsanwendungen aus dem jakarta-tomcat-5.5.9-admin.tar.gz Paket benötigt. Zum Test der Unterscheidung von Klartext-Passworten und Digest-Passworten, die per MD5-Digest aus den Klartext-Passworten gewonnen werden, wird bei den Benutzern mit Digest-Passworten die Benutzernamenserweiterung hash angehängt. Somit erhält man folgendes Benutzer-Schema: Seite 59 (von 187) Bundesamt für Sicherheit in der Informationstechnik Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einrichtung der Authentisierungsinformationen Benutzer mem Re jdbc al m jndi admin memadmin manager memmanager user1 memuser1 user2 memuser2 memadminhash memmanagerhash memuser1hash memuser2hash jdbcadmin jdbcmanager jdbcuser1 jdbcuser2 jdbcadminhash jdbcmanagerhash jdbcuser1hash jdbcuser2hash jndiadmin jndimanager jndiuser1 jndiuser2 jndiadminhash jndimanagerhash jndiuser1hash jndiuser2hash Tabelle 1 Verfügbare Benutzer für die verschiedenen Authentisierungsvarianten Zur Vereinfachung der Tests wird für alle Benutzer einheitlich das Passwort vmware verwen­ det. Dies entspricht einem in Verbindung mit dem <Realm>-Attribut digest=“MD5“ verwen­ deten MD5-Digest-Wert von 92963abd36c896b93a36b8e296ff3387, der mit dem Kommando $CATALINA_HOME/bin/digest.sh -a MD5 vmware erzeugt wurde. In der vorliegenden Testumgebung sind zwar alle Kombinationen vorhanden, in Abhängigkeit von dem jeweils gesetzten bzw. nicht gesetzten <Realm>-Attribut digest=“MD5“ in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml sind aber jeweils nur die Digest-User / -Passworte Non-Digest-User / -Passworte verwendbar. Für die Tests wurde eine server.xml Datei erzeugt, deren unterschiedliche Abschnitte bezüglich der Authentisierung durch XML-Kommentare <!-- ... --> aktiviert bzw. deaktiviert werden können. Nach einer Änderung ist der Tomcat Servlet Container neu zu starten. Außerdem muss gewährleistet sein, dass der OpenLDAP-Daemon slapd bzw. die MySQL-Datenbank (mysqld) aktiv sind und die Datenbanken mit entsprechenden Benutzerinformationen gefüllt sind, wenn auf diesem Weg eine Authentisierung erfolgen soll. Für CLIENT-CERT-basierte Authentisierung sind darüber hinaus noch Einträge für zugelas­ sene Zertifikate und deren Rollenzuordnung in der Datei tomcat_users.xml zu erzeugen (s. hierzu S. 78). 4.3 Initialisierung der tomcat_users.xml Datei Für eine Memory Realm-basierte Authentisierung $CATALINA_HOME/conf/tomcat_users.xml verwendet: wird die folgende Datei Listing 18: Tomcat-Benutzer-Definitionsdatei tomcat_users.xml: <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="admin"/> <role rolename="manager"/> <role rolename="user1"/> <role rolename="user2"/> <user username="memadmin" password="vmware" roles="admin"/> <user username="memadminhash" password="92963abd36c896b93a36b8e296ff3387" roles="admin"/> <user username="memmanager" password="vmware" roles="manager"/> Bundesamt für Sicherheit in der Informationstechnik Seite 60 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einrichtung der Authentisierungsinformationen <user username="memmanagerhash" password="92963abd36c896b93a36b8e296ff3387" roles="manager"/> <user username="memuser1" password="vmware" roles="user1"/> <user username="memuser1hash" password="92963abd36c896b93a36b8e296ff3387" roles="user1"/> <user username="memuser2" password="vmware" roles="user2"/> <user username="memuser2hash" password="92963abd36c896b93a36b8e296ff3387" roles="user2"/> </tomcat-users> 4.4 Initialisierung der MySQL-Datenbank mit den Authentisierungsinformationen Zur Erstellung der zur JDBC Realm-basierten Authentisierung benötigten Datenbank, die Tabellen und Tabelleninhalte im MySQL-DBMS wird das Skript mysql_init_db.sql verwendet, das aus der MySQL-Kommandozeile per mysql> source mysql_init_db.sql ausgeführt wird. Darin werden die benötigte Datenbank, die einzelnen Tabellen, deren Tabelleninhalte sowie die Benutzer-Zugriffsberechtigungen auf diese Inhalte definiert. Listing 19: MySQL-Initialisierungsdatei mysql_init_db.sql ############################################################ # MySQL setup script for # JDBC based web application authentication ############################################################ ############################################################ # setup the database ############################################################ create database authority; use authority; ############################################################ # define the record structure # (we use 35 characters for all elements to allow for # storing MD5 hashes) ############################################################ create table users ( user_name varchar(35) not null primary key, user_pass varchar(35) not null ); create table user_roles ( user_name varchar(35) not null, role_name varchar(35) not null, primary key (user_name, role_name) ); ############################################################ # populate the users table with the predefined examples ############################################################ Seite 61 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers insert into users (user_name,user_pass) values ('jdbcadmin','vmware'), ('jdbcadminhash','92963abd36c896b93a36b8e296ff3387'), ('jdbcmanager','vmware'), ('jdbcmanagerhash','92963abd36c896b93a36b8e296ff3387'), ('jdbcuser1','vmware'), ('jdbcuser1hash','92963abd36c896b93a36b8e296ff3387'), ('jdbcuser2','vmware'), ('jdbcuser2hash','92963abd36c896b93a36b8e296ff3387'); ############################################################ # populate the user_roles table ############################################################ insert into user_roles (user_name,role_name) values ('jdbcadmin','admin'), ('jdbcadminhash','admin'), ('jdbcmanager','manager'), ('jdbcmanagerhash','manager'), ('jdbcuser1','user1'), ('jdbcuser1hash','user1'), ('jdbcuser2','user2'), ('jdbcuser2hash','user2'); ############################################################ # setup a user to perform JDBC queries ############################################################ grant update,select on authority.* to [email protected] identified by "jdbcpass"; ############################################################ # report the current table setups ############################################################ select * from authority.users; select * from authority.user_roles; select * from mysql.db; ############################################################ # -- eof -############################################################ 4.5 Initialisierung der LDAP-Datenbank mit den Authentisierungsinformationen Basierend auf den bei der Installation des Betriebssystems gemachten LDAP-Konfigurations­ angaben (s. S. 25) werden die Informationen für eine JNDI Realm-basierte Authentisierung in die LDAP-Datenbank aufgenommen. Hierfür wurde das Skript setup_openldap.sh erstellt, das die LDAP-Datenbank neu anlegt: Listing 20: LDAP-Initialisierungsskript setup_openldap.sh #!/bin/bash ############################################################ # setup_openldap.sh ############################################################ Bundesamt für Sicherheit in der Informationstechnik Seite 62 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einrichtung der Authentisierungsinformationen # reinitialize the LDAP database OPENLDAP_LIB_DIR=`egrep -e "^directory" /etc/ldap/slapd.conf | cut -f 2 -d \"` if [ -z "$OPENLDAP_LIB_DIR" ] || [ ! -d $OPENLDAP_LIB_DIR ] ; then echo "#E# OPENLDAP_LIB_DIR undefined or not existing" exit 1 fi echo "#I# stopping slapd" /etc/init.d/slapd stop echo "#I# Purging OpenLDAP OPENLDAP_LIB_DIR $OPENLDAP_LIB_DIR" echo "#I# removing existing directory" rm -rf $OPENLDAP_LIB_DIR echo "#I# recreate OpenLDAP database" mkdir $OPENLDAP_LIB_DIR slapadd -v -l openldap_debian_init.ldif slapadd -v -l openldap_init.ldif echo "#I# restarting slapd" /etc/init.d/slapd start ############################################################ # -- eof -############################################################ Dieses Skript verwendet die in der Datei openldap_init.ldif eingetragen Benutzer- und Rollen­ definitionen: Listing 21: LDAP-Benutzer- bzw. Rollendefinitionsdatei openldap_init.ldif ############################################################ # Initialization LDIF file for # JNDI based web application authentication ############################################################ ############################################################ # Define an entry to contain people # # Searches for users are based on this entry dn: ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: organizationalUnit ou: people #----------------------------------------------------------# define entries for every user #----------------------------------------------------------# Define a user entry for "jndiadmin" dn: uid=jndiadmin,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: inetOrgPerson uid: jndiadmin sn: jndiadmin cn: jndiadmin userPassword: vmware # Define a user entry for "jndiadminhash" dn: uid=jndiadminhash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: inetOrgPerson uid: jndiadminhash Seite 63 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers sn: jndiadminhash cn: jndiadminhash userPassword: 92963abd36c896b93a36b8e296ff3387 # Define a user entry for "jndimanager" dn: uid=jndimanager,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: inetOrgPerson uid: jndimanager sn: jndimanager cn: jndimanager userPassword: vmware # Define a user entry for "jndimanagerhash" dn: uid=jndimanagerhash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: inetOrgPerson uid: jndimanagerhash sn: jndimanagerhash cn: jndimanagerhash userPassword: 92963abd36c896b93a36b8e296ff3387 # Define a user entry for "jndiuser1" dn: uid=jndiuser1,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: inetOrgPerson uid: jndiuser1 sn: jndiuser1 cn: jndiuser1 userPassword: vmware # Define a user entry for "jndiuser1hash" dn: uid=jndiuser1hash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: inetOrgPerson uid: jndiuser1hash sn: jndiuser1hash cn: jndiuser1hash userPassword: 92963abd36c896b93a36b8e296ff3387 # Define a user entry for "jndiuser2" dn: uid=jndiuser2,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: inetOrgPerson uid: jndiuser2 sn: jndiuser2 cn: jndiuser2 userPassword: vmware # Define a user entry for "jndiuser2hash" dn: uid=jndiuser2hash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: inetOrgPerson uid: jndiuser2hash sn: jndiuser2hash cn: jndiuser2hash userPassword: 92963abd36c896b93a36b8e296ff3387 ############################################################ # Define an entry to contain LDAP groups # # Searches for roles are based on this entry dn: ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: organizationalUnit ou: groups #----------------------------------------------------------# define entries for every role #----------------------------------------------------------- Bundesamt für Sicherheit in der Informationstechnik Seite 64 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einrichtung der Authentisierungsinformationen # Define an entry for the "admin" role dn: cn=admin,ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: groupOfUniqueNames cn: admin uniqueMember: uid=jndiadmin,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de uniqueMember: uid=jndiadminhash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de # Define an entry for the "manager" role dn: cn=manager,ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: groupOfUniqueNames cn: manager uniqueMember: uid=jndimanager,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de uniqueMember: uid=jndimanagerhash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de # Define an entry for the "user1" role dn: cn=user1,ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: groupOfUniqueNames cn: user1 uniqueMember: uid=jndiuser1,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de uniqueMember: uid=jndiuser1hash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de # Define an entry for the "user2" role dn: cn=user2,ou=groups,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: groupOfUniqueNames cn: user2 uniqueMember: uid=jndiuser2,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de uniqueMember: uid=jndiuser2hash,ou=people,dc=bsitomcat,dc=tsi-itcsec,dc=de ############################################################ # -- eof -############################################################ Diese Definitionen ergänzen die bei der Installation des Betriebssystems zur Konfiguration von slapd gemachten Angaben (s. S. 25). Die initiale LDAP-Konfiguration wird zuvor mit dem Kommando slapcat > openldap_debian_init.ldif für ein mögliches künftiges erneutes Aufsetzen der OpenLDAP-Datenbank unmittelbar nach der Erstinstallation und -konfiguration des Betriebssystems, also noch vor der Einbringung der Informationen aus der o. g. Datei openldap_init.ldif, in die Datei openldap_debian_init.ldif gesichert und hat folgenden Inhalt: Listing 22: LDAP-Inhalt aus Betriebssysteminstallation openldap_debian_init.ldif dn: dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: top objectClass: dcObject objectClass: organization o: BSI-Tomcat TSI ITC-Security dc: bsitomcat structuralObjectClass: organization entryUUID: 449e0962-ca90-1029-9b2b-fe9c288508dd creatorsName: cn=anonymous modifiersName: cn=anonymous createTimestamp: 20051006083809Z modifyTimestamp: 20051006083809Z entryCSN: 20051006083809Z#000001#00#000000 Seite 65 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers dn: cn=admin,dc=bsitomcat,dc=tsi-itcsec,dc=de objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword:: e2NyeXB0fVdXOVBDYTJnMXVyRVU= structuralObjectClass: organizationalRole entryUUID: 44a3814e-ca90-1029-9b2c-fe9c288508dd creatorsName: cn=anonymous modifiersName: cn=anonymous createTimestamp: 20051006083809Z modifyTimestamp: 20051006083809Z entryCSN: 20051006083809Z#000002#00#000000 Hinweis: Zur Vereinfachung der Durchführung der Tests mit einer vereinfachten manuellen Änderung von Passworten werden sämtliche Passworte im Klartext gespeichert. Für den Einsatz in einer Wirkumgebung wird empfohlen, neben geeigneten Zugriffsberechtigungen auf die Passwortinformationen durch die Verwendung geeigneter LDAP Access Control Listen (ACL) Einträge die Passworte nur als Hashwert in der Datenbank abzulegen. Für die JNDI-Authentisierung hat dies keine Folge, da das von Tomcat an den OpenLDAP Server weitergereichte Passwort dann ggf. vor einem Vergleich mit dem in der Datenbank gespeicherten Wert gleichfalls in einen Hashwert umgesetzt wird. 4.6 Konfiguration des LDAP-Browsers gq Zur Durchführung von späteren Änderungen an den Authentisierungsinformationen in der LDAP-Datenbank wird der gq LDAP-Browser verwendet, der für eine Verbindung mit dem LDAP-Server wie folgt konfiguriert wird: Nach dem Start von gq wird die Konfiguration über das Menü File → Preferences, Reiter Server mit den in Abschnitt 2.2 bei der Konfiguration des LDAP-Servers angegebenen Parametern vorgenommen: Bundesamt für Sicherheit in der Informationstechnik Seite 66 (von 187) Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 4.1.: Allgemeine Einstellungen zum LDAP-Server Zur Änderung von Passworten erfolgt die Anmeldung als LDAP-Administrator an den LDAPServer mit dem BIND-DN cn=admin,dc=bsitomcat,dc=tsi-itcsec,dc=de . Seite 67 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 4.2.: Verbindungseinstellungen zum LDAP-Server Über den „Browse“ Reiter im Hauptfenster kann nun eine Verbindung zum LDAP-Server durchgeführt werden, wobei das konfigurierte Passwort für den LDAP-Administrator vmware zu verwenden ist. Abbildung 4.3.: In der LDAP-Datenbank gespeicherte Informationen zu einem Benutzer Bundesamt für Sicherheit in der Informationstechnik Seite 68 (von 187) Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Mit Hilfe des gq LDAP-Browsers können nun die benötigten Änderungen vorgenommen werden. 4.7 Erzeugung einer CA und Generierung von SSL-Server- und Client-Zertifikaten Für die Zertifikat-basierte Client-Authentisierung werden entsprechende Zertifikate benötigt, die im Webbrowser zu installieren sind. Diese Zertifikate sind von einer Certification Authority (CA) zu signieren, mit der die Webanwendungen in einer Vertrauensbeziehung stehen. Um die von der eigenen CA signierten Zertifikate (z. B. Client-Zertifikate) überprüfen zu können, ist das Zertifikat der CA mit dem JAVA keytool in den JAVA Zertifikatspeicher $JAVA_HOME/jre/lib/security/cacerts zu importieren (mit dem Default-Passwort des Zertifikatspeichers changeit). Die nachfolgend beschriebenen Shell-Scripts werden der Einfachheit halber vom Benutzer root ausgeführt. Üblicherweise erzeugt ein Benutzer selbst sein Client-Zertifikat-Request, reicht dieses Zertifikat dann zusammen mit den für die Zertifizierung notwendigen Authentisierungsdoku­ menten bei der CA zur Signierung ein und erhält das signierte Zertifikat zum Import in verschiedene Applikationen wie z. B. den Webbrowser zurück. 4.7.1 Installation einer Certification Authority (CA) Die Installation einer einfachen CA für die hier durchzuführenden Tests erfolgt mit dem Skript setup_ca.sh. Listing 23: CA-Installationsskript setup_ca.sh #!/bin/bash -x ############################################################### # setup a private CA for issueing user certificates # used for certificate based user authentication ############################################################### ## some global setups export CA_ROOT=/root/bsitomcat_ca export export export export JAVA_HOME="/opt/jdk1.5.0_05" JRE_HOME="/opt/jdk1.5.0_05/jre" CATALINA_HOME="/opt/jakarta-tomcat-5.5.9" CATALINA_BASE="/opt/jakarta-tomcat-5.5.9" CA_DIR=${CA_ROOT}/ssl/ca SSL_SERVER_DIR=${CA_ROOT}/ssl/server CLIENT_DIR=${CA_ROOT}/ssl/client CA_PASSWORD=vmware CACERTS_PASSWORD=changeit #-------------------------------------------------------------mkdir -p $CA_ROOT cd $CA_ROOT # remove data from previous installations rm -rf ssl Seite 69 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers ############################################################### # SETTING UP YOUR CA ############################################################### #-------------------------------------------------------------# Create directories to hold your CA keys, your SSL server keys and, # if you want to use SSL client authentication, your client keys. For # the sake of argument let's assume that these directories are called # "${CA_DIR}", "${SSL_SERVER_DIR}" and "${CLIENT_DIR}". mkdir -p ${CA_DIR} ${SSL_SERVER_DIR} ${CLIENT_DIR} #-------------------------------------------------------------# Create a private key and certificate request for your own CA: openssl req -new -newkey rsa:1024 \ -subj "/CN=BSITomcat ITC-Sec CA/L=Bonn/ST=NRW/C=DE/[email protected]/O=BSITomcat ITC-Sec Certification Authority" \ -days 3650 \ -passout pass:${CA_PASSWORD} \ -out ${CA_DIR}/ca.csr \ -keyout ${CA_DIR}/ca.key #-------------------------------------------------------------# Create your CA's self-signed certificate: openssl x509 -trustout \ -signkey ${CA_DIR}/ca.key \ -passin pass:${CA_PASSWORD} \ -days 3650 \ -req -in ${CA_DIR}/ca.csr \ -out ${CA_DIR}/ca.pem #-------------------------------------------------------------# Import the CA certificate into the JDK certificate authorities # keystore: ## ## ## ## !! !! !! !! some www research (at http://mindprod.com/jgloss/keytool.html as well as "man keytool", search for 'cacerts keystore') has shown, that $JAVA_HOME/jre/lib/security/cacerts is protected by the password "changeit" # well, use the actual system wide JDK cacerts keystore # read by Java and tomcat: # purge old version of our CA certificate - if not available # in the keystore, it will generate an error message: # Keytool-Fehler: java.lang.Exception: Alias <bsitomcat_ca> existiert nicht. echo "#I# Subsequent command may generate error if no old certificat exists" ${JAVA_HOME}/bin/keytool -delete \ -keystore $JAVA_HOME/jre/lib/security/cacerts \ -storepass $CACERTS_PASSWORD \ -alias bsitomcat_ca \ -noprompt # import current version of our CA certificate ${JAVA_HOME}/bin/keytool -import \ -keystore $JAVA_HOME/jre/lib/security/cacerts \ -storepass $CACERTS_PASSWORD \ -file ${CA_DIR}/ca.pem \ -alias bsitomcat_ca \ -noprompt #-------------------------------------------------------------- Bundesamt für Sicherheit in der Informationstechnik Seite 70 (von 187) Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers # Create a file to hold your CA's serial numbers. # with the number "2": This file starts echo "02" > ${CA_DIR}/ca.srl # the CA is now ready to sign certificate requests ############################################################### # -- eof -############################################################### Das CA-Zertifikat wird für eine weitere Nutzung auch automatisch in den globalen JAVA Zertifikatspeicher installiert. Abhängig von der Nutzung des globalen JAVA Zertifikat­ speichers ($JAVA_HOME/jre/lib/security/cacerts) oder des Tomcat-Zertifikatspeichers (definiert mit dem Attribut truststoreFile, z. B. $CATALINA_HOME/conf/truststore) ist bei der Konfiguration des SSL-Connectors in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml folgendes zu beachten: • Ist das Attribut truststoreFile (ggf. mit truststorePass) definiert, so wird das CAZertifikat aus dem Tomcat-Zertifikatspeicher verwendet. Dies muss dort vorhanden sein, da ansonsten eine CLIENT-CERT Authentisierung nicht möglich ist. • Ist das Attribut truststoreFile (ggf. mit truststorePass) nicht definiert, so wird das CAZertifikat aus dem globalen Java-Zertifikatspeicher verwendet. Beide Fälle wurden durchgespielt, aber letztlich hauptsächlich der Java-Zertifikatspeicher verwendet. Das in Listing 4.6 dargestellte Skript speichert das CA-Zertifikat in den JavaZertifikatspeicher. Bei Verwendung eines Tomcat-Zertifikatspeichers ist das keytool -import Kommando aus dem Skript entsprechend auf den Tomcat-Zertifikatspeicher anzuwenden. Mit Hilfe dieser CA-Installation können nachfolgend Server-Zertifikate zur Server-Authenti­ sierung beim Aufbau von SSL-Verbindungen wie auch Client-Zertifikate signiert werden. 4.7.2 Erzeugung eines SSL Server-Zertifikats (Tomcat) Zur Authentisierung des Webservers wird beim Aufbau einer SSL-Verbindung ein ServerZertifikat benötigt. Dies wird mit dem Script setup_server_cert.sh durchgeführt und in die Tomcat Installation übertragen. Voraussetzung für das Ausführen dieses Scripts ist das Vorhandensein der im vorigen Schritt generierten CA. Listing 24: Skript zur Erzeugung eines SSL-Server-Zertifikats setup_server_cert.sh #!/bin/bash -x ############################################################### # setup a server certificate required for tomcat SSL server # authentication ############################################################### ## some global setups export CA_ROOT=/root/bsitomcat_ca export export export export JAVA_HOME="/opt/jdk1.5.0_05" JRE_HOME="/opt/jdk1.5.0_05/jre" CATALINA_HOME="/opt/jakarta-tomcat-5.5.9" CATALINA_BASE="/opt/jakarta-tomcat-5.5.9" Seite 71 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers CA_DIR=${CA_ROOT}/ssl/ca SSL_SERVER_DIR=${CA_ROOT}/ssl/server CLIENT_DIR=${CA_ROOT}/ssl/client CA_PASSWORD=vmware WEBSERVER_PASSWORD=vmware #-------------------------------------------------------------# check, if the required CA is already installed if [ ! -d ${CA_DIR} ] ; then echo "#E# $0 requires a CA to be installed" echo "#E# Please run setup_ca.sh first" exit 1 fi #-------------------------------------------------------------mkdir -p $CA_ROOT cd $CA_ROOT # remove data from previous installations rm -rf ${SSL_SERVER_DIR}/{server.crs|server.crt|truststore} ############################################################### # SETTING UP YOUR WEB SERVER ############################################################### #-------------------------------------------------------------# Create directories to hold your CA keys, your SSL server keys and, # if you want to use SSL client authentication, your client keys. For # the sake of argument let's assume that these directories are called # "${CA_DIR}", "${SSL_SERVER_DIR}" and "${CLIENT_DIR}". mkdir -p ${SSL_SERVER_DIR} #-------------------------------------------------------------# Create a keystore for your web server. ${JAVA_HOME}/bin/keytool -genkey \ -alias tomcat \ -keyalg RSA \ -keysize 1024 \ -keystore ${SSL_SERVER_DIR}/.keystore \ -storetype JKS \ -keypass $WEBSERVER_PASSWORD \ -storepass $WEBSERVER_PASSWORD \ -validity 1000 \ -dname "CN=tomcathost, OU=BSI-Tomcat, O= T-Systems International SSC T&S, L=Bonn, ST=NRW, C=DE" #-------------------------------------------------------------# Create a certificate request for your web server. ${JAVA_HOME}/bin/keytool -certreq \ -keyalg RSA \ -alias tomcat \ -file ${SSL_SERVER_DIR}/server.csr \ -storepass $WEBSERVER_PASSWORD \ -keystore ${SSL_SERVER_DIR}/.keystore # You need to edit the certificate request file slightly. Open it up # in a text editor and amend the text which reads "NEW CERTIFICATE # REQUEST" to "CERTIFICATE REQUEST" Bundesamt für Sicherheit in der Informationstechnik Seite 72 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einrichtung der Authentisierungsinformationen sed -e 's/ NEW CERTIFICATE REQUEST/ CERTIFICATE REQUEST/' \ < ${SSL_SERVER_DIR}/server.csr > ${SSL_SERVER_DIR}/server.csr_tmp mv ${SSL_SERVER_DIR}/server.csr_tmp ${SSL_SERVER_DIR}/server.csr #-------------------------------------------------------------# Have your CA sign your certificate request: openssl x509 \ -CA ${CA_DIR}/ca.pem \ -CAkey ${CA_DIR}/ca.key \ -CAserial ${CA_DIR}/ca.srl \ -passin pass:$CA_PASSWORD \ -req \ -in ${SSL_SERVER_DIR}/server.csr \ -out ${SSL_SERVER_DIR}/server.crt \ -days 3650 #-------------------------------------------------------------# Import your signed server certificate into your server keystore: ${JAVA_HOME}/bin/keytool -import \ -alias tomcat \ -storepass $WEBSERVER_PASSWORD \ -keystore ${SSL_SERVER_DIR}/.keystore \ -trustcacerts \ -file ${SSL_SERVER_DIR}/server.crt # You should see a message "Certificate reply was installed in keystore". #-------------------------------------------------------------# Import your CA certificate into your server truststore: ${JAVA_HOME}/bin/keytool -import \ -alias bsitomcat_ca \ -storepass $WEBSERVER_PASSWORD \ -keystore ${SSL_SERVER_DIR}/truststore \ -trustcacerts \ -file ${CA_DIR}/ca.pem \ -noprompt # This step is only necessary if you wish to use SSL client # authentication with Tomcat. #-------------------------------------------------------------# Set up an SSL connector for Tomcat. I assume that you know, or can # find out, how to do this. Open up conf/server.xml in a text editor # and search for the text "keystoreFile". Ensure that the attribute # value is the keystore you've created above. #-------------------------------------------------------------# distribute the certificates and keys files to the tomcat # installation cp -p ${SSL_SERVER_DIR}/.keystore ${SSL_SERVER_DIR}/truststore \ ${CATALINA_HOME}/conf ############################################################### # -- eof -############################################################### Das in Tomcat einzubindende Zertifikat befindet sich nach Abarbeitung dieses Skripts schließlich unter $CATALINA_HOME/conf/.keystore und kann bei der Aktivierung des Seite 73 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Tomcat HTTPS-Connectors in der Datei $CATALINA_HOME/conf/server.xml mit dem gewählten Passwort genutzt werden. Hinweis: Wichtig ist bei der Erzeugung des Server-Zertifikates, dass bei den Eingaben statt eines Inhaber-Namens (Vor- / Nachname) der Hostname des Servers eingetragen wird. Andernfalls gibt der Webbrowser, der eine so konfigurierte Webseite aufruft, eine Warn­ meldung aus, dass der Server-Name und der Name des Zertifikatinhabers nicht überein­ stimmen. 4.7.3 Erzeugung eines SSL Server-Zertifikats (Apache) Um HTTPS-Verbindungen zum Apache Webserver öffnen zu können, muss dieser über ein dazu notwendiges Server-Zertifikat zu seiner Authentisierung gegenüber dem Webbrowser verfügen. Zur Durchführung der Authentisierung muss im Webserver auf den jeweils zum Server-Zertifikat gehörigen privaten Schlüssel zugegriffen werden. Weil Tomcat und Apache diese privaten Schlüssel aber in unterschiedlichen Formaten verwenden, zwischen denen es keine Import- / Exportmöglichkeit gibt, wird für den Apache Webserver mit dem Skript setup_apacheserver_cert.sh ein eigenes Server-Zertifikat erzeugt: Listing 25: Skript zur Erzeugung eines SSL-Server-Zertifikats setup_apacheserver_cert.sh #!/bin/bash -x ############################################################### # setup a server certificate required for Apache SSL server # authentication ############################################################### ## some global setups export CA_ROOT=/root/bsitomcat_ca export export export export JAVA_HOME="/opt/jdk1.5.0_05" JRE_HOME="/opt/jdk1.5.0_05/jre" CATALINA_HOME="/opt/jakarta-tomcat-5.5.9" CATALINA_BASE="/opt/jakarta-tomcat-5.5.9" export HTTPD_HOME="/opt/httpd-2.0.54" CA_DIR=${CA_ROOT}/ssl/ca SSL_SERVER_DIR=${CA_ROOT}/ssl/server CLIENT_DIR=${CA_ROOT}/ssl/client CA_PASSWORD=vmware #-------------------------------------------------------------# check, if the required CA is already installed if [ ! -d ${CA_DIR} ] ; then echo "#E# $0 requires a CA to be installed" echo "#E# Please run setup_ca.sh first" exit 1 fi #-------------------------------------------------------------mkdir -p $CA_ROOT cd $CA_ROOT # remove data from previous installations rm -rf ${SSL_SERVER_DIR}/apache* Bundesamt für Sicherheit in der Informationstechnik Seite 74 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einrichtung der Authentisierungsinformationen ############################################################### # SETTING UP YOUR WEB SERVER ############################################################### #-------------------------------------------------------------# Create directories to hold your CA keys, your SSL server keys and, # if you want to use SSL client authentication, your client keys. For # the sake of argument let's assume that these directories are called # "${CA_DIR}", "${SSL_SERVER_DIR}" and "${CLIENT_DIR}". mkdir -p ${SSL_SERVER_DIR} #-------------------------------------------------------------# Create a certificate request for your apache web server. openssl req -new \ -newkey rsa:2048 \ -nodes \ -out ${SSL_SERVER_DIR}/apache_ssl.csr \ -keyout ${SSL_SERVER_DIR}/apache_ssl.key \ -subj "/CN=tomcathost/L=Bonn/ST=NRW/C=DE/emailAddress=${CLIENT}@bsitomcat.de/O=BSITomcat ITC-Sec" #-------------------------------------------------------------# Have your CA sign your certificate request: openssl x509 \ -CA ${CA_DIR}/ca.pem \ -CAkey ${CA_DIR}/ca.key \ -CAserial ${CA_DIR}/ca.srl \ -passin pass:$CA_PASSWORD \ -req \ -in ${SSL_SERVER_DIR}/apache_ssl.csr \ -out ${SSL_SERVER_DIR}/apache_ssl.crt \ -days 3650 #-------------------------------------------------------------# Import your # - CA certificate # - signed server certificate # - server key # into the respective directories to allow for client certificate # based client authentication and for SSL server authentication mkdir -p ${HTTPD_HOME}/conf/ssl.key ${HTTPD_HOME}/conf/ssl.crt \ ${HTTPD_HOME}/conf/ca.crt cp -p ${CA_DIR}/ca.pem \ ${HTTPD_HOME}/conf/ca.crt/. cp -p ${SSL_SERVER_DIR}/apache_ssl.crt \ ${HTTPD_HOME}/conf/ssl.crt/. cp -p ${SSL_SERVER_DIR}/apache_ssl.key \ ${HTTPD_HOME}/conf/ssl.key/. # keep the original names, but make the files available # under the standard names as used in conf/ssl.conf: for s in key crt ; do cd ${HTTPD_HOME}/conf/ssl.${s} ln -sf apache_ssl.${s} server.${s} done ############################################################### Seite 75 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers # -- eof -############################################################### Das signierte Zertifikat sowie der dazu gehörige private Schlüssel werden in die entsprechenden Verzeichnisse, die in der $APACHE_INSTALL/conf/ssl.conf Konfigurations­ datei der Apache-Installation angegeben sind, kopiert. In dieser Konfigurationsdatei sind noch folgende Ergänzungen durchzuführen, um eine auf Client-Zertifikaten basierende Client-Authentisierung zu ermöglichen. Listing 26: Ergänzungen in der Apache-Konfigurationsdatei ssl.conf SSLVerifyClient require SSLCACertificateFile /opt/httpd-2.0.54/conf/ca.crt/ca.pem SSLVerifyDepth 1 SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth 4.7.4 Erzeugung von Client-Zertifikaten Zur Browser-Authentisierung gegenüber dem Webserver werden in einigen Tests ClientZertifikate verwendet. Diese könne mit dem Skript setup_client_cert.sh generiert werden, das der Einfachheit aus vom Benutzer root ausgeführt wird. Üblicherweise würde ein Benutzer seinen Zertifikat-Request selbst erzeugen, reicht dieses Zertifikat dann zusammen mit den notwendigen Authentisierungsdokumenten bei der CA zur Signierung ein und erhält das signierte Zertifikat zum Import in verschiedene Applikationen wie z. B. den Webbrowser zurück). Das Skript kann optional den Benutzernamen (als erstes Argument, default: memuser1), sowie ggf. ein Zertifikatpasswort (als zweites Argument, default: vmware) erhalten. Listing 27: Skript zur Erzeugung von Client-Zertifikaten setup_client_cert.sh #!/bin/bash -x ############################################################### # setup a client certificate ############################################################### ## some global setups export CA_ROOT=/root/bsitomcat_ca export export export export JAVA_HOME="/opt/jdk1.5.0_05" JRE_HOME="/opt/jdk1.5.0_05/jre" CATALINA_HOME="/opt/jakarta-tomcat-5.5.9" CATALINA_BASE="/opt/jakarta-tomcat-5.5.9" CA_DIR=${CA_ROOT}/ssl/ca SSL_SERVER_DIR=${CA_ROOT}/ssl/server CLIENT_DIR=${CA_ROOT}/ssl/client CA_PASSWORD=vmware # use either the command line arguments for this script # $1: client_name or the default memuser1 # $2: client_password or the default vmware CLIENT=${1:-memuser1} CLIENT_PASSWORD=${2:-vmware} Bundesamt für Sicherheit in der Informationstechnik Seite 76 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einrichtung der Authentisierungsinformationen #-------------------------------------------------------------# check, if the required CA is already installed if [ ! -d ${CA_DIR} ] ; then echo "#E# $0 requires a CA to be installed" echo "#E# Please run 'setup_ca.sh' first" exit 1 fi #-------------------------------------------------------------mkdir -p $CA_ROOT cd $CA_ROOT # remove data from previous installations rm -rf ${CLIENT_DIR}/${CLIENT}* ############################################################### # SETTING UP AN SSL CLIENT ############################################################### #-------------------------------------------------------------# Create directories to hold your CA keys, your SSL server keys and, # if you want to use SSL client authentication, your client keys. For # the sake of argument let's assume that these directories are called # "${CA_DIR}", "${SSL_SERVER_DIR}" and "${CLIENT_DIR}". mkdir -p ${CLIENT_DIR} #-------------------------------------------------------------# Create a client certificate request: openssl req -new \ -newkey rsa:2048 \ -passout pass:$CLIENT_PASSWORD \ -out ${CLIENT_DIR}/${CLIENT}.req \ -keyout ${CLIENT_DIR}/${CLIENT}.key \ -subj "/C=DE/ST=NRW/L=Bonn/O=BSITomcat ITC-Sec/OU=Testlab/CN=${CLIENT}" # The common name of the client must match a user in Tomcat's user # realm (e.g. an entry in conf/tomcat-users.xml) in REVERSE # order: # <user username="CN=${CLIENT}, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, # ST=NRW, C=DE" password="" roles="userrole">. #-------------------------------------------------------------# Have your CA sign your client certificate. openssl x509 \ -CA ${CA_DIR}/ca.pem \ -CAkey ${CA_DIR}/ca.key \ -CAserial ${CA_DIR}/ca.srl \ -passin pass:${CA_PASSWORD} \ -req \ -in ${CLIENT_DIR}/${CLIENT}.req \ -out ${CLIENT_DIR}/${CLIENT}.pem \ -days 3650 #-------------------------------------------------------------# Generate a PKCS12 file containing your server key and server # certificate. # convert to PKCS12 for import by web browser openssl pkcs12 \ -export \ -clcerts \ -in ${CLIENT_DIR}/${CLIENT}.pem \ Seite 77 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers -inkey ${CLIENT_DIR}/${CLIENT}.key \ -out ${CLIENT_DIR}/${CLIENT}.p12 \ -passin pass:${CLIENT_PASSWORD} \ -passout pass:${CLIENT_PASSWORD} \ -name "${CLIENT}_client_certificate" #-------------------------------------------------------------# Import the PKCS12 file into your web browser to use as your client # certificate and key. #-------------------------------------------------------------# Enable client certificate authentication in Tomcat. Open up # conf/server.xml and search for the text "clientAuth". Set the value # of the attribute to "true". ############################################################### # -- eof -############################################################### Zu beachten ist, dass bei der Erzeugung der Client-Zertifikate mit openssl das Element emailAddress nicht verwendet werden sollte, da diese Information nicht als eigenständiger Eintrag im Zertifikat erscheint, sondern offenbar an ein anderes Element angehängt wird. Außerdem ist die Reihenfolge der Attribute des subjectDN zu beachten: Einem subjectDN-Eintrag für die Erzeugung des Client-Zertifikatrequests ... -subj "/C=DE/L=Bonn/ST=NRW/O=BSITomcat ITC-Sec/OU=Testlab/CN=my_username" ... muss ein Eintrag <user username=“CN=my_username, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password=““ roles=“user1“/> in der $CATALINA_HOME/conf/tomcat-users.xml Konfigurationsdatei entsprechen (d. h. mit umgekehrter Reihenfolge der Elemente), um eine CLIENT-CERT Authentisierung erfolgreich durchführen zu können. Außerdem ist es erforderlich, dass das CA-Zertifikat der CA, mit der das Client-Zertifikat signiert wurde, im globalen Java- oder im Tomcat-Zertifikatspeicher vorhanden sein muss. Dort stehen alle CA-Zertifikate, denen z. B. im Hinblick auf die Signierung von Client- oder Benutzer-Zertifikaten vertraut werden soll. Wird hingegen im Rahmen einer lokalen Zertifikatprüfung eines Client- oder Benutzer-Zertifikats das zugehörige CA-Zertifikat nicht in einem der lokalen Zertifikatspeicher vorgefunden, so wird eine Fehlermeldung ausgegeben, dass das Client- bzw. Benutzer-Zertifikat nicht verifiziert werden konnte. Wird der Zugriff auf den Zertifikatspeicher mit einem Passwort geschützt, so muss das Passwort für den Zugriff auf den jeweiligen Zertifikatspeicher in der Konfigurations­ datei $CATALINA_HOME/conf/server.xml spezifiziert sein. Nach der Erzeugung des Client-Zertifikates durch das Skript in Listing 4.10, das das ClientZertifikat für einen Import in den Webbrowser im PKCS12 Format bereitstellen muss, ist das erzeugte Zertifikat noch aus dem Verzeichnis /root/bsitomcat_ca/ssl/client in ein Verzeichnis zu kopieren, auf das vom entsprechenden Benutzer lesend zugegriffen werden kann.35 Dieses Zertifikat ist für eine Verwendung anschließend in den benutzten Webbrowser zu importieren. Am Beispiel des Webbrowsers Firefox werden die benötigten Schritte nach­ folgend zusammengefasst: 35 Dies entspricht der Lieferung des signierten Zertifikats durch die CA an den Benutzer. Bundesamt für Sicherheit in der Informationstechnik Seite 78 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einrichtung der Authentisierungsinformationen Im Webbrowser Firefox wird unter Edit→Preference→Advanced im Abschnitt Certificates das Fenster zur Zertifikatverwaltung geöffnet: Abbildung 4.4.: Zertifikatverwaltung im Browser Firefox Mit der Schaltfläche „Manage Certificates ...“ wird das Zertifikate-Verwaltungsfenster geöffnet: Seite 79 (von 187) Bundesamt für Sicherheit in der Informationstechnik Einrichtung der Authentisierungsinformationen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 4.5.: Zertifikatimport Das zuvor erzeugte Zertifikat kann nun über die Schaltfläche „Import“ importiert werden, wobei der Dateiname des Zertifikats in einem weiteren Popup-Fenster einzugeben ist. Beim Import ist das bei der Zertifikaterstellung verwendete Passwort anzugeben: Abbildung 4.6.: Passwortabfrage zum Importieren Der erfolgreiche Zugriff auf das in der Importdatei vorhandene Zertifikat und dessen Import wird bestätigt. Bundesamt für Sicherheit in der Informationstechnik Seite 80 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Einrichtung der Authentisierungsinformationen Abbildung 4.7.: Bestätigung des erfolgreichen Imports des Zertifikats Das importierte Zertifikat wird in der Übersicht der vorhandenen Zertifikate angezeigt und steht nach Abschluss des Importes zur Verwendung zur Verfügung. Abbildung 4.8.: Übersicht über die nun im Webbrowser vorhandenen Zertifikate Hinweis: Falls der Zertifikatspeicher des Webbrowsers Firefox durch ein Passwort geschützt ist, das bei erstmaliger Benutzung der Zertifikat-Management-Funktionen gesetzt werden kann, ist abweichend von der dargestellten Vorgehensweise bei Zugriffen auf den Zertifikatspeicher dieses Passwort (ggf. an mehreren Stellen) auf Anfrage einzugeben. Seite 81 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 5. Durchführung der Tests Die nachfolgend beschriebenen Tests wurden der Feinspezifikation [Tomcat Fein.] aus der Projektphase 1 entnommen und mit den gewonnenen Ergebnissen ergänzt. Hinweis: In den URLs der nachfolgenden Tests ist der Hostname tomcathost synonym zu localhost und wurde in der Datei /etc/hosts nachgetragen. Das für HTTPS / SSL benötigte Server-Zertifikat wurde auf den Host tomcathost ausgestellt. Dies kann zur Überprüfung der Ausgabe einer Warnung im Webbrowser verwendet werden, die erscheinen sollte, wenn sich der Hostname in der vom Webbrowser verwendeten URL und im Server-Zertifikat unter­ scheiden. 5.1 Funktionale Tests der Sicherheitsfunktionen von Tomcat Ziel dieser Tests ist es festzustellen, • ob es möglich ist, die Sicherheitsfunktionen von Tomcat zu umgehen und • ob die Sicherheitsfunktionen von Tomcat der Dokumentation entsprechen. Bei den Tests wird überprüft, welche Arbeitsschritte Tomcat durchführt, wenn die jeweilige Sicherheitsfunktion von Tomcat verwendet wird. Die Analyse besteht dabei im wesentlichen aus der Auswertung der Netzkommunikation der beteiligten Kommunikationspartner und der Sichtung der Tomcat Protokolldateien bei geeignet eingestelltem Debug-Level. Die Tomcat Protokoll-Dateien befinden sich in den vorliegenden Testinstallationen im Verzeichnis $CATALINA_HOME/logs. 5.1.1 Funktionale Tests für die Authentisierung Die einzelnen Webanwendungen können verschiedene Authentisierungsmethoden verwen­ den. Es werden daher bei den Tests zwei Anwendungen mit unterschiedlichen Benutzern und Rollen eingesetzt. Die zur Verfügung stehenden Benutzer und Rollen wurden in Abschnitt 4 definiert. Es werden die folgenden Tests durchgeführt: 1. Test1: Ein Benutzer gibt ungültige Authentisierungsinformationen (Kombination von Benutzernamen / Passwort bzw. Client Zertifikat) bei der Authentisierung an einer Webanwendung an. Es wird die Verarbeitung der Authentisierungsinformationen durch Tomcat sowie der Protokollierung ausgewertet. 2. Test2: Ein Benutzer authentisiert sich erfolgreich an einer Webanwendung. Anschließend ruft er eine andere Webanwendung auf, auf die er laut Einstellungen der web.xml-Datei der Webanwendung keinen Zugriff hat. Für diesen Test wird Single Sign On (SSO) eingestellt, da ansonsten für jede Webanwendung eine erneute Authentisierung erforderlich wäre. Der Test wird zunächst mit Anwendungen durchgeführt, die so konfiguriert sind, dass sie die gleiche Authentisierungsmethode gegenüber dem Client einsetzen (z. B. HTTP FORM für beide). Anschließend wird der Test mit Anwendungen wiederholt, die unterschiedliche Authentisierungsmethoden einsetzen (z. B. HTTP FORM für die eine und HTTP BASIC für die andere Anwendung). So wird das Funktionieren des SSO Valves überprüft. Das SSO Valve sollte im Falle der erfolgreichen Authentisierung nur Zugriffsrechte entsprechend der Einstellungen in den web.xml-Dateien der einzelnen Webanwendungen erteilen. Bundesamt für Sicherheit in der Informationstechnik Seite 82 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests 3. Test3: Der Benutzer authentisiert sich erfolgreich. Die Authentisierungsdatenbank wird anschließend geändert. Es wird überprüft, ob dies von Tomcat bemerkt wird. Dies sollte bei dem JDBC Realm und bei dem JNDI Realm in jedem Fall bemerkt werden. Im Falle des File Realms hängt das Erkennen der Änderungen durch Tomcat davon ab, ob die Konfigurationsdatei direkt über einen Datei-Editor oder über die entsprechende Tomcat Web-GUI Anwendung (admin) geändert wurde. Im zweiten Fall, d. h., Änderung über die Web-GUI, sollte die Änderung von Tomcat bemerkt werden. Bei den Tests werden die unterschiedlichen Connectoren von Tomcat, die einsetzbaren Authentisierungsmethoden (BASIC, DIGEST, FORM und CLIENT-CERT) und die von Tomcat unterstützten Methoden, die auf Authentisierungsdatenbestände (Realms: UserDatabase, JDBC (MySQL), JNDI (LDAP)) zugreifen, berücksichtigt. Aufgrund der Architektur von Tomcat – die drei angesprochenen Komponenten sind im Wesentlichen voneinander unabhängig (Ausnahme: Authentisierung über Client Zertifikate) – besteht keine Notwendigkeit alle möglichen Kombinationsmöglichkeiten zu testen. Die vorgesehenen Tests sind in Tabelle 2 zusammengefasst. Test Tomcat­ Authentisierungsmethode/ Testbeschreibung Nr. Connector Benutzerdatenbank T 1 HTTP BASIC User Test1 (s. o.) T2 JDBC Test1 (s. o.) T3 JNDI Test1 (s. o.) User Test1 (s. o.) FORM User Client-Zertifikat User BASIC User Test1 (s. o.) Test1 (s. o.) Test1 (s. o.) DIGEST User Test1 (s. o.) T9 FORM User T 10 AJP1.3 / SSL Client-Zertifikat User T 11 HTTP BASIC User Test1 (s. o.) Test1 (s. o.) Test2 (s. o.) T 12 DIGEST User Test2 (s. o.) T 13 T 14 HTTPS T 15 AJP1.3 FORM User Client-Zertifikat User BASIC User Test2 (s. o.) Test2 (s. o.) Test2 (s. o.) T 16 DIGEST User Test2 (s. o.) T 17 FORM User T 18 AJP1.3 / SSL Client-Zertifikat User T 19 HTTP BASIC User Test2 (s. o.) Test2 (s. o.) Test3 (s. o.) T 20 DIGEST User Test3 (s. o.) T 21 T 22 HTTPS T 23 AJP1.3 FORM User Client-Zertifikat User BASIC User Test3 (s. o.) Test3 (s. o.) Test3 (s. o.) T 24 DIGEST User Test3 (s. o.) T 25 FORM User T 26 AJP1.3 / SSL Client-Zertifikat User Test3 (s. o.) Test3 (s. o.) T4 T5 T6 T7 DIGEST HTTPS AJP1.3 T8 Seite 83 (von 187) Bundesamt für Sicherheit in der Informationstechnik Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Tabelle 2: Funktionale Tests der Authentisierung Die Verwendung der zwei Tomcat Connectoren (HTTP/HTTPS bzw. AJP1.3) entspricht den Einsatzszenarien 1 (HTTP / HTTPS-Verbindung direkt zu Tomcat) bzw. 2 (Verbindung über den AJP1.3-Connector zu Tomcat) des Feinkonzepts [Tomcat Fein.]. Da sich die Authentisierung bei anderen Einsatzszenarien nicht grundlegend unterscheidet, ist eine explizite Berücksichtigung der anderen Einsatzszenarien bei diesem Test nicht sinnvoll. Nach den für die jeweiligen Tests vorgenommenen individuellen Konfigurationseinstellungen wird der Tomcat Servlet Container neu gestartet, um sicherzustellen, dass die Konfigura­ tionseinstellungen auch in den Betrieb übernommen wurden. Außerdem muss ggf. der Webbrowser wegen der Pufferung der Authentisierungsinformatio­ nen nach einmal erfolgter Authentisierung verlassen werden, um sich unter einem anderen Benutzer anmelden zu können. Zur Vorbereitung der nachfolgenden Zugriffsschutz- und Single-Sign-On-Tests werden drei einfache Webanwendungen (simple_info1, simple_info1a, simple_info2) definiert und unter $CATALINA_HOME/webapps installiert. Sie enthalten jeweils die „Top-Level“ Webseite index.jsp und eine weitere confidential.jsp sowie die entsprechende Tomcat-Konfigurations­ datei der Webanwendungen unter WEB-INF/web.xml. Die Zugriffsberechtigungen sind wie folgt vergeben: Webanwendung simple_info1 Datei simple_info1/index.jsp simple_info1/confidential.jsp simple_info1a simple_info1/subdir/moreinfo.jsp simple_info1a/index.jsp simple_info2 simple_info1a/confidential.jsp simple_info2/index.jsp simple_info2/confidential.jsp Freigabe für Rolle, verwendete Authentisierungs­ methode - alle user1, BASIC-Authentisierung user1, FORM-Authentisierung user2, DIGEST-Authentisierung Tabelle 3: Test-Webanwendungen und den Dateien zugeordnete Rollenfreigaben Für jede Webanwendung werden darüber hinaus auch die beiden in Verbindung mit der FORM-Authentisierung benötigten Dateien login.jsp sowie error.jsp installiert, die für alle Benutzer freigegeben sein müssen, da ansonsten durch die Blockierung von noch un­ authentisierten Zugriffen auf diese beiden Dateien keine erfolgreiche Authentisierung durchgeführt werden kann. 5.1.1.1 Ergebnisse zu Test1 Für die Tests der verschiedenen Authentisierungsmethoden können zunächst die mit installierten Applikationen • simple_info1 (für BASIC-Authentisierung), • simple_info1a (für FORM-Authentisierung), Bundesamt für Sicherheit in der Informationstechnik Seite 84 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • Durchführung der Tests simple_info2 (für DIGEST-Authentisierung) verwendet werden, wobei die jeweilige Authentisierungsmethode in der Datei WEBINF/web.xml der Webanwendung spezifiziert wird. Für die Tests wurden, soweit nicht anders angegeben, keine besonderen oder weitergehenden Logging-Optionen aktiviert. Bei den Tests konnte durch das Mitlesen der Netzwerkkommunikation mit dem Werkzeug ethereal verifiziert werden, dass über die HTTP-Verbindung zwischen dem Webbrowser und dem Webserver36 bzw. zwischen dem Webbrowser und dem Tomcat Servlet Container37, die Authentisierungsinformationen in folgenden Fällen im Klartext ausgetauscht werden: • BASIC-Authentisierung: als reversibel Base64-codierte Zeichenkette der Konkatena­ tion von benutzername:passwort mit dem Doppelpunkt als Trennzeichen zwischen Benutzername und Passwort. Damit ist die BASIC-Authentisierung bei einer Verwendung über unsichere Netzwerke (z. B. das Internet), wo der Datenverkehr zwischen dem Webbrowser und dem Webserver abgehört werden kann, nicht als sicher zu betrachten. • FORM-Authentisierung: im Klartext innerhalb eines HTTP-POST Paketes, womit die FORM-Authentisierung gleichfalls nicht als sicher zu betrachten ist. Lediglich bei der DIGEST-Authentisierung kann das Benutzerpasswort nicht einfach aus den übertragenen HTTP-Nachrichten rekonstruiert werden und sollte daher zur Authentisierung über ungeschützte Netzwerke verwendet werden. 5.1.1.1.1 T1: HTTP Connector, BASIC-Authentisierung, Memory Realm Zunächst erfolgt eine Aktivierung der Memory Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet. Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die geschützte Webseite http://tomcathost:8080/simple_info1/confidential.jsp der simple_info1 Anwendung führte zur Ablehnung des Logins ohne Protokollierung einer Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log, woraufhin das Browser-Popup-Fenster zur HTTP-Authentisierung erneut geöffnet wird. Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer memuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins, diesmal mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser. Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer memuser1 und dem Passwort vmware auf die manager Anwendung wurde erfolgreich, aber auch ohne Logdateieinträge, durchgeführt. Ein Neustart des Webbrowsers war erforderlich, da die vorherige Benutzerinformation für den Webbrowser noch gültig war38 und im WebbrowserCache vorlag. Wenn ein erneuter Zugriff auf dieselbe Webseite mit den gleichen Benutzerinformationen versucht worden wäre, hätte dies erneut zur Ablehnung durch den 36 37 38 bei Verwendung von Apache-mod_jk sowie Tomcat mit AJP13 Connector beim Direktzugriff auf den HTTP-Connector von Tomcat Die Fehlermeldung des Webservers war schließlich „HTTP Status 403 - Access denied“ und deutet damit auf ein Zugriffsverbot, nicht aber einen Authentisierungsfehler hin. Seite 85 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Webserver mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied" geführt. Für eine Protokollierung von Fehlzugriffen auf die von Tomcat bereitgestellten Web­ anwendungen sollte eine Aktivierung der Logging-Funktionen gemäß den in Abschnitt 6.3.3 gegebenen Hinweisen beachtet werden. 5.1.1.1.2 T2: HTTP Connector, BASIC-Authentisierung, JDBC Realm Zunächst erfolgt eine Aktivierung der JDBC Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet. Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die Anwendung simple_info1 http://tomcathost:8080/simple_info1/confidential.jsp führte zu einer Ablehnung des Logins und zwar ohne Protokollierung einer Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log. Anschließend wird das Browser-PopupFenster zur Eingabe der HTTP-Authentisierungsdaten erneut geöffnet. Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer jdbcuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser. Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer jdbcuser1 und dem Passwort vmware auf die manager Anwendung wurde erfolgreich aber auch ohne Logdateieinträge durchgeführt. Bei der Nachverfolgung des Netzwerkverkehrs mit dem MySQL-Server (Port 3306) konnte festgestellt werden, dass das in der Datenbank gespeicherte Referenzpasswort für die Authentisierung im Klartext zurück zum Tomcat Servlet Container übertragen wird. Falls diese Übertragung nicht innerhalb eines gesicherten Netzwerkbereiches erfolgt (z. B. bei Aufteilung auf separaten Tomcat-Rechner und MySQL-Rechner), ist das Risiko des Mitlesens von Passwortinformationen zu berücksichtigen. 5.1.1.1.3 T3: HTTP Connector, BASIC-Authentisierung, JNDI Realm Zunächst erfolgt eine Aktivierung der JNDI Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet. Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die simple_info1 Anwendung http://tomcathost:8080/simple_info1/ führte zur Ablehnung des Logins ohne Protokollierung einer Fehlermeldung in $CATALINA_HOME/logs/catalina<datum>.log, woraufhin das Browser-Popup-Fenster zur HTTP-Authentisierung erneut geöffnet wird. Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer jndiuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins, diesmal mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser. Bundesamt für Sicherheit in der Informationstechnik Seite 86 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer jndiuser1 und dem Passwort vmware auf die simple_info1 Anwendung wurde erfolgreich aber auch ohne Logdateieinträge. durchgeführt. Bei der Nachverfolgung des Netzwerkverkehrs mit dem OpenLDAP-Server (Port 389) konnte festgestellt werden, dass das vom Benutzer zur Authentisierung eingegebene Passwort an den OpenLDAP-Server zur dortigen Überprüfung übertragen wird. Falls diese Übertragung nicht innerhalb eines gesicherten Netzwerkbereiches erfolgt (Aufteilung auf separaten Tomcat-Rechner und OpenLDAP-Rechner), ist das Risiko des Mitlesens von Passwortinformationen zu berücksichtigen. 5.1.1.1.4 T4: HTTP Connector, DIGEST-Authentisierung, Memory Realm Zunächst erfolgt eine Aktivierung der Memory Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet. Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die manager Anwendung http://tomcathost:8080/simple_info2/ führte zur Ablehnung des Logins ohne Protokollierung einer Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log. Auch ein Zugriffsversuch mit dem im Test T1 verwendeten Benutzer memuser1 und dem Passwort vmware führte ebenso zu einer Ablehnung des Logins mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser. Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer memuser2 und dem Passwort vmware auf die manager Anwendung wurde erfolgreich, aber auch ohne Logdateieinträge, durchgeführt. Durch die Verwendung • eines vom Webserver gelieferten Zufallswertes, • dem Benutzernamen, • dem Passwort sowie • der Realm-Information wird ein Digest-Wert berechnet und zum Webserver übertragen. Somit sind keine Passwortinformationen bei der Übertragung vom Webbrowser zum Webserver im Klartext bzw. in einfacher Base64-codierter39 Form sichtbar. Dies konnte beim Mitlesen des Netzwerkverkehrs zwischen diesen beiden Kommunikationspartnern verifiziert werden. 5.1.1.1.5 T5.1: HTTP Connector, FORM-Authentisierung, Memory Realm Zunächst erfolgt eine Aktivierung der Memory Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet. 39 wie bei der HTTP BASIC-Authentisierung Seite 87 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die simple_info1a Anwendung http://tomcathost:8080/simple_info1a/ führte zur Ablehnung des Logins ohne Protokollierung der Fehlermeldung in $CATALINA_HOME/logs/catalina<datum>.log und Ausgabe der von der Webanwendung bereitgestellten Fehler-Webseite http://tomcathost:8080/simple_info1a/error.jsp im Webbrowser. Auf die gleiche Weise wurde ein Zugriffsversuch mit dem einer anderen Rolle zugeordneten Benutzer memuser2 und dem Passwort vmware abgewiesen, wobei die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser ausgegeben wurde. Ein nachfolgender Zugriff im neu gestartetem Webbrowser mit dem Benutzer memuser1 und dem Passwort vmware auf die simple_info1a Anwendung wurde erfolgreich und ohne Logdateieinträge durchgeführt. Zu beachten ist bei der Verwendung des FORM-Authentisierungsverfahrens, dass Benutzername und -passwort im Klartext über die HTTP-Verbindung (Tomcat-Frontend) übertragen werden und somit auf dem Weg zwischen dem Webbrowser und dem HTTPConnector von Tomcat abgehört werden kann. Nachfolgend werden der Vollständigkeit halber noch die Varianten JDBC Realm, JNDI Realm sowie Memory Realm mit Digest in Verbindung mit FORM-Authentisierung getestet. 5.1.1.1.6 T5.2: HTTP Connector, FORM-Authentisierung, JDBC Realm Zunächst erfolgt eine Aktivierung der JDBC Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei und ein Restart von Tomcat. Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die simple_info1a Anwendung http://tomcathost:8080/simple_info1a/ führte zur Ablehnung des Logins ohne Protokollierung der Fehlermeldung in $CATALINA_HOME/logs/catalina<datum>.log und Ausgabe der von der Webanwendung bereitgestellten Fehler-Webseite http://tomcathost:8080/simple_info1a/error.jsp im Webbrowser. Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer jdbcuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser. Ein nachfolgender Zugriff im neu gestarteten Webbrowser mit dem Benutzer jdbcuser1 und dem Passwort vmware auf die simple_admin1a Anwendung wurde erfolgreich und ohne Logdateieinträge durchgeführt. Zu beachten ist bei der Verwendung des FORM-Authentisierungsverfahrens, dass Benutzername und -passwort im Klartext über die HTTP-Verbindung (Tomcat-Frontend) übertragen werden und somit auf dem Weg zwischen dem Webbrowser und dem HTTPConnector von Tomcat abgehört werden kann (analog zum vorigen Test T5.1). Bei der Nach­ verfolgung des Netzwerkverkehrs des Tomcat Servlet Containers mit dem MySQL-Server (Port 3306) konnte festgestellt werden, dass das in der Datenbank gespeicherte Referenz­ passwort für die Authentisierung im Klartext zurück zum Tomcat Servlet Container über­ tragen wird. Falls diese Übertragung nicht innerhalb eines gesicherten Netzwerkbereiches Bundesamt für Sicherheit in der Informationstechnik Seite 88 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests erfolgt (Aufteilung auf separaten Tomcat Rechner und MySQL Rechner), ist das Risiko des Mitlesens von Passwortinformationen zu berücksichtigen. 5.1.1.1.7 T5.3: HTTP Connector, FORM-Authentisierung, JNDI Realm Zunächst erfolgt eine Aktivierung der JNDI Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei. Anschließend wird Tomcat neu gestartet. Der Zugriff mit dem Benutzer invaliduser und dem Passwort invalidpassword auf die simple_info1a Anwendung führte zur Ablehnung des Logins ohne Protokollierung der Fehlermeldung in $CATALINA_HOME/logs/catalina-<datum>.log und Ausgabe der FehlerWebseite http://tomcathost:8080/simple_info1a/error.jsp im Webbrowser. Auch ein Zugriffsversuch mit dem für eine andere Rolle eingetragenen Benutzer jndiuser2 und dem zugehörigen gültigen Passwort vmware führte ebenso zu einer Ablehnung des Logins mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser. Ein nachfolgender Zugriff mit dem Benutzer jndiuser1 und dem Passwort vmware auf die simple_info1a Anwendung wurde erfolgreich und gleichfalls ohne Logdateieintrag durch­ geführt. Zu beachten ist bei der Verwendung des FORM-Authentisierungsverfahrens, dass Benutzername und -passwort im Klartext über die HTTP-Verbindung (Tomcat-Frontend) übertragen werden und somit auf dem Weg zwischen dem Webbrowser und dem HTTPConnector von Tomcat abgehört werden kann (analog zum vorigen Test T5.1). Bei der Nachverfolgung des Netzwerkverkehrs des Tomcat Servlet Containers mit dem OpenLDAPServer (Port 389) konnte festgestellt werden, dass das vom Benutzer zur Authentisierung eingegebene Passwort an den OpenLDAP-Server zur dortigen Überprüfung übertragen wird. Falls diese Übertragung nicht innerhalb eines gesicherten Netzwerkbereiches erfolgt (Aufteilung auf separaten Tomcat Rechner und OpenLDAP Rechner), ist das Risiko des Mitlesens von Passwortinformationen zu berücksichtigen. 5.1.1.1.8 T6: HTTPS Connector, Client Zertifikat Authentisierung, Memory Realm Zunächst erfolgt eine Aktivierung der Memory Realm Authentisierungskonfiguration in der $CATALINA_HOME/conf/server.xml Konfigurationsdatei und ein Restart von Tomcat. Weiterhin wird für die Webanwendungen simple_info1a (freigegeben für die Rolle user1) und simple_info2 (freigegeben für die Rolle user2) in der jeweiligen WEB-INF/web.xml Konfigurationsdatei die Authentisierungsmethode von BASIC auf CLIENT-CERT umgestellt. In der $CATALINA_HOME/conf/tomcat-users.xml Datei sind die beiden Zertifikat-gebunde­ nen Benutzer eingetragen, für die entsprechende Client-Zertifikate im Webbrowser vorhanden sein müssen, um die jeweilige Webanwendung aufrufen zu können. Listing 28: Ergänzte Benutzer mit Client Zertifikat Authentisierung in tomcat_users.xml <user username="CN=memuser1, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password="null" roles="user1"/> <user username="CN=memuser2, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password="null" roles="user2"/> Seite 89 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers In Verbindung mit der CLIENT-CERT Authentisierung erfolgt keine Auswertung der unter password eingetragenen Werte (wie dies bei der BASIC-Authentisierung der Fall wäre), sodass hier beliebige Werte eingetragen sein können. Bei einem Zugriff auf eine geschützte Webseite ohne HTTPS-Verbindung (z. B. http://tomcathost:8080/simple_info1a/ bzw. http://tomcathost:8080/simple_info2/) und damit ohne Austausch von Zertifikatinformationen wird der Zugriff mit der Fehlermeldung „HTTP Status 400 – No client certificate chain in this request“ verweigert. Beim HTTPS-Zugriff auf die Webseite mit einem gültigen aber unpassenden Zertifikat (https://tomcathost:8443/simple_info1a/ mit Zertifikat für eine Rollenzuordnung user2 bzw. https://tomcathost:8443/simple_info2/ mit Zertifikat für eine Rollenzuordnung user1) wird der Zugriff mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ verweigert. Beim HTTPS-Zugriff mit einem für die jeweilige Webseite passenden Zertifikat (https://tomcathost:8443/simple_info1a/ mit Zertifikat für eine Rollenzuordnung user1 bzw. https://tomcathost:8443/simple_info2/ mit Zertifikat für eine Rollenzuordnung user2) ist ein Zugriff möglich. Zu beachten ist hierbei, dass durch die Zwischenspeicherung von für die Authentisierung benötigen Informationen im Webbrowser beim Wechsel in eine andere Rolle der Webbrowser neu gestartet werden muss. Die in der HTTPS-Anfrage übertragenen Zertifikatinformationen können mit der in jeder der betrachteten Webanwendungen installierten JSP-Datei request_data.jsp abgefragt werden (z. B. https://tomcathost:8443/simple_info1a/request_data.jsp). 5.1.1.1.9 T7: AJP1.3 Connector, BASIC-Authentisierung, Memory Realm Die Vorgehensweise ist wie bei Test T1 mit geänderter URL http://tomcathost:80/simple_info1/confidential.jsp, um den Zugriff auf die simple_info1 Anwendung über den vorgeschalteten Apache Webserver mit mod_jk – AJP1.3 durchzuführen. Sowohl bei der Nachverfolgung des HTTP-Netzwerkverkehrs zwischen Webbrowser und Apache Webserver (Frontend) als auch des AJP-Netzwerkverkehrs zwischen dem Apache Webserver (mod_jk Connector Backend) und Tomcat konnten Benutzername und Passwort mitgelesen werden, was bei einer Kommunikation über unsichere Netzwerke zu berücksichtigen ist. Ansonsten sind die Ergebnisse mit denen des Tests T1 vergleichbar. 5.1.1.1.10 T8: AJP1.3 Connector, DIGEST-Authentisierung, Memory Realm Die Vorgehensweise ist wie bei Test T4 mit geänderter URL http://tomcathost:80/simple_user2/, um den Zugriff auf die simple_user2 Anwendung über den vorgeschalteten Apache Webserver mit mod_jk – AJP1.3 durchzuführen. Auch hier konnten wie in Test T7 Benutzername und Passwort im HTTP- wie im AJPNetzwerkverkehr mitgelesen werden. Ansonsten sind die Ergebnisse mit denen des Tests T4 vergleichbar. Bundesamt für Sicherheit in der Informationstechnik Seite 90 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests 5.1.1.1.11 T9: AJP1.3 Connector, FORM-Authentisierung, Memory Realm Die Vorgehensweise ist wie bei Test T5.1 mit geänderter URL http://tomcathost:80/simple_user1a/, um den Zugriff auf die simple_user1a Anwendung über den vorgeschalteten Apache Webserver mit mod_jk – AJP1.3 durchzuführen. Auch hier konnten wie in Test T7 Benutzername und Passwort im HTTP- wie im AJPNetzwerkverkehr mitgelesen werden. Ansonsten sind die Ergebnisse mit denen des Tests T5.1 vergleichbar. 5.1.1.1.12 T10: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory Realm Die Vorbereitungen für Test T10 sind analog zu denen von Test T6. Zusätzlich ist für diesen Test der Apache Webserver mit dem Kommando /opt/httpd-2.0.54/bin/apachectl -f /opt/httpd-2.0.54/conf/httpd.conf -DSSL zu starten. Die Zugriffe erfolgen jetzt über den Apache Webserver mit den URLs http://tomcathost:80/simple_info1a/ bzw. https://tomcathost:443/simple_info1a/ (und analog für die zweite Webanwendung). Die beim Zugriff über den Apache Webserver mit mod_jk sowie dem Tomcat AJP13Connector auf Tomcat erzielten Ergebnisse ähneln denen des Tests T6. 5.1.1.2 Ergebnisse zu Test2 Zum Test von Single Sign On (SSO) werden wiederum die zuvor verwendeten BeispielWebanwendungen (simple_info1, simple_info1a, simple_info2) verwendet. Damit kann nach einer Authentisierung als Benutzer mit der Rollenzuordnung user1 überprüft werden, ob • ohne Aktivierung der SSO-Valve für jede Applikation eine separate Anmeldung erforderlich ist. • bei Aktivierung der SSO-Valve eine Freigabe für alle Ressourcen mit einer Freigabe für die angemeldete Rolle ohne separate Anmeldung erfolgt ist. Für die SSO Tests werden zunächst für alle Webanwendungen die BASIC-Authentisierung eingestellt (in der Datei WEB-INF/web.xml der jeweiligen Webanwendung). 5.1.1.2.1 T11: HTTP Connector, BASIC-Authentisierung, Memory Realm Test ohne Aktivierung des SSO-Valve Ohne Aktivierung des SSO-Valve erfolgt zunächst ein Zugriff auf die allgemein freigegebene Webseite http://tomcathost:8080/simple_info1. Über den dort vorhandenen URL wird die Folgeseite http://tomcathost:8080/simple_info1/confidential.jsp aufgerufen, für die zunächst ein Browser-Popup-Fenster zur HTTP-Authentisierung geöffnet wird. Nach erfolgreicher Ein­ gabe von Benutzer memuser1 und Passwort vmware wird diese Seite dann gleichfalls angezeigt. Seite 91 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info1a erfordert eine erneute Authentisierung. Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info2 erfordert eine Authentika­ tion mit dem Benutzer memuser2 und Passwort vmware. Wird die Authentisierung mit der zuvor verwendeten Benutzer memuser1 / Passwort vmware Kombination versucht, so erhält man die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser zurück. Test mit Aktivierung des SSO-Valve Es erfolgt nach der Aktivierung des SSO-Valve (zusätzlicher Eintrag <Valve className=“org.apache.catalina.authenticator.SingleSignOn“/> in der <Host>-Section der Datei $CATALINA_HOME/conf/server.xml, s. [Moczar] S. 657) ein Zugriff auf die allgemein freigegebene Webseite http://tomcathost:8080/simple_info1. Über den dort vorhandenen URL wird die Folgeseite http://tomcathost:8080/simple_info1/confidential.jsp aufgerufen, für die zunächst ein Browser-Popup-Fenster zur HTTP-Authentisierung geöffnet wird. Nach erfolgreicher Eingabe von Benutzer memuser1 und Passwort vmware wird diese Seite dann gleichfalls angezeigt. Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info1a erwartungsgemäß keine erneute Authentisierung. erfordert jetzt Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info2 wird unmittelbar mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser quittiert. Ein erneutes Login-Fenster wird hier – im Gegensatz zum Test ohne SSO – nicht angezeigt. Der Webbrowser verbleibt also im Kontext der zuvor authentisierten Rolle user1, für den die Webanwendung simple_info2 nicht freigegeben ist, was zur festgestellten Abweisung führt. Nach Abschluss des SSO-Tests wird die $CATALINA_HOME/conf/server.xml wieder entfernt. eingefügte SSO-Valve-Zeile in 5.1.1.2.2 T12: HTTP Connector, DIGEST-Authentisierung, Memory Realm Zur Durchführung der Tests mit DIGEST-Authentisierung wird in den drei Anwendungen (simple_info1, simple_info1a, simple_info2) in der Tomcat-Konfigurationsdatei WEBINF/web.xml die Authentisierungsmethode von <auth-method>BASIC</auth-method> auf <auth-method>FORM</auth-method> umgestellt (s. [Moczar], S. 316 ff.). Die Testdurchführung und die dabei gewonnenen Ergebnisse sind mit denen aus Test T11 vergleichbar. 5.1.1.2.3 T13.1: HTTP Connector, FORM-Authentisierung, Memory Realm Zur Durchführung der Tests mit FORM-Authentisierung werden in den drei Anwendungen (simple_info1, simple_info1a, simple_info2) in der Tomcat-Konfigurationsdatei WEBINF/web.xml jeweils die Einträge innerhalb des <login-config> Abschnitts ergänzt und die Bundesamt für Sicherheit in der Informationstechnik Seite 92 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Authentisierungsmethode von <auth-method>BASIC</auth-method> method>FORM</auth-method> umgestellt (s. [Moczar], S. 316 ff.): auf <auth- Listing 29: Ergänzung in den Konfigurationsdateien WEB-INF/web.xml <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> Test ohne Aktivierung des SSO-Valve Ohne Aktivierung des SSO-Valve erfolgt zunächst ein Zugriff auf die allgemein freigegebene Webseite http://tomcathost:8080/simple_info1. Über den dort vorhandenen URL wird die Folgeseite http://tomcathost:8080/simple_info1/confidential.jsp aufgerufen, für die zunächst die automatisch die zur Anwendung gehörige Authentisierungs-Webseite http://tomcathost:8080/simple_info1/login.jsp geöffnet wird. Nach erfolgreicher Eingabe von Benutzer memuser1 und Passwort vmware wird diese Seite dann gleichfalls angezeigt. Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info1a erfordert eine erneute Authentisierung mit der der neuen Applikation entsprechenden Authentisierungs-Webseite http://tomcathost:8080/simple_info1a/login.jsp. Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info2 erfordert eine Authentisierung mit dem Benutzer memuser2 und Passwort vmware über die automatisch geöffnete und zur Anwendung gehörige Authentisierungs-Webseite http://tomcathost:8080/simple_info2/login.jsp. Wird die Authentisierung mit der zuvor verwendeten Benutzer memuser1 / Passwort vmware Kombination versucht, so erhält man die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser zurück. Hinweis: Wird eine komplett ungültige Benutzer / Passwort Kombination verwendet, so erscheint die unter <form-error-page> angegebene Fehlerseite der jeweiligen Anwendung, z. B. http://tomcathost:8080/simple_info2/error.jsp. Wurde bei der Anmeldung eine gültige Kombination von Benutzer / Passwort verwendet, wobei die diesem Benutzer zugeordneten Rollen nicht auf diejenigen passen, für die die Anwendung freigegeben wurden, erhält man hingegen die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser zurück. Es ist evtl. noch weiter zu untersuchen, ob sich hieraus Angriffsszenarien ableiten lassen, da über die HTTP-Fehlermeldung indirekt bestätigt wurde, dass die verwendete Benutzer / Passwort Kombination in einem anderen Webanwendungskontext gültig sein könnte. Test mit Aktivierung des SSO-Valve Es erfolgt nach der Aktivierung des SSO-Valve durch den zusätzlichen Eintrag <Valve className=“org.apache.catalina.authenticator.SingleSignOn“/> in der <Host>-Section der Datei $CATALINA_HOME/conf/server.xml, s. [Moczar] S. 657, ein Zugriff auf die allgemein freigegebene Webseite http://tomcathost:8080/simple_info1. Über den dort vorhandenen URL wird die Folgeseite Seite 93 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers http://tomcathost:8080/simple_info1/confidential.jsp aufgerufen, für die zunächst die Authentisierung-Webseite http://tomcathost:8080/simple_info1/login.jsp automatisch geöffnet wird. Nach erfolgreicher Eingabe von Benutzer memuser1 und Passwort vmware wird diese Seite dann gleichfalls angezeigt. Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info1a erfordert jetzt erwar­ tungsgemäß keine erneute Authentisierung mehr, da hierfür die gleiche Rollenfreigabe vorliegt wie in der vorigen Applikation. Ein Wechsel auf die Webseite http://tomcathost:8080/simple_info2 wird unmittelbar mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser quittiert, da die Anmeldung in der für die beiden vorigen Applikationen benötigten Rolle erfolgreich durchgeführt wurde, diese Rolle jedoch nicht für die aktuelle Anwendung zugelassen ist. Nach Abschluss des SSO-Tests wird die $CATALINA_HOME/conf/server.xml wieder entfernt. eingefügte SSO-Valve-Zeile in 5.1.1.2.4 T13.2: HTTP Connector, gemischte BASIC- und FORM-Authentisierung, Memory Realm Im folgenden Test erfolgt die Authentisierung der Webanwendungen simple_info1 und simple_info2 mit BASIC-Authentisierung und simple_info1a mit FORM-Authentisierung. Test ohne Aktivierung des SSO-Valve Der erste Test beginnt mit dem Aufruf der per BASIC-Authentisierung gesicherten Webseite http://tomcathost:8080/simple_info1/confidential.jsp, wo die HTTP-Authentisierungsabfrage per Browser-Popup-Fenster durchgeführt wird (Benutzer memuser1 / Passwort vmware). Anschließend kann nach erneuter Authentisierung auf die per FORM-Authentisierung gesicherte Webseite http://tomcathost:8080/simple_info1a zugegriffen werden. Auch der Zugriff auf die nur für eine andere Rolle freigegebene Webseite http://tomcathost:8080/simple_info2 ist erst nach erneuter HTTP-Authentisierung per Browser-Popup-Fenster möglich. Das gleiche Resultat von jeweils individueller Authentisierung je Applikation erhält man durch geänderte Aufrufreihenfolge der Webseiten (im zweiten Test: http://tomcathost:8080/simple_info1a, http://tomcathost:8080/simple_info1/confidential.jsp und http://tomcathost:8080/simple_info2, im dritten Test http://tomcathost:8080/simple_info2, http://tomcathost:8080/simple_info1/confidential.jsp und http://tomcathost:8080/simple_info1 ). Test mit Aktivierung des SSO-Valve Es erfolgt zunächst die Aktivierung des SSO-Valve durch den zusätzlichen Eintrag <Valve className=“org.apache.catalina.authenticator.SingleSignOn“/> in der <Host>-Section der Datei $CATALINA_HOME/conf/server.xml, s. [Moczar] S. 657, und ein Neustart von Tomcat. Bundesamt für Sicherheit in der Informationstechnik Seite 94 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Der erste Test beginnt mit dem Aufruf der per BASIC-Authentisierung gesicherten Webseite http://tomcathost:8080/simple_info1/confidential.jsp, wo die HTTP-Authentisierungsabfrage per Browser-Popup-Fenster durchgeführt wird (Benutzer memuser1 / Passwort vmware). Anschließend kann ohne weitere Authentisierung auf die per FORM-Authentisierung gesicherte Webseite http://tomcathost:8080/simple_info1a zugegriffen werden, nicht jedoch auf die nur für eine andere Rolle freigegebene Webseite http://tomcathost:8080/simple_info2. Hier wird die Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser zurück gegeben. Im zweiten Test wird zuerst die FORM-Authentisierung in der Reihenfolge der Abfragen http://tomcathost:8080/simple_info1a, http://tomcathost:8080/simple_info1/confidential.jsp und schließlich http://tomcathost:8080/simple_info2 durchgeführt und das gleiche erwartete Verhalten erzielt. Im dritten Test wird nach einer HTTP-Authentisierung als Benutzer memuser2 / Passwort vmware per Browser-Popup-Fenster über die BASIC-Authentisierung in Verbindung mit der Webseite http://tomcathost:8080/simple_info2 der Zugriff auf die beiden anderen gesicherten Webanwendungen mit Rückgabe der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser erwartungsgemäß blockiert. Nach Abschluss des SSO-Tests wird die $CATALINA_HOME/conf/server.xml wieder entfernt. eingefügte SSO-Valve-Zeile in 5.1.1.2.5 T14: HTTPS Connector, Client Zertifikat Authentisierung, Memory Realm Zum Test werden die beiden Webanwendungen simple_info1 (mit BASIC-Authentisierung) und simple_info1a (mit CLIENT-CERT-Authentisierung) verwendet. Es erfolgt zunächst die Aktivierung des SSO-Valve durch den zusätzlichen Eintrag <Valve className=“org.apache.catalina.authenticator.SingleSignOn“/> in der <Host>-Section der Datei $CATALINA_HOME/conf/server.xml, s. [Moczar] S. 657, und ein Neustart von Tomcat. Zuerst erfolgt ein Zugriff mit HTTP-Authentisierung als Benutzer memuser1 / Passwort vmware auf die geschützte Webseite https://tomcathost:8443/simple_info1/confidential.jsp durchgeführt. Es folgt ein Zugriff auf die für die gleiche Rolle freigegebene Webseite https://tomcathost:8443/simple_info1a/index.jsp, der korrekt und ohne weitere Authenti­ sierung zugelassen wird. Ein Zugriff auf die für eine andere Rolle freigegebene Webseite https://tomcathost:8443/simple_info2/index.jsp wird hingegen mit Rückgabe der Fehlermel­ dung „HTTP Status 403 – Access to the requested resource has been denied“ im Web­ browser erwartungsgemäß blockiert. Im zweiten Versuch erfolgte zuerst ein Zugriff mit HTTP-Authentisierung als Benutzer memuser1 / Passwort vmware auf die geschützte Webseite http://tomcathost:8080/simple_info1/confidential.jsp. Es folgt ein Zugriff auf die für die gleiche Rolle freigegebene Webseite http://tomcathost:8080/simple_info1a/index.jsp, der korrekt und ohne weitere Authentisierung zugelassen wird. Seite 95 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Es konnte festgestellt werden, dass beim Zugriff auf die per BASIC-Authentisierung geschützte Webanwendung simple_info1 ein beliebiges gültiges Zertifikat im Rahmen der erforderlichen Client-Authentisierung des HTTPS-Verbindungsaufbaus vorgelegt werden kann, ohne dass die Verbindung abgewiesen wird. Wird dann nach erfolgreicher HTTPAuthentisierung in die durch CLIENT-CERT-Authentisierung geschützte Webanwendung simple_info1a gewechselt, so ist kein gültiges Zertifikat erforderlich, da die Authentisierung bereits erfolgreich per HTTP-Authentisierung durchgeführt wurde. Falls beide Bereiche derselben Rolle zugeordnet sind, ist der Zugang in einen Webanwendungsbereich, der durch eine stärkere CLIENT-CERT-Authentisierung geschützt ist, auf diese Weise über den SSOValve, wegen der schwachen HTTP-Authentisierung möglich. Die überprüften Zugriffs­ szenarien sind in den folgenden Abbildungen aufgezeichnet: Abbildung 5.1.: Zugriffsszenario beginnend mit Webanwendung simple_info1 und HTTP-Erstzugriff Beim in Abbildung 5.1 dargestellten Aufruf des geschützten Bereichs von Webanwendung simple_info1 erfolgt eine HTTP-Authentisierung, deren Ergebnis auch zum Wechsel in die für die gleiche Rolle freigegebene Webanwendung simple_info1a verwendet wird. Ein Wechsel in die für eine andere Rolle freigegebene Webanwendung simple_info2 wird hingegen abgewiesen. Beim Wechsel in den HTTPS-Bereich ist in der eingestellten HTTPS-Konfigura­ tion ein Client-Zertifikat vorzulegen. Dies hat aber offenbar im o. g. Zugriffsszenario keine weitergehende Bedeutung bei der Authentisierung. Trotz der Verwendung des Zertifikats für einen Benutzer mit Berechtigung für die Rolle user2 ist es nicht möglich, aus der Webanwendung simple_info1a (HTTPS) zur Webanwendung simple_info2 (HTTPS) zu wechseln (unterer horizontaler Pfeil). Bundesamt für Sicherheit in der Informationstechnik Seite 96 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Abbildung 5.2.: Zugriffsszenario beginnend mit Webanwendung simple_info1 und HTTPS-Erstzugriff Der in Abbildung 5.2 dargestellten Fall des Zugriffs auf die Webanwendung simple_info1 keine Client-Zertifikat-Authentisierung erfolgt, genügt auch hier bei der erstmaligen HTTPSVerbindung die Vorlage eines beliebigen gültigen Zertifikats (hier das für die Rolle user2), das aber auch hier offenbar nicht weiter ausgewertet wird, da nach einer erfolgreichen HTTP-Authentisierung der Zugriff auf die Webseiten der Applikation simple_info1a möglich sind. Abb. 5.3.: Zugriffsszenario beginnend mit Webanwendung simple_info1a und HTTPS-Erstzugriff Seite 97 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Beginnt die Zugriffssequenz wie in Abb. 5.3 dargestellt mit der durch CLIENT-CERT Authentisierung geschützten Webanwendung simple_info1a, so muss ein dafür gültiges Client-Zertifikat vorgelegt werden. Nachfolgende Zugriffe auf Webseiten der durch BASICAuthentisierung geschützten Webanwendung simple_info1 sind dann durch das SSO-Valve ohne weitere Authentisierung möglich. Ein Zugriff auf Webseiten der Webanwendung simple_info2 wird erwartungsgemäß mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser abgewiesen. 5.1.1.2.6 T15: AJP1.3 Connector, BASIC-Authentisierung, Memory Realm Die Ergebnisse in Test 15 sind mit denen aus Test 11 vergleichbar. Hierbei wurden jedoch die URLs http://tomcathost/simple_info1, http://tomcathost/simple_info1a bzw. http://tomcathost/simple_info2 verwendet (ohne Angabe der Portnummer :8080). 5.1.1.2.7 T16: AJP1.3 Connector, DIGEST-Authentisierung, Memory Realm Die Ergebnisse in Test 16 sind mit denen aus Test 12 vergleichbar. Hierbei wurden jedoch die URLs http://tomcathost/simple_info1, http://tomcathost/simple_info1a bzw. http://tomcathost/simple_info2 verwendet (ohne Angabe der Portnummer :8080). 5.1.1.2.8 T17.1: AJP1.3 Connector, FORM-Authentisierung, Memory Realm Die Ergebnisse in Test 17.1 sind mit denen aus Test 13.1 vergleichbar. Hierbei wurden jedoch die URLs http://tomcathost/simple_info1, http://tomcathost/simple_info1a bzw. http://tomcathost/simple_info2 verwendet (ohne Angabe der Portnummer :8080), um die Verbindung zum Tomcat Servlet Container über den Apache Webserver und das mod_jkModul zu testen. 5.1.1.2.9 T17.2: AJP Connector, gemischte BASIC- und FORM-Authentisierung, Memory Realm Die Ergebnisse in Test 17.2 sind mit denen aus Test 13.2 vergleichbar. Hierbei wurden jedoch die URLs http://tomcathost/simple_info1, http://tomcathost/simple_info1a bzw. http://tomcathost/simple_info2 verwendet (ohne Angabe der Portnummer :8080), um die Verbindung zum Tomcat Servlet Container über den Apache Webserver und das mod_jkModul zu testen. 5.1.1.2.10 T18: AJP1.3 / SSL Connector, Client Zertifikat Authentisierung, Memory Realm Die Vorbereitungen für Test T18 sind analog zu denen von Test T14. Zusätzlich ist für diesen Test der Apache Webserver mit dem Kommando /opt/httpd-2.0.54/bin/apachectl -f /opt/httpd-2.0.54/conf/httpd.conf -DSSL zu starten. Die Zugriffe erfolgen jetzt über den Apache Webserver mit den URLs http://tomcathost:80/simple_info1a/ bzw. https://tomcathost:443/simple_info1a/ (und analog für die zweite Webanwendung). Bundesamt für Sicherheit in der Informationstechnik Seite 98 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Die beim Zugriff über den Apache Webserver mit mod_jk sowie dem Tomcat AJP13Connector auf Tomcat erzielten Ergebnisse sind mit denen des Tests T14 vergleichbar. Einzig bei Zugriffen auf HTTPS-Webseiten erfolgt im Unterschied zu Test T14 eine doppelte Abfrage des zu verwendenden Client-Zertifikats. 5.1.1.3 Ergebnisse zu Test3 Zum Test der Berücksichtigung von Änderungen in der Authentisierungsdatenbank wird die Applikation simple_info2 verwendet, die über die beiden Webseiten http://tomcathost/simple_info2/index.jsp und http://tomcathost/simple_info2/confidential.jsp (in Verbindung mit dem AJP Connector bzw. in Verbindung mit dem HTTP Connector unter zusätzlicher Angabe der Portnummer :8080 in der URL). 5.1.1.3.1 T19.1: HTTP Connector, BASIC-Authentisierung, Memory Realm Nach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der Datei $CATALINA_HOME/conf/tomcatusers.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinfor­ mation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich. Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost:8080/simple_info2/index.jsp mit der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen, so erscheint erneut ein Browser-Popup-Fenster zur Authentisierung. Hier ist jetzt das neu gesetzte Passwort einzugeben, um auf die Webseite zugreifen zu können. Im Gegensatz zum ersten Test übernimmt Tomcat die per admin Webanwendung geänderte Passwortinformation sofort. 5.1.1.3.2 T19.2: HTTP Connector, BASIC-Authentisierung, JDBC Realm Nach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erfor­ derlichen HTTP-Authentisierung mit Benutzer jdbcuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der MySQL-Datenbank modifiziert: Listing 30: Kommandos zur Passwort-Änderung in der MySQL-Datenbank mysql> use authority; mysql> update users set user_pass = “<neues_passwort>“ where user_name = “jdbcuser2“; Anschließend wird über http://tomcathost:8080/simple_info2/confidential.jsp auf die zweite Webseite zugegriffen. Hierzu werden die geänderten Authentisierungsinformationen in einem Browser-Popup-Fenster abgefragt. Somit übernimmt Tomcat die geänderten Passwortinformationen sofort. Nach Durchführung des Tests wird das Passwort in der Datenbank für weitere Tests wieder auf den ursprünglichen Zustand zurück gesetzt. Seite 99 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 5.1.1.3.3 T19.3: HTTP Connector, BASIC-Authentisierung, JNDI Realm Nach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer jndiuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der LDAP-Datenbank mit dem LDAP-Browser gq modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen. Hierzu werden die geänderten Authentisierungsinformationen in einem Browser-Popup-Fenster abgefragt. Somit übernimmt Tomcat die geänderten Passwortinformationen sofort. 5.1.1.3.4 T20: HTTP Connector, DIGEST-Authentisierung, Memory Realm Nach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der Datei $CATALINA_HOME/conf/tomcatusers.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinfor­ mation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich. Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost:8080/simple_info2/index.jsp mit der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen, so erscheint erneut ein Browser-Popup-Fenster zur HTTP-Authentisierung. Hier ist jetzt das neu gesetzte Passwort einzugeben, um auf die Webseite zugreifen zu können. Im Gegensatz zum ersten Test übernimmt Tomcat die per admin Webanwendung geänderte Passwortinformation sofort. 5.1.1.3.5 T21: HTTP Connector, FORM-Authentisierung, Memory Realm Zur Durchführung der Tests mit FORM-Authentisierung werden der Tomcat-Konfigurations­ datei $CATALINA_HOME/webapps/simple_info2/WEB-INF/web.xml jeweils die Einträge innerhalb des <login-config> Abschnitts ergänzt und die Authentisierungsmethode von <auth-method>BASIC</auth-method> auf <auth-method>FORM</auth-method> umgestellt (s. [Moczar], S. 316 ff.). Listing 31: Ergänzung in der Konfigurationsdatei der Webanwendung WEB-INF/web.xml <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> Nach einer Erstverbindung zu http://tomcathost:8080/simple_info2/index.jsp und der erforderlichen Authentisierung mit Benutzer memuser2 / Passwort vmware in der automatisch aufgerufenen Webseite http://tomcathost:8080/simple_info2/login.jsp wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinfor­ mation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich. Bundesamt für Sicherheit in der Informationstechnik Seite 100 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost:8080/simple_info2/index.jsp mit der erforderlichen Authentisierung mit Benutzer memuser2 / Passwort vmware in der automatisch aufgerufenen Webseite http://tomcathost:8080/simple_info2/login.jsp geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost:8080/simple_info2/confidential.jsp zugegriffen, so ist diese im Gegensatz zur BASIC-Authentisierung ohne weitere Authentisierung möglich. Die per admin Webanwendung geänderte Passwortinformation werden somit nicht sofort verwendet. 5.1.1.3.6 T22: HTTPS Connector, Client Zertifikat Authentisierung, Memory Realm Nach der Erstverbindung zu https://tomcathost:8443/simple_info2/ werden die Rollenzuord­ nungen der beiden Zertifikat-gebundenen Benutzer in der Datei $CATALINA_HOME/conf/tomcat_users.xml vertauscht (roles: user1 ↔ user2). Listing 32: Änderung in der Tomcat-Benutzer-Konfigurationsdatei tomcat_users.xml <user username="CN=memuser1, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password="null" roles="user1"/> <user username="CN=memuser2, OU=Testlab, O=BSITomcat ITC-Sec, L=Bonn, ST=NRW, C=DE" password="null" roles="user2"/> Anschließend erfolgt ein Zugriff auf die gleichfalls für die ursprüngliche Rolle freigegebene Webseite https://tomcathost:8443/simple_info2/confidential.jsp. Bei einer Änderung mit einem Texteditor werden im Test die Modifikationen der Zugriffs­ berechtigungen erst mit einem Neustart von Tomcat wirksam, sodass der Zugriff auf die zweite Webseite nicht abgewiesen wird. Bei einer Änderung über die admin Webanwendung ist die Änderung im Test hingegen sofort wirksam, sodass der zweite Zugriff mit einer Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser abgewiesen wird, da die im Webbrowser gespeicherten Kontext- (Session) und Authentikationsinformationen nun nicht mehr zu den geänderten Einstellungen passen. 5.1.1.3.7 T23.1: AJP1.3 Connector, BASIC-Authentisierung, Memory Realm Nach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforder­ lichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem BrowserPopup-Fenster wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinformation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich. Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost/simple_info2/index.jsp mit der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen, so erscheint erneut ein BrowserSeite 101 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Popup-Fenster zur HTTP-Authentisierung. Hier ist jetzt das neu gesetzte Passwort einzugeben, um auf die Webseite zugreifen zu können. Im Gegensatz zum ersten Test übernimmt Tomcat die per admin Webanwendung geänderte Passwortinformation sofort. 5.1.1.3.8 T23.2: AJP1.3 Connector, BASIC-Authentisierung, JDBC Realm Nach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforder­ lichen HTTP-Authentisierung mit Benutzer jdbcuser2 / Passwort vmware in einem BrowserPopup-Fenster wird das Passwort in MySQL-Datenbank modifiziert: Listing 33: Kommandos zur Passwort-Änderung in der MySQL-Datenbank mysql> use authority; mysql> update users set user_pass = “<neues_passwort>“ where user_name = “jdbcuser2“; Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Hierzu werden die geänderten Authentisierungsinformationen in einem BrowserPopup-Fenster abgefragt. Somit übernimmt Tomcat die geänderten Passwortinformationen sofort. Nach Durchführung des Tests wird das Passwort in der Datenbank für weitere Tests wieder auf den ursprünglichen Zustand zurück gesetzt. 5.1.1.3.9 T23.3: AJP1.3 Connector, BASIC-Authentisierung, JNDI Realm Nach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforderlichen HTTP-Authentisierung mit Benutzer jndiuser2 / Passwort vmware in einem Browser-Popup-Fenster wird das Passwort in der LDAP-Datenbank mit dem LDAP-Browser gq modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Daraufhin werden die geänderten Authentisierungsinformationen in einem Browser-Popup-Fenster abgefragt. Mit den überschriebenen Authentisierungsinformationen ist ein Zugriff nicht mehr möglich. 5.1.1.3.10 T24: AJP1.3 Connector, DIGEST-Authentisierung, Memory Realm Zur Durchführung der Tests mit DIGEST-Authentisierung wird in der Tomcat-Konfigurations­ datei $CATALINA_HOME/webapps/simple_info2/WEB-INF/web.xml die Authentikationsme­ thode von <auth-method>BASIC</auth-method> auf <auth-method>FORM</auth-method> umgestellt und Tomcat neu gestartet. Nach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforder­ lichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem BrowserPopup-Fenster wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinformation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich. Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost/simple_info2/index.jsp mit der erforderlichen HTTP-Authentisierung mit Benutzer memuser2 / Passwort vmware in einem Browser-Popup-Fenster geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite Bundesamt für Sicherheit in der Informationstechnik Seite 102 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests http://tomcathost/simple_info2/confidential.jsp zugegriffen, so erscheint erneut ein BrowserPopup-Fenster zur HTTP-Authentisierung. Hier ist jetzt das neu gesetzte Passwort einzugeben, um auf die Webseite zugreifen zu können. Im Gegensatz zum ersten Test übernimmt Tomcat die per admin Webanwendung geänderte Passwortinformation sofort. 5.1.1.3.11 T25: AJP1.3 Connector, FORM-Authentisierung, Memory Realm Zur Durchführung der Tests mit FORM-Authentisierung werden in der TomcatKonfigurationsdatei $CATALINA_HOME/webapps/simple_info2/WEB-INF/web.xml die Einträge innerhalb des <login-config> Abschnitts ergänzt und die Authentisierungsmethode von <auth-method>BASIC</auth-method> auf <auth-method>FORM</auth-method> umgestellt (s. [Moczar], S. 316 ff.) und Tomcat neu gestartet. Listing 34: Ergänzung in der Konfigurationsdatei der Webanwendung WEB-INF/web.xml <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> Nach einer Erstverbindung zu http://tomcathost/simple_info2/index.jsp und der erforderlichen Authentisierung mit Benutzer memuser2 / Passwort vmware in der automatisch aufgerufenen Webseite http://tomcathost/simple_info2/login.jsp wird das Passwort in der Datei $CATALINA_HOME/conf/tomcat-users.xml mit einem Texteditor modifiziert. Anschließend wird auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen. Da die neue Passwortinformation von Tomcat nicht übernommen wurde, war der zweite Zugriff möglich. Im zweiten Test wird statt eines Texteditors die Tomcat admin Webanwendung zur Änderung des Passwortes verwendet, nachdem die Erstverbindung nach http://tomcathost/simple_info2/index.jsp mit der erforderlichen Authentisierung mit Benutzer memuser2 / Passwort vmware in der automatisch aufgerufenen Webseite http://tomcathost/simple_info2/login.jsp geöffnet wurde. Wird nach der Passwortänderung auf die zweite Webseite http://tomcathost/simple_info2/confidential.jsp zugegriffen, so ist diese im Gegensatz zur BASIC-Authentisierung ohne weitere Authentisierung möglich. Die per admin Webanwendung geänderte Passwortinformation werden somit nicht sofort verwendet. Somit entsprechen die Ergebnisse denen aus Test T21. 5.1.1.3.12 T26: AJP1.3 / SSL Connector, Client Zertifikat Memory Realm Test T26 wird analog zu Test T22 durchgeführt, wobei https://tomcathost:443/simple_info2/ https://tomcathost:443/simple_info2/confidential.jsp verwendet werden. Authentisierung, jetzt die URLs bzw. Das Verhalten entspricht im Fall der Änderung der Authentisierungsinformationen per Texteditor demjenigen aus Test22. Seite 103 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Nach einer Änderung mit der admin Webanwendung hingegen wird der Zugriff auf die zweite Webseite nicht sofort mit einer Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser abgewiesen sondern es erfolgt eine erneute Abfrage eines Client-Zertifikates. Wenn dies zu den geänderten Autorisierungsinformationen passt, ist eine Fortsetzung der Web-Session möglich. Wird hingegen das für den ersten Zugriff verwendete Zertifikat, das nach der Änderung nun nicht mehr zu den Autorisierungsinformationen passt, vorgelegt, so wird der Zugriff mit der Fehlermeldung „HTTP Status 403 – Access to the requested resource has been denied“ im Webbrowser abgewiesen. 5.1.2 Funktionale Tests für die Zugriffskontrolle Für die drei Möglichkeiten der Zugriffskontrolle in Tomcat sind die im folgenden aufgelisteten unterschiedlichen Tests vorgesehen. 5.1.2.1 Tests der Zugriffsrechte auf dem Niveau der Java Virtual Machine Wird Tomcat ohne Java Security Manager gestartet, so können Webanwendungen u. a. • Tomcat beenden, • einen neuen Prozess erzeugen, • einen Netzwerk-Socket öffnen und darüber Daten übertragen, • auf das Dateisystem mit den Rechten des Tomcat zugreifen sowie • auf interne Tomcat-Komponente (Java Pakete, Classes) zugreifen, die mit erhöhten Rechten laufen. Aus diesen Gründen sollte Tomcat in produktiven Umgebungen immer mit einer Java Security Policy gestartet werden. Als Ausgangsbasis für die Tests dient die Java Security Policy, die mit Tomcat mitgeliefert und in den Konfigurationsdateien catalina.policy und catalina.properties definiert wird. Die Test-Webanwendungen (JSP oder Servlet, je nachdem, welche Fähigkeit benötigt wird) werden für die einzelnen Tests erstellt. Im Test wird überprüft, ob die oben genannten Möglichkeiten bei eingeschalteter Default Security Policy für die entsprechende TestWebanwendung nur entsprechend der Dokumentation des Tomcat möglich sind: Bundesamt für Sicherheit in der Informationstechnik Seite 104 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Test Nr. T 27 T 28 T 29 T 30 T 31 T 32 Durchführung der Tests Beschreibung Tomcat beenden möglich? Einen neuen Prozess erzeugen möglich? Einen Netzwerk-Socket öffnen und darüber Daten übertragen möglich? Das Lesen / Schreiben / Ausführen / Löschen einer Datei40 innerhalb des Verzeichnisses der Webanwendung möglich? Das Lesen / Schreiben / Ausführen / Löschen einer Datei außerhalb des Verzeichnisses der Webanwendung möglich? Zugriff auf Tomcat-eigene Komponenten möglich? (Java-Pakete mit Namen wie sun.*, org.apache.catalina.*, ...) erwartetes Bemerkung Resultat Nein Nein Nein Nur Lesen41 (laut Dokumentation möglich) Nein Nein (laut Vorgaben aus der Datei catalina.proper­ ties) Tabelle 4: Funktionale Tests der Zugriffskontrolle auf dem Niveau der Java Virtual Machine 5.1.2.1.1 T27 Tomcat beenden Es wird ein Servlet definiert, welches i. W. die folgende Zeile enthält: java.lang.System.exit(9); Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert (500 bedeutet laut HTTP-Protokoll Server-interner Fehler). Beim Backtrace erscheint im Browser deutlich der Eingriff des Security Managers von Java: The server encountered an internal error () that prevented it from fulfilling this request. java.security.AccessControlException: access denied (java.lang.RuntimePermission exitVM) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkExit(SecurityManager.java:744) java.lang.Runtime.exit(Runtime.java:88) java.lang.System.exit(System.java:868) Der Backtrace ist tatsächlich umfangreicher und wird in den folgenden Tests nur noch um den konstanten Teil verkürzt dargestellt: javax.servlet.http.HttpServlet.service(HttpServlet.java:689) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:419) org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:133) javax.servlet.http.HttpServlet.service(HttpServlet.java:689) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 40 41 Die Zugriffsrechte werden auf Dateisystem-Ebene so gesetzt, dass der Tomcat Prozess die erforderlichen Rechte hat. Der Zugriff soll auf Ebene der Anwendung verweigert werden, während das Betriebssystem ihn zulassen würde. Im Feinkonzept stand hier „Ja“. Jedoch werden sowohl in der Tomcat-Dokumentation in http://tomcat.apache.org/tomcat5.5-doc/security-manager-howto.html als auch in der Datei catalina.policy lediglich Leserechte aufgeführt. Seite 105 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:243) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:517) org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:275) org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:161) java.security.AccessController.doPrivileged(Native Method) filters.ExampleFilter.doFilter(ExampleFilter.java:101) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:585) org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:243) java.security.AccessController.doPrivileged(Native Method) javax.security.auth.Subject.doAsPrivileged(Subject.java:517) org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:275) org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:217) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.9 logs. 5.1.2.1.2 T28 neuen Prozess starten Dieser Fall ist deckungsgleich mit dem Versuch des Ausführens von Programmen in T30 und T31. Im Gegensatz zu externen Prozessen können Java-interne Threads sehr wohl von einer Webanwendung gestartet werden. Getestet wurde wie folgt: Listing 35: Datei webapps/WEB-INF/classes/TryThread.java public class TryThread implements Runnable { TryThread(long v, String comment) { } public void run() { try { java.lang.Thread.sleep(2000,0); throw new NullPointerException(); } catch (InterruptedException e) { // nothing } } } Ein Thread kann innerhalb eines Servlet wie folgt gestartet werden: TryThread x = new TryThread(1000,"Try it out"); new Thread(x).start(); In der Logdatei catalina.out erscheint daraufhin die vom Thread provozierte NullPointerException, als Nachweis der Programmausführung, während die Webanwendung erfolgreich die Webseite zum Browser liefert: Bundesamt für Sicherheit in der Informationstechnik Seite 106 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Exception in thread "Thread-33" java.lang.NullPointerException at TryThread.run(TryThread.java:9) at java.lang.Thread.run(Thread.java:595) java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1158) at TryExec.doGet(TryExex.java:51) 5.1.2.1.3 T29 Netzwerk-Socket öffnen und Daten übertragen Das Anlegen eines sogenannten passiven Sockets für einen Server auf Port 20000 wird mit einem Servlet getestet, das im Wesentlichen folgendes enthält: java.net.ServerSocket svs = new java.net.ServerSocket(20000); svs.close(); Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert. Beim Backtrace erscheint im Browser der Eingriff des Security Managers von Java: java.security.AccessControlException: access denied (java.net.SocketPermission localhost:20000 listen,resolve) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkListen(SecurityManager.java:1120) java.net.ServerSocket.bind(ServerSocket.java:318) java.net.ServerSocket.<init>(ServerSocket.java:185) java.net.ServerSocket.<init>(ServerSocket.java:97) 5.1.2.1.4 T30.1 Lesen innerhalb des Bereichs der Web-Anwendung Vielfältige Lesezugriffe sind möglich, sowohl auf Dateien als auch auf das Dateisystem. Verschiedene Zugriffsversuche wurden getestet, zunächst einmal: import java.io.*; File f = new File("."); out.println(f.getAbsolutePath()); Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert. Auch hier ist der Eingriff des Security-Managers von Java im Browser sichtbar, jedoch wurde beim Versuch, das mit „.“ bezeichnete, „aktuelle“ Verzeichnis aufzulösen, der Zugriff auf die Java Property user.dir verwehrt: java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285) java.lang.System.getProperty(System.java:627) java.io.UnixFileSystem.resolve(UnixFileSystem.java:118) java.io.File.getAbsolutePath(File.java:473) Folgende Zugriffsversuche wurden ebenfalls verwehrt: Seite 107 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers import java.io.*; File f = new File("index.html"); out.println(f.exists()); oder: import java.io.*; File f = new File("."); out.println(f.canRead()); mit der Fehlermeldung: java.security.AccessControlException: access denied (java.io.FilePermission . read) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkRead(SecurityManager.java:871) java.io.File.canRead(File.java:658) Offensichtlich verfügen Servlets über keinen vereinfachten Zugriff über relative Pfadnamen auf Dateien in ihrem jeweiligem Verzeichnis. Stattdessen funktioniert der Zugriff über den vollen Pfadnamen, beginnend mit „/“: import java.io.*; File f = new File("/opt/tomcat...webapps/.../index.html"); out.println(f.canRead()); Als Ergebnis wird der Wert „true“ ausgegeben und das folgende Servlet kann daher das erste Byte auslesen: import java.io.*; File f = new File("/opt/tomcat...webapps/.../index.html"); FileInputStream fis = new FileInputStream(f); out.println(fis.read()); fis.close(); Es erscheint 60, der ASCII-Code für das Zeichen „<“ vom öffnenden Tag des HTMLDokuments index.html. 5.1.2.1.5 T30.2 Schreiben innerhalb des Bereichs der Web-Anwendung Das Anlegen von neuen Dateien mit java.io.File.createNewFile wird zurückgewiesen. Dabei wird der vollständige Pfad benutzt, der beim Lesen erlaubt war: import java.io.*; File f = new File("/opt/tomcat...webapps/.../foobar"); out.println(f.createNewFile()); Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert. Auch hier ist der Eingriff des Security-Managers von Java im Browser sichtbar: Bundesamt für Sicherheit in der Informationstechnik Seite 108 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests java.security.AccessControlException: access denied (java.io.FilePermission /opt/tomcat...webapps/.../foobar write) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkWrite(SecurityManager.java:962) java.io.File.createNewFile(File.java:849) Der Versuch des Anlegens einer neuen Datei über die Klasse java.io.FileOutputStream wird ebenfalls zurückgewiesen: import java.io.*; File f = new File("/opt/tomcat...webapps/.../foobar"); FileOutputStream fs = new FileOutputStream(f); fs.close(); Quittiert mit der gleichlautenden Fehlermeldung: java.security.AccessControlException: access denied (java.io.FilePermission /opt/tomcat...webapps/.../foobar write) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkWrite(SecurityManager.java:962) java.io.FileOutputStream.<init>(FileOutputStream.java:169) java.io.FileOutputStream.<init>(FileOutputStream.java:131) 5.1.2.1.6 T30.3 Löschen innerhalb des Bereichs der Web-Anwendung Das Löschen der vorhandenen Datei index.html wird zurückgewiesen. Dabei wird der vollständige Pfad benutzt, der beim Lesen erlaubt war: import java.io.*; File f = new File("/opt/tomcat...webapps/.../index.html"); out.println(f.delete()); Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert. Auch hier ist der Eingriff des Security-Managers von Java im Browser sichtbar: java.security.AccessControlException: access denied (java.io.FilePermission /opt/jakartatomcat-5.5.9/webapps/.../index.html delete) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkDelete(SecurityManager.java:990) java.io.File.delete(File.java:869) Ähnlich verhält es sich mit dem Versuch, über java.io.File.deleteOnExit eine Zeitbombe (löschen beim beenden) einzufügen: import java.io.*; File f = new File("/opt/tomcat...webapps/.../index.html"); f.deleteOnExit(); Seite 109 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Quittiert wird hierbei mit der Fehlermeldung: java.security.AccessControlException: access denied (java.io.FilePermission /opt/jakartatomcat-5.5.9/webapps/.../index.html delete) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkDelete(SecurityManager.java:990) java.io.File.deleteOnExit(File.java:901) 5.1.2.1.7 T30.4 Ausführen innerhalb des Bereichs der Web-Anwendung Das Ausführen von Programmen wird zurückgewiesen. Beim Test wird ein vollständiger Pfad benutzt, wie er beim Lesen erlaubt war. Das Programm /bin/true wurde dazu in das Verzeichnis webapps/.../WEB-INF/classes/ kopiert. java.lang.Runtime.getRuntime().exec("/opt/jakarta-tomcat-5.5.9/webapps/xyztests/WEBINF/classes/true"); Quittiert wird hierbei mit der Fehlermeldung: java.security.AccessControlException: access denied (java.io.FilePermission /opt/jakartatomcat-5.5.9/webapps/xyztests/WEB-INF/classes/true execute) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkExec(SecurityManager.java:779) java.lang.ProcessBuilder.start(ProcessBuilder.java:447) java.lang.Runtime.exec(Runtime.java:591) java.lang.Runtime.exec(Runtime.java:429) java.lang.Runtime.exec(Runtime.java:326) TryExec.doGet(TryExec.java:71) 5.1.2.1.8 T31 Lesen / Schreiben / Löschen / Ausführen außerhalb der Web-Anwendung Es wird zunächst ein Servlet definiert, welches versucht das Vorhandensein der Datei index.html einer Nachbar-Webanwendung abzufragen: File f = new File("/opt/jakarta-tomcat-5.5.9/webapps/jsp-examples/index.html"); out.println(f.exists()); Bei eingeschalteter Security Policy wird der Aufruf des Servlets mit HTTP-Status 500 quittiert (500 bedeutet laut HTTP-Protokoll Server-interner Fehler). Beim Backtrace erkennt man im Browser deutlich den Eingriff des Security Managers von Java: java.security.AccessControlException: access denied (java.io.FilePermission /opt/jakartatomcat-5.5.9/webapps/jsp-examples/index.html read) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkRead(SecurityManager.java:871) java.io.File.exists(File.java:700) Ein Schreibversuch, diesmal ins Verzeichnis /tmp/, wird ebenfalls zurückgewiesen: File f = new File("/tmp/foobar"); Bundesamt für Sicherheit in der Informationstechnik Seite 110 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests FileOutputStream fs = new FileOutputStream(f); fs.close(); Die Fehlermeldung lautet bei allen Versuchen vergleichbar wie folgt: description The server encountered an internal error () that prevented it from fulfilling this request. exception java.security.AccessControlException: access denied (java.io.FilePermission /tmp/foobar write) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkWrite(SecurityManager.java:962) java.io.FileOutputStream.<init>(FileOutputStream.java:169) java.io.FileOutputStream.<init>(FileOutputStream.java:131) Der Versuch, das Programm /bin/true auszuführen, wird ebenfalls zurückgewiesen: java.lang.Runtime.getRuntime().exec("/bin/true"); Quittiert wird hierbei mit der Fehlermeldung: java.security.AccessControlException: access denied (java.io.FilePermission /bin/true execute) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkExec(SecurityManager.java:779) java.lang.ProcessBuilder.start(ProcessBuilder.java:447) java.lang.Runtime.exec(Runtime.java:591) java.lang.Runtime.exec(Runtime.java:429) java.lang.Runtime.exec(Runtime.java:326) TryExec.doGet(TryExec.java:70) 5.1.2.1.9 T32 Zugriff auf Tomcat-eigene Komponenten Es wird ein Servlet definiert, welches im Wesentlichen die folgende Zeile enthält: out.println(org.apache.catalina.realm.RealmBase.Digest("abc","def","0")); Bei eingeschalteter Security Policy wird der Aufruf des Servlets erwartungsgemäß mit HTTPStatus 500 quittiert. Auch hier ist der Eingriff des Security-Managers von Java im Browser sichtbar: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.catalina.realm) java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) java.security.AccessController.checkPermission(AccessController.java:427) java.lang.SecurityManager.checkPermission(SecurityManager.java:532) java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512) sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) java.lang.ClassLoader.loadClass(ClassLoader.java:251) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1247) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181) Seite 111 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) Wird stattdessen auf eine öffentliche Konstante von org.apache.catalina zugegriffen, z. B. innerhalb von org.apache.catalina.realm.Constants, so wird der Zugriff erlaubt. public static final String FORM_ACTION = "/j_security_check"; Im Servlet steht: out.println(org.apache.catalina.realm.Constants.FORM_ACTION); Der Text /j_security_check erscheint im Browser. Möglicherweise wird aufgrund der Deklaration final der Wert in das compilierte Servlet übernommen, sodass vielleicht keine Referenz mehr auf das Paket catalina vorhanden ist. 5.1.2.2 Tests der Zugriffsrechte auf dem Niveau von Webanwendungen Diese Tests werden über den HTTP und den AJP1.3 Connector durchgeführt. Test Nr. T 33 T 34 T 35 TomcatBeschreibung erwartetes Resultat Connector HTTP und In der web.xml Datei einer Webanwendung wirdnicht möglich AJP eine einzelne JSP-Seite vor anonymen Zugriffen geschützt. Es wird untersucht, ob es möglich ist, ohne Authentisierung auf diese Datei zuzugreifen. HTTP und In der web.xml Datei einer Webanwendung wird nicht möglich AJP ein Verzeichnis vor anonymen Zugriffen geschützt. Es wird untersucht, ob es möglich ist, ohne Authentisierung auf Web-Ressourcen unterhalb dieses Verzeichnisses zuzugreifen. HTTP und In der web.xml Datei einer Webanwendung nicht möglich AJP werden einzelne HTTP Methoden (DELETE, PUT, GET, POST) vor anonymen Zugriffen geschützt. Es wird untersucht, ob es möglich ist, ohne Authentisierung mit den entsprechenden Methoden auf Web-Ressourcen zuzugreifen. Tabelle 5: Funktionale Tests der Zugriffskontrolle auf dem Niveau der Webanwendungen Die hier überprüften Mechanismen regeln den Zugriff auf dem Niveau der einzelnen Webanwendung und sind somit für alle Einsatzszenarien aus dem Feinkonzept [Tomcat Fein.] von Bedeutung. Da der Zugriff auf die Webanwendung beim Einsatzszenario 1 (mit HTTP Connector) prinzipiell anders ist als bei allen anderen Einsatzszenarien (mit AJP Connector), werden diese Tests für Einsatzszenario 1 und Einsatzszenario 2 wiederholt. Die Tests T33 und T34 werden in Verbindung mit der Webanwendung simple_info1 durchgeführt. Neben einer ungeschützten Startseite index.jsp verfügt die Webanwendung über zwei geschützte Webseiten confidential.jsp sowie subdir/moreinfo.jsp, die nur für Zugriffe von authentisierten Benutzern mit einer Rollenzuordnung user1 freigegeben sind. Bundesamt für Sicherheit in der Informationstechnik Seite 112 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Die geschützten Webseiten bzw. -verzeichnisse sind innerhalb der web.xml Datei dieser Webanwendung wie folgt festgelegt: Listing 36: Definition geschützter Bereiche in der Konfigurationsdatei der Webanwendung WEB-INF/web.xml <!-- Define a Security Constraint on this Application --> <security-constraint> <web-resource-collection> <web-resource-name>Simple_Info1 JSP Application</web-resource-name> <url-pattern>/confidential.jsp</url-pattern> <url-pattern>/subdir/</url-pattern> <url-pattern>/subdir/*</url-pattern> </web-resource-collection> <auth-constraint> <!-- NOTE: This role is not present in the default users file --> <role-name>user1</role-name> </auth-constraint> </security-constraint> 5.1.2.2.1 T33.1 HTTP Connector, Zugriff auf eine geschützte JSP-Seite Es erfolgt aus der allgemein freigegebenen Webseite http://tomcathost:8080/simple_info1 heraus ein Zugriff auf die nur für authentisierte Benutzer mit einer Rollenzuordnung user1 freigegebene Webseite http://tomcathost:8080/simple_info1/confidential.jsp. Ein BrowserPopup-Fenster öffnet sich, um eine HTTP-Benutzeranmeldung durchzuführen. Es existieren nun 4 mögliche Fälle: • Die HTTP-Authentisierung wird im Popup-Fenster mit Cancel abgebrochen. Tomcat gibt darauf hin die Fehlermeldung „HTTP Status 401: This request requires HTTP authentication ()“ im Browser zurück. Ein Zugriff auf die geschützte Webseite ist nicht möglich. • Wird in das Popup-Fenster ein ungültiger Benutzername und / oder ein ungültiges Passwort eingegeben, so wird die Authentisierung abgelehnt und das Popup-Fenster erneut geöffnet. Ein Zugriff auf die geschützte Webseite ist ohne erfolgreiche Authentisierung auch nach mehreren Fehlversuchen nicht möglich. • Die HTTP-Authentisierung wird im Popup-Fenster mit einer gültigen Benutzerken­ nung (Benutzer memuser2 / Passwort vmware) durchgeführt, die jedoch nicht über die benötigte Rollenzuordnung verfügt. Tomcat gibt darauf hin die Fehlermeldung „HTTP Status 403: Access to the requested resource has been denied“ im Browser zurück. Ein Zugriff auf die geschützte Webseite ist nicht möglich. • Die HTTP-Authentisierung wird im Popup-Fenster mit einer gültigen Benutzerken­ nung (Benutzer memuser1 / Passwort vmware) durchgeführt, die über die benötigte Rollenzuordnung verfügt. Tomcat gibt darauf die angeforderte Webseite wie erwartet zurück. Seite 113 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 5.1.2.2.2 T33.2 AJP13 Connector, Zugriff auf eine geschützte JSP-Seite Es erfolgt aus der allgemein freigegebenen Webseite http://tomcathost/simple_info1 heraus ein Zugriff auf die nur für authentisierte Benutzer mit einer Rollenzuordnung user1 freigegebene Webseite http://tomcathost/simple_info1/confidential.jsp. Ein Browser-PopupFenster öffnet sich, um eine HTTP-Benutzeranmeldung durchzuführen. Es existieren nun 4 mögliche Fälle: • Die HTTP-Authentisierung wird im Popup-Fenster mit Cancel abgebrochen. Tomcat gibt darauf hin die Fehlermeldung „HTTP Status 401: This request requires HTTP authentication ()“ im Browser zurück. Ein Zugriff auf die geschützte Webseite ist nicht möglich. • Wird in das Popup-Fenster ein ungültiger Benutzername und / oder ein ungültiges Passwort eingegeben, so wird die Authentisierung abgelehnt und das Popup-Fenster erneut geöffnet. Ein Zugriff auf die geschützte Webseite ist nicht möglich. • Die HTTP-Authentisierung wird im Popup-Fenster mit einer gültigen Benutzerken­ nung (Benutzer memuser2 / Passwort vmware) durchgeführt, die jedoch nicht über die benötigte Rollenzuordnung verfügt. Tomcat gibt darauf hin die Fehlermeldung „HTTP Status 403: Access to the requested resource has been denied“ im Browser zurück. Ein Zugriff auf die geschützte Webseite ist nicht möglich. • Die HTTP-Authentisierung wird im Popup-Fenster mit einer gültigen Benutzerken­ nung (Benutzer memuser1 / Passwort vmware) durchgeführt, die über die benötigte Rollenzuordnung verfügt. Tomcat gibt darauf die angeforderte Webseite zurück. 5.1.2.2.3 T34.1 HTTP Connector, Zugriff auf ein geschütztes Verzeichnis Im Rahmen dieses Tests werden zur Überprüfung des Zugriffsschutzes Zugriffe auf die geschützte URL http://tomcathost:8080/simple_info1/subdir sowie auf die zur gleichen Web­ anwendung gehörige URL http://tomcathost:8080/simple_info1/subdir/moreinfo.jsp durch­ geführt. Die beim Test erzielten Ergebnisse entsprechen denen aus Test T33.1, d. h. ein Zugriff ist nur nach erfolgreicher vorheriger Authentisierung möglich. 5.1.2.2.4 T34.2 AJP13 Connector, Zugriff auf ein geschütztes Verzeichnis Dieser Test nutzt Zugriffe auf die geschützten URLs http://tomcathost/simple_info1/subdir sowie http://tomcathost/simple_info1/subdir/moreinfo.jsp. Die beim Test erzielten Ergebnisse entsprechen denen aus Test T33.2, d. h. ein Zugriff ist nur nach erfolgreicher vorheriger Authentisierung möglich. 5.1.2.2.5 T35 Schutz einzelner HTTP-Methoden vor anonymen Zugriffen Zur Durchführung von Test T35 wird zunächst die Webseite simple_info1/request_data.jsp, die bislang ohne weiteren Zugriffsschutz konfiguriert war, mit einer entsprechenden Zugriffsrestriktion in der Konfigurationsdatei simple_info1/WEB-INF/web.xml versehen. Abgebildet ist in Listing 5.10 der Endzustand, die <http-method> Zeilen werden nach jedem Teiltest schrittweise ergänzt: Bundesamt für Sicherheit in der Informationstechnik Seite 114 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Listing 37: Spezifikation des HTTP-Methoden-basierten Zugriffsschutzes in der Konfigura­ tionsdatei der Webanwendung WEB-INF/web.xml ... <!-- Define a Security Constraint on this Application --> <security-constraint> <web-resource-collection> <web-resource-name>Simple_Info1 JSP Application</web-resource-name> <url-pattern>/confidential.jsp</url-pattern> <url-pattern>/subdir/</url-pattern> <url-pattern>/subdir/*</url-pattern> </web-resource-collection> <web-resource-collection> <web-resource-name>Simple_Info1 HTTP Access Auth Check</web-resource-name> <url-pattern>/request_data.jsp</url-pattern> <http-method>GET</http-method> <http-method>HEAD</http-method> <http-method>PUT</http-method> <http-method>POST</http-method> <http-method>DELETE</http-method> </web-resource-collection> <auth-constraint> <!-- NOTE: This role is not present in the default users file --> <role-name>user1</role-name> </auth-constraint> </security-constraint> ... Bei den nun folgenden Zugriffsversuchen auf die URL http://tomcathost:8080/simple_info1/request_data.jsp (Tomcat HTTP-Connector) bzw. http://tomcathost:80/simple_info1/request_data.jsp (via Apache Webserver mit mod_jk auf Tomcat mit AJP-Connector) per Webbrowser bzw. telnet wurde der Zugriff der Reihe nach per GET, HEAD, PUT, POST und DELETE Methode auf die betreffende URL im jeweils ersten Zugriff (ohne zugehörige Zeile <http-method>) erlaubt und beim jeweils zweiten Zugriff (nun mit zugehöriger Zeile <http-method>) ohne vorherige Authentisierung mit der Fehlermeldung HTTP 401 Unauthorized blockiert. Als Beispiel für die Zugriffstests ist das Protokoll der Direktzugriffe auf den Tomcat HTTPConnector vor und nach Einfügung der Zeile <http-method>GET</http-method> in die Konfigurationsdatei web.xml hier mit eingefügt, der zunächst die hinterlegte Webseite korrekt zurück gibt: Listing 38: Ausgaben beim Zugriffstest ohne Zugriffsbeschränkung debian-host1:/opt/jakarta-tomcat-5.5.9/logs# telnet localhost 8080 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. GET /simple_info1/request_data.jsp HTTP/1.0 HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=FFE7DC47922C502F1A8DE4D6334F2268; Path=/simple_info1 Content-Type: text/html;charset=ISO-8859-1 Content-Length: 367 Date: Thu, 03 Nov 2005 13:57:44 GMT Connection: close <html> Seite 115 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers <head> <title> Display HTTP Request Data </title> </head> <body> <h1>Request = <br /> GET localhost.localdomain: 8080 HTTP/1.0 </h1> <hr /> <h2><font color=red>Request header entries:</font></h2> <hr /> <h2><font color=red>Request parameters:</font></h2> <hr /> <h2><font color=red>Request attributes:</font></h2> <hr /> </body> </html> Connection closed by foreign host. Nach Einfügung der Zeile <http-method>GET</http-method> in die web.xml-Konfigurations­ datei der Webanwendung wird der Zugriff beim erneuten Versuch blockiert: Listing 39: Ausgaben beim Zugriffstest mit Zugriffsbeschränkung debian-host1:/opt/jakarta-tomcat-5.5.9/logs# telnet localhost 8080 Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. GET /simple_info1/request_data.jsp HTTP/1.0 HTTP/1.1 401 Unauthorized Server: Apache-Coyote/1.1 Pragma: No-cache Cache-Control: no-cache Expires: Thu, 01 Jan 1970 01:00:00 CET WWW-Authenticate: Basic realm="Simple_Info1 Realm" Content-Type: text/html;charset=utf-8 Content-Length: 952 Date: Thu, 03 Nov 2005 13:58:18 GMT Connection: close <html><head><title>Apache Tomcat/5.5.9 - Error report</title><style><!--H1 {fontfamily:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;fontsize:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {fontfamily:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 401 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>This request requires HTTP authentication ().</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/5.5.9</h3></body></html>Connection closed by foreign host. Bundesamt für Sicherheit in der Informationstechnik Seite 116 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Das gleiche Verhalten zeigt sich so auch bei den anderen HTTP-Zugriffsmethoden (HEAD, PUT, POST, DELETE), unabhängig davon ob die Verbindung direkt zum Tomcat HTTPConnector oder via Apache Webserver mit mod_jk und Tomcat mit AJP-Connector aufgebaut wurde. Im letzten Fall ändert sich die Anweisung zum Aufbau der HTTPVerbindung in telnet tomcathost 80: • Ohne die Zeile zur Zugriffsbeschränkung wird die Anfrage ohne Authentisierung mit einem HTTP-Status 200 OK akzeptiert. Bei der vorliegenden Konfiguration werden allerdings keine Datei per PUT erzeugt, keine Informationen aus der POST-Anfrage ausgewertet und keine Löschoperation aus der DELETE-Anfrage heraus durchgeführt. • Mit der Zugriffsbeschränkung wird die Anfrage mit einer Authentisierungsanforderung („HTTP-Status 401 Unauthorized“) unter Angabe des für die Authentisierung zu verwendenden Authentisierungs-Realm zurückgewiesen. Da neben den getesteten HTTP-Zugriffsmethoden noch weitere existieren, z. B. OPTIONS, TRACE, CONNECT und außerdem für WebDAV die Methoden PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, s. a. [RFC2518], wurde im Tomcat-Quelltext nachgeprüft, dass prinzipiell beliebige HTTP-Zugriffsmethoden definiert werden können. Diese können dann als Zeile <http-method>...</http-method> in die Konfigurationsdatei WEB-INF/web.xml in den Bereich <web-resource-collection> der Webanwendung eingefügt werden. Beim Zugriff auf das zugehörige und per <url-pattern>...</url-pattern> definierte URL-Pattern wird nun eine Überprüfung auf Zulässigkeit per Zeichenkettenvergleich der HTTP-Methode und den spezifizierten Methoden, die eine Authentisierung erfordern, durchgeführt. Wichtig ist hierbei, dass immer ein zugehöriges URL-Pattern, für das die Einschränkung gelten soll, definiert sein muss. Hinweis: Bei der Verwendung der <http-method> Direktiven ist zu beachten, dass nur für in der Liste aufgeführte Zugriffsmethoden eine Authentisierung erforderlich ist. Für die nicht genannten Zugriffsmethoden ist ein Zugriff ohne Authentisierung möglich, sofern diese nicht auf anderem Weg erzwungen wird. Diese Zugriffsmethoden sind somit nicht blockiert. Hinweis: im Test T35 werden lediglich die Filtermöglichkeiten seitens Tomcat untersucht. Der Apache Webserver bietet darüber hinaus eine Beschränkung der HTTP-Zugriffsmethoden (GET, PUT, POST, DELETE, ...) in Verbindung mit der <Limit>-Direktive, die allerdings nicht Gegenstand der hier vorgenommenen Untersuchungen ist. Beim Apache Webserver wurden für diesen Test keine Restriktionen gesetzt. 5.1.2.3 Tests der Zugriffsrechte auf dem Niveau von Valves Für diese Tests wird ein Request Filter Valve auf Host-Ebene definiert. Dieses soll die Anfragen an alle Webanwendungen des Hosts auf Basis der IP-Adresse oder des Host­ namens regeln. Beispielsweise wird durch die folgenden Einträge im Host-Bereich der server.xml-Datei ein „Remote Address Filter“ eingerichtet: Listing 40: Request Filter Valve Ergänzung in der Tomcat-Konfigurationsdatei server.xml <Host name="localhost" ...> ... Seite 117 (von 187) Bundesamt für Sicherheit in der Informationstechnik Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests <Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="192.168.1.*"/> ... </Host> Dieser Eintrag verbietet Anfragen von bestimmten IP-Adressen bzw. IP-Adressbereichen. Die Wirkungsweise des Filter Valves würde die gleiche sein, wenn es auf der Ebene der Webanwendung definiert wäre. Anders wäre dann die Reichweite, eben nur für diese spezifische Webanwendung, statt für den gesamten Tomcat Server. Valves werden von der Tomcat-Engine verwaltet, d. h. von einem hohen Niveau in der Tomcat-Architektur. Die Tomcat-Engines bekommen Nachrichten von Connectoren, bevor diese an ein Servlet oder JSP geleitet werden und umgekehrt. Die Filter Valves leiten Nachrichten abhängig vom Inhalt, aber unabhängig vom Installationskontext des Valves weiter bzw. nicht weiter. Deshalb ist eine Überprüfung des Valves auf dem Niveau des Hosts ausreichend, um die Sicherheitsfunktionalität zu testen. Tabelle 6 zeigt die verschiedenen Filter, die durch diese Tests überprüft werden. Bei allen Tests wird versucht, von verschiedenen Maschinen aus auf eine von Tomcat verwaltete Webanwendung zuzugreifen. Test Nr. TomcatConnector T 36 HTTP und AJP T 37 HTTP und AJP T 38 HTTP und AJP T 39 HTTP und AJP Beschreibung: Konfiguration des Valves erwartetes Resultat: Zugriff vom Client / von anderen Maschinen Anfragen der IP-Adresse des Clientsnicht möglich / möglich sollten verboten sein. („Remote Address Filter“) Anfragen der IP-Adresse des Clientsmöglich / nicht möglich sollten erlaubt sein. („Remote Address Filter“) Anfragen mit dem Hostnamen des Clientsnicht möglich / möglich sollten verboten sein. („Remote Address Filter“) Anfragen mit dem Hostnamen des Clientsmöglich / nicht möglich sollten erlaubt sein. („Remote Address Filter“) Tabelle 6: Funktionale Tests der Zugriffskontrolle auf dem Niveau von Valves Diese Tests werden sowohl für die Konfiguration mit dem HTTP Connector (stand-alone, Einsatzszenario 1) als auch für die Konfiguration mit dem AJP Connector durchgeführt. Prinzipiell könnte es zwischen den zwei Connectoren Unterschiede in den übertragenen Informationen zum Client-System geben. Zunächst wird die IP-Adresse des VMware-Hostsystems bigmama durch den Eintrag in der <Host> Deklaration innerhalb von $CATALINA_HOME/conf/server.xml vom Zugriff ausge­ schlossen. Listing 41: IP-Address Filter Eintrag in der Tomcat-Konfigurationsdatei server.xml <Valve className=“org.apache.catalina.valves.RemoteAddrValve“ deny=“192.168.118.1“ /> Bundesamt für Sicherheit in der Informationstechnik Seite 118 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Hinweis: Im Verlauf der Tests wurde festgestellt, dass zwar Wildcard-Character in der IPAdresse verwendet werden dürfen (z. B. 192.168.118.*), die Verwendung der alternativen Notation 192.168.118.0/24 jedoch nicht zum Ausschluss der entsprechenden IP-Adressen führt. Dies könnte in Verbindung mit dem Ausschluss von IP-Adressbereichen, die kein vollständiges Oktett umfassen, z. B. für ein Subnetz 192.168.118.0/26 für den Adressbereich 192.168.118.0 ... 192.168.118.63, zu Problemen führen, da in diesem Fall einzelne IPAdressen, durch Komma separiert in der deny-Liste, aufgeführt werden müssten. Hinweis: Die verwendbaren Wildcard-Character und Regular-Expressions bei der Definition der IP-Adressen sind u. U. abweichend von den üblicherweise im Kontext von Shell-Pro­ grammierung gebräuchlichen. Tomcat verwendet die Jakarta Regexp Bibliothek, eine Beschreibung der damit verwendbaren regulären Ausdrücke findet sich in [Jakarta Regexp]. 5.1.2.3.1 T36.1 HTTP Connector, verbotene Anfragen mit IP-Adresse des Clients Der Aufruf der Webseite http://192.168.118.101:8080/simple_info1 mit einem Webbrowser vom VMware-Hostsystem bigmama aus führt zu einer leeren Webseite. Ein direkter Aufruf der Applikation mit telnet führt zu folgendem Ergebnis: zunächst wird ein Redirect ausgelöst, wobei der folgende Zugriff auf das dabei angegebene Ziel nicht zugelassen wird. Listing 42: Ausgaben beim Test des Zugriffs eines blockierten Clients (HTTP Connector) bigmama> telnet 192.168.118.101 8080 Trying 192.168.118.101... Connected to 192.168.118.101. Escape character is '^]'. GET /simple_info1 HTTP/1.0 HTTP/1.1 302 Moved Temporarily Server: Apache-Coyote/1.1 Location: http://192.168.118.101:8080/simple_info1/ Date: Thu, 20 Oct 2005 22:14:35 GMT Connection: close Connection closed by foreign host. bigmama> telnet 192.168.118.101 8080 Trying 192.168.118.101... Connected to 192.168.118.101. Escape character is '^]'. GET /simple_info1/ HTTP/1.0 HTTP/1.1 403 Forbidden Server: Apache-Coyote/1.1 Date: Thu, 20 Oct 2005 22:17:38 GMT Connection: close Connection closed by foreign host. 5.1.2.3.2 T36.2 AJP13 Connector, verbotene Anfragen mit IP-Adresse des Clients Der Aufruf der Webseite http://192.168.118.101/simple_info1 mit einem Webbrowser vom VMware-Hostsystem aus führt zu einer leeren Webseite. Ein direkter Aufruf der Applikation Seite 119 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers mit telnet führt zu folgendem Ergebnis: zunächst wird ein Redirect ausgelöst, wobei der Zugriff auf das dabei angegebene Ziel nicht zugelassen wird. Listing 43: Ausgaben beim Test des Zugriffs eines blockierten Clients (AJP13 Connector) bigmama> telnet 192.168.118.101 80 Trying 192.168.118.101... Connected to 192.168.118.101. Escape character is '^]'. GET /simple_info1 HTTP/1.0 HTTP/1.1 302 Moved Temporarily Date: Thu, 20 Oct 2005 22:14:52 GMT Server: Apache/2.0.54 (Unix) mod_jk/1.2.14 Location: http://127.0.0.1/simple_info1/ Connection: close Content-Type: text/plain Connection closed by foreign host. bigmama> telnet 192.168.118.101 80 Trying 192.168.118.101... Connected to 192.168.118.101. Escape character is '^]'. GET /simple_info1/ HTTP/1.0 HTTP/1.1 403 Forbidden Date: Thu, 20 Oct 2005 22:18:18 GMT Server: Apache/2.0.54 (Unix) mod_jk/1.2.14 Connection: close Content-Type: text/plain Connection closed by foreign host. 5.1.2.3.3 T37 Erlaubte Anfragen mit IP-Adresse des Clients Für die Tests in T37 wird zunächst die IP-Adresse des VMware-Hostsystems bigmama durch den Eintrag in der <Host> Deklaration innerhalb von $CATALINA_HOME/conf/server.xml für den Zugriff zugelassen. Listing 44: IP-Address Filter Eintrag in der Tomcat-Konfigurationsdatei server.xml <Valve className=“org.apache.catalina.valves.RemoteAddrValve“ allow=“192.168.118.1“ /> 5.1.2.3.4 T37.1 HTTP Connector, erlaubte Anfragen mit IP-Adresse des Clients Der Aufruf der Webseite http://192.168.118.101:8080/simple_info1 mit einem Webbrowser vom VMware-Hostsystem aus führt zur gewünschten Webseite. Ein Aufruf vom lokalen Host, auf dem der Tomcat Servlet Container läuft, führt zu einer leeren Webseite. Analog zum vorigen Test T36.1 führt ein direkter Aufruf der Applikation vom lokalen Host aus mit telnet zu folgendem Ergebnis: zunächst wird ein Redirect ausgelöst, wobei der Zugriff auf das dabei angegebene Ziel nicht zugelassen wird. Bundesamt für Sicherheit in der Informationstechnik Seite 120 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests 5.1.2.3.5 T37.2 AJP13 Connector, erlaubte Anfragen mit IP-Adresse des Clients Der Aufruf der Webseite http://192.168.118.101/simple_info1 mit einem Webbrowser vom VMware-Hostsystem aus führt zur gewünschten Webseite. Ein Aufruf vom lokalen Host, auf dem der Tomcat Servlet Container läuft, führt zu einer leeren Webseite. Analog zum vorigen Test T36.2 führt ein direkter Aufruf der Applikation vom lokalen Host aus mit telnet zu folgendem Ergebnis: zunächst wird ein Redirect ausgelöst, wobei der Zugriff auf das dabei angegebene Ziel nicht zugelassen wird. 5.1.2.3.6 T38 / T 39 HTTP bzw. AJP13 Connector, verbotene / erlaubte Anfragen mit Hostname des Clients Zum Test der auf Hostnamen basierenden Zugriffssteuerung ist eine funktionsfähige Domain Name Service (DNS) Infrastruktur erforderlich, da Tomcat die Hostnamen anhand der in den Paket-Headern befindlichen IP-Adressen bestimmt. Beim Reverse DNS Lookup sind die Anfragen an den DNS-Server im Netzwerkverkehr mitlesbar. Anhand des vom DNS-Server zurückgegebenen Hostnamens des anfragenden Webclients wird mit dem Suchmuster bestimmt, ob ein Zugriff auf die Webseite zugelassen oder abgelehnt werden muss. Eine Beschreibung der Konfiguration eines hierfür geeigneten DNS-Servers wird in Abschnitt 3.8 gegeben. Zum Test wurde ein DNS-Server auf der virtuellen Maschine installiert, die gleichzeitig als Webserver- und Tomcat-Host dient. Auf diesem DNS-Server wurden folgende Definitionen vorgenommen: • Domäne: external.de (192.168.118.64/26) • • Host: bigmama, IP-Adresse 192.168.118.1 Domäne: bsitomcat.de (192.168.118.128/26) • Host: template, IP-Adresse 192.168.118.100 • Host: tomcathost, IP-Adresse 192.168.118.101 Für die Zugriffstests werden durch den Eintrag <Valve className=“org.apache.catalina.valves.RemoteHostValve“ **** allow/deny declaration *** /> in der <Host> Deklaration innerhalb von $CATALINA_HOME/conf/server.xml die verbotenen bzw. zugelassenen Hosts bzw. Domänen eingetragen (s. Tabelle 7). Nach Änderung dieses Eintrags ist Tomcat jeweils neu zu starten. Es wurden folgende Testergebnisse Webanwendung mit den URLs • bei Zugriffen auf die simple_info1 Tomcat http://tomcathost.bsitomcat.de:8080/simple_info1/ bzw. Seite 121 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests • Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers http://localhost:8080/simple_info1/ für einen Direktzugriff auf Tomcat über den HTTP-Connector sowie • http://tomcathost.bsitomcat.de:80/simple_info1/ bzw. • http://localhost:80/simple_info1/ für einen Zugriff über den Apache Webserver in Verbindung mit dem mod_jk-Modul sowie dem Tomcat AJP-Connector erzielt: Bundesamt für Sicherheit in der Informationstechnik Seite 122 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers *** allow / deny declaration *** für das RemoteHostValve (in $CATALINA_HOME/conf/server.xml) Durchführung der Tests Zugriff über bigma templ tomcat Port (Tomcat ma.exte ate.bs host.bs Connector) rnal.de itomc itomcat at.de .de deny=“.*\.external\.de“ 8080 (HTTP) 403 200 200 localho st (auf tomcat host), s. u. 200 allow=“.*\.external\.de“ 80 (AJP) 8080 (HTTP) 403 200 200 403 200 403 200 403 deny=“.*\.bsitomcat\.de“ 80 (AJP) 8080 (HTTP) 200 200 403 403 403 403 403 200 allow=“.*\.bsitomcat\.de“ 80 (AJP) 8080 (HTTP) 200 403 403 200 403 200 200 403 80 (AJP) 403 200 200 403 Tabelle 7: Tests der Hostnamen-basierten Zugriffskontrolle (Reverse DNS Lookup ist verfügbar) Die dem HTTP Status Code entsprechenden Einträge in der Tabelle haben dabei die folgende Bedeutung: • 200: die Webseite konnte korrekt abgerufen werden („HTTP Status 200 Success“) • 403: ein Zugriff auf die Webseite wurde blockiert („HTTP Status 403 Forbidden“) Insgesamt konnten keine Abweichungen vom erwarteten Verhalten festgestellt werden. Bei Zugriffen von der virtuellen Maschine aus, auf der Tomcat selbst läuft, ist folgende Unterscheidung zu beachten: • Wird dort die Webseite http://localhost:8080/simple_info1/ aufgerufen, so erfolgt die Kommunikation in beide Richtungen (vom / zum Tomcat- bzw. Webserver) über die IP-Adresse 127.0.0.1 (localhost), die keiner der im DNS-Server eingetragenen Domänen angehört. Somit wird sie bei der Sperrung der lokalen Domäne bsitomcat.de auch nicht blockiert. • Wird hingegen die Webseite http://tomcathost.bsitomcat.de:8080/simple_info1/ aufgerufen, so wird die Kommunikation über die dem Server zugeordnete IP-Adresse 192.168.118.101 (tomcathost) abgewickelt. Hierzu kann bei der DNS-Abfrage (Reverse DNS Lookup) für den Webclient eine Domänenzuordnung nach bsitomcat.de vorgenommen werden. Diese Besonderheiten wurden durch Mitlesen des Netzwerkverkehrs zwischen Webbrowser und Webserver sowie dessen Kommunikation mit dem DNS-Server verifiziert. Hinweis: Die verwendbaren Wildcard-Character und Regular-Expressions bei der Definition der Host- oder Domänennamen sind u. U. abweichend von den üblicherweise im Kontext von Shell-Programmierung gebräuchlichen, sodass bei Verwendung Letzerer möglicher­ weise unerwartete Ergebnisse erzielt werden können. Insbesondere bei der Definition von deny-Regeln ist mit entsprechender Vorsicht vorzugehen. Tomcat verwendet die Jakarta Regexp Bibliothek, eine Beschreibung der Ausdrücke findet sich in [Jakarta Regexp]. Neben dem regulären Verhalten wurde auch noch der Fall untersucht, dass der DNS Server für ein Reverse DNS Lookup nicht zur Verfügung steht. Dieser Fall kann eintreten, wenn Seite 123 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers beispielsweise die für den Tomcat Server eingestellten DNS Server z. B. auf Grund von Netzwerkproblemen nicht erreichbar sind. Im vorliegenden Test wurde einfach der lokale DNS-Server auf tomcathost mit dem Kommando /etc/init.d/bind9 stop angehalten. Bei diesem Test wurden die in Tabelle 8 gezeigten Ergebnisse erzielt, wobei das korrekte Verhalten bei Verfügbarkeit des DNS-Server aus dem vorigen Test zum Vergleich mit aufgenommen wurde. In der Tabelle wurden durch die unterstrichenen Einträge die Stellen markiert, bei denen abweichendes Verhalten gegenüber den gewählten RemoteHostValve-Einstellungen auf Grund fehlenden Reverse DNS Lookups festzustellen ist. Die Tabelleneinträge entsprechen wiederum dem HTTP Status Code der Antworten von Tomcat (s. S. 123). Bei den Einträgen mit dem HTTP Status Code 200 wird die angeforderte Webseite zurück gegeben, beim HTTP Status Code 403 erfolgt eine Fehlermeldung. Zusammenfassend lässt sich feststellen, dass im Fall der Nicht-Verfügbarkeit des DNS Servers für ein Reverse DNS Lookup und damit der Namensauflösung zur IP-Adresse der HTTP-Anfrage folgendes Verhalten auftritt: • bei grundsätzlicher Zugriffserlaubnis: d. h. es werden alle Anfragen beantwortet, die nicht per deny Regel blockiert werden. Da zur IP-Adresse der Anfrage kein Hostbzw. Domänenname gefunden wird, kann nicht positiv mit einer deny Regel verglichen werden und es erfolgt somit die Beantwortung aller Anfragen. Und dies, obwohl der der IP-Adresse zugeordnete Host- oder Domänenname in der deny Regel für einen Zugriff auf die Web-Ressourcen möglicherweise nicht freigegeben ist und somit zu einer Abweisung hätte führen müssen. • bei grundsätzlichem Zugriffsverbot : d. h. es werden keine Anfragen beantwortet, die nicht per allow Regel zugelassen werden. Da zur IP-Adresse der Anfrage kein Hostbzw. Domänenname gefunden wird, kann nicht positiv mit einer allow Regel verglichen werden und es erfolgt keine Beantwortung der Anfrage. Dies führt zu einer Abweisung aller Anfragen, obwohl möglicherweise der der IP-Adresse zugeordnete Host- oder Domänenname in der allow Regel freigegeben ist. Bundesamt für Sicherheit in der Informationstechnik Seite 124 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers *** allow / deny declaration *** für das RemoteHostValve (in $CATALINA_HOME/conf/server.xml) deny=“.*\.external\.de“ allow=“.*\.external\.de“ deny=“.*\.bsitomcat\.de“ allow=“.*\.bsitomcat\.de“ Durchführung der Tests Zugriff über Revers bigm tomcat localho Port (Tomcat e DNS- ama.e host.bs st (auf Connector) Lookup xtern itomcat tomcat verfügb al.de .de host), ar s. u. 8080 (HTTP) Ja 403 200 200 Nein 200 200 200 80 (AJP) Ja 403 200 200 8080 (HTTP) Nein Ja 200 200 200 403 200 403 Nein 403 403 403 80 (AJP) Ja 200 403 403 8080 (HTTP) Nein Ja 403 200 403 403 403 200 Nein 200 200 200 80 (AJP) Ja 200 403 200 8080 (HTTP) Nein Ja 200 403 200 200 200 403 Nein 403 403 403 Ja 403 200 403 Nein 403 403 403 80 (AJP) Tabelle 8: Tests der Hostnamen-basierten Zugriffskontrolle in Abhängigkeit von der Verfügbarkeit von Reverse DNS Lookup 5.1.2.4 Protokollierung Ziel des Tests ist es zu prüfen, ob und wie System-Ereignisse, beispielsweise Meldungen mit Informationen, Fehlern oder Warnungen, sowie webanwendungsspezifische Client Anfragen protokolliert werden. Für den Test werden zwei Arten von Protokollierungen eingerichtet: 1. Protokollierung durch eine <Logger>-Komponente 2. Protokollierung durch ein AccessLogValve Beide Protokollierungsarten werden für Testzwecke auf dem Niveau der Catalina Engine eingestellt und werden daher die maximale Reichweite haben. Die <Logger>-Komponente wird mit den Default-Einstellungen eingerichtet und maximale „verbosity“ („debug“, Niveau 4) der Protokollierung in eine Datei („FileLogger“) besitzen. Für das Access Log Valve wird die Default-Einstellung für das Format der Protokolldatei („common“) übernommen. Die in Tabelle 9 zusammengefassten Tests bestehen im Wesentlichen aus einer Kontrolle des Umfangs und der Struktur der erstellten Protokolldateien. Seite 125 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Test Nr. T 40 TomcatBeschreibung Connector HTTP und Kontrolle der Protokolldatei für eine AJP <Logger>-Komponente T 41 HTTP und Kontrolle der Protokolldatei für ein AccessLogValve AJP Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers erwartetes Resultat protokollierte Information entsprechend der Dokumentation dargestellt protokollierte Information entsprechend der Dokumentation dargestellt Tabelle 9: Übersicht über die funktionalen Sicherheitstests der Protokollierung Zur Durchführung der Tests werden verschiedene Anfragen für Ressourcen von ClientBrowsern an Tomcat gesendet. Zudem wird z. B. der Tomcat-Server heruntergefahren oder es werden bestimmte Webanwendungen angehalten, um die Protokollierung der System­ ereignisse zu untersuchen. Da die zwei Connectoren (HTTP, AJP) im Prinzip unterschiedliche Information vom Client nach Tomcat übertragen könnten, werden diese Tests für beide Connectoren durchgeführt. 5.1.2.4.1 T40 Kontrolle der Log-Datei für eine <Logger>-Komponente Durch Änderungen in der Architektur von Tomcat 5.5 im Vergleich zu den Vorgängerver­ sionen wird die früher vorhandene <Logger>-basierte Protokollierung nicht mehr unterstützt. Eine versuchsweise Aktivierung durch Einbringung einer <Logger>-Definition in der Konfigu­ rationsdatei $CATALINA_HOME/conf/server.xml führte zu einer „ClassNotFound Exception“ beim Start von Tomcat. Statt dessen erfolgt die Protokollierung per java.util.logging Paket, dessen Konfiguration in der Datei $CATALINA_HOME/common/class/logging.properties festgelegt wird. In den unter $CATALINA_HOME/logs erzeugten Protokolldateien können wichtige System­ ereignisse wie • Tomcat gestartet / beendet, • Webanwendung gestartet / beendet, • Aktualisierung von laufenden Webanwendungen, z. B. nach Änderungen in den Konfigurationsdateien der Webanwendungen, • Fehlermeldungen, z. B. bei der Übersetzung von Servlets währende einer HTTP(S)/AJP-Benutzeranfrage oder fehlenden Klassen / jar-Archiven, aus entsprechend programmierten Fehlerausgaben der Servlets nachvollzogen werden. Zugriffe von Benutzern auf Webanwendungen werden hiermit nicht protokolliert. Dies ist vielmehr die Aufgabe der separat zu spezifizierenden AccessLogValve. Bundesamt für Sicherheit in der Informationstechnik Seite 126 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests 5.1.2.4.2 T41 Protokollierung mit Access Log Valve Zur Feststellung der überhaupt mit den Standard Pattern Codes protokollierbaren Informationen wird zunächst unter Verwendung aller Pattern Codes die maximal mögliche Protokollierungstiefe eingestellt42: <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="accLogValve_##_" pattern="%t %a %A %b %B %h %H %l %m %p %q %r %s %S %u %U %v %D %T" suffix=".txt"> </Valve> Die Reihenfolge ist – mit Ausnahme der Zugriffszeit (%t) – einfach alphabetisch gewählt. Dieser Eintrag wird in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml je einmal auf <Host>-Ebene (## = host) und einmal auf <Engine>-Ebene (## = engine) definiert, wobei durch die unterschiedlichen Protokolldateien eine Unterscheidbarkeit der Einträge für den Test gewährleistet wird. Nach einigen Testzugriffen auf Tomcat konnte bei einem Vergleich beider generierter LogDateien festgestellt werden, dass sich die Einträge außer in der Bearbeitungszeit der einzelnen Anfragen nicht unterscheiden. Der Unterschied der Bearbeitungszeit-Einträge ist dadurch hervorgerufen, dass auf <Engine>-Niveau zusätzliche Zeit zur Auswahl des (virtuellen) Hosts zur Abarbeitung der Anfragen benötigt wird. Der Umfang der mit­ geschriebenen Protokollinformationen entspricht den in der Dokumentation angegebenen Werten. Nach Änderung des Protokollierungspattern-Eintrages auf “common“ (entspricht der Stan­ dardeinstellung ohne Angabe eines Protokollierungspattern) bzw. “combined“ und Restart von Tomcat werden nur noch die jeweils in der Tomcat-Dokumentation angegebenen Werte in der Protokolldatei erfasst. Auch hierbei sind keine Unterschiede (evtl. mit Ausnahme der Bearbeitungszeit) in Abhängigkeit von der Schnittstelle, über die die Anfrage bei Tomcat eingetroffen ist, feststellbar. Eine Unterscheidung, über welche Schnittstelle die Anfrage bei Tomcat eingetroffen ist (HTTP/HTTPS-Connector, AJP-Connector), ist lediglich über die protokollierten PortInformation (%p) und deren Zuordnung zu den eingestellten Connector-Port-Zuweisungen in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml möglich. Es erfolgt sowohl eine Protokollierung der erfolgreichen Zugriffe, als auch derjenigen die z. B. mangels vorhandener Webseite bzw. Applikation (HTTP-Return-Code 404) oder wegen nicht ausreichender Zugriffsberechtigungen abgebrochen wurden (HTTP-Return-Code 401 oder 403). 5.1.2.5 Zuverlässigkeit der Dienstleistung Bei diesem Test wird eine Konfiguration für Hochverfügbarkeit eingerichtet. Diese entspricht Einsatzszenario 3: 42 Neben den Standard Pattern Codes können weitere gemäß der Apache Syntax definiert werden (s. [Apache mod_log]) wie %{###}i zur Abfrage des HTTP(S) Header Attributs ###, %{###}c für Cookie-Informationen, %{###}r für das Attribut ### im ServletRequest und %{###}s für Attribut ### der HTTP-Session, die hier nicht weiter untersucht werden. Da mit diesen noch detailliertere Informationen aus den HTTP(S)-Anfragen mit protokolliert werden könnten, können hiermit Datenschutz-relevante Punkte berührt werden. Seite 127 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • Zwei identische Tomcat-Instanzen in einer Load-Balancing-Konfiguration hinter einem Apache-Server mit mod_jk. • „Sticky Sessions“ • Speicherung der Sessiondaten in einem externen NFS-Dateisystem mit dem „Persistent Session Manager“ Danach werden die Tests aus Tabelle 10 durchgeführt. Test Nr. T 42 TomcatConnector AJP T 43 AJP Beschreibung erwartetes Resultat Test des automatischen Failovers Übernahme einer Session ohne beim Ausfall einer Tomcat-Instanz Verlust der Sessiondaten Test der „Persistent Sessions“ beim Beim anschließenden Neustart Runterfahren beider Tomcatkein Verlust der Sessiondaten Instanzen. Tabelle 10: Übersicht über die funktionalen Sicherheitstests der Zuverlässigkeit der Dienstleistung 5.1.2.5.1 T42 Failover beim Ausfall einer Tomcat-Instanz Gemäß Dokumentation43 wird eine Web-Anwendung zunächst so konfiguriert, dass der PersistentManager zum Speichern von Session-Daten im Dateisystem zum Einsatz kommt. Als Anwendung ist SessionExample aus den Demos zu Tomcat geeignet. Folgende Konfigurationsdatei wird benötigt: Listing 45: Einsatz von Persistent Sessions per Datei webapps/servlets-examples/METAINF/context.xml <Context> <Manager className="org.apache.catalina.session.PersistentManager" maxIdleBackup="1" maxIdleSwap="2" maxInactiveInterval="1800" saveOnRestart="true"> <Store className="org.apache.catalina.session.FileStore" directory="/tmp/tomcat" checkInterval="10"/> </Manager> </Context> Die Parameter maxIdleSwap usw. sind extrem klein gewählt, damit Tomcat die SessionDaten schnell in den persistenten Speicher überträgt. Diese Werte erleichtern die Tests, sind für den Produktivbetrieb jedoch ungeeignet. Laut Dokumentation sollte das Element <distributable> für die Webanwendung noch wie folgt gesetzt werden: 43 http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html Bundesamt für Sicherheit in der Informationstechnik Seite 128 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Listing 46: Ergänzung webapps/servlets-examples/WEB-INF/web.xml um <distributable> <web-app> <display-name>Servlet 2.4 Examples</display-name> <description> Servlet 2.4 Examples. </description> <distributable/> Wenige Sekunden nach dem ansprechen der URL http://tomcathost/servletsexamples/servlet/SessionExample wird im Verzeichnis /tmp/tomcat/ die Datei 6A3FDD31BCF6C6399BAC938F97C8AA8D.session erzeugt. Diese enthält im „Serializable“ genannten standardisierten binären Format von Java die im Browser angegebenen Parameter und Wertepaare. Diese Nummer entspricht dem Wert des Cookies, das unter dem Namen JSESSIONID und dem Pfad /servlets-examples im Browser abgelegt wird. Anhand dieses Cookies wird die Session identifiziert. sessions.id 6A3FDD31BCF6C6399BAC938F97C8AA8D sessions.created Tue Jan 17 11:02:36 CET 2006 sessions.lastaccessed Tue Jan 17 11:10:29 CET 2006 sessions.data foo = bar zot = grr javax.security.auth.subject = Betreff: bar = zot Im Browser erscheint ein Formular zur Eingabe weiterer Wertepaare. Bei Änderung wird die Datei aktualisiert, was sowohl am Datum als auch am Inhalt sichtbar wird. Wird eine Instanz vom Tomcat abgebrochen, so wird bei weiteren Zugriffen nach einiger Verzögerung die zweite Instanz von Tomcat aufgerufen. Anhand des im Browser gespeicherten Cookies und des von beiden Instanzen erreichbaren Pfades /tmp/tomcat/ ist auch der zweite Tomcat in der Lage die gleichen Inhalte wie zuvor anzuzeigen. Session-ID und sämtliche Wertepaare bleiben erhalten. 5.1.2.5.2 T43 Persistente Sessions beim Herunterfahren Es wird die gleiche Konfiguration wie bei T42 verwendet. Die Zeile saveOnRestart="true" stellt sicher, dass etwaig gespeicherte Session-Daten beim normalen Beenden von Tomcat gespeichert und beim Neustart geladen werden. Sofern der Browser den Cookie behalten hat, bzw. gar nicht erst geschlossen wurde, stehen die Session-Daten unter der URL http://tomcathost/servlets-examples/servlet/SessionExample wieder zur Verfügung. Die Dokumentation zum PersistentManager erwähnt, dass dieser nicht für den Produktiv­ betrieb geeignet ist. In der Tat bietet das Abspeichern in Dateien mehrere Hürden, die mit serialisiertem, atomaren und konsistenten Zugriffsmöglichkeiten von Datenbanken gemeistert werden. Seite 129 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 5.1.2.6 Verschlüsselung Bei diesem Test werden die Möglichkeiten des Clients in Bezug auf Veränderungen in der SSL-Verschlüsselung untersucht. Eine Webanwendung wird mit einem Security Constraint eingerichtet, welches eine Verschlüsselung verlangt („Confidential“). Danach wird von einem Client aus versucht, verschiedene Merkmale der SSL-Verschlüsselung zu beeinflussen (Tabelle 11). Test Nr. T 44 TomcatConnector HTTP und AJP T 45 HTTP und AJP T 46 HTTP und AJP Beschreibung erwartetes Resultat Client versucht, ein Cipher nicht möglich „NULL“ zu verlangen und so die Verschlüsselung abzuschalten Client versucht, ein unbekannt schwaches Cipher (z. B. 40 Bit EXPORT) zu verlangen Client versucht, eine unbekannt Veränderung der SSLVersion-Nr. (2.0, 3.0) zu verlangen Bemerkung sollte von Tomcat abgefangen werden, zumindest beim HTTP Connector diesbezüglich keine Dokumentation bekannt diesbezüglich keine Dokumentation bekannt Tabelle 11: Übersicht über die funktionalen Sicherheitstests der Verschlüsselung Die SSL-Kommunikation des Clients mit dem AJP-Connector erfolgt über das Produkt Apache Webserver / mod_ssl, wobei die SSL-Verschlüsselung nicht durch den Tomcat Server durchgeführt wird. Daher werden SSL-basierte Untersuchungen ausschließlich am SSL/HTTP-Connector des Tomcat-Servers durchgeführt. 5.1.2.6.1 T44 SSL mit Null-Cipher Bei diesem Test wurde geprüft, ob der SSL-Connector des Tomcat Servers auch eine SSLVerbindung ohne Verschlüsselung (-cipher NULL) akzeptiert. Der SSL-Connector des Tomcat-Servers wurde entsprechend der Installationsanleitung in diesem Dokument konfiguriert. Die Anfrage des Clients wurde mit folgendem Script T44_request.sh abgesendet: #!/bin/bash echo -e "GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n"|openssl s_client \ -connect localhost:8443 \ -cipher NULL \ -debug \ -quiet Die Benutzung dieses Skripts war erfolgreich. Eine SSL-Verbindung zwischen dem Client openssl und dem Server kam zustande, obwohl eine Verschlüsselung nicht statt fand (cipher: NULL-SHA). Nachfolgend wird ein Ausschnitt der Protokollierung der SSL-Verbindung dargestellt. Bundesamt für Sicherheit in der Informationstechnik Seite 130 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests ... --SSL handshake has read 1501 bytes and written 235 bytes --New, TLSv1/SSLv3, Cipher is NULL-SHA Server public key is 1024 bit SSL-Session: Protocol : TLSv1 Cipher : NULL-SHA Session-ID: 4387774D6BAB4F85DE47DBA6A248BDC24629029862680D61B02A7D3B2EC9BF11 Session-ID-ctx: Master-Key: 033B3FF05B5DDD3400BBC1793DEC5C6F2D570780707885209F65BE2B568F3F6B 838A233F7112E01FC1E02C5B3E48EBB6 Key-Arg : None Start Time: 1132951373 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- 5.1.2.6.2 T45 SSL mit schwacher Verschlüsselung Bei diesem Test wurde geprüft, ob der SSL-Connector des Tomcat Servers auch eine SSLVerbindung mit schwacher Export-Verschlüsselung (-cipher EXP-RC4-MD5) akzeptiert. Wiederum wurde ein Skript T45request.sh aufgesetzt, mit dem der Test durchgeführt wurde: #!/bin/bash echo -e "GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n"|openssl s_client \ -connect localhost:8443 \ -cipher EXP-RC4-MD5 \ -debug \ -quiet Der Client konnte erfolgreich eine SSL-Verbindung mit dem SSL-Connector des Tomcat Servers aufbauen. Nachfolgend der Auszug aus dem Verbindungsprotokoll. ... --New, TLSv1/SSLv3, Cipher is EXP-RC4-MD5 Server public key is 1024 bit SSL-Session: Protocol : TLSv1 Cipher : EXP-RC4-MD5 Session-ID: 438777935665009A73A93E8AF1D577FA419B49A2DDE1F657129C6DF0AEDE86B2 Session-ID-ctx: Master-Key: AD6D4A2B416ACED072534EB7FF74F592A67B325E389D72E89E2DF10EB6F14C72 A4AD5DC0CAD23EAD180CD3EF29CB9DA5 Key-Arg : None Start Time: 1132951443 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) ... 5.1.2.6.3 T46 SSLv2, SSLv3 oder TLS Bei diesem Test wurde geprüft, ob der SSL-Connector des Tomcat Servers auch eine SSLVerbindung mit anderen Verbindungsstandards (SSLv2, SSLv3, TLS) akzeptiert, obwohl als Protokoll in der Konfiguration des SSL Connectors TLS festgelegt war. Für den Test wurde folgendes Skript T46request.sh verwendet: #!/bin/bash Seite 131 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers echo -e "GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n"|openssl s_client \ -connect localhost:8443 \ -ssl2 \ -debug \ -quiet Neben diesem Skript, welches Client-seitig SSLv2 verwendet, wurde das gleiche Skript auch mit der Option SSLv3 angewendet. Die Ergebnisse der Anfragen sind in nachfolgender Tabelle dargestellt: VerschlüsselungsProtokoll TLS SSLv2 SSLv3 Ergebnis Erfolgreich Nicht erfolgreich Erfolgreich Tabelle 12: Ergebnisse von T46 Obwohl als Protokoll TLS konfiguriert war, hat der SSL-Connector des Tomcat-Servers auch SSLv3 zugelassen. Zusammenfassung von T44, T45 und T46 Ein wie in der hier enthaltenen Installationsanleitung S. 36 konfigurierter SSL Connector des Tomcat Servers akzeptiert beliebige, unter anderem auch unsichere Verschlüsselungsmodi. Er akzeptiert darüber hinaus auch das Verschlüsselungsprotokoll SSLv3, obwohl TLS konfiguriert war. In der Dokumentation des Tomcat Servers44 wird erwähnt, dass durch die Konfigurations­ option ciphers definiert werden kann, welche Verschlüsselungsalgorithmen der SSL Connector zulassen soll. Es werden jedoch keine Beispiele für gültige Begriffe (der Verschlüsselungsalgorithmen) aufgezählt. Es wurden versuchsweise mehrere Begriffe aus dem RFC 3268 (Verschlüsselungsalgo­ rithmen für TLS) sowie einer SUN JSSE Dokumentation45 als VerschlüsselungsalgorithmusBezeichnungen für die Konfigurationsoption ciphers ausprobiert. Wurden ausschließlich unbekannte Namen oder Namen mit Tippfehlern angegeben, hat der Server jedoch so reagiert, als sei die Konfigurationsoption ciphers gar nicht in der Konfiguration vorhanden. Dieses Verhalten, gepaart mit dem Fehlen einer diesbezüglichen Fehlermeldung, ist aus Sicherheitsgründen nicht akzeptabel. Zu groß ist das Risiko einer Fehlkonfiguration und die Abhängigkeit von den genauen Namen der verwendeten Version der JSSE. Es folgt die Liste der von JSSE bzw. Tomcat unterstützten Angaben zur Option ciphers in unserer Testumgebung. Diese Liste wurde durch Instrumentieren von Tomcat anhand der Funktion getSupportedCipherSuites der Klasse java.net.ServerSocket ermittelt. Man beachte, dass openssl andere Namen verwendet und meldet. Listing 47: mögliche Angaben zu ciphers in conf/server.xml (mit JSSE/JDK 1.5.0) SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA 44 45 http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html Appendix A Bundesamt für Sicherheit in der Informationstechnik Seite 132 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA SSL_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_WITH_AES_128_CBC_SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_KRB5_WITH_RC4_128_SHA TLS_KRB5_WITH_RC4_128_MD5 TLS_KRB5_WITH_3DES_EDE_CBC_SHA TLS_KRB5_WITH_3DES_EDE_CBC_MD5 TLS_KRB5_WITH_DES_CBC_SHA TLS_KRB5_WITH_DES_CBC_MD5 TLS_KRB5_EXPORT_WITH_RC4_40_SHA TLS_KRB5_EXPORT_WITH_RC4_40_MD5 TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 Der Tomcat HTTP/SSL-Connector auf Port 8443 wurde nun mit dem Parameter ciphers=“SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA“ versehen. In diesem Fall (und in mehreren anderen Fällen, in denen Algorithmusnamen der obigen Liste verwendet wurden) verhielt sich der Tomcat SSL Connector wie erwartet, d. h. er hat nur die Algorithmen zugelassen, die auch konfiguriert waren. Zusammenfassend lässt sich feststellen, dass keine Dokumentation existiert, die eine sichere und nachvollziehbare Konfiguration des SSL-Connectors von Tomcat möglich macht. Zudem startet der Tomcat Server trotz unbekannter Verschlüsselungsmodi ohne Fehlermeldung und verhält sich somit anders als konfiguriert. Bewertung Es ist daher davon abzuraten, den SSL-Connector von Tomcat 5 als Netzwerkschnittstelle für sicherheitskritische Anwendungen zu verwenden. Seite 133 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Empfehlung Für das Tomcat-Entwicklungsprojekt ist zu empfehlen, dass eine Konfiguration des TomcatSSL-Connectors analog zur Konfiguration von mod_ssl ermöglicht wird. Darüber hinaus sollten die Konfigurationsoptionen für den SSL-Connector dokumentiert werden. 5.1.2.7 Datenschutz Beim Thema Datenschutz geht es um Informationen, die Tomcat protokolliert. Zuerst werden die Ergebnisse des Tests T 40 und T 41 (oben) noch einmal aus Sicht des Datenschutzes betrachtet. So werden die Default-Einstellungen von Tomcat im Hinblick auf den Daten­ schutz überprüft. Test Nr. T 47 TomcatConnector HTTP und AJP T 48 HTTP und AJP Beschreibung erwartetes Resultat Ergebnisse des Tests T 40 wahrscheinlich und T 41 analysieren unter keine dem Gesichtspunkt datenschutz­ „Datenschutz“ relevanten Aspekte Einstellung der unbekannt Protokollierung (Access Log Valve) mit einer maximalen Protokollierungstiefe; Durchführung von Anfragen für Ressourcen von ClientBrowsern an Tomcat Bemerkung Vermutlich ist die Speicherung einiger benutzerorientierter Informationen (z. B. „remote logical user name“ oder „user session ID“) für den Datenschutz von Bedeutung Tabelle 13: Übersicht über die funktionalen Sicherheitstests zum Datenschutz Danach wird der Test bei der „maximalen Protokollierung“ wiederholt. Hierbei werden z. B. alle die für den Datenschutz relevanten „patterns“ im Access Log Valve eingeschaltet. Die so erstellten Protokolldateien werden im Hinblick auf den Datenschutz analysiert. Da die zwei Connectoren (HTTP, AJP) im Prinzip unterschiedliche Information vom Client nach Tomcat übertragen können, wird der Test für beide Connectoren durchgeführt. Hinweis: bei der Verwendung des Tomcat Servlet Containers in Verbindung mit dem Apache Webserver über mod_jk-AJP-Connector bzw. mod_proxy-HTTP-Connector ist zu beachten, dass neben der Protokollierung durch Tomcat auch der Apache Webserver selbst Protokolldaten mit möglicherweise datenschutzrechtlich relevanten Informationen generieren kann. Dies ist bei einer Konfiguration des Apache Webservers zu berücksichtigen, wird aber im Rahmen dieser Untersuchungen nicht weiter betrachtet. 5.1.2.7.1 T47 / T48 Datenschutz-bezogene Analyse der Ergebnisse aus Tests T40 und T41 Die Analyse der Protokolldateien und der verwendbaren Protokollformat-Optionen hat zum Ergebnis geführt, dass die Erzeugung von für den Datenschutz relevanten Informationen je nach Einstellung der Log-Funktionen nicht ausgeschlossen werden kann. Bundesamt für Sicherheit in der Informationstechnik Seite 134 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Bei der Verwendung des “combined“ Log-Konfigurationspattern oder z. B. in Verbindung mit den “%u“ oder “%{Referer}i“ Protokollierungsformat-Optionen können Informationen wie der Name eines authentisierten Benutzers oder die zuvor besuchte Webseite in die Log-Dateien mit aufgenommen werden. Letzteres kann insbesondere dann von Bedeutung sein, wenn in den URLs auch weiter gehende Informationen, wie Parameter für den vorherigen HTTPRequest in der Form ...?param1=value1&param2=value2&... die beispielsweise in Verbindung mit HTML-Formularabfragen verwendet werden, kodiert sind. Da keine allgemeinen Annahmen über die hierbei vorkommenden Informationen getroffen werden können, muss zunächst davon ausgegangen werden, dass es sich hierbei um für den Datenschutz relevante Informationen handeln könnte, was zu entsprechenden Konsequenzen im Umgang mit den Log-Dateien führt. Analoges gilt für Cookie-Informationen, die bei der Protokollierung aufgezeichnet werden können und möglicherweise gleichfalls sensible Informationen enthalten. In der Standardeinstellung mit dem Log-Pattern “common“ werden diese Informationen nicht mit protokolliert. Für die Protokollierung der Tomcat Ereignisse per java.util.logging Mechanismen kann festgestellt werden, dass in der Standardeinstellung (entsprechend dem Log-Pattern “common“) zunächst keine datenschutzrechtlich relevanten Informationen erfasst werden. Es ist aber möglich, dass die in Tomcat laufenden Webanwendungen selbst interne Zustände über diesen Logging-Mechanismus protokollieren, wobei u. U. auch datenschutzrechtlich relevante Informationen betroffen sein könnten. Da dies aber abhängig von der konkreten Webanwendung ist, kann hier keine allgemeine Feststellung getroffen werden. Wie bereits oben erwähnt betrifft die Protokollierung nicht nur den Jakarta Tomcat Servlet Container alleine. Da dieser in den meisten Fällen in Verbindung mit einem vorgeschalteten Webserver (z. B. Apache) verwendet werden wird und der Webserver über eigene Protokol­ lierungsfunktionalität verfügt, gelten die gemachten Hinweise analog für dessen Protokol­ lierung. 5.1.2.8 Minimale Rechtevergabe Die Einsatzumgebung wird so geändert, dass Tomcat unter einem eigenen Benutzerkonto mit eingeschränkten Rechten (z. B. ohne Login-Shell) läuft. Danach werden Anfragen für Ressourcen von Client-Browsern an Tomcat gesendet und das ordnungsgemäße Funktio­ nieren der Engine beurteilt. Test Nr. T 49 TomcatConnector HTTP und AJP Beschreibung Ausführung von Tomcat als nicht-privilegierter Benutzer; Sendung von Anfragen für Ressourcen von ClientBrowsern an Tomcat. erwartetes Resultat ordnungs­ gemäßes Funktioniere n Bemerkung Betrieb sollte laut Dokumentation möglich sein Tabelle 14: Übersicht über die funktionalen Sicherheitstests zur minimalen Rechtevergabe Dieser Test ist für die Tomcat-Engine selbst von Bedeutung und ist daher unabhängig von den verschiedenen Konfigurationen der einzelnen Einsatzszenarien. Jedoch ist es denkbar, dass die zwei Connectoren unterschiedlich auf die veränderten Rechte der Tomcat-Engine Seite 135 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers reagieren. Deswegen ist es sinnvoll, den Test mit beiden Connectoren durchzuführen (HTTP, AJP). 5.1.2.8.1 T49 Ausführung von Tomcat als nicht-privilegierter Benutzer Zur Vorbereitung des Tests werden vor dem Starten von Tomcat sämtliche Dateien und Verzeichnisse unterhalb von $CATALINA_HOME dem neu erzeugten Benutzer tomcat und der neu erzeugten Gruppe tomcat zugewiesen, um eventuell benötigte Schreib- (LogDateien!) und Leseberechtigungen für den Tomcat-Prozess zu erhalten: Listing 48: Zuweisung der Tomcat Dateien an einen unprivilegierten Benutzer groupadd -g 150 tomcat useradd -c “Tomcat“ -g 150 -u 150 -d /opt/jakarta-tomcat-5.5.9 -s /bin/bash tomcat find /opt/jakarta-tomcat-5.5.9 -exec chown tomcat:tomcat {} \; Nun kann unter diesem neuen Benutzer Tomcat wie üblich gestartet werden: su – tomcat bin/catalina start Sowohl direkt über den HTTP(S)-Connector als auch über den AJP13-Connector (via Apache), ergaben sich bei den nachfolgenden Zugriffstests (über HTTP und HTTPS) keine Unterschiede im Verhalten gegenüber der Tomcat-Installation unter dem root Benutzer. Im realen Einsatz würde Tomcat nicht per Startkommando aus einer Shell sondern wahrscheinlich eher über ein Startup-Skript während des Boot-Vorgangs gestartet. In diesem Fall könnte auf eine Login-Shell bei der Einrichtung des unprivilegierten Benutzers verzichtet werden. Bei der Einrichtung des Benutzers tomcat könnte statt -s /bin/bash entweder -s /bin/false oder -s /bin/nologin46 verwendet werden, was zu einer Erhöhung der Sicherheit beitragen würde. 5.2 Penetrationstests - Vorgehensweise Die Penetrationstests dienen dazu festzustellen, ob Tomcat durch Protokoll verletzenden oder unerwarteten Netzwerkverkehr in seinem Programmablauf beeinflusst werden kann. 5.2.1 Angriffsszenarien Bei diesen Tests wird der Netzwerkverkehr gezielt mittels entsprechender Werkzeuge manipuliert. Dabei wird das Verhalten des zu testenden Systems (Tomcat bzw. Apache mit mod_jk) überwacht. Die Vorgehensweise besteht dabei aus den folgenden Schritten: 1. Aufzeichnung des protokollkonformen Netzwerkverkehrs, 46 falls dieses Skript in der Linux-Installation vorhanden ist und ein benötigt wird. Bundesamt für Sicherheit in der Informationstechnik syslog-Logging der nicht zugelassenen Login-Versuche Seite 136 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests 2. Veränderung des protokollkonformen Netzwerkverkehrs und dessen Einspielung nach der Veränderung und 3. Auswertung der Protokolldateien und Kontrolle der angegriffenen Dienste. Es werden zwei prinzipiell unterschiedliche Angriffsszenarien betrachtet: • Angriffe eines Web Clients mit nicht konformen HTTP-Paketen bzw. mit nicht erwarteten HTTP-Header-Feldern (überlange Felder, Java Skript Code) oder • Angriffe von einer Web Anwendung bei eingeschalteter Standard Java Security Policy gegen einen davor stehenden Apache-Server bzw. gegen das AJPProtokoll (mod_jk) mittels übergroßer HTTP-Header (Cookies, etc.). Im Folgenden werden die Angriffe nach den verwendeten Tomcat-Connectoren unter­ schieden • HTTP-Connector: Angriffe von einem HTTP-Client • AJP-Connector ohne SSL-Client-Authentisierung: Angriffe von HTTP-Client und Angriffe einer Web Anwendung • AJP-Connector mit SSL Client Authentisierung: Angriffe eines Web-Clients mit nicht konformen SSL-Zertifikaten. Die Durchführung dieser Angriffe wird in den drei folgenden Kapiteln erläutert. Anmerkung: Für den HTTPS-Connector sind keine Angriffe vorgesehen, da die verwendete SSL-Implementierung von den Standard Java Klassen durchgeführt werden und sich die Angriffe auf HTTP-Ebene nicht unterscheiden. 5.2.2 Beispielanwendungen Für die Angriffe war vorgesehen, Beispielanwendungen anzugreifen, um eine möglichst realistische Abbildbarkeit der Tests zu gewährleisten. Es sollten insbesondere WebAnwendungen angegriffen werden, welche HTTP-Sessions verwenden und über Authen­ tisierungs- und Autorisierungsfunktionen verfügen. Es wurden die unten dargestellten Angriffe gegen eine derartige Beispielanwendung (webgoat aus dem OWASP Projekt) durchgeführt. Seite 137 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 5.3 HTTP-Connector: Angriffe von einem HTTP-Client Abbildung 5.4: Angriffe auf den HTTP-Connector des Tomcat-Servers Die Verwendung des HTTP- oder SSL-Connectors eines Tomcat-Servers als direkte Schnitt­ stelle zu Anwendern, deren HTTP-/HTTPS-Anfragen maliziöse Inhalte besitzen können (Abbildung 5.4), ist in vielen Punkten gegenüber einer mehrstufigen Architektur (Abbildung 5.5) mit Nachteilen versehen. 1. Performanz: der HTTP-/SSL-Connector des Tomcat-Servers verfügt nicht über die vielfältigen Einstellmöglichkeiten des Apache Webservers, mit denen Ressourcen eines Servers optimal für die Anfragen von Anwendern ausgenutzt werden können. 2. Schutz vor schädlichen Übergabeparametern: Filternde Sicherheitsmodule wie z. B. mod_security des Apache Webservers sind nicht für den Tomcat-Server erhältlich. 3. Fehlende Diversifikation von Schutzmechanismen: Wird der HTTP-/SSL-Connector des Tomcat-Servers falsch konfiguriert, so kann dies direkt die Kompromittierbarkeit von sensiblen Web-Inhalten (z. B. des Source-Code von JSPs) oder die Angreifbar­ keit der Management-Schnittstelle bedeuten. Wird ein filternder Apache Webserver „vor“ den Tomcat-Server geschaltet, so ist die Fehlkonfiguration mit weniger Sicher­ heitsrisiken verbunden. Vom Einsatz der hier beschriebenen Webanbindung, einer Architektur wie in Abbildung 5.4, wird aufgrund der beschriebenen Probleme abgeraten. Der prinzipiellen Vorteile einer mehrstufigen Architektur mit Tomcat-Server und vorgeschaltetem Apache Webserver kommt besonders in sicherheitsrelevanten Umgebungen zum Tragen und sollte dort nur so eingesetzt werden. Aus diesem Grund werden Angriffsszenarien gegen eine Architektur wie in Abbildung 5.4 hier nicht weiter untersucht (vgl. auch [Tomcat Fein.]). Bundesamt für Sicherheit in der Informationstechnik Seite 138 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests 5.4 AJP-Connector ohne SSL-Client-Authentisierung Die am weitesten verbreitete Architekturvariante beim Betrieb des Tomcat Application Servers ist die Vorschaltung eines Webservers mit einem Modul mod_jk, welches die Verbindung zwischen Webserver und Tomcat-Server ermöglicht. Abbildung 5.5: Angriffe mit maliziösen HTTP-Inhalten 5.4.1 Angriffe eines maliziösen HTTP-Clients Bei den Tests mit dem AJP-Connector ohne Authentisierung mit SSLClient-Zertifikaten werden die Werte mehrerer HTTP-Parameter vom HTTP-Client in den Anfragen variiert. 5.4.1.1 Vorgehensweise Für die Durchführung und Dokumentation der Tests wurde eine einheitliche Vorgehensweise angewendet (siehe Abbildung 5.6). Seite 139 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Für alle Testfälle T66 bis T81 Angriffsprogramm T**webfuzz.c editieren Angriffsprogramm T**webfuzz.c compilieren catalina.out leeren localhost-10-**.log leeren mod_jk.log leeren Jakarta Tomcat Server neu starten Apache Web Server neu starten Netzwerksniffer starten Angriffsprogramm starten: ./T**webfuzz localhost 80 > T**_HTTP_fuzz.txt Netzwerkmitschnitt abspeichern als T**_ethereal_dump.dmp mod_jk.log abspeichern als T**_mod_jk.log catalina.out abspeichern als T**_catalina.out localhost-10-**.log abspeichern als T**_localhost.out Abbildung 5.6: Vorgehensweise HTTP-Client-Angriffe Bundesamt für Sicherheit in der Informationstechnik Seite 140 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Ein Beispiel für die SPIKE-Angriffsprogramme, mit denen die maliziösen HTTP-Anfragen gestellt wurden, ist im Abschnitt Installation bereits beschrieben worden. 5.4.1.2 Bewertungskriterien Um festzustellen, ob die Angriffe Hinweise auf Schwachstellen des Untersuchungs­ gegenstandes geben, wurden folgende Zustände / Protokolldateien untersucht: • Ist die angesprochene Web-Anwendung nach den Angriffen noch benutzbar? • Enthält die Protokolldatei des mod_jk Hinweise auf eine temporäre NichtVerfügbarkeit der Web-Anwendung? • Enthalten die Protokolldateien des Tomcat-Servers Fehlermeldungen oder sogar Java Stack Traces? • Enthält der HTTP-Reply des Tomcat-Servers HTTP-Meldungen wie „HTTP Status 500 (Internal Server Error)“ oder „HTTP Status 503 (Service Temporarily Unavailable)“? • Enthält der HTTP-Reply des Tomcat-Servers den Source-Code der angefragten Java Server Page? (Source Code Disclosure) Seite 141 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 5.4.1.3 Ergebnis Die nachfolgende Tabelle gibt eine Übersicht über die Testergebnisse. Test Nr. Testbeschreibung HTTP-Anfrage T 50 HTTP Methode T 51 URI T 52 HTTP Version T 53 Query String HTTP-Header T 54 Accept T 55 Accept-charset T 56 Authorization T 57 Connection T 58 Content-Type T 59 Content-Length Resultat T 60 T 61 T 62 T 63 OK OK OK FEHLER Bemerkung OK OK OK OK OK OK OK OK OK FEHLER Content-Length:<Leerzeichen> führt zu Fehlerzustand im Tomcat-Server Cookie Cookie2 Referer Host • Host: localhostSelect "DAV:displayname" from scope()“ • Host: C:localhost • Host: Select "DAV:displayname" from scope() führen zu Fehlerzustand im Tomcat-Server T 64 T 65 Unknown User-Agent OK OK Tabelle 15: Ergebnisse der Tests T66 bis T81 Schwachstelle in T75 Das Fehlen des Übergabeparameters im HTTP-Header Content-Length führte zu schwer­ wiegenden Fehlerzuständen im Tomcat-Server. Nachfolgende HTTP-Anfrage und -Antwort war mit einer gleichzeitigen Fehlermeldung in der Protokolldatei catalina.out verbunden. Listing 49: HTTP-Anfrage: POST /webgoat/attack HTTP/1.1 Host: 192.168.179.128 Bundesamt für Sicherheit in der Informationstechnik Seite 142 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,* /*;q=0.0 Accept-Language: en-us,en;q=0.0 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.0 Connection: close Referer: http://192.168.179.128/webgoat/attack Cookie: JSESSIONID=F7F97CD94DB5137AE94EA6FFF3D145E9 Authorization: Basic bWVtd2FkbWluOnZtd2FyZQ== Content-Type: application/x-www-form-urlencode Content-Length: person=bla Listing 50: HTTP-Antwort: HTTP/1.1 503 Service Temporarily Unavailable Date: Wed, 30 Nov 2005 21:10:25 GMT Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e mod_jk/1.2.14 Content-Length: 446 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>503 Service Temporarily Unavailable</title> </head><body> <h1>Service Temporarily Unavailable</h1> <p>The server is temporarily unable to service your request due to maintenance downtimVariablesize= 5 Listing 51: Korrespondierende Fehlermeldung in catalina.out: 30.11.2005 22:10:25 org.apache.jk.common.HandlerRequest invoke SCHWERWIEGEND: Error decoding request java.lang.NumberFormatException at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:145) at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:491) at org.apache.tomcat.util.buf.MessageBytes.getInt(MessageBytes.java:687) at org.apache.jk.common.HandlerRequest.decodeHeaders(HandlerRequest.java:686) at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:510) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 30.11.2005 22:10:25 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 30.11.2005 22:10:25 org.apache.jk.common.HandlerRequest invoke SCHWERWIEGEND: Error decoding request java.lang.NumberFormatException at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:145) at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:491) at org.apache.tomcat.util.buf.MessageBytes.getInt(MessageBytes.java:687) at org.apache.jk.common.HandlerRequest.decodeHeaders(HandlerRequest.java:686) Seite 143 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:510) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 30.11.2005 22:10:25 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 30.11.2005 22:10:25 org.apache.jk.common.HandlerRequest invoke SCHWERWIEGEND: Error decoding request java.lang.NumberFormatException at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:145) at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:491) at org.apache.tomcat.util.buf.MessageBytes.getInt(MessageBytes.java:687) at org.apache.jk.common.HandlerRequest.decodeHeaders(HandlerRequest.java:686) at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:510) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 30.11.2005 22:10:25 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 Aus der identifizierten Schwachstelle konnten keine Sicherheitsrisiken abgeleitet werden. Mit dem durchgeführten Angriff konnte weder die Verfügbarkeit des Tomcat-Servers beeinträchtigt werden noch konnten interne bzw. vertrauliche Daten (z. B. Der Source-Code der angesprochenen JSP) veröffentlicht werden. Schwachstelle in T79 Bestimmte Übergabeparameter im HTTP-Header Host führten zu schwerwiegenden Fehlerzuständen im Tomcat-Server. Nachfolgende HTTP-Anfrage und -Antwort war mit einer gleichzeitigen Fehlermeldung in der Protokolldatei catalina.out verbunden: Listing 52: HTTP-Anfrage: POST /webgoat/attack HTTP/1.1 Host: Select "DAV:displayname" from scope() User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,* /*;q=0.0 Accept-Language: en-us,en;q=0.0 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.0 Connection: close Referer: http://192.168.179.128/webgoat/attack Cookie: JSESSIONID=9885AC16C6E36559C7751D07CC8395C3 Authorization: Basic bWVtd2FkbWluOnZtd2FyZQ== Content-Type: application/x-www-form-urlencode Bundesamt für Sicherheit in der Informationstechnik Seite 144 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Content-Length: Durchführung der Tests 12 person=bla Listing 53: HTTP-Antwort: HTTP/1.1 503 Service Temporarily Unavailable Date: Wed, 30 Nov 2005 23:24:43 GMT Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e mod_jk/1.2.14 Content-Length: 468 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>503 Service Temporarily Unavailable</title> </head><body> <h1>Service Temporarily Unavailable</h1> <p>The server is temporarily unable to service your request due to maintenance downtimVariablesize= 21 Listing 54: Korrespondierende Fehlermeldung in catalina.out: 01.12.2005 00:24:43 org.apache.jk.common.HandlerRequest invoke SCHWERWIEGEND: Error decoding request java.io.CharConversionException: Invalid char in port: 41 at org.apache.jk.common.HandlerRequest.parseHost(HandlerRequest.java:762) at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:516) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 01.12.2005 00:24:43 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 01.12.2005 00:24:43 org.apache.jk.common.HandlerRequest invoke SCHWERWIEGEND: Error decoding request java.io.CharConversionException: Invalid char in port: 41 at org.apache.jk.common.HandlerRequest.parseHost(HandlerRequest.java:762) at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:516) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 01.12.2005 00:24:43 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 01.12.2005 00:24:43 org.apache.jk.common.HandlerRequest invoke SCHWERWIEGEND: Error decoding request java.io.CharConversionException: Invalid char in port: 41 at org.apache.jk.common.HandlerRequest.parseHost(HandlerRequest.java:762) at org.apache.jk.common.HandlerRequest.decodeRequest(HandlerRequest.java:516) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:363) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678) Seite 145 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) 01.12.2005 00:24:43 org.apache.jk.common.ChannelSocket processConnection WARNUNG: processCallbacks status 2 Durch weitere Tests wurde herausgefunden, dass bereits die Zeichenkette „Host: x:y“ im HTTP-Header ausreicht, um den Fehlerzustand im Tomcat auszulösen. Aus der identifizierten Schwachstelle konnten keine Sicherheitsrisiken abgeleitet werden. Mit dem durchgeführten Angriff konnte weder die Verfügbarkeit des Tomcat-Servers beeinträchtigt werden noch konnten interne / vertrauliche Daten (z. B. der Source-Code der angesprochenen JSP) veröffentlicht werden. 5.4.2 Angriffe einer maliziösen Web-Anwendung Bei den Tests mit dem AJP-Connector (ohne SSL-Client-Zertifikate) werden die Werte einiger HTTP-Header von den Web Anwendungen in den Antworten variiert. Hinweis: Der Test wird auf die HTTP-Header beschränkt, die von Servlets bzw. JSPs modifiziert werden können. 5.4.2.1 Vorgehensweise Gesamtablauf Für die Durchführung und Dokumentation der Tests wurde eine einheitliche Vorgehensweise angewendet (siehe Abbildung 5.7). Bundesamt für Sicherheit in der Informationstechnik Seite 146 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Abbildung 5.7: Vorgehensweise Angriffe mit maliziöser Web-Anwendung Seite 147 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Maliziöse Anwendung Ein Beispiel einer Web-Anwendung, welche maliziöse HTTP-Header erzeugt, wird nachfolgend dargestellt: import java.io.*; import java.text.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*; public class T82 extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String malstring=""; Vector v = null; if (v == null) { try{ BufferedReader br = new BufferedReader(new FileReader("/opt/jakarta -tomcat-5.5.9/webapps/malservlet/WEB-INF/classes/datei.txt")); v = new Vector(); while(br.ready()) v.add(br.readLine()); }catch(Exception e){} } Random r = new Random(); malstring= (String)v.get(r.nextInt(v.size())); response.setContentType("text/html"); PrintWriter out = response.getWriter(); response.addHeader("Date", malstring); out.println("<html>"); out.println("<head>"); String title = "Example_Title"; out.println("<title>" + title + "</title>"); out.println("</head>"); out.println("<body bgcolor=\"white\">"); out.println("<a href=\"../helloworld.html\">"); out.println("<img src=\"../images/code.gif\" height=24 " + "width=24 align=right border=0 alt=\"view code\"></a>"); out.println("<a href=\"../index.html\">"); out.println("<img src=\"../images/return.gif\" height=24 " + "width=24 align=right border=0 alt=\"return\"></a>"); out.println("<h1>" + title + "</h1>"); out.println("</body>"); out.println("</html>"); } } In diesem Beispiel wird der Header Date mit schadhaften Inhalten gefüllt. Die Java-Funktion, mit der die schadhaften response.addHeader("Date", malstring). HTTP-Header gesetzt werden, ist Aus den vorangegangenen Tests, bei denen mit SPIKE schadhafte HTTP-Anfragen gestellt wurden, sind die von SPIKE erzeugten schadhaften Zeichenketten herausgefiltert und in der Datei /opt/jakarta-tomcat-5.5.9/webapps/malservlet/WEB-INF/classes/datei.txt gesammelt worden. Bundesamt für Sicherheit in der Informationstechnik Seite 148 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Abbildung 5.8 zeigt den Ablauf der schadhaften Web-Anwendung, welche auf eine HTTPAnfrage eine HTTP-Antwort zurückgibt, in der ein HTTP-Header mit schadhaftem Inhalt gefüllt ist. Abbildung 5.8: Ablaufschema der schadhaften Web-Anwendung Abfrageskript Um zweitausend mal die maliziöse Web-Anwendung anzufragen und dabei zweitausend mal einen anderen maliziösen Wert im HTTP-Header zu verarbeiten, wurde folgendes Skript benutzt. #!/bin/bash i=0 while ( [ $i -le 2000 ] ) ; do echo -e "GET /malservlet/T82 HTTP/1.0 \r\n\r\n"|nc localhost 80 i=$[ i+1 ]; done Je nach Testfall wurde T82 durch T83, T84, etc. ersetzt. 5.4.2.2 Bewertungskriterien Um festzustellen, ob die Angriffe Hinweise auf Schwachstellen des Untersuchungsgegen­ standes geben, wurden folgende Zustände / Protokolldateien untersucht: • Ist die angesprochene Web-Anwendung nach den Angriffen noch benutzbar? • Enthält die Protokolldatei des mod_jk Hinweise auf eine temporäre Nicht-Verfügbar­ keit der Web-Anwendung? Seite 149 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • Enthalten die Protokolldateien des Tomcat-Servers Fehlermeldungen oder sogar Java Stack Traces? • Enthält der HTTP-Reply des Tomcat-Servers HTTP-Meldungen wie „HTTP 500 (Internal Server Error)“ oder „HTTP 503 (Service Temporarily Unavailable)“? 5.4.2.3 Ergebnis Die nachfolgende Tabelle gibt eine Übersicht über die Testergebnisse. Test Nr. Testbeschreibung T 66 Date Resultat OK T 67 Last-Modified OK T 68 T 69 T 70 T 71 T 72 T 73 Content-Type WWW-Authenticate Etag Expires Set-Cookie Set-Cookie2 OK OK OK OK OK OK Bemerkung Feld kann nicht mit beliebigen Inhalten gefüllt werden. Feld kann nicht mit beliebigen Inhalten gefüllt werden. Tabelle 16: Testergebnisse T82 bis T89 Bei den Feldern Date und Last-Modified war es nicht möglich, den Inhalt des jeweiligen Feldes auf beliebige Werte zu setzen. Jeder Versuch, den Inhalt anders zu füllen als mit einer positiven Zahl (Anzahl Millisekunden seit dem 1.1.1970 0:00 Uhr) ergibt als Ausgabe das aktuelle Datum (z. B. „Date: Tue, 25 Oct 2005 16:23:38 GMT“) oder den 1.1.1970 („LastModified: Thu, 01 Jan 1970 00:00:00 GMT“). Es konnten keine Schwachstellen identifiziert werden. 5.5 AJP Connector mit SSL Client Authentisierung Abbildung 5.14 zeigt den Versuchsaufbau, bei dem vom Client Anfragen mit maliziösen Inhalten an den Apache Webserver gesendet und Zertifikatsinhalte an den Tomcat-Server weitergeleitet wurden. Abbildung 5.9: Angriffe mit maliziösen SSL Client Zertifikaten Bundesamt für Sicherheit in der Informationstechnik Seite 150 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Bei den Tests mit dem AJP-Connector mit Authentisierung über SSL-Client-Zertifikate wurde versucht, Schwachstellen im mod_jk und in der AJP-Schnittstelle des Tomcat-Servers zu finden, ohne vorgelagerte Komponenten wie den Apache Webserver oder mod_ssl durch die Tests zu beeinflussen. Es wurde versucht Fehler im Apache oder in mod_ssl zu vermeiden, die womöglich dazu geführt hätten, dass die maliziösen Übergabeparameter gar nicht bis mod_jk oder zum TomcatServer gelangt wären. Zuerst wurde die Funktionsweise des Gesamtsystems bei Verwendung von SSL-Client- Zertifikaten analysiert, um einzelne Angriffe planen zu können. 5.5.1 Funktionsweise des Systems Überblick Abbildung 5.10 zeigt noch einmal die Funktionsweise, mit der der Datenfluss analysiert wurde. Abbildung 5.10: Ablauf bei Authentisierung mit SSL Client-Zertifikat Erzeugung des SSL-Client-Zertifikats Die Erzeugung eines SSL-Client-Zertifikats wurde bereits in im Abschnitt 4.7.4 erläutert. Verarbeitung in mod_ssl Das Modul mod_ssl innerhalb des Apache Webservers, welches den Zugriff auf den Server über SSL implementiert, wurde so konfiguriert, dass ein solcher Zugriff nur erlaubt wird, wenn ein HTTPS-Client ein Client-Zertifikat einer anerkannten CA vorweist. Hierfür wurden folgende Konfigurationsparameter in der Datei ssl.conf gesetzt: SSLVerifyClient require SSLCACertificateFile /root/bsitomcat_ca/ssl/ca/ca.pem Seite 151 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers SSLVerifyDepth 1 SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth Die Option SSLVerifyClient require sorgt dafür, dass SSL-Verbindungsaufbauten ohne jegliches SSL Client-Zertifikat abgelehnt werden. Die Option SSLCACertificateFile bestimmt, dass die Client-Zertifikate auf eine Signatur der CA geprüft werden, dessen öffentlicher Schlüssel im Zertifikat in der angegebenen Datei enthalten ist. Clients mit Zertifikaten, die nicht von dieser CA signiert wurden, sollen dabei abgelehnt werden. Die Option SSLVerifyDepth 1 bestimmt, dass nur eine Zertifizierungsebene geprüft wird. Ein Client-Zertifikat, welches nicht von der anerkannten CA, sondern von einer anderen CA ausgestellt worden ist, wird damit nicht akzeptiert, selbst wenn der öffentliche Schlüssel dieser anderen CA von der anerkannten CA signiert wurde. In der Option SSLOptions sorgt der Parameter +ExportCertData dafür, dass der Webserver die Inhalte des SSL-Client-Zertifikats an mod_jk weitergibt. Ist diese Option nicht aktiv, so werden die Inhalte des Client-Zertifikats nicht an mod_jk und somit nicht an den TomcatServer weitergegeben. Die anderen Parameter der Option SSLOptions sind für die Authentisierung per SSL-Client-Zertifikat nicht relevant und werden hier nicht näher erläutert. Verarbeitung in mod_jk Das Modul mod_jk gibt die übergebenen Zertifikatsinhalte ungefiltert an den AJP-Connector des Tomcat-Servers weiter. Verarbeitung im AJP-Connector Die Komponente mod_jk übergibt ein vom HTTP-Client abgesendetes SSL-Client-Zertifikat über das AJP-Protokoll dem AJP-Connector im Tomcat. Der folgende Netzwerkmitschnitt zeigt dabei, dass das Zertifikat als Ganzes, d. h. noch nicht in einzelne Komponenten aufgeteilt, übergeben wird. Bundesamt für Sicherheit in der Informationstechnik Seite 152 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Abbildung 5.11: Mitschnitt des AJP-Protokolls mit Ethereal Die vorige Abbildung zeigt die Anzahl der Netzwerkpakete, die zwischen mod_jk bzw. dem Apache Webserver und dem AJP-Connector des Tomcat-Servers bei einer einfachen HTTP(S)-Anfrage entstehen. Die Anfrage lautet beispielhaft: "GET /simple_info1/index.jsp HTTP/1.0\r\n\r\n" Seite 153 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abbildung 5.12: Inhalt des AJP-Netzwerkmitschnitts Welche Inhalte bei diesem Datentransfer fließen, ist in der folgenden Abbildung zu sehen. Der Webserver bzw. mod_jk übergibt dem AJP-Connector des Tomcat-Servers das SSLClient-Zertifikat (umrahmt von „BEGIN CERTIFICATE“ und „END CERTIFICATE“), eine Information über den Verschlüsselungsalgorithmus („DHE-RSA-AES256-SHA“) sowie die SSL Session-ID („@08D320A8...“). Zertifikatsauswertung im Tomcat Der folgende Source Code der Datei request_data.jsp zeigt, wie die Zertifikatsinhalte ausgewertet werden. Listing 55: Datei request_data.jsp <html> <%@ page language="java" import="java.security.cert.*,java.lang.reflect.*"%> <head> <title> Display HTTP Request Data </title> </head> <body> <% java.util.Enumeration attNames = request.getAttributeNames(); java.util.Enumeration paramNames = request.getParameterNames(); java.util.Enumeration hdrNames = request.getHeaderNames(); %> <h1>Request = <br /> <%= request.getMethod() %> <%= request.getServerName() %>: Bundesamt für Sicherheit in der Informationstechnik Seite 154 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests <%= request.getServerPort() %> <%= request.getProtocol() %> </h1> <hr /> <h2><font color=red>Request header entries:</font></h2> <% while (hdrNames.hasMoreElements()) { String name = (String) hdrNames.nextElement(); String value = request.getHeader(name); out.println("<b>" + name + "</b>: " + value + "<br />"); } %> <hr /> <h2><font color=red>Request parameters:</font></h2> <% while (paramNames.hasMoreElements()) { String name = (String) paramNames.nextElement(); String value = request.getParameter(name); out.println("<b>" + name + "</b>: " + value + "<br />"); } %> <hr /> <h2><font color=red>Request attributes:</font></h2> <% while (attNames.hasMoreElements()) { String name = (String) attNames.nextElement(); Object value = request.getAttribute(name); out.println("<b>" + name + "</b>: " + value + "<br />"); // check, if name contains "X509Certificate" i.e. // we have certificate(s) in our current entry int x509index = name.indexOf("X509Certificate"); if (x509index > 1) { int i; // there can more than one certificates be encoded // in the current attribute X509Certificate certs[] = (X509Certificate[])request.getAttribute(name); for(i=0; i<certs.length; i++) { // display all relevant information out.println("#####<b>certificate[" + i + "]</b>#####" + "<ul>" + "<li/><i>SubjectDN</i>: " + certs[i].getSubjectDN() + "<li/><i>IssuerDN</i>: " + certs[i].getIssuerDN() + "<li/><i>SerialNumber</i>: " + certs[i].getSerialNumber() + "<li/><i>Signature</i>: " + certs[i].getSignature() + "<li/><i>NotBefore</i>: " + certs[i].getNotBefore() + "<li/><i>NotAfter</i>: " + certs[i].getNotAfter() + "<li/><i>Version</i>: " + certs[i].getVersion() + "<li/><i>SigAlgorithm</i>: " + certs[i].getSigAlgName() + "<li/><i>SigAlgParmams</i>: " + certs[i].getSigAlgParams() + "<li/><i>KeyUsageExt</i>: " + certs[i].getKeyUsage() + "</ul>"); } } }%> <hr /> </body> </html> Seite 155 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Die oben abgebildete JSP-Datei bekommt als Parameter ein Array von X509-Zertifikaten übergeben (Typ X509Certificate[]), welches es einzeln mit Methoden der JSSE auswertet. Die Methoden getSubjectDN(), getSerialNumber(), getSigAlgParams() usw. der Klasse java.security.cert.X509Certificate werden dabei von SUN (JSSE 5 innerhalb des JDK 5) zur Verfügung gestellt, sind also nicht Bestandteil von Tomcat. 5.5.2 Angriffe Ausgehend von der oben geschilderten Analyse der Funktionsweise wurden für die Penetrationstests folgende Schlussfolgerungen getroffen: • Das Modul mod_jk decodiert / analysiert das vom Web Browser übergebene X509codierte Client-Zertifikat nicht. Angriffe durch ungewöhnliche Zeichenketten im Common Name (CN) oder Distinguished Name (DN) des Zertifikats können somit in mod_jk keine unerwarteten Effekte verursachen. • auf Ebene des AJP-Connectors wird das Zertifikat ebenfalls nicht decodiert, womit ungewöhnliche Zeichenketten in den Zertifikatsattributen auch hier keine unerwar­ teten Effekte auslösen können. • Für die Auswertung / Verarbeitung der Zertifikatsinhalte werden JSSE-Klassen von SUN verwendet, die nicht Bestandteil von Tomcat sind. Diese sind also nicht Gegenstand unserer Untersuchung. Die verbleibenden Angriffsmöglichkeiten bestehen darin, die Länge des X509-Zertifikats variabel zu gestalten, um somit eventuelle Puffergrenzen in mod_jk oder im AJP-Connector des Tomcat-Servers zu überschreiten. Da die einzelnen Felder eines X509-Zertifikats nur 64 Zeichen lang sein können [ISIS MTT] (mehr wird vom eingesetzten Werkzeug openssl auch nicht unterstützt), aber beliebig viele Attribute für OU (Organisation Unit) erlaubt sind, wurde die Gesamtlänge des SSL-ClientZertifikats dadurch beeinflusst, dass wenige oder viele OU-Attribute gesetzt wurden. Somit konnten Zertifikatslängen bis zu 200KB erzeugt werden (übliche Länge: etwa 1KB). 5.5.2.1 Testfälle Es wurden die folgenden vier Tests durchgeführt. Test Nr. Testbeschreibung T 74.1 Client-Zertifikat mit 4389 Byte Länge (10 OUAttribute) T 90.2 Client-Zertifikat mit 4393 Byte (100 OU-Attribute) T 90.3 Client-Zertifikat mit 33643 Byte (1000 OU-Attribute) T 90.4 Client-Zertifikat mit 196147 Byte (6000 OUAttribute) Erwartetes Resultat OK OK OK OK Tabelle 17: Übersicht über die Penetrationstests, AJP-Connector mit Authentisierung über SSLClient-Zertifikate Bundesamt für Sicherheit in der Informationstechnik Seite 156 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Eine Erzeugung von noch längeren SSL-Client-Zertifikaten scheiterte am verwendeten Werkzeug openssl, welches bei wesentlich mehr als 6000 OU-Attributen mit einer Fehler­ meldung abbrach. Das Skript, mit dem die Client-Zertifikate erzeugt wurden, wurde bereits im Abschnitt 4.7.4 gezeigt. Es wurde nur dadurch erweitert, dass statt eines OU-Attributswertes mehrere angegeben wurden: Listing 56: Ergänzung zum Skript setup_client_cert.sh ... #-------------------------------------------------------------# Create a client certificate request: malstring=`/usr/bin/perl -e'print "/OU=Organisation1"x100'` openssl req -new \ -newkey rsa:2048 \ -nodes \ -out ${CLIENT_DIR}/${CLIENT}.req \ -keyout ${CLIENT_DIR}/${CLIENT}.key \ -subj "/CN=${CLIENT}${malstring}/L=Bonn/ST=NRW/C=DE/emailAddress=${CLIENT}@bsitomcat.de/O=BSITomc at ITC-Sec" ... Seite 157 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 5.5.2.2 Vorgehensweise In Abbildung 5.13 ist die Vorgehensweise bei der Durchführung der Angriffe dargestellt. Abbildung 5.13: Vorgehensweise bei SSL-Zertifikats-Authentisierung Bundesamt für Sicherheit in der Informationstechnik Seite 158 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests 5.5.2.3 Bewertungskriterien Um festzustellen, ob die Angriffe Hinweise auf Schwachstellen des Untersuchungsgegen­ standes geben, wurden folgende Zustände / Protokolldateien untersucht: • Ist die angesprochene Web-Anwendung nach den Angriffen noch benutzbar? • Enthält die Protokolldatei des mod_jk Hinweise auf eine temporäre Nicht-Verfügbar­ keit der Web-Anwendung? • Enthalten die Protokolldateien des Tomcat-Servers Fehlermeldungen oder sogar Java Stack Traces? • Enthält der HTTP-Reply des Tomcat-Servers HTTP-Meldungen wie „HTTP 500 (Internal Server Error)“ oder „HTTP 503 (Service Temporarily Unavailable)“? 5.5.2.4 Ergebnis Die nachfolgende Tabelle gibt eine Übersicht über die Testergebnisse. Test Nr. Testbeschreibung T 90.1 T 90.2 T 90.3 Client-Zertifikat mit 4389 Byte Länge (10 OU-Attribute) Client-Zertifikat mit 4393 Byte (100 OU-Attribute) Client-Zertifikat mit 33643 Byte (1000 OU-Attribute) Erwartetes Resultat OK Bemerkungen OK Fehler Fehlerzustand in mod_jk: ajp_marshal_into_msgb::jk_ajp_co mmon.c (490): failed appending the SSL certificates Keine HTTP-Antwort Netzwerkdump zeigt, dass nicht das ganze SSL-Zertifikat von mod_jk zum Tomcat übertragen wird. T 90.4 Kein Eintrag in den Logs des Tomcat-Servers. Keine Vollendung des SSLVerbindungsaufbaus. Client-Zertifikat mit 196147 Byte Fehler (6000 OU-Attribute) Tabelle 18: Ergebnisse der Tests mit SSL Client-Zertifikat Fehler in Test T90.3 Bei der Verwendung von 1000 OU-Attributen im Client-Zertifikat trat ein Fehler auf, der im mod_jk.log dokumentiert wurde: [Fri Oct 28 17:49:1130514593 2005] Seite 159 (von 187) [error] ajp_marshal_into_msgb::jk_ajp_common Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers .c (490): failed appending the SSL certificates [Fri Oct 28 17:49:1130514593 2005] [info] ajp_service::jk_ajp_common.c (1662): Creating AJP message failed, without recovery [Fri Oct 28 17:49:1130514593 2005] bsi_ajp13_1 www.example.com 0.000482 [Fri Oct 28 17:49:1130514593 2005] [info] jk_handler::mod_jk.c (1964): Abortin g connection for worker=bsi_ajp13_1 In der HTTP-Anwort des Webservers kann man erkennen, dass der Webserver die HTTPSAnfrage nicht verarbeiten kann: Listing 57: HTTP-Antwort des Webservers HTTP/1.1 413 Request Entity Too Large Date: Fri, 28 Oct 2005 15:38:40 GMT Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e mod_jk/1.2.14 Content-Length: 474 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>413 Request Entity Too Large</title> </head><body> <h1>Request Entity Too Large</h1> The requested resource<br />/simple_info1/index.jsp<br /> does not allow request data with GET requests, or the amount of data provided in the request exceeds the capacity limit. <hr> <address>Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7e mod_jk/1.2.14 Server at www.example.com Port 443</address> </body></html> Der Test T90.3 ergab keine sicherheitsrelevanten Hinweise. Fehler in Test T90.4 Bei der Verwendung von 6000 OU-Attributen im Client-Zertifikat ist die SSL-Verbindung zwischen openssl als Client und dem Webserver bzw. mod_ssl abgebrochen worden. Der openssl-Client hat dabei folgende Fehlermeldung ausgegeben: depth=1 /CN=BSITomcat ITC-Sec CA/L=Bonn/ST=NRW/C=DE/[email protected] /O=BSITomcat ITC-Sec Certification Authority verify return:1 depth=0 /CN=tomcathost/L=Bonn/ST=NRW/C=DE/[email protected]/O=BSITomcat ITC-Sec verify return:1 write:errno=32 Im Netzwerkmitschnitt kann man erkennen, dass die SSL-Verbindung zwar aufgebaut, dann aber sofort wieder abgebaut wird (Abbildung 5.12). Bundesamt für Sicherheit in der Informationstechnik Seite 160 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Abbildung 5.14: Netzwerkmitschnitt von Test T90.4 Der als T904_ethereal_dump.dmp abgespeicherte Netzwerkmitschnitt wurde mit tcpflow analysiert. Dabei zeigte sich, dass das TCP-Paket des openssl-Clients an den Webserver nur 1353 der 6000 OU-Attribute enthält und danach abrupt endet. Offensichtlich ist der Funktionsmangel in openssl begründet und nicht in mod_jk oder Tomcat. Der Test T90.4 ergab keine sicherheitsrelevanten Hinweise. 5.6 Quellcode-Analysen Ziel der Quellcode-Analyse ist es, sicherheitsrelevante Programmierfehler in Tomcat zu finden. Solche Fehler könnten auf Schwächen in der Implementierung, z. B. Pufferüberläufe, Race Conditions und unsichere System-Calls oder auf Schwächen in der Architektur selbst, wie fehlerhafte Zugriffskontrolle durch falsch definierte Rollen basieren. Der Fokus wird hierbei auf den Quellcode gerichtet, der Eingaben von nicht vertrauens­ würdigen Quellen entgegen nimmt oder der Sicherheitsfunktionen des Tomcat bereitstellt. Die Quellcode Analyse besteht dabei aus zwei Teilen. 5.6.1 Automatische Überprüfung des Quellcodes Für die automatische Analyse des C-Quell-Codes wurden die Werkzeuge flawfinder und splint eingesetzt. Beide entstammen dem Bereich der Open Source. Das bekannte Programm rats ist dagegen nicht frei erhältlich. Es wird auch nicht weiter benötigt, weil es sich mit den Fähigkeiten von flawfinder überschneidet. Ähnliches gilt für ITS4, das wohl berühmteste von allen. Da es in durchgeführten Analysen von den anderen Programmen übertroffen wird, besitzt es nunmehr eher historischen Charakter. Seite 161 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Für die automatische Analyse des Java-Quell-Code wurde das Werkzeug findbugs47 eingesetzt. Es hat gegenüber anderen Werkzeugen wie pmd48 den Vorteil, dass es sich weniger auf syntaktische Elemente beschränkt. Vielmehr berücksichtigt es auch Besonderheiten der objektorientierten Programmierung (OOP). So nimmt es beispielsweise auch Prüfungen an der Vererbungshierarchie vor. Es wird hierbei der Quellcode von Tomcat der in Java programmiert ist, sowie der Apacheseitige AJP-Connector mod_jk, der in C programmiert ist, analysiert. Die Ergebnisse der Analysewerkzeuge werden gesichtet und bezüglich ihrer Sicherheits­ relevanz priorisiert. Jedes der genannten Werkzeuge liefert eine Liste von Meldungen. Einige davon bedürfen keiner weiteren Prüfung, z. B. beim Erkennen einer unbenutzten Variable. Für Sicherheits­ analysen jedoch gilt, dass jede Meldung, die relevant sein könnte, im Quelltext erst mal geprüft werden muss. Der Grund ist, die Werkzeuge sind nicht gut genug, um die Fehler mit Bestimmtheit fest zu stellen. Die Zahl der Falschmeldungen wie „möglicher Fehler“ oder „mögliche gefährliche Verwendung von ...“ machen leider den allergrößten Teil der Meldungen aus. Dennoch sind solche Werkzeuge nützlich, denn sie zeigen Bereiche im Quelltext, in denen beispielsweise Puffer variabler Länge verwendet werden. Solche Bereiche können dann manuell untersucht werden. Das bedeutet, die Werkzeuge dienen vor allem der Orientierung während eines Software Reviews. Folgendes Beispiel zeigt dieses Zusammenspiel. Flawfinder moniert jedes Vorkommen von strlen(), darunter: mod_jk.c:1044: [1] (buffer) strlen: Does not handle strings that are not \0-terminated (it could cause a crash if unprotected). In den allermeisten Fällen ist die Verwendung von strlen() unproblematisch, jedoch zeigt das manuelle Sichten des Umfelds dieser Funktion, dass eine ungeschützte Speicherallokation vorkommt, die bei Speichermangel zum Absturz des Apache führen kann: static void request_log_transaction(request_rec * r, jk_server_conf_t * conf) { [...] strs = apr_palloc(r->pool, sizeof(char *) * (format->nelts)); strl = apr_palloc(r->pool, sizeof(int) * (format->nelts)); items = (request_log_format_item *) format->elts; for (i = 0; i < format->nelts; ++i) { strs[i] = process_item(r, &items[i]); } 5.6.2 Manuelle Überprüfung des Quellcodes Das Ergebnis der automatischen Überprüfung wird durch eine manuelle Sichtung des Quellcodes ergänzt. Ausgesuchte Softwareteile werden gesichtet und auf das 47 48 http://findbugs.sourceforge.net/ http://pmd.sourceforge.net/ Bundesamt für Sicherheit in der Informationstechnik Seite 162 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Vorhandensein von Schwachstellen geprüft. Beschreibungen der Sicherheitslücken und der daraus resultierenden Bedrohungen werden mit Beispielen aufgezeigt. Es wird nicht geprüft, ob gefundene Schwachstellen auch ausnutzbar sind. Die Vorgehensweise der manuellen Prüfung unterscheiden sich bei C und Java. Bei der Programmiersprache C kann eine Datei bzw. Modul untersucht werden, in dem sie linear von oben bis unten durchgesehen wird. Favorisiert wird dabei eine Bottom-UpAnalyse. Dieser Ansatz setzt einen Aufbau der Datei voraus, der für die Programmiersprache Pascal üblich ist. Hier ist es nämlich nahezu erforderlich Vorwärtsreferenzen zu vermeiden. Dies bedeutet, Prozeduren weiter unten im Quelltext nutzen die Unterprozeduren weiter oben im Quelltext. Der Vorteil dieser Vorgehensweise liegt darin, dass kaum falsche Annahmen über kleine Hilfsfunktionen gebildet werden, z. B. ob NULL als Parameter erlaubt ist oder nicht. Beim Betrachten der kleinen Unterprozedur kann also ein sofortiger Abgleich zwischen dem bisher aufgebauten Wissen aus früheren Prozeduren, Dokumentationen und Codes stattfinden. Das Wissen über die Funktionsweise des Code wird dabei inkrementell aufgebaut und validiert. Schreitet man bei der Analyse fort, so gelangt man zu den Prozeduren weiter unten in der Datei und kennt die Einsatzbedingungen sowie Nebeneffekte der darin aufgerufenen, bereits analysierten Prozeduren bestens. Wer dagegen die Analyse zuerst mit den übergeordneten Prozeduren beginnen würde, müsste viele Annahmen über die darin aufgerufenen Prozeduren und Module bilden. Das menschliche Gehirn ist aber nicht besonders geeignet im Zurücknehmen von falschen Annahmen. Die oben geschilderte Vorgehensweise ist für viele Programmiersprachen anwendbar, darunter Ada, Lisp und C++. Für formale Sprachen mit Möglichkeiten bis hin zum Beweisen von Programmeigenschaften wie bei B oder VDM ist auch der umgekehrte Ansatz denkbar, also von oben (abstrakt) nach unten (detailliert). Er wird, wie in der Mathematik auch üblich, so praktiziert. Speziell bei Java Java hingegen gibt es Hürden bei der Analyse: 1. Der Quellcode liegt seltenst in der für das Review idealen Pascal-ähnlichen Form vor. In Tomcat sind ausreichend Beispiele zu finden, wo Variablen an beliebiger Stelle innerhalb einer Datei definiert werden. Stellenweise referenzieren Methoden Variablen, die erst weiter unten im Quellcode definiert werden. Darüber hinaus werden Hilfsfunktionen gerne ans Dateiende verlagert. Diese Tendenz wird durch den Einsatz von grafischen Benutzer­ oberflächen (IDE) vermutlich verstärkt, weil individuelle Methoden per Mausklick angesprungen werden und der logische Aufbau der Datei dadurch in den Hintergrund gerät. 2. Es kommt erschwerend immer wieder vor, dass konzeptuell zusammengehörige Funktionalitäten sich wegen objektorientierter Vererbungshierarchien über mehrere Klassen und damit auch Dateien verteilen. Wer Java analysiert, wird daher zwangsläufig zwischen Methoden hin und herspringen, die über mehrere Dateien verteilt sind. Ein Beispiel dafür liefert die Hierarchie JSSE14SocketFactory → JSSESocketFactory → ServerSocketFactory (vgl. T92). Hier wird das Verarbeiten der Konfigurationsattribute auf zwei Dateien verteilt, während die Attribute selbst aus einer dritten Datei stammen. Seite 163 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 3. Viele APIs von Java durchdringt der Wunsch nach möglichst großer Austauschbarkeit von Komponenten. Dieser bewirkt leider, dass eine Funktionalität stets indirekt aufgerufen wird, oftmals über Konfigurationsdateien statt direkt erkennbar im Code. Dies erzeugt eine Vielzahl von Interfaces und Adapterklassen. Damit wächst der Bedarf an Schnittstellen anpassenden Klassen enorm. Die Zahl der Methoden steigt, weil viele nur für die Schnittstellenanpassung nach beiden Seiten hin benötigt werden. Gemeint sind mit letzterem bzgl. eines Moduls die Schnittstelle „angebotenen Leistung“ und die Schnittstelle zu den dafür benötigten anderen Modulen. In der Sprache der Entwickler reflektiert sich dies durch Metaphern im Bereich der Klempnerei, z. B. Adapter, Connectoren oder Valves kanalisieren Informationen, die von Modulen verarbeitet werden. Die wenigsten Werkzeuge sind in der Lage, Datenflussanalysen über mehrere Funktionen hinweg durchzuführen. Dazu wäre auch das Erkennen von Protokollen oder Traces nötig, was im allgemeinen sehr schwierig und noch Gegenstand von Forschungsarbeiten ist. Mit Protokollen oder Traces ist im Rahmen der Programmanalyse die Aufrufreihenfolge von Methoden eines Objekts oder eines abstrakten Datentyps gemeint. Daraufhin könnte die festgestellte Reihenfolge mit einer spezifizierten Reihenfolge verglichen werden. Der Begriff Methode bezieht sich nicht nur auf objektorientierte Programmierung (OOP). Auch für C kann modelliert werden, dass beispielsweise für Objekte vom Typ FILE* gilt: fopen() → ... → fclose(), d. h. auf den Konstruktor (fopen) muss das Schließen der Datei (fclose) folgen. Ansätze davon sind in der verschiedenen Werkzeuge enthalten. So erkennt splint die Aufrufe von malloc() und kann unter Umständen melden, wenn ein Speicher nicht freigegeben wird. Findbugs enthält eine einfach Regel, die auch ohne Datenflussanalyse implementiert werden könnte. Ein Konstruktor sollte sämtliche Instanzenvariablen initialisieren. Leider wird bei der OOP oftmals von diesem eleganten Modell abgewichen. Stattdessen müssen bestimmte Methoden, typischerweise init, set o. ä. genannt, aufgerufen werden, bevor die meisten Methoden des Objekts angesprochen werden dürfen und das Objekt sinngemäß voll initialisiert ist. Ein Beispiel soll das verdeutlichen: Listing 58: Eine Warnung von Findbugs zu möglicherweise uninitialisierten Variablen: Field not initialized in constructor: org.apache.jk.common.JkInputStream.mc JkInputStream.java Listing 59: Quellcodeauszug zur Klasse org.apache.jk.common.JkInputStream49: /** Must be called when the stream is created */ public void setMsgContext( MsgContext mc ) { this.mc=mc; } Aus verschiedenen Gründen war es nicht möglich, den MsgContext bereits dem Konstruktor mitzuteilen. Erst nachdem der Wert nachgeliefert wurde, kann das Objekt zum Lesen benutzt werden. Obiges Listing zeigt, dass das API diese Anforderung erwähnt. 49 Datei jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JkInputStream.java Bundesamt für Sicherheit in der Informationstechnik Seite 164 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Der maschinelle Nachweis, dass setMsgContext stets vor anderen Methoden dieser Klasse aufgerufen wird, ist alles andere als trivial. Das Entwurfsmuster Factory bietet hierzu eine saubere, aber leider aufwändige Lösung an: die Trennung der Zustände „teilweise initialisiert“ und „voll initialisiert“ wird durch zwei verschiedene Objekttypen bzw. -klassen erreicht. Die Factory stellt den ersten Zustand dar und speichert einige Eigenschaften, die anschließend beim Individualisieren an das daraufhin voll initialisierte Objekt der getrennten Klassen weitergegeben wird. Durch die getrennten Klassen kann kein Zugriff auf ein uninitialisiertes Objekt erfolgen. Positiv ist bei Java gegenüber C zu vermerken, dass die Sprache und die Ausführung der Bytecodes auf einer JVM besser definiert sind. Auch gibt es kein Pointer Aliasing, das Analysen erschweren würde. Dies hat zur Folge, dass Java oder JVM-basierte Systeme gerne in kleinen sicherheitsrelevanten Anwendungen, z. B. bei Chipkarten eingesetzt werden. Bei kleinen Anwendungen mit maximal zweitausend Zeilen Code werden formale Beweismethoden praktikabel und bereits eingesetzt. 5.6.3 Umfang der Quellcode-Analyse Der Fokus der automatischen Überprüfung wird bei Quellcode in C (z. B. mod_jk) auf die Suche nach potentiellen Pufferüberläufen und Format-String-Schwächen gerichtet. Es werden die Quellcode-Teile des Tomcat, die Verschlüsselungsfunktionen und Authenti­ sierungsfunktionen bereitstellen, manuell gesichtet und auf Sicherheitsprobleme hin untersucht. Bei der Verschlüsselung werden die Schnittstellen zu JSSE untersucht. Die SSLImplementierung von Java selbst ist nicht Bestandteil der Untersuchung. Weiterhin werden die Programmteile von Tomcat untersucht, die Authentisierungsfunktionen bereitstellen. Die externen Softwarekomponenten, z. B. JDBC-Schnittstellen zu Datenbanken, JavaKomponenten wie JNDI oder JAAS, die bei den entsprechenden Authentisierungsmethoden verwendet werden, sind jedoch nicht Gegenstand der Untersuchung. Falls die früher durchgeführten Tests wesentliche Abweichungen von den Sicherheitszielen oder fehlerhafte Sicherheitsfunktionen von Tomcat identifiziert haben, werden die entsprechenden Teile des Quellcodes in dieser Phase natürlich genauer betrachtet. Um das Ergebnis der Analyse vorwegzunehmen - Fehler und Inkonsistenzen wurden zwar gefunden, aber keine solchen, die die Sicherheitsziele gefährden. Die gefundenen Fehler wurden bzw. werden den Entwicklern mitgeteilt, meist in der Form von Bugmeldungen. Deren Bearbeitungsstand kann in sog. Bugtracker-Systemen online50 nachgesehen werden. Die folgenden Tabelle fasst die Tests bezüglich des Quellcodes zusammen: Test Nr. Testbeschreibung T 75 T 76 50 Automatische Quellcode Überprüfung auf Pufferüberlauf und Format String Schwächen Manuelle Sichtung des Quellcodes: Schnittstellen zu JSSE (SSL) Erwartetes Resultat unbekannt Bemerkungen flawfinder und splint für C, findbugs für Java unbekannt http://bugzilla.apache.org/ darin Produkt Tomcat 5 auswählen, dazu die Komponente JK oder Catalina Seite 165 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Test Nr. Testbeschreibung T 77 T 78 Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Erwartetes Resultat unbekannt Bemerkungen Manuelle Sichtung des Quellcodes: Authentisierungsmethoden Manuelle Sichtung des unbekannt Quellcodes vorher identifizierter Probleme Tabelle 19: Übersicht über die Quellcode Analysen 5.6.3.1.1 T91/T94 Automatische und manuelle Prüfung des Quellcode Es ist sinnvoll, automatische und manuelle Prüfung zu verbinden, da die Ergebnisse der mechanischen Werkzeuge stets manuell begutachtet werden müssen. Dies liegt in den vielfältigen Einschränkungen der Analysefähigkeit der Werkzeuge, aber auch in den Grenzen der automatischen Programmanalyse begründet. Flawfinder ist zum Aufspüren von Fehlern zu Pufferüberläufen ganz brauchbar. Eine Anwendung auf die Datei mod_jk.c ließ aufgrund der geringen Anzahl der Warnungen vermuten, die Autoren dieses Moduls haben das Werkzeug bereits selbst eingesetzt. Eine Suche in Mailinglisten, Kommentaren im Code oder den Änderungsvermerken in den ChangeLog ergab dazu jedoch keinen Hinweis. Listing 60: Statistiken von Flawfinder zu mod_jk.c: Flawfinder version 1.26, (C) 2001-2004 David A. Wheeler. Number of dangerous functions in C/C++ ruleset: 158 Examining mod_jk.c mod_jk.c:243: [2] (buffer) char: Statically-sized arrays can be overflowed. Perform bounds checking, use functions that limit length, or ensure that the size is larger than the maximum possible length. [...] mod_jk.c:2691: [1] (buffer) strlen: Does not handle strings that are not \0-terminated (it could cause a crash if unprotected). Hits = 13 Lines analyzed = 2736 in 1.34 seconds (3252 lines/second) Physical Source Lines of Code (SLOC) = 1856 Hits@level = [0] 0 [1] 9 [2] 4 [3] 0 [4] 0 [5] 0 Hits@level+ = [0+] 13 [1+] 13 [2+] 4 [3+] 0 [4+] 0 [5+] 0 Hits/KSLOC@level+ = [0+] 7.00431 [1+] 7.00431 [2+] 2.15517 [3+] 0 [4+] 0 [5+] Minimum risk level = 1 Not every hit is necessarily a security vulnerability. There may be other security vulnerabilities; review your code! 0 Obiges Listing enthält die erste und letzte Meldung von Flawfinder zur Datei mod_jk.c. Flawfinder fügt jeder Meldung einen Sicherheitslevel hinzu. Jede solche Meldung oder zumindest die der höchsten Level kann anschließend manuell auf Falschmeldungen geprüft werden. Feststellung: jk_error_exit() formatiert die Fehlermeldungstext im printf()-Stil über apr_pvsprintf() aus der Bibliothek APR von Apache, übergibt den formatierten String jedoch an ap_log_error(), welches wiederum eine printf()-Formatierung durchführt. Nach der ersten Bundesamt für Sicherheit in der Informationstechnik Seite 166 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Formatierung übrig gebliebene oder entstandene %-Zeichen würden beim zweiten Mal zu Fehlverhalten führen. Derzeit wird jk_error_exit() nur mit der Text "Memory Error" aufgerufen, der Fehler kommt also nicht zum Tragen. Ganz anders würde es sich verhalten, wenn beliebige Texte zum Einsatz kämen. Während der Projektlaufzeit wurde von anderer Stelle ein ähnlicher Fehler in der libgda für GNOME gefunden, der zu einer CERT-Meldung51 und sofortigem Security Patches führte. Leider erkennt keines der eingangs beschriebenen und auch der für die Tests verwendeten Werkzeuge eine solche Doppelformatierung automatisch. Feststellung: Die Funktion jk_log()52 implementiert unzureichende Vorkehrungen gegen einen Pufferüberlauf. Die gefundenen Fehler sind jedoch wahrscheinlich nicht ausnutzbar. Detailiertere Beschreibung: 1. In folgender Codezeile muss die Puffergröße entsprechend der bereits enthaltenen Zeichen reduziert werden, es sollte also HUGE_BUFFER_SIZE – used heißen: used += snprintf(&buf[used], HUGE_BUFFER_SIZE/*-used fehlt hier!*/, "%s (%d): ", 2. Das Mitzählen der benutzten Zeichen über used += snprintf(...,limit,...) ist ebenfalls problematisch, weil POSIX spezifiziert, dass der Rückgabewert der Funktionen snprintf(), vsnprintf() usw. beliebig größer als der übergebene Grenzwert wird, wenn der Puffer nicht groß genug ist. Der Rückgabewert ist die Größe, die benötigt worden wäre, um den Text vollständig zu formatieren. Als Folge würde der Wert von BUFFER_SIZE - used negativ bzw. aus Sicht von snprintf() eher enorm groß, da diese Funktionen mit natürlichen Zahlen (unsigned long) anstelle von vorzeichen­ behafteten Zahlen (int oder long) arbeiten. Die Grenzwertüberprüfung wird damit effektiv außer Kraft gesetzt. Außerdem verweist &buf[used] bei darauf folgenden Aufrufen auf ungültigen Speicher! 3. Die Funktion verwendet return nicht nur als letzte Zeile, so dass der auf bestimmten Systemen (NETWARE) mit malloc() allokierte Speicher dann nicht freigegeben wird. Trotz dieser Fehler vermuten wir, dass die Funktion kaum missbraucht werden kann, da der Überlauf nur durch überlange Dateinamen ausgelöst werden kann, die im Code fest eincompiliert sind, so dass für diese der verwendete Puffer (8KB) groß genug sein müsste. Feststellung: In mod_jk werden die Rückgabewerte der Funktionen von APR zur Speicher­ allokation wie z. B. apr_palloc() nur stellenweise abgefragt. Ein systematisches Abfragen ist nicht zwanghaft, denn APR53 stellt ebenfalls einen Callback zur Verfügung, der bei Speichermangel aufgerufen werden könnte: pool->abort_fn(APR_ENOMEM); Dazu müsste dieser jedoch gesetzt werden. Wer darf diesen setzen und welche Möglichkeiten bieten sich dann in C (wo könnte der Code hin springen, um die aktuelle 51 52 53 http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=libgda/libgda&command=D IFF_FRAMESET&file=gda-log.c&rev1=1.12&rev2=1.13&root=/cvs/gnome Datei jakarta-tomcat-connectors-1.2.14.1-src/jk/native/common/jk_util.c Datei apr_pools.c der Bibliothek APR, ebenfalls in Apache enthalten Seite 167 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Funktion zu beenden)? Sprachen mit Exception Handling haben es hier wesentlich einfacher. Feststellung: mod_jk enthält einen Ersatz für die Funktion vsnprintf(), der zur Anwendung kommt, wenn diese im Betriebssystem nicht enthalten ist. Dies wird aber beim Compilieren und nicht zur Laufzeit festgestellt. Diese Ersatzfunktion ruft Funktionen von POSIX inkorrekt auf, so dass die erwünschte Funktionalität nicht sichergestellt werden kann. Linux-Systeme sind davon nicht betroffen, weil die darin verwendete glibc diese Funktion bereits seit Jahren zur Verfügung stellt. Listing 61: vsnprintf-Ersatz in jk_util.c: #if !defined(HAVE_VSNPRINTF) && !defined(HAVE_APR) static FILE *f = NULL; static int vsnprintf(char *str, size_t n, const char *fmt, va_list ap) { int res; if (f == NULL) f = fopen("/dev/null", "w"); if (f == NULL) return -1; setvbuf(f, str, _IOFBF, n); res = vfprintf(f, fmt, ap); if (res > 0 && res < n) { res = vsprintf(str, fmt, ap); } return res; } #endif Die Abweichungen von POSIX sind gemäß Manpage zu setvbuf wie folgt beschrieben: 1. „You must make sure that both buf and the space it points to still exist by the time stream is closed, which also happens at program termination.“. Der übergebene Puffer str hat aber eine ganz kurze Lebensdauer und die Datei wird erst bei Programmende (exit) geschlossen. 2. „The setvbuf function may only be used after opening a stream and before any other operations have been performed on it.“ Die Datei in der globalen Variable f wird jedoch offen gehalten, die Funktion bei jedem Logvorgang erneut aufgerufen, also nach dem vorigem Schreiben eines Logeintrags. Feststellung: Aus Sicht eines Code-Reviews wäre es wünschenswert, stellenweise Änderungen am Code vorzunehmen, die die Lesbarkeit erhöhen. Diese Feststellung betrifft die Sicherheit nur indirekt sollte aber für das Review als Sicherheitsmaßnahme beachtet werden: • die Funktion ws_write() in mod_jk verwendet sowohl eine Variable Namens r als auch einen Feldnamen gleichen Namens. Bundesamt für Sicherheit in der Informationstechnik Seite 168 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests • Funktionen in mod_jk verwenden beispielsweise wiederum in ws_write() eine Variable Namens l, die leicht mit der Zahl 1 zu verwechseln ist . • Die Datei HandlerRequest.java54 definiert sowohl SC_A_SSL_KEYSIZE als auch SC_A_SSL_KEY_SIZE identisch an weit auseinander liegenden Stellen im Code. • Namensgleiche Instanzenvariablen innerhalb einer Klassenhierarchie sind stets problematisch und sollten vermieden werden. Findbugs moniert diese zu recht: MF: Class org.apache.jk.common.JkMX defines field that obscures superclass field org.apache.jk.core.JkHandler.mserver Class defines field that obscures a superclass field This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other. Feststellung: Bei der Fehlerbehandlung in Java wird teilweise inkonsistent geloggt: Die verwendeten Loglevel können von Modul zu Modul voneinander abweichen. Wünschenswert wäre ein Logging oberhalb des Level „debug“. Der Level „debug“ sollte im Betrieb nicht eingesetzt werden, auch wenn die Administratoren über Fehler informiert werden müssen. Die meisten Module, mit Ausnahme von catalina/Realm/RealmBase.java, tun dies richtig und loggen auf Ebene „warn“ oder „error“. Folgender Shell-Befehl liefert dazu eine Übersicht: egrep -n --after-context=2 -e '\bcatch\b' */*.java Im folgenden Beispiel wäre es vermutlich sinnvoll, den Fehler bei der Namensauflösung nicht bloß auf Level „debug“ zu loggen: Listing 62: Auszug aus JkCoyoteHandler.java55: // If remoteHost not set by JK, get it's name from it's remoteAddr if( req.remoteHost().isNull()) { try { req.remoteHost().setString(InetAddress.getByName( req.remoteAddr().toString()). getHostName()); } catch(IOException iex) { if(log.isDebugEnabled()) log.debug("Unable to resolve "+req.remoteAddr()); } } Zusammenfassung: Die Fundstellen sollten umgeschrieben werden, selbst wenn nicht jede sicherheitskritisch ist oder wahrscheinlich gar nicht für einen Angriff ausgenutzt werden kann. Zum Teil handelt es sich um klassische Fehler, wie sie in C Programmen immer wieder vorkommen und Angriffe über Buffer-Overflow ermöglichen. Diese Programmfehler wurden in den Apache Bugtracker56 eingegeben, so dass diese nach und nach von den Entwicklern behoben werden dürften. 54 55 56 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java http://bugzilla.apache.org/ Seite 169 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 5.6.3.1.2 T92 Manuelle Sichtung der Schnittstelle zu JSSE (SSL) JSSE bzw. SSL kommt in Tomcat an zwei Stellen zum Einsatz: 1. als Authentisierungsmöglichkeit (vgl. T6). 2. innerhalb des HTTP-Connectors Im ersten Fall wird JSSE nur indirekt benutzt. Der Zugriffsschutz wird in der Datei SSLAuthenticator.java57 innerhalb der Komponente Catalina implementiert. SSL kommt darin indirekt zum Einsatz, indem das Zertifikat des Clients angefordert wird (z. B. über das AJPProtokoll) und der darin angegebene Name zur Prüfung an das für die aktuelle URL konfigurierte Realm übergeben wird. Der HTTPS-Connector muss dagegen letztendlich SSL einsetzen. In der Datei SSLImplementation.java58 wird JSSE nur dann ausgewählt, wenn das Paket org.apache.tomcat.util.net.puretls.PureTLSImplementation nicht gefunden wird. JSSE wird also nur alternativ benutzt. In JSSEImplementation.java wird anschließend zwischen der JSSE ab dem SDK-1.4 (JSSE14) oder einem älteren JSSE (JSSE13) unterschieden. Letztlich aber spielen alle Dateien im Verzeichnis tomcat/util/net/ und insbesondere tomcat/util/net/jsse zusammen. Dort wird die durch javax.net.ssl standardisiert angebotene Funktionalität angesprochen, um sowohl die Verbindung über einen SSL-Socket aufzubauen, zu verwalten aber auch um daraus die Zertifikatsinformation zu gewinnen. Die Dateien JSSE14SocketFactory.java und JSSESocketFactory.java setzen die Optionen aus der Konfigurationsdatei server.xml um. Die Prüfung des Codes offenbarte bis auf eine Ausnahme (s. u.) keine Sicherheitsmängel. Es werden aber folgende Abweichungen von der Dokumentation, dem Dokument „SSL Configuration HOW-TO“59, festgestellt: Feststellung: Es gibt zwei undokumentierte Attribute in den zwei Dateien: „truststoreAlgorithm“ (Default-Wert: wie beim Attribut „algorithm“) für den Zugriff auf den Truststore und „keyAlias“ für den Zugriff auf Keystores. Beim Abgleich zwischen Code und Dokumentation muss berücksichtigt werden, dass die eine Datei60 einige Abweichungen von der ansonsten 1:1-Übereinstimmung zwischen XMLAttribut in server.xml und dem Code einführt. Darunter sind auch „sslProtocol“ für „protocol“, „clientAuth“ statt „clientauth“ oder „keystorePass“ für „keypass“ zu finden. Dies liegt vermutlich in der Historie begründet. Die Erkenntnisse aus T45 und T46 veranlassten eine vertiefte Analyse des Umgangs mit den Attributen „ciphers“ und „protocol“: Festellung: Beim Umgang mit den erlaubten Algorithmen (enabledCiphers) wird zwar zwischen der ungesetzten Option und der leeren Schnittmenge erlaubter (enabled) und möglicher (supported) Algorithmen unterschieden. Leider werden unerkannte Namen von Algorithmen, beispielsweise durch Tippfehler, ohne jegliche Meldung ignoriert. Ist die Schnittmenge leer, wird setEnabledCipherSuites nicht zur Begrenzung aufgerufen. Tomcat verhält sich dann so, als wäre die Option gar nicht angegeben worden. 57 58 59 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/SSLImplementation.java http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html oder jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml im Quelltext 60 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java Bundesamt für Sicherheit in der Informationstechnik Seite 170 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Die Ursache dafür liegt womöglich in der Methode set EnabledCipherSuites61 des JSSE, für die spezifiziert ist, dass der Wert NULL anstelle eines Feldes von Namen nicht angenommen wird. Offen bleibt dabei, ob eine leeres Feld (im Sinne von new String[0]) zur notwendigen Zurückweisung sämtlicher Kommunikation auf dem betroffenen Socket führen wird. U. U. könnte bei leerer Menge auch sofort ein Ausnahmezustand (Exception) erzeugt werden. Eine andere Erklärung ist denkbar. Die folgenden Funktionen aus zwei getrennten Dateien behandeln den Fall enabledCiphers=null unterschiedlich. Für die erste bedeutet dieser Fall, wie im Kommentar erklärt, dass keine gültige Angabe erkannt wurde. Die zweite Funktion dagegen behandelt den Fall, als wäre keine Angabe vorhanden, dass also keine Einschränkung besteht. Listing 63: Auszug aus JSSESocketFactory.java zu getEnabledCiphers: * @return Array of SSL cipher suites to be enabled, or null if none of the * requested ciphers are supported */ protected String[] getEnabledCiphers(String requestedCiphers, String[] supportedCiphers) { Listing 64: Auszug aus JSSESocketFactory.java zu enabledCiphers: private void initServerSocket(ServerSocket ssocket) { [...] if (enabledCiphers != null) { socket.setEnabledCipherSuites(enabledCiphers); } Feststellung: Völlig ähnlich verhält sich der Code in JSSE14SocketFactory62 bei der Verarbeitung der Angaben zu „protocol“ bzw. zu „sslProtocol“. Die Funktion setEnabledProtocols wird nur aufgerufen, wenn sich unter den konfigurierten Protokollen ein unterstütztes Protokoll befindet. Dies wird mit getSupportedProtocols geprüft. Ist die Schnittmenge leer, findet keine Einschränkung statt. Alle unterstützten Protokolle sind dann anwendbar. Dieses Verhalten betrachten wir als schweren Fehler wider die Erwartungskonformität von Tomcat. 1. Nicht erkannte Protokolle muss Tomcat in Fehlermeldungen aufzeigen. 2. Wird kein einziges gültiges Protokoll erkannt, muss sämtliche Kommunikation abgewiesen werden, oder alternativ Tomcat gar nicht erst starten. 5.6.3.1.3 T93 Manuelle Sichtung der Authentisierungsmethoden Bei der Sichtung der Authentisierungsmethoden wurden keine sicherheitsrelevante Fehler entdeckt. Folgende Abweichungen von der Dokumentation sind dabei jedoch aufgefallen. 61 62 javax.net.ssl.SSLSocket.setEnabledCipherSuites Datei jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSE14SocketFactory.java Seite 171 (von 187) Bundesamt für Sicherheit in der Informationstechnik Durchführung der Tests Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Der Tomcat-Container, genannt Catalina, zentralisiert die verfügbaren Authentisierungs­ methoden im Paket org.apache.catalina.Realm, das den Dateien des Verzeichnisses catalina/realm/*.java entspricht. Dort liegen die Dateien MemoryRealm.java, JDBCRealm.java, JNDIRealm.java, JAASRealm.java, DataSourceRealm.java, die die gleichnamigen Klassen definieren, sowie einige Zusatzklassen wie die Datei RealmBase.java, die Gemeinsamkeiten dieser Mechanismen durch Vererbung kapselt. Die Vielfalt der Realms ist verwirrend. Sie bieten laut Dokumentation („Realm Configuration HOW-TO“63 zu Tomcat) folgende Möglichkeiten: Name MemoryRealm UserDataBaseRealm JDBCRealm JNDIRealm JAASRealm DataSourceRealm Datenquelle XML-Datei (veraltet?) XML-Datei als globale Ressource (z. B. tomcat-users.xml) JDBC-Datenquelle (relationale Datenbank) LDAP, über JNDI JAAS, darüber wiederum je nach Provider64 als Quelle eine XMLDatei, X500, Unix-Login, NTLM oder Kerberos JDBC-Datenquelle über JNDI Tabelle 20: Namen der Realm und deren Einsatzmöglichkeiten Feststellung: UserDataBaseRealm wurde in die Tabelle mit aufgenommen, obwohl es im HOW-TO nicht erwähnt wird, weil es im Quellcode verwendet wird. JAASRealm wird im HOW-TO zwar erwähnt, fehlt aber in der getrennten Datei mit Beispielen zur Konfiguration65. Das Logging dieser Module wird im HOW-TO so dokumentiert, dass die auszugebende Informationen über die Logkomponente des Containers ausgegeben werden (engl. „Debugging and exception messages logged by a Realm will be recorded by the logging configuration associated with the container for the realm: its surrounding Context, Host, or Engine.“). Auf Ebene des Code wird dies wie folgt erreicht: Listing 65: Übernehmen der Logkomponente des umgebenden Containers: this.containerLog = container.getLogger(); [...] if(! validated ) { if (containerLog.isTraceEnabled()) { containerLog.trace(sm.getString("realmBase.authenticateFailure", username)); } return null; } if (containerLog.isTraceEnabled()) { containerLog.trace(sm.getString("realmBase.authenticateSuccess", username)); } Feststellung: Der JNDIRealm fasst das Ergebnis der Authentisierung in einem eigenen Log zusammen. Der Container wird dazu nicht benutzt. Die Logmeldungen zu diesem Modul müssen daher anders als die Dokumentation erwarten lässt ab- und zugeschaltet werden. 63 64 65 http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html oder lokal http://localhost:8080/tomcat-docs/realm-howto.html oder im Quelltext jakarta-tomcat-5.5.9-src/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/ Die aufgeführten Möglichkeiten entsprechen denen des Sun-Providers, vgl. Package com.sun.security.auth im JavaSDK der Firma Sun. Datei webapps/docs/config/realm.xml Bundesamt für Sicherheit in der Informationstechnik Seite 172 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Durchführung der Tests Feststellung: Die Module MemoryRealm und JAASRealm weichen ebenfalls von der im HOW-TO beschriebenen Vorgabe ab und definieren eine eigene Komponente wie folgt: Listing 66: eigene Logkomponente in MemoryRealm und JAASRealm: private static Log log = LogFactory.getLog(MemoryRealm.class); [...] if (validated) { if (log.isDebugEnabled()) log.debug(sm.getString("memoryRealm.authenticateSuccess", username)); return (principal); } else { if (log.isDebugEnabled()) log.debug(sm.getString("memoryRealm.authenticateFailure", username)); return (null); }; Feststellung: MemoryRealm loggt den Erfolg oder Misserfolg der Authentisierung lediglich auf Debug-Ebene, d. h. zu niedrig für den normalen Betrieb eines Webservers. Diese Inkonsistenz zu den anderen Verfahren ist nicht weiter kritisch, denn grundsätzlich ist das zentrale Logging anhand einer AccessLogValve vorzuziehen (vgl. T41). Insbesondere lässt sich dann das Format festlegen und somit einfacher der maschinellen Auswertung der Log­ dateien zuführen als die individuellen Logmeldungen der einzelnen Komponenten. Positiv aufgefallen ist in JDBCRealm die Verwendung von PreparedStatement. Diese sind nicht anfällig gegen die üblichen Methoden der SQL-Injection, sofern sie in den unteren Schichten tatsächlich implementiert und nicht emuliert werden. Dann werden zur Laufzeit nämlich keine SQL-Abfragen aus Zeichenketten zusammengebaut, sondern grob gesehen Parameter an fertige SQL-Prozeduren übergeben und diese aufgerufen. Wenn PreparedStatement dagegen lediglich emuliert wird, gibt es keine Vorteile, sondern sogar Geschwindigkeitseinbußen gegenüber einfachen SQL-Abfragen. Dies ist uns in einem früheren Projekt mit Microsoft-SQL aufgefallen. Seite 173 (von 187) Bundesamt für Sicherheit in der Informationstechnik Empfehlungen und Maßnahmen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 6. Empfehlungen und Maßnahmen Nachfolgend sollen einige Empfehlungen gegeben werden, die zur Erhöhung der Sicherheit beim Betrieb des Jakarta Tomcat Servlet Containers dienen können. Diese ersetzen nicht die grundlegenden Sicherheitsrichtlinien einer IT-Umgebung bzw. das IT-Sicherheitskonzept einer Behörde oder eines Unternehmens. Eine Grundlage für Sicherheitsrichtlinien oder ITSicherheitskonzepte sollten immer die Sicherheitsempfehlungen und Maßnahmen des ITGrundschutzhandbuchs des BSI sein. Die in diesem Kapitel aufgeführten Empfehlungen und Maßnahmen sollen diese spezifizieren und ergänzen. Hinweis: Die verwendete Reihenfolge gibt keine Information über eine Priorisierung. 6.1 Allgemeine Maßnahmen bzw. Maßnahmen auf Betriebssystemebene 6.1.1 Dateiberechtigungen und -zuordnung Da die untersuchten Anwendungen (Apache Webserver, Jakarta Tomcat Servlet Container, mod_jk Connector Modul) standardmäßig mit relativ offenen Berechtigungen installiert werden, mit Lese- bzw. Ausführrechten für die Gruppe root und für world, sollte zur Verbesserung der Sicherheit von restriktiveren Berechtigungen Gebrauch gemacht werden, z. B. Entzug der Lese- bzw. Ausführungsberechtigungen für world. Die Einschränkung der Dateiberechtigungen ist insbesondere für die ausführbaren Programme oder Shell-Skripts sowie für die Konfigurationsdateien wichtig, um unbefugte Ausführung von Programmen oder Einsichtnahme in die Konfigurationsinformationen, die möglicherweise auch Passwörter oder andere sensible Informationen enthalten könnten, zu unterbinden. Weiterhin empfiehlt sich für eine mögliche separate Administration der Anwendungen diese unterschiedlichen Nutzern / Gruppen, z. B. www für den Apache Webserver Administrator und tomcat für den Tomcat Administrator, zuzuordnen. Der Apache Webserver muss wegen der Belegung von privilegierten Ports, HTTP: Port 80 bzw. HTTPS: Port 443 bei Standardbelegung, nach wie vor durch den Nutzer root gestartet werden. Dies kann aber beispielsweise durch den Start der Anwendungen beim Booten des Systems geschehen oder ein Nutzer kann über das sudo Kommando die Rechte eines Administrators erlangen und damit die Berechtigung zum Starten / Anhalten der Apache Applikationen bekommen. Nach der Belegung der privilegierten Ports kann der Apache Webserver, unter Verwendung der Apache USER und GROUP Direktiven, in einen nicht-privilegierten Benutzer-Modus wechseln. Neben den untersuchten Anwendungen sind gleichfalls restriktive Dateiberechtigungen und -zuordnungen bei den verwendeten Diensten wie LDAP bzw. bei einer Hintergrunddaten­ bank, die zur Benutzerauthentisierung und -autorisierung verwendet wir, zu setzen. Hier ist sicherzustellen, dass sensitive Informationen wie Passwörter durch Unbefugte weder gelesen noch modifiziert werden können. Zu berücksichtigen sind dabei sowohl die Betriebs­ systemebene, wo die Dateiberechtigungen entsprechend zu setzen sind, als auch die Dienste selbst, die über Mechanismen zum Schutz sensitiver Informationen verfügen. Dies sind beispielsweise: • Access-Control Lists (ACLs) in der Konfigurationsdatei /etc/ldap/slapd.conf für eine Zugriffssteuerung innerhalb von OpenLDAP bei der Realisierung einer OpenLDAPbasierten JNDI Realm Authentisierung Bundesamt für Sicherheit in der Informationstechnik Seite 174 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • Empfehlungen und Maßnahmen der SQL GRANT Befehl zur Freigabe von Lese- bzw. ggf. Modifikationsoperationen der Nutzerinformationen in der MySQL-Datenbank bei der Realisierung einer MySQLbasierten JDBC Realm Authentisierung. Hinweis: Je nachdem welcher Dienst Sicherheitsmechanismen Anwendung finden. verwendet wird, können auch andere 6.1.2 Passworte für die Benutzer / Webanwendung Zum Schutz vor unberechtigten Zugriffen sollten die üblichen Regeln für die Verwendung von Passworten angewendet werden. Dies betrifft beispielsweise die Charakterisierung der Passworte, wie Mindestlänge, Anforderungen an die zu verwendenden Zeichenklassen, Wechselhäufigkeit, etc., die den in der IT-Umgebung geltenden Richtlinien entsprechen muss. Neben einzelnen Benutzerkonten sind hiervon auch Webanwendungen betroffen, insbesondere auch die Tomcat-Management-Applikationen admin und manager, die, soweit sie auf dem betreffenden System, durch die weit reichenden Konfigurationsmöglichkeiten für andere Webanwendungen besonders zu schützen sind. Nach Möglichkeit sollten die Passworte einmal durch die betriebssystemspezifischen Schutz­ mechanismen (Dateizugriffsbeschränkungen) und andererseits durch die Vermeidung der Speicherung im Klartext, d. h. stattdessen die Verwendung von Passwort-Hashwerten geschützt werden, um eine Kenntnisnahme durch Unbefugte zu verhindern. Dies gilt insbesondere für Passworte in Verbindung mit der Benutzung von Datenbanken, z. B. für Webanwendungen oder die Tomcat-Authentisierung, die nur von Programmen (Daemons) selbst, nicht aber von Benutzern verwendet werden und deshalb u. U. keinem regelmäßigen Passwortwechsel unterworfen sind. Die zu schützenden Benutzer- und Passwortinformationen in Verbindung mit dem Tomcat Servlet Container befinden sich bei Verwendung von Memory Realm Authentisierung in der Datei $CATALINA_HOME/conf/tomcat-users.xml bzw. bei Verwendung von JDBC Realm oder JNDI Realm Authentisierung in einer separaten Datenbank, die für Authentisierungs­ zugriffe durch Tomcat verwendbar, aber vor anderen Benutzern zugriffsgeschützt sein sollten. 6.1.3 Passwort des JAVA Zertifikatspeichers Zur Überprüfung von Zertifikaten verwendet JAVA und somit auch der in JAVA geschriebene Tomcat Servlet Container den JAVA Zertifikatspeicher, der in der Datei ${JAVA_HOME}/jre/lib/security/cacerts abgelegt ist. Da somit die dort abgelegten Zertifikate66 eine zentrale Rolle bei der Sicherheit besitzen, wird empfohlen, das Standard­ passwort changeit des Zertifikatspeichers direkt nach dessen Installation, die im Rahmen der Installation des JAVA SDKs erfolgt, neu zu setzen. Alternativ können in Tomcat die Zertifikate der die Client-Zertifikate signierenden Certification Authorities (CAs), im Tomcat-Zertifikatspeicher abgelegt werden, der mit den zusätzlichen Optionen truststoreFile und ggf. truststorePass in der <Connector>-Deklaration der Konfigurationsdatei $CATALINA_HOME/conf/server.xml spezifiziert wird. Auch dieser In der JAVA Standard-Installation sind dies im Wesentlichen Root-CA-Zertifikate. Bei der Nutzung von SSL-Client Authentisierung oder Client-Zertifikat-Authentisierung in Verbindung mit dem Apache Webserver oder Tomcat können dies darüber hinaus auch selbst erzeugte oder von einer Certification Authority (CA) signierte Server-Zertifikate sein. 66 Seite 175 (von 187) Bundesamt für Sicherheit in der Informationstechnik Empfehlungen und Maßnahmen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers gegebenenfalls verwendete Zertifikatspeicher ist entsprechend durch ein ausreichend sicher gewähltes Passwort gegen unbefugte Manipulationen zu schützen. 6.1.4 Host-basierte Firewall (netfilter / iptables) Über eine host-basierte Firewall kann eine explizite Freigabe der Kommunikationsports erfolgen, die entweder direkt, z. B. von extern angesprochen werden können oder die der Kommunikation des Apache Webservers mit dem / den Jakarta Tomcat Servlet Containern über das Connector-Modul mod_jk dienen. Auf diese Weise kann der Rechner mit dem darauf laufenden Webserver, dem Servlet-Container und der Webanwendungen gegen Zugriffe mit nicht freigegebenen Protokollen geschützt werden. Insbesondere bei auf mehreren Rechnern verteilten Systemen, z. B. der Apache Webserver auf einem Rechner und der Jakarta Tomcat Servlet Container zur Lastverteilung auf anderen Rechnern, ist auf eine sorgfältige Abbildung der benötigten Kommunikationspfade für die FirewallKonfiguration zu achten. Nur durch aufmerksame Administration der Firewall werden die für die Anwendungen benötigten, Rechner übergreifenden Kommunikationspfade zwischen den Servern im Netz nicht behindert und dennoch unzulässige Kommunikationspfade wirksam unterbunden. 6.1.5 Gesicherte Kommunikation Sollen verschiedene Softwarekomponenten, die selbst keine Verschlüsselung zur Erhöhung der Abhörsicherheit und zum Schutz der übertragenen Daten anbieten, miteinander über ein ungeschütztes Netzwerk abgesichert kommunizieren, so kommen zum Schutz der Kommuni­ kation beispielsweise virtuelle private Netzwerk (VPN) Techniken oder Port-Forwarding über verschlüsselte Verbindungen in Frage. Im Fall von VPNs wird zwischen den beteiligten Hosts bzw. der an der Grenze zum ungesicherten Netzwerken befindlichen Firewall ein verschlüsselter Tunnel aufgebaut. Diese Tunnels können beispielsweise mit Hilfe von IPsec-Verschlüsselung [RFC2401] realisiert werden. Neben einem Schutz des Datenverkehrs vor unbefugtem Abhören durch die Verschlüsselung kann die gegenseitige Authentisierung der beiden an den Tunnelenden befindlichen Hosts auch genutzt werden, um die Berechtigung der Nutzung des aufgebauten Tunnels durch die Kommunikationspartner sicher zu stellen. Beim Port-Forwarding per Secure Shell (SSH) hingegen wird statt einer direkten Kontaktaufnahme des Clients mit dem Server über ungeschützte Netzwerkbereiche hinweg der Netzwerkverkehr von der Client-Maschine durch einen SSH-Tunnel auf die ServerMaschine an den eigentlichen Server-Port weiter geleitet. Somit wird beispielsweise der Server-Port eines Datenbankservers virtuell auf den Client transferiert und dort für die Anwendung, in diesem Fall Tomcat, nutzbar gemacht. Details zur Installation von SSH basiertem Port-Forwarding finden sich auch [Barret]. Bedeutung hat die Absicherung der Kommunikation insbesondere bei der Übertragung sensibler Informationen wie • Authentisierungsinformationen, die • zwischen dem Webserver, mit mod_jk / mod_proxy Modul und Tomcat, mit AJP / HTTP Connector oder Bundesamt für Sicherheit in der Informationstechnik Seite 176 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • Empfehlungen und Maßnahmen zwischen Tomcat und einer per JDBC- bzw. JNDI-Schnittstelle angebundene Datenbank, ausgetauscht werden und • im Bereich der Webanwendungen bei den zwischen dem Web-Frontend und den Hintergrundapplikationen ausgetauschten Informationen, z. B. Kreditkartennummern, Kennwörter, PINs und TANs, Personen bezogene Daten oder andere schützenswerte Informationen. 6.1.6 Eingeschränkte Laufzeitumgebung (chroot) Eine weitere Abschottung der Anwendung vom übrigen System kann durch die Verwendung von eingeschränkten Umgebungen erfolgen. Ein Nachteil ist hierbei jedoch der mit der teilweisen mehrfach Installation von Dateien / Anwendungen verbundene SpeicherMehraufwand, der sowohl auf der Betriebssystemebene der Host-Maschine, als auch innerhalb von chroot-Umgebungen benötigt wird. Ziel der Verwendung einer chrootUmgebung ist die Separierung der darin laufenden Programme von den übrigen auf der Maschine laufenden Anwendungen durch eine eingeschränkte Umgebung, in der nur die für diese Anwendungen benötigten Softwareprogramme verfügbar sind. Bei einem eventuellen Einbruch auf Grund beispielsweise einer Sicherheitslücke in der Webanwendung, ist es einem erfolgreichen Angreifer so nur innerhalb der beschränkten Umgebung möglich Zugriff auf Programme und Daten zu nehmen. 6.1.7 Nutzung von erweiterten Zugriffsschutzmechanismen unter SELinux Bei der Nutzung künftiger Debian Linux Varianten mit Unterstützung von SELinux (Security Enhanced Linux) bieten sich Möglichkeiten zur detaillierten Spezifikation von Zugriffs- und Ausführungsberechtigungen einzelner Programme und Anwendungen. Diese ermöglichen es beispielsweise die Zugriffsmöglichkeiten von Web-Diensten auf Dateien oder Programme weit gehend einzuschränken und damit die Sicherheit dieser Dienste zu erhöhen. Da in der aktuellen Betriebssystemplattform Debian 3.1 Sarge, die auch für die Tests verwendet wurde, noch kein vollständiger SELinux-Support integriert ist, können derzeit noch keine konkreten Vorgaben für einen sicheren Betrieb gemacht werden. Weiter gehende Informationen zum Themenkomplex SELinux finden sich beispielsweise in [NSA SELinux] bzw. [McCarty] und für die nächste, als unstable gekennzeichnete Debian Linux Version Sid in [Debian SELinux]. 6.2 Maßnahmen beim Apache Webserver Neben den allgemeinen Richtlinien zum sicheren Betrieb des Apache Webservers wie die Ausführung unter einem non-root Benutzer, der Vergabe entsprechend restriktiver Zugriffsberechtigungen, etc., sollten hier spezifische Maßnahmen genutzt werden, die bei der Verbindung des Apache Webservers, ergänzt durch das Connector-Modul mod_jk, mit dem Jakarta Tomcat Servlet Container zum Einsatz kommen können. Seite 177 (von 187) Bundesamt für Sicherheit in der Informationstechnik Empfehlungen und Maßnahmen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 6.2.1 Zugriffsberechtigungen Durch eine restriktive Vergabe der Zugriffsberechtigungen sowohl auf Betriebssystemebene, bei Dateien oder Verzeichnissen, als auch bei den Zugriffsregeln auf die bereitgestellten Web-Ressourcen, die in der Apache Webserver Konfigurationsdatei httpd.conf festgelegt werden, sollte eine unautorisierte Einsicht in die auf dem Webserver befindlichen Dateien / Verzeichnisse verhindert werden. Hiervon sind betroffen: • Webanwendungen (z. B. Servlets, JSPs, CGI-Programmdateien) • Konfigurationsdateien der Webanwendungen • Dateien / Verzeichnisse von Hintergrundapplikationen (z. B. Datenbanken, o. ä.) Der Apache Webserver bietet die Möglichkeit der Filterung von eintreffenden Anfragen bezüglich der IP-Adresse oder den Host- bzw. Domänennamen, sowie bezüglich der verwendbaren HTTP-Zugriffsmethoden (GET, POST, PUT, DELETE, HEAD, ... per <Limit> Direktive). So können unerwünschte Anfragen heraus gefiltert werden und gelangen gar nicht bis zum Tomcat Servlet Container um dort Schadfunktionen auszulösen. 6.2.2 Watchdog-Funktionalität Es kommt vor, dass komplexe Anwendung wie Tomcat einfach hängen bleiben, ohne abzustürzen und ohne dass in den Logdateien etwas ersichtlich ist. Dennoch reagiert der Webserver auf keine Anfrage mehr. Aus diesem Grund ist es ratsam, nicht nur mittels ping die Funktionsfähigkeit der Netzwerkkarte des Rechners zu testen, sondern regelmäßig über den Apache bis zum Tomcat einen Zugriff über HTTP(S) auszuführen. Der getestete Bereich ist dann viel größer als bei ping. Am sinnvollsten paart man dies mit einer Kurzprüfung der Zugangsberechtigungen. Ansonsten kann es recht kompliziert werden, eine gültige Anfrage automatisch an die Webanwendung zu schicken. Ein illegaler Zugriff dagegen testet die Funktionalität von einem wichtigen Teil der Webanwendung und sollte einfach zu automatisieren sein. Um eine möglichst tiefe Testschleife durch das System zu ziehen, sollte der illegale Zugriff idealerweise erst spät abgelehnt werden, also beispielsweise von einem Servlet selbst anstelle eines AccessValve in Tomcat oder im Apache. 6.3 Maßnahmen beim Jakarta Tomcat Servlet Container 6.3.1 Installation unter einem Tomcat Benutzer Um ein root Login zur Konfiguration von Tomcat und den Webanwendungen zu verhindern, sollten Tomcat, dessen Konfigurationsdateien und ggf. die Webanwendungen unter einem eigenen Linux-Benutzerkonto eingerichtet werden. Zusätzlich sollten die Web-Applikationen unter anderen Benutzerkonten als der Tomcat-Benutzer eingerichtet werden, so sind ent­ sprechende Berechtigungen für den Tomcat-Benutzer auf die Dateien der Webanwendungen einstellbar. Solange nur lesend auf die Dateien zugegriffen werden muss, genügen entsprechende Leseberechtigungen. Müssen von den Servlets lokale Dateien angelegt bzw. modifiziert werden, so sind ggf. entsprechende Schreibberechtigungen vorzusehen. Bundesamt für Sicherheit in der Informationstechnik Seite 178 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Empfehlungen und Maßnahmen 6.3.2 Shutdown-Port Zur Vermeidung von Denial-of-Service (DoS) Angriffen sollte auf die Freigabe eines Ports zum Herunterfahren des Jakarta Tomcat Servlet Containers verzichtet werden, da für das Herunterfahren lediglich die Kenntnis der dafür konfigurierten Zeichenkette erforderlich ist und eine weiter gehende Authentisierung zur Feststellung der Berechtigung zum Herunter­ fahren nicht erfolgt. Zwar ist gemäß der Tomcat Dokumentation das Herunterfahren durch eine Kontaktierung des Ports nur vom lokalen Host, auf dem der Jakarta Tomcat Servlet Container selbst auch läuft, möglich, jedoch kann jeder auf diesem Host eingeloggte Nutzer mit Kenntnis der Shutdown-Zeichenkette das Herunterfahren durch das Kommando telnet localhost 8005 sowie der anschließenden Eingabe dieser Shutdown-Zeichenkette initiieren. Vielmehr sollte auf die übliche Methode der Verwendung von System-Startup-Skripts (unter /etc/init.d) zurückgegriffen werden, um Tomcat zu starten bzw. zu beenden. Diese Skripts können durch entsprechend berechtigte Nutzer, ggf. über die Verwendung des sudo Kommandos, ausgeführt werden. Somit ist die Nutzung von Shutdown-Port und -String nicht notwendig, um den Tomcat Servlet Container durch berechtigte Benutzer herunter zu fahren. 6.3.3 Logging Beim Produktiveinsatz des Jakarta Tomcat Servlet Containers ist zu überprüfen, welche LogInformationen für den Betrieb und zur Fehlersuche tatsächlich benötigt werden, um übermäßigen Ressourcen-Verbrauch hinsichtlich CPU-Leistung oder Speicherplatzbedarf zu vermeiden. Das Logging kann unterschieden werden nach • dem Logging auf der Ebene der Betriebszustände von Tomcat auf der Stufe der Tomcat-Engine, der virtuellen Hosts, etc.. Hierunter fällt z. B. das Hoch- oder Herunterfahren von Tomcat oder Webanwendungen, die Änderung der Konfiguration oder die Aktualisierung von Webanwendungen oder die Protokollierung von Fehlern zur Laufzeit. • dem Logging der Zugriffe auf die bereitgestellten Webanwendungen mit Informationen über den anfragenden Webclient, den Benutzer, die angefragte Webanwendungsressource, etc.. Während beim Debugging umfangreiche Log-Informationen zur Fehlersuche und -behebung sinnvoll sein können, sollten im Produktivsystem die debug Attribute auf 0 gesetzt sein und das AccessLogValve nur bei Bedarf eingesetzt werden. Weiterhin ist zu beachten, dass je nach Detaillierungsgrad der Protokollierung u. U. datenschutzrechtlich relevante Informationen gewonnen werden könnten. Insbesondere in Verbindung mit der Protokollie­ rung der Zugriffe, wobei z. B. Benutzernamen oder Cookie-Informationen festgehalten werden können sind datenschutzrechtliche Belange zu beachten. Daraus resultierend sind natürlich die Log-Dateien entsprechend zu behandeln. Maßnahmen für den Zugriffsschutz und Beschränkung der Verwendungs- / Auswertungsmöglichkeit sind dann auf jeden Fall umzusetzen. Wird das AccessLogValve eingesetzt, so werden wesentliche Informationen über den Zugriff auf Tomcat bereits mit den Log-Pattern pattern=“common“ erfasst, welche sich aus den folgenden Einzel-Log-Pattern kombiniert: %h: Host, auf dem der Web-Client (z. B. Webbrowser) läuft Seite 179 (von 187) Bundesamt für Sicherheit in der Informationstechnik Empfehlungen und Maßnahmen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers %l: Entfernter logischer Benutzername per identd ermittelt (immer „-“) %u: Authentisierter entfernter Benutzername, ansonsten „-“ %t: Datum und Uhrzeit im Common Log Format %r: Erste Zeile der HTTP Anfrage (HTTP Methode und URI) %s: HTTP Status Code %b: Zahl der zurückgeschickten Bytes (ohne HTTP Header), „-“ für 0 Bytes Wird das Log-Pattern pattern=“combined“ selektiert, so werden zusätzlich die Werte Referer und User-Agent des HTTP Headers protokolliert, wobei die zum Wert Referer gespeicherten Informationen für den Datenschutz relevante Inhalte umfassen könnte, wie beispielsweise in der URL des vorigen Zugriffs eingebettete Authentisierungsinformationen. Erfolgreiche bzw. fehlgeschlagene Zugriffe werden unterscheidbar durch den HTTP Status Code protokolliert. Zur Vermeidung von Speicherplatzüberläufen sollten ggf. angelegte Log-Dateien in den üblichen logrotate-Mechanismus einbezogen sowie nach einer gewissen Speicherzeit, üblicherweise in der Größenordnung von Tagen bis Wochen und ggf. nach einer vorherigen Archivierung, von den Systemen gelöscht werden (siehe auch [IT-GSHB]). Datenschutzrechliche Vorgaben müssen hierbei ggf. beachtet werden. 6.3.4 Manager und Admin Webanwendungen Sofern die manager bzw. admin Webanwendungen zur Administration von Tomcat verwen­ det werden, sollten diese zur Vermeidung von unerwünschten Zugriffen, die die Gefahr einer Manipulation der Konfiguration bergen, durch eine Filterung der berechtigten RemoteAdressen beim Zugriff auf diese Webanwendungen geschützt werden. Hierzu wird ein RemoteAddrValve in den zu den Applikationen gehörigen Konfigurationsdateien $CATALINA_HOME/conf/Catalina/localhost/manager.xml bzw. $CATALINA_HOME/conf/Catalina/localhost/admin.xml eingefügt: <Valve className=“org.apache.catalina.valves.RemoteAddrValve“ allow=“127.0.0.1,192.168.*.*“ /> Hierbei sind unter allow die für den Zugriff zugelassenen Adressen entsprechend anzupassen. Hierin sind durch Kommata getrennte Listeneinträge mit IP-Adressen, ggf. mit Wildcard-Zeichen einzufügen. Die Konfiguration entsprechender URL-Sperrlisten im vorgelagerten Apache-Webserver (Anwendungsszenarien 2 – 6) reichen, falls diese überhaupt aktiviert sind, unter Umständen nicht aus, wenn ein Direktzugriffe über den HTTP(S)-Connector von Tomcat beispielsweise aus dem lokalen Netzwerk heraus möglich ist. Werden diese beiden Administrationswerkzeuge überhaupt nicht verwendet, so sollten sie aus Sicherheitsgründen nicht installiert sein. Bundesamt für Sicherheit in der Informationstechnik Seite 180 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Empfehlungen und Maßnahmen Hinweis: Wird zur Administration der Tomcat-Konfiguration die admin Webanwendung verwendet, so gehen eventuell manuell in die Konfigurationsdateien eingetragene XMLKommentare verloren. 6.3.5 Zugriffsbeschränkungen Eine Festlegung von Beschränkungen bezüglich der für Zugriffe auf den Tomcat-Server oder dessen Webanwendungen freigegebenen oder gesperrten Hosts, Web-Domänen oder Subnetze kann in der Konfigurationsdatei $CATALINA_HOME/conf/server.xml vorgenommen werden. Dies geschieht unter Verwendung des RemoteAddrValve, mittels IPAdressen oder des RemoteHostValve, mithilfe von Host- oder (Sub-)Domänennamen. Bei Nutzung von Wildcard-Characters ist die teilweise von der üblichen Shell-Syntax abweichende Verwendung zu beachten, die von der Nutzung der Jakarta Regexp Bibliothek [Jakarta Regexp] bei der Analyse der IP-Adressen oder Host-Namen herrührt. Bei der Verwendung von RemoteHostValve ist ein funktionsfähiges Reverse DNS Lookup zur Gewinnung des Hostnamens aus der IP-Adresse des die Anfrage stellenden Webclients zwingend erforderlich, möchte man keine Sicherheits- oder Verfügbarkeitsprobleme riskieren. Ist eine Namensauflösung zur vorliegenden IP-Adresse nicht möglich, so greifen die Default-Regeln: • bei den deny Regeln: Alle Anfragen außer von den in den deny Regeln genannten Hosts bzw. Domänen werden beantwortet. Dies kann zu einer Beantwortung von Anfragen führen, obwohl der der IP-Adresse zugeordnete Host- oder Domänenname in der deny Regel für einen Zugriff auf die Web-Ressourcen nicht freigegeben ist und birgt somit ein potenzielles Sicherheitsrisiko. • bei den allow Regeln: Alle Anfragen außer den in den allow Regeln genannten Hosts bzw. Domänen werden abgewiesen. Dies kann zu einer Abweisung von Anfragen führen, obwohl der der IP-Adresse zugeordnete Host- oder Domänenname in der allow Regel freigegeben ist. In diesem Fall wäre der Web-Service für Zugriffe nicht verfügbar. Für einen sicheren Betrieb sollte also ein lokaler DNS-Server zur Verfügung stehen, um in jedem Fall ein Reverse DNS Lookup zu ermöglichen, der zumindest die Namensauflösung der in den deny oder allow Regeln des RemoteHostValves vorkommenden Host- oder Domänennamen durch ein Caching erlaubt, selbst wenn die im Internet befindlichen DNSServer temporär nicht erreichbar sein sollten. In der Konfigurationsdatei WEB-INF/web.xml einer jeden Webanwendung besteht die Möglichkeit zur Anforderung einer Authentisierung beim Zugriff auf einzelne Teile oder die gesamten der Webanwendungen, ggf. auch noch mit Beschränkung der Anforderung der Authentisierung auf die Nutzung einzelner HTTP-Zugriffsmethoden, wie GET, HEAD, PUT, POST oder DELETE mit der <http-method> Direktive. Hierbei ist zu beachten, dass in dem Fall für nicht genannte HTTP-Zugriffsmethoden keine Authentisierung erforderlich ist und diese nicht etwa ganz gesperrt sind. 6.3.6 Tests der Konfiguration Anwendungen mit vielfältigen Konfigurationseinstellungen wie Apache oder Tomcat bieten erfahrungsgemäß Raum für irrtümliche Fehlkonfigurationen. Zurückgewiesene aber erlaubte Zugriffe befugter Benutzer werden bekanntlich schnell genug geprüft und bei Zurückweisung Seite 181 (von 187) Bundesamt für Sicherheit in der Informationstechnik Empfehlungen und Maßnahmen Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers gemeldet. Daher ist besonders zu testen, was zurückgewiesen werden soll. Besonders Ausschlussregeln (z. B. zurückzuweisende IP-Adressen oder schwache Verschlüsselungs­ algorithmen) sollten dabei getestet werden. Ansonsten wiegt man sich in Scheinsicherheit. 6.3.7 Verschlüsselte Verbindung (SSL) Zum Schutz der Kommunikation zwischen dem Webbrowser und dem Webserver kann eine Nutzung der SSL-Funktionen des Apache Webservers wie Ent- / Verschlüsselung sowie ggf. Authentisierung bei unverschlüsselter Verbindung Apache Webserver / Connector Modul mit Tomcat auf der lokalen Plattform erfolgen. Wird Tomcat als Standalone Webserver verwendet (Szenario 1 in [Tomcat Fein.]), so besteht auch hier die Möglichkeit der Verwendung von verschlüsselten Verbindungen mit dessen HTTPS-Connector. Entsprechende Konfigurationen sind in der $CATALINA_HOME/conf/server.xml Datei vorzunehmen. Es sind dies die Bereitstellung eines <Connector>s mit der Deklaration der Attribute scheme="https" secure="true" sslProtocol="TLS" keystoreFile="conf/.keystore" keystorePass="<passwort>"> sowie die Installation eines Server-Zertifikats zur Identifikation des Tomcat Servers im Webbrowser des Nutzers. Die Installation des, ggf. von einer Certification Authority signierten, Server-Zertifikats in das angegebene keystoreFile erfolgt mit dem Java-Werkzeug keytool. Wird die SSL-Verbindung zusammen mit CLIENT-CERT Authentisierung verwendet, so ist zusätzlich, damit eine Client-Zertifikatprüfung erfolgen kann, das CA-Zertifikat der für die Signatur der Client-Zertifikate verantwortlichen Certification Authority (CA) einzustellen. Dies erfolgt wiederum mit dem Java-Werkzeug keytool in den • globalen JAVA-Zertifikatspeicher ($JAVA_HOME/jre/lib/security/cacerts) bzw. in den • Tomcat-Zertifikatspeicher, der mit den zusätzlichen Optionen truststoreFile und ggf. dem dafür benötigten Passwort unter truststorePass in der <Connector>-Deklaration der Konfigurationsdatei $CATALINA_HOME/conf/server.xml spezifiziert wird. Weiterhin ist zu berücksichtigen, dass ohne weitere Maßnahmen die Authentisierungsinfor­ mationen bei der Nutzung von JDBC Realm- bzw. JNDI Realm-basierter Authentisierung im Klartext übermittelt werden können. Dies kommt zum Tragen: • bei Verwendung des HTTP-Connectors (Anwendungsszenario 1 aus [Tomcat Fein.]) zwischen Tomcat und der Datenbank bzw. dem LDAP-Server, • bei Verwendung des AJP-Connectors (Anwendungsszenarien 2 - 6 aus [Tomcat Fein.]) darüber hinaus auch zwischen Apache / mod_jk und Tomcat, Bundesamt für Sicherheit in der Informationstechnik Seite 182 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers • Empfehlungen und Maßnahmen wenn zwischen dem Web-Client (Browser) und dem Apache Webserver (bei Nutzung des AJP-Connectors) bzw. dem Jakarta Tomcat Servlet Container (bei direkter Nutzung des HTTP-Connectors) kein HTTPS verwendet wird. 6.3.8 Anbindung einer Datenbank per JDBC Wird Tomcat zur Authentisierung von Benutzeranfragen per JDBC mit einer Datenbank die die benötigten Informationen wie Benutzernamen, Passworte, Rollenzuordnungen, etc. enthält verbunden, so besteht bei Nutzung eines gültigen in der Datenbank abgelegten Benutzernamens das Problem einer unverschlüsselten Übertragung von Referenzpass­ worten aus der Datenbank zur Authentisierung in Tomcat. Die Informationen können bei der Übermittlung zwischen Datenbank und Tomcat im Netzwerkverkehr mitgelesen werden, was zum Ausspionieren von Benutzernamen und den zugehörigen Passworten missbraucht werden kann. Zur Abhilfe sollten die in Abschnitt 6.1.5 gegebenen Hinweise besondere Berücksichtigung finden. 6.3.9 Anbindung einer Datenbank per JNDI Wird Tomcat zur Authentisierung von Benutzeranfragen per JNDI mit einer LDAP-Datenbank verbunden, so erfolgt die Übertragung des vom Benutzer verwendeten Benutzernamens und des zugehörigen Passwortes an den LDAP-Server zur Durchführung der Authentisierung unverschlüsselt. Diese Informationen können bei der Übermittlung zwischen Tomcat und LDAP-Server im Netzwerkverkehr mitgelesen werden, was zur Erlangung von Benutzer­ namen und den zugehörigen Passworten missbraucht werden kann. Auch hier sollten zur Abhilfe die in Abschnitt 6.1.5 gegebenen Hinweise besondere Berück­ sichtigung finden 6.3.10 Single-Sign-On In Verbindung mit aktiviertem Single-Sign-On (SSO-Valve) wird, gewissermaßen nach dem Prinzip „eine Rolle – eine Authentisierungsmethode“, zur Erzielung einer möglichst hohen Sicherheit empfohlen, eine Vermischung von unterschiedlichen Authentisierungsmethoden für einzelne Rollen zu vermeiden. Dies bedeutet, dass beispielsweise auf die für die Rolle roleA freigegebenen Webanwendungen app1 und app2 nicht über BASIC-Authentisierung (app1) und CLIENTCERT-Authentisierung (app2) zugegriffen werden können soll, da ansonsten das schwächere der beiden Authentisierungsverfahren (BASIC-Authentisierung) für beide Anwendungen genutzt wird. Hierbei würde zuerst eine Anmeldung an app1 per HTTPAuthentisierung und anschließender Wechsel zu app2 erfolgen, die wegen SSO dann ohne weitere Authentisierung ist. Das Sicherheitsniveau der Gesamtanwendung würde somit auf das der schwächsten Authentikation reduziert. Seite 183 (von 187) Bundesamt für Sicherheit in der Informationstechnik Weitere Punkte / Bugs / Verbesserungsmöglichkeiten Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers 7. Weitere Punkte / Bugs / Verbesserungsmöglichkeiten • Spracheinstellungen – Loginformationen: Die Logdaten werden in der vorliegenden Installation (Standard-Spracheinstellung: Deutsch) z. T. gemischt Deutsch und Englisch aufgezeichnet, was evtl. zu Problemen beim Suchen nach Textmustern für die Bewertung der Logeinträge führen könnte. • Verbesserung der Beschreibung der Tomcat Dokumentation im Hinblick auf die CLIENT-CERT Authentisierung, ggf. aus den hier gewonnenen Ergebnissen. Folgende Fragen sollten dort beantwortet sein: wie müssen die Zertifikate beschaffen sein, wo sind die CA-Zertifikate zur Prüfung der Client-Zertifikate zu installieren, wie erfolgt die Rollenzuordnung zwischen DN (Distinguished Name) im Zertifikat und einer Rolle für den Zugriff auf eine Tomcat-Webanwendung • Korrektur der Fehler bzgl. der Optionen zu SSL und TLS (s. T44-T46) und Verbesserung der diesbezüglichen Auswahlmöglichkeiten in der Dokumentation. Bundesamt für Sicherheit in der Informationstechnik Seite 184 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Abkürzungen 8. Abkürzungen ACL AJP API APR CA CD CPU DBMS DNS DoS DVD GB HTTP IPsec JAAS JDBC JNDI JSP JSSE LDAP LCD MB NAT OOP SCSI SDK SGID SSH SSL SSO SQL SUID TLS VM VPN XML Seite 185 (von 187) Access Control List Apache JServ Protocol Application Programming Interface Apache Portable Runtime Certification Authority Compact Disc Central Processing Unit DataBase Management System Domain Name Service Denial of Service Digital Versatile Disc Giga Byte HyperText Transfer Protocol Internet Protocol Security Java Authentication and Authorization Service Java Database Connectivity Java Naming and Directory Interface Java Server Pages Java Secure Socket Extension Lightweight Directory Access Protocol Liquid Crystal Display Mega Byte Network Address Translation objektorientierte Programmierung Small Computer System Interface Software Development Kit Set Group Identity Secure Shell Secure Sockets Layer Single Sign On Structured Query Language Set User Identity Transport Layer Security Virtual Machine Virtual Private Network EXtended Markup Language Bundesamt für Sicherheit in der Informationstechnik Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Wichtige Shell-Variablen, Verzeichnisse und Dateien 9. Wichtige Shell-Variablen, Verzeichnisse und Dateien Um eine verbesserte Lesbarkeit bei der Bezeichnung von Dateien und Verzeichnissen zu erhalten, wird im Text eine Notation unter Verwendung von Shell-Variablen benutzt. Hiermit lässt sich außerdem eine bessere Übertragbarkeit der Angaben in andere Systemumgebungen realisieren, die die Softwarepakete an anderer Stelle installiert haben. Tomcat (Version 5.5.9) $CATALINA_HOME $CATALINA_HOME/bin/catalina.sh $CATALINA_HOME/conf/server.xml $CATALINA_HOME/conf/tomcat-users.xml $CATALINA_HOME/logs $CATALINA_HOME/webapps $CATALINA_HOME/conf/workers.properties Wurzelverzeichnis der Tomcat-Installation (Testumgebung: /opt/jakarta-tomcat-5.5.9) Tomcat Startscript Tomcat Konfiguration Tomcat Benutzerdefinition (Memory Realm) Tomcat Log-Verzeichnis Verzeichnis der Tomcat Webanwendungen Konfiguration der AJP-Schnittstelle zwischen Apache und Tomcat Apache Webserver (Version 2.0.54) $HTTPD_HOME $HTTPD_HOME/bin/apachectl $HTTPD_HOME/conf/httpd.conf $HTTPD_HOME/conf/ssl.conf $HTTPD_HOME/conf/workers.properties Wurzelverzeichnis der Apache-Installation, äquivalent zur an manchen Stellen verwendeten Variable $APACHE_INSTALL (Testumgebung: /opt/httpd-2.0.54) Apache Startscript Apache Konfiguration SSL-Konfiguration Apache Konfiguration der AJP-Schnittstelle zwischen Apache und Tomcat (Soft-Link auf die gleichnamige Konfigurationsdatei in der TomcatInstallation, s. o.) JAVA SDK (Version 1.5.0_05) $JAVA_HOME $JRE_HOME $JAVA_HOME/jre/lib/security/cacerts Bundesamt für Sicherheit in der Informationstechnik Wurzelverzeichnis der Java-SDK-Installation (Testumgebung: /opt/jdk1.5.0_05) Wurzelverzeichnis der Java-RuntimeEnvironment Installation ($JAVA_HOME/jre) Datei mit den Zertifikaten der Certification Authorities (CAs) Seite 186 (von 187) Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers Referenzen 10. Referenzen [Barret] Daniel J. Barret, Richard E. Silverman, SSH: The Secure Shell – The Definitive Guide, O'Reilly, 2001 [BSI GSHB] IT-Grundschutzhandbuch, Bundesamt für Sicherheit in der Informationstechnik, 2004, http://www.bsi.bund.de/gshb/index.htm [Darwin] Ian E. Darwin, Jason Brittain, Tomcat – The Definitive Guide, OReilly, Inc., 2003 [Moczar] Lajos Moczar, Tomcat 5 – Einsatz in Unternehmensanwendungen mit JSP und Servlets, Addison Wesley, 2005 [McCarty] Bill McCarty, SELinux – NSA's OpenSource Security Enhanced Linux, O'Reilly, 2004 [Tomcat Fein.] Sicherheitsuntersuchung des Apache Jakarta Tomcat Servlet Containers – Feinkonzept, 2005 [Viega] John Viega, Matt Messier, Pravir Chandra, Network Security with OpenSSL, O'Reilly, 2002 10.1 Web-Referenzen (Stand 30.11.2005) [Apache mod_log] Apache Module mod_log_config Documentation, http://httpd.apache.org/docs/2.0/mod/mod_log_config.html [Debian SELinux] SELinux for Distributions – Debian Distribution, http://selinux.sourceforge.net/distros/debian.php3 [Jakarta Regexp] Jakarta Regexp 1.4 API, Class RE, http://jakarta.apache.org/regexp/apidocs/org/apache/regexp/RE.html [NSA SELinux] National Security Agency – Central Security Service, Security-Enhanced Linux, http://www.nsa.gov/selinux/ [RFC2401] IETF, RFC 2401 Security Architecture for the Internet Protocol, ftp://ftp.rfc-editor.org/in-notes/rfc2401.txt, 1998 [RFC2518] IETF, RFC 2518 HTTP Extensions for Distributed Authoring – WEBDAV, ftp://ftp.rfc-editor.org/in-notes/rfc2518.txt, 1999 [Sun JSP] Sun Microsystems, Java Server Pages Specification (Version 2.0), http://java.sun.com/products/jsp/docs.html [Sun Servlets] Sun Microsystems, Java Servlets Specification (Version 2.4), http://java.sun.com/products/servlet/reference/api/index.html [ISIS MTT] Core Specification (Version 1.1), http://www.teletrust.de/fileadmin/files/ISISMTT_Core_Specification_v1.1.pdf Seite 187 (von 187) Bundesamt für Sicherheit in der Informationstechnik
