Methoden zur Sicherheitsanalyse webbasierter

Transkript

1 Fachhochschule Köln Cologne University of Applied Sciences Methoden zur Sicherheitsanalyse webbasierter Anwendungen Analyse bestehender Werkzeuge, sowie Modellierung und Entwicklung neuartiger Konzepte MASTERTHESIS Wolfgang Moser Matrikelnr.: Institut für Informatik Fachhochschule Köln, Campus Gummersbach Erstprüfer: Prof. Dr. Karsch Zweitprüfer: Prof. Dr. Stenzel Externer Betreuer: Dipl.-Inf. Randolf Skerka 7. Dezember 2006

2 2 Vorwort Die vorliegende Masterthesis wurde im Zeitraum Juni bis November 2006 bei der Firma SRC Security Research & Consulting GmbH in Kooperation mit dem Labor für Kommunikationstechnik und Datensicherheit der Fachhochschule Köln vorbereitet und angefertigt. Mein besonderer Dank gilt meinen Betreuern Prof. Dr. Stefan Karsch und Dipl.-Inf. Randolf Skerka für die wissenschaftliche und fachliche Betreuung, sowie meinem langjährigen Mentor Prof. Dr. Horst Stenzel. Weiterhin möchte ich die Gelegenheit nutzen, meinen Teammitgliedern im Bereich Sicherheitsmanagement und Netzwerksicherheit bei SRC, Christopher Kristes, Daniel Jedecke, Manuel Atug und Holger von Rhein meinen Dank auszusprechen für die vielen anregenden Gespräche, Ideen und Hinweise, die zu dieser Arbeit beitrugen. Herausstellen möchte ich die emotionale Unterstützung durch Verwandte, Freunde und Nachbarn, insbesondere meiner Schwester Jana Moser, Dr. Volker Brückner, Andreas Zwicker und Christian Wurst. Erwähnen möchte ich gerne auch Karl-Heinz Kerschgens und Christa Brennig, die auf besondere Weise dazu beitrugen, dass ich meinen Weg in Richtung eines Informatikstudiums eingeschlagen habe. Ich danke weiterhin meiner Familie, die mir so viel Unterstützung während meiner Studienzeiten zuteil werden ließen, Gertrud und Peter Brennig, Monika und Rolf Moser, meinem Bruder Jonas, sowie Lissy, Ingo und Jörg Grosz. Ein herzliches Dankeschön auch an die Familien Schilling und Euchler, Edvard Pavlic, Volker Stamm, Frank Bruch, Andreas Klein, Iwona und Jörg Luther, Frank Panno, Mario Linke, Beate Breiderhoff, Norbert Gesper, Karl-Heinz Kohlenbeck, Johannes Josef Bungart, Frauke Voss, Martin Wisskirchen, Ina und Boris Hirschmann, Petra Riemer, Beate Otrzonsek und Guido Münster für Rat, Zuspruch und Freundschaft. Nicht vergessen mit einzubeziehen möchte ich alle die Menschen, die insbesondere während meiner Studienzeiten mit ihrer (Ein-) Wirkung auf mich irgendwie zum Gelingen dieser Arbeit beigetragen haben, allen Kommilitonen, Professoren und Mitarbeitern beziehungsweise ehemaligen Kollegen an der Fakultät für Informatik der Fachhochschule Köln.

3 3 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Einleitung Ausgangslage Vorstellung SRC Kunden und Kundenumfeld im Bereich Netzwerksicherheit Bei Kunden eingesetzte Softwarearchitekturen im Überblick Bisherige Vorgehensweise: manuelle Überprüfung der Ergebnisse automatisierter (Vor-) Tests Vulnerability-Scan Penetrationstest Bei SRC eingesetzte Werkzeuge für Vulnerability-Scans Manuelle Nacharbeiten bei einem Vulnerability-Scan Zielsetzung der Arbeit Grundlagen Hypertext Transfer Protokoll (HTTP) Erweiterungen des HTTP-Protokolls Session-Management und clientseitige Speicherung von Zustandsdaten (Cookies) Protokollerweiterungen für Inhaltsbearbeitung und Versionskontrolle, WebDAV Weitere in Web-Anwendungen genutzte Protokolle und Formate außerhalb HTTP Hypertext Markup Language (HTML) Structured Query Language (SQL) Abfragesprachen für weitere Datenspeichersysteme Leightweight Directory Access Protocol, Abfragesyntax und Filter Andere Datenbankmanagementsysteme (DBMS) und deren jeweilige Abfragesyntax XML-basierte Datenbanken und Abfragesprachen bzw. Adressierungsmethoden Verallgemeinerte Struktur von web-basierten Anwendungen Das Open Web Application Security Project (OWASP) Projekte des OWASP Liste der 10 kritischsten Sicherheitslücken in Web- Anwendungen Zum OWASP vergleichbare Institutionen Payment Card Industry Data Security Standard (PCI-DSS) Ziele des PCI-DSS Gegenüberstellungen zu den Anforderungen des OWASP Bekannte Schwachstellen und Schwachstellenklassen Fehlende Parameterprüfung

4 Command Execution Top-1-Ziel: Ausführung von vom Angreifer frei bestimmbarer Semantik Funktionsweise und Maßnahmen zur Vermeidung dieser Schwäche Konkrete Arten von Command Execution Clientseitige Angriffe, Cross-Site-Scripting Ziel eines Angreifers Funktionsweise von XSS XSS-Varianten Generische XSS-Angriffsarten SQL-Injection Angriffsziele in Datenbanken Auffinden von anfälligen Webseiten oder -applikationen Systematik zur Datenbank-Analyse Blind-SQL-Injection Buffer-Overflow Angriffsflächen web-basierter Anwendungen Angriffsziele Funktionsweise von Buffer-Overflow-Attacken Durchführung von Buffer-Overflow-Attacken Weitere Angriffsarten des OWASP-Top-10-Kataloges Preisgabe geschützter Informationen (Information Disclosure) Angriffe auf die Anwendungslogik Organisatorische Maßnahmen Vorstellung und Modellierung eines einfachen Attack Trees Attack Trees nach Bruce Schneier Aufbau von Attack Trees Bewertung von Gegenmaßnahmen Definition eines Attack Trees für web-basierte Anwendungen Festlegung des Angriffszieles Attack Tree: Brückenkopf in der DMZ Untersuchungsmethoden und Anforderungen an Werkzeuge zum automatischen Security-Test von web-basierten Anwendungen Schwachstellen-Scanner für nicht web-basierte Anwendungen Spezielle Anforderungen an Scanner von web-basierten Anwendungen Charakteristika web-basierter Anwendungen Konsequenz für automatische Scanner Grundarbeitsprinzip eines Webapplikations-Scanners Gegenüberstellung der Anforderungen an Scanner webbasierter Anwendungen mit Scannern für nicht web-basierte Anwendungen Ablauf einer Analyse Konkrete Aufgaben Informationsgewinnung und Planung der Untersuchung Durch die Software Qualys abgedeckte Vulnerability-Scans Intensive Begutachtung einzelner Sicherheits-Aspekte Begutachtung von Geschäfts- und Systemlogiken Der Prozess der Durchführung des manuellen Security-Scans. 84

5 Präsentation und Aufbereitung der Ergebnisse Hauptschwierigkeiten bei der Anwendung automatischer Schwachstellen-Scanner Generelle Grenzen automatisierter Tests Dynamische clientseitige Webseiten-Inhalte Menschliche Interpretationsfähigkeit Punkte des OWASP-Top-10-Katalog mit eingeschränkten Automatisierungsmöglichkeiten Domäne existierender Werkzeuge: Gewinnung nützlicher Informationen Analyse bestehender Konzepte Informationsgewinnung Lexikalische Auswertung von URLs nach Dateinamen und -endungen Auswertungen bei SSL/TLS gesicherten Verbindungen Inhaltsanalyse von Seiteninhalten mit auf regulären Ausdrücken basierenden Suchmustern Fehlverhalten bei gehärteten Web-Anwendungen Adaption von nicht einschlägig sicherheitsorientierten Testverfahren Fingerprinting als spezialisierte Informationsgewinnung OS-Fingerprinting HTTP-Fingerprinting SSL/TLS-Fingerprinting Backend-Fingerprinting Konzept für einen generischen Fingerprinter Vorgehen bei der Erstellung der notwendigen Signaturen Verfahren zur Entdeckung von Cross-Site-Scripting-Lücken Aktuelle verfügbare Werkzeuge zur Detektion von XSS- bzw. HTML-Injection-Schwachstellen Strategien für aufeinander aufbauende Tests für reflektive HTML-Injektion Brute-Force-Tests mit aggregierten Teststrings Erweiterte Techniken zum Auffinden unsichtbarer Lücken Detektion von stored XSS-Schwachstellen Buffer-Overflow-Tests Aktuelle Situation von Blackbox-Testtools zur Penetrationsanalyse Organisatorische Schwierigkeiten bei der Verifikation von Buffer-Overflows Ansätze für automatisierte Penetrationstests Code-Injektion, speziell SQL-Injektion Einfache SQL-Injektion Verfeinerungsmöglichkeiten der Detektion Quoting, Kodierung und Verifikation Blind SQL-Injection Error Handling Denial of Service

6 Zusammenfassung Software-Architektur für ein integriertes Werkzeug zur Analyse von web-basierten Anwendungen Zielsetzung für das Testframework Verwendete Werkzeuge, Komponenten, Bibliotheken und weitere Frameworks HtmlUnit, Aufbau und Vorteile durch dessen Verwendung Eigenschaften und Vorteile Nachteile Erweiterung von HtmlUnit für Penetrationstest-Zwecke Anforderungen Funktion und Aufbau von HttpWebConnection Strategie für das Einbringen eigener Logik in das HtmlUnit-Framework Erweiterung des Unterbrecherkonzeptes Realisierung eines universellen Plugin-Konzeptes Maßnahmen zur Unterstützung von gesicherten Verbindungen Das Hauptframework Konfiguration des über HtmlUnit simulierten Web-Browsers Datenstruktur zur Traversierung von Webseiten Behandlung einer aus der Queue entnommenen URL Abstrakte Hilfsstruktur Spiderable Aufruf der Plugins der ersten Hierarchieebene Die Entwicklung von Plugins Implementierung eines XSS-Penetrationstesters Zweistufige Struktur: Zunächst Test auf Reflexionen von Eingabestrings Plugins rufen Plugins auf: Der eigentliche XSS-Test Weitere mögliche Penetrationstests Verbesserungspotenziale Reflexion der Ergebnisse dieser Arbeit Zusammenfassung Fazit Bewertung Ausblick Literatur A. Statische Klassendiagramme in UML-1.1-Notation B. Datenträger

7 7 Abbildungsverzeichnis 1 Firmelogo SRC Gesellschafter der SRC Security & Research GmbH Corporate-Identity-Symbol SRC Beispiel einer HTTP-POST-Anfrage Beispiel einer HTTP-Antwort (nur Kopfzeilen) SOAP über HTTP oder andere Protokolle, siehe [76] Logo des OWASP Logo des PCI Security Standards Council Angriffsklassen web-basierter Anwendungen Szenario zum Diebstahl von Cookies mittels XSS Übergeordnete Klassifizierung von Angriffsflächen mit Zuordnungsüberschneidungen Abtrennung einer DMZ mit zwei Netzfiltern/Firewalls Schaffung einer DMZ mit einem 3-Wege-Netzfilter/Firewall Attack Tree: Installation einer Hintertür auf einem Rechner in der DMZ Bewerteter Attack Tree: Installation einer DMZ-Hintertür Seltener Fehlerzustand einer bekannten Web-Auktionsplattform unter hoher Last Nachbehandelter Fehlerzustand einer bekannten Web-Auktionsplattform Schematische Darstellung einer untergliederten Plugin-Technik Aggregation des HTTP-Connectors im HTMLUNIT-Framework Aufbau eines alle Zertifikate akzeptierenden Trustmanagers Beispielimplementierung für eine zweistufige Plugin-Hierarchie UML-1.1-Diagramm des Plugin-Ladesystems UML-1.1-Diagramm der Erweiterungen an HTMLUnit UML-1.1-Diagramm des Crawler-Frameworks mit Referenzen auf die vorherigen Diagramme in Abbildungen 22 und 23(grau eingefärbte Elemente) Tabellenverzeichnis 1 Verschiedene Einrahmung- und Kodierungsformen zur Verifikation einer SQL-Injection-Schwachstelle

8 8 Zusammenfassung Steigender Bedarf an Penetrationstests web-basierter Anwendungen entsteht durch restriktivere Zulassungsvoraussetzungen seitens der Kreditkartengesellschaften und steigendem öffentlichen Druck auf Geldinstitute wegen der wirtschaftlichen Folgen beispielsweise durch Phishing-Attacken deren Nutzer. Ziel für einen Dienstleister in diesem wachsenden Markt für Penetrationstests ist es, durch Optimierung seiner internen Prozesse die Wettbewerbsfähigkeit langfristig zu sichern. Nach derzeitigem Stand der Technik sind Penetrationstests nur mit intensiver Steuerung durch erfahrene IT-Security-Berater sachgerecht durchführbar. In dieser Masterthesis werden bestehende Methoden und Konzepte zur Schwachstellenanalyse web-basierter Anwendungen untersucht und daraus neuartige Konzepte erarbeitet und diskutiert. Das Ziel ist eine Erhöhung des allgemeinen Automatisierungsgrades, welches durch eine Steigerung der Effektivität bestehender automatischer Methoden und eine bessere Integration verschiedener Verfahren erreicht wird. Die Arbeit kann in den Themenkomplex Qualitätssicherung (Software) Blackbox-Test Penetrationtesting eingeordnet werden. Abstract Increasing demand on penetration tests derives from more restrictive admission requirements on the part of the credit card corporations and increasing public pressure onto the financial institutions because of the economic consequences for example through phishing attacks at their users. The objective for a service provider in this growing market for penetration testing is to ensure his competitiveness through the improvement of his internal processes. At the current state-of-the-art, penetration tests are only doable properly by intensive control by an experienced IT security consultant. With this Master s thesis existing methods and concepts to vulnerability analyses of web based applications are explored. Subsequently new concepts are developed and discussed. The objective is to increase the level of automation in general which is reached by an increase of the effectivity of existing automatic methods and by a better integration of several procedures. This thesis can be classified into the complex of topics: quality assurance (software) black box testing penetration testing.

9 9 1. Einleitung Softwarequalität wird üblicherweise 1 unter dem Motto der Funktionalität und Benutzbarkeit eines Werkzeuges zur Verarbeitung elektronischer Daten verstanden. Darin fließen verschiedene Tests ein, die unter anderem folgerichtiges Verhalten auf Eingabedaten prüfen, oben angeführte Benutzbarkeit (Usability Tests) untersuchen oder auf die Interaktionsfähigkeit abzielen (Mensch-Computer-Interaktion). Die im Rahmen der Qualitätssicherung zumeist gestellte Frage lautet: Macht die Software das, was sie laut Spezifikation machen soll? Untersuchungsmethoden des Softwaretestens werden grob in die Klassen Whitebox- und Blackboxtesting unterteilt. Beim Whiteboxverfahren hat das Qualitätssicherungsteam Zugriff auf alle Quelldateien und Dokumente, die im Rahmen der Softwareerstellung angefallen sind. Mit verschiedenen Verifikationsmethoden können Fehler in Quellen und Spezifikationen aufgedeckt werden. Beim Blackboxtesting besteht die Aufgabe eher darin, das fertige Produkt aus Sicht des Anwenders zu betrachten. Zum einen ist auch hier eine Verifikation untersuchbar, wenn es um die grundsätzliche Anwendbarkeit geht. Als Beispiel sei die Erreichbarkeit aller Eingabemasken als ein Testziel genannt. Zum anderen wird beim Blackboxtesting aber auch versucht, das fertige Programm gezielt mit speziell präparierten Eingabewerten in einen Fehlerzustand zu zwingen, um auf dieses Weise bewertbare Qualitätsmängel aufzuzeigen. Ein ganz anderes Ziel wird beim so genannten Penetrationstest (auch: Pentesting) gestellt. Die Fragestellung hier lautet eher: Ist eine Software resistent gegen Angriffe, sie dazu zu bringen etwas zu tun, was sie nicht machen soll? Die generelle Schwierigkeit, Software widerstandsfähig gegen typische Angriffsmuster von Hackern zu gestalten, erwächst schon alleine aus dem Umstand, dass solcherart Anforderungen in Spezifikationen oft nicht klar ausformuliert werden können und sich Angreifer Lücken innerhalb der Spezifikation zu Nutze machen. Allgemeines Ziel sollte sein, Software nicht nur gegen bereits bekannte Angriffsmuster resistent zu halten, sondern möglichst so zu erstellen, dass auch zukünftige Verfeinerungen bestehender oder neuer Angriffsmuster möglichst unwirksam bleiben. Pentesting kann auch als sehr spezialisierte Form des Blackboxtesting verstanden werden. Ohne die genaue Programmlogik zu kennen oder Zugriff auf die Quellen der Software zu besitzen, versucht ein simulierter Angreifer das Verhalten des Programms zu manipulieren. Ziel ist es dabei, durch Variation von Eingabedaten ein Software-Verhalten herbeizuführen, welches 1 Für eine Übersicht über verschiedene Softwarequalitätsziele, siehe die Zusammenfassung der Norm ISO/IEC 9126 in [79]

10 10 für unerwünschte Folgeaktionen wie Einbruch, Diebstahl, Spionage oder Sabotage missbraucht werden könnte 2. In den folgenden Abschnitten wird der Rahmen für diese Arbeit definiert. Dazu wird in Abschnitt 1.1 die aktuelle Situation geschildert, die Ursprung der Motivation für diese Arbeit ist. In Abschnitt 1.2 wird das Unternehmen vorgestellt, welches den Projektrahmen bereit stellt, sowie in den Abschnitten 1.3 und 1.4 die Kunden des Unternehmens und dort eingesetzte Software. Abschnitt 1.5 gibt einen Überblick über die in diesem Unternehmen ablaufenden Prozesse, welche den Ausgangspunkt für die in Abschnitt 1.6 definierten konkreten Ziele definiert, die diese Arbeit erreichen soll Ausgangslage Pentesting als Dienstleistung der Informationstechnologie (IT) kann in anderen Ingenieurdisziplinen mit der Materialprüfung von der Sicherheit dienenden Produkten verglichen werden. Motorrad- und Fahrradhelme beispielsweise werden in Produktserien- und Chargentests gezielt normierten Zerstörungen zugeführt, um deren Widerstandsfähigkeit gegenüber äußeren Einwirkungen beurteilen zu können. Crashtests bei der Neuentwicklung von Fahrzeugen und auch bei späteren Veränderungen an der Fahrgastzelle gehören zum Standardtestprogramm, um die allgemeine Betriebstauglichkeit von Personentransportmitteln belegen zu können. Bei Anwendungen der IT-Welt steht als zu schützender Faktor aber weniger der Mensch im Vordergrund als vielmehr persönliche Daten von Menschen, Finanztransaktionen und andere virtuelle Werte wie Berechtigungs- und Zugangsmerkmale. Mit dem Erwachsenwerden des Internet seit Mitte der 1990 er Jahre und der flächendeckenden Etablierung von E-Commerce-Anwendungen sind im Schlepptau auch auf den Online-Handel spezialisierte (Daten-) Diebe, (Trick-) Betrüger, und das elektronische Äquivalent von Einbrechern und Räubern eingezogen; neben Hackern, deren Motivation sich aus Imageschäden der angegriffenen Betreiber ergibt oder aus Wettbewerben mit anderen Hackern und Hackergruppen. Seit dem Ende der 1990 er Jahre ist im Monatsrhythmus über öffentliche Nachrichten von Kredikartendaten-Diebstählen, Fälschung von Nachrichten, der Erschleichung von Zugangsberechtigungen für Einkaufsportale unter fremden Namen oder der gefälschten Authorisierung von Banktransaktionen zu lesen 3. In diesem für E-Commerce-Anbieter schwieriger werdenden Umfeld sehen sich insbesondere die zentralen Dienstleister im elektronischen Finanztransaktionsgeschehen verpflichtet, Maßstäbe zu definieren und durchzusetzen, 2 Im Kontrast zu dieser Ableitung siehe auch die Definition der Online-Enzyklopädie Wikipedia [73] 3 Zwei aktuelle Fälle Mitte 2006 dokumentieren [21] und [22]

11 11 die die Sicherheit aller an Finanztransaktionen beteiligten Systeme erhöhen sollen. Die großen Kredikartengesellschaften haben ökonomischerweise ein großes Interesse daran, dem letztendlichen Abnehmer und Nutznießer ihrer Dienstleistungen ein Umfeld zu schaffen, in dem er, der Kunde, gerne bereit ist auf elektronischen Wege einzukaufen und auch zu bezahlen. Im Rahmen der von den Kreditkartenunternehmen definierten Standards werden alle an der elektronischen Zahlungsabwicklung über Kreditkarten beteiligten Unternehmen und Dienstleister zu regelmäßigen Sicherheitsprüfungen verpflichtet. Diese Systemüberprüfungen und Security-Tests wiederum werden von akkreditierten Beratern und Prüfern durchgeführt. Das im Folgenden vorgestellte Unternehmen SRC Security Research & Consulting GmbH ist ein solcher Berater. In dieser Arbeit werden die Methoden zur Schwachstellenanalyse web-basierter Anwendungen beleuchtet und es werden neuartige Konzepte gesucht und diskutiert, um die Effektivität der eingesetzten Werkzeuge zu erhöhen. Damit einher gehend soll durch eine Erhöhung des Automatisierungsgrades gleichermaßen die Effizienz des gesamten Verfahrens verbessert werden. Zunächst werden in Kapitel 2 und 3 die notwendigen Grundlagen für diese Arbeit zusammengefasst beschrieben, verschiedene Penetrationstest-Techniken werden tiefer durchdringend erläutert. Kapitel 4 dient der Darstellung der Schritte zur Durchführung von Security-Scans (nach aktuellem Stand der Dinge), um in Kapitel 5 darauf aufbauend Verbesserungsvorschläge bzw. Konzepte für zukünftig zu erstellende, integrierte Werkzeuge diskutieren zu können. Kapitel 6 nimmt die Darstellung der Softwarearchitektur für ein mögliches solches zukünftiges Werkzeug auf, welches in seinen grundlegenden Funktionen bereits implementiert ist. In Kapitel 7 werden die Ergebnisse der Arbeit reflektiert und mögliche Aufgabenpakete für Folgearbeiten bereits grob umrissen Vorstellung SRC Die Gesellschaft SRC Security Research & Consulting GmbH (Firmenlogo bzw. Dachmarke siehe Abb.: 1) ist ein noch recht junges Beratungsunternehmen im deutschen IT-Markt. Sie wurde im Herbst 2000 als ein auf Abbildung 1. Firmelogo SRC Sicherheitsthemen spezialisiertes Unternehmen mit drei Hauptbereichen gegründet. SRC ist unter anderem mit der Pflege der kartengestützten Zahlungssysteme in Deutschland betraut, im Bereich der Netzwerksicherheit von MasterCard und Visa als Qualified Security Assessor anerkannt, sowie als Auditor bzw. Gutachter für Sicherheits-

12 12 Abbildung 2. Gesellschafter der SRC Security & Research GmbH untersuchungen nach Common Criteria (ISO 15408), IT-Grundschutz und IT-Managementsysteme nach ISO akkreditiert bzw. zertifiziert 4. Gesellschafter und Gründer der Firma SRC Security Research & Consulting GmbH sind zu gleichen Teilen die vier deutschen kreditwirtschaftlichen Verlage Deutscher Sparkassen Verlag GmbH (DSV) Stuttgart, Deutscher Genossenschafts-Verlag eg (DG-Verlag) Wiesbaden, Bank-Verlag GmbH mit Stammsitz in Köln und VÖB-ZVD Bank für Zahlungsverkehrsdienstleistungen GmbH aus Bonn (Abb.: 2). Alle vier Verlage zeichnen sich verallgemeinert dadurch aus, dass sie für die jeweiligen Verbände 5 und die darin organisierten Kreditinstitute zentralisiert Servicedienstleistungen übernehmen. Dazu gehört nicht nur das klassische Verlagsgeschäft mit der Erstellung von Druckmedien, Vordrucken und Formularen, sondern seit circa 1995 die Abwicklung von elektronischen Transaktionsgeschäften. Dies schließt den Betrieb und die Zertifizierung von Anlagen für die Abwicklung elektronischer, insbesondere chipkartengestützter Zahlungssysteme mit ein 6. Mit Bildung der gemeinsamen Tochter SRC bündeln die Gesellschafter spezielles Know-How zu allen Fragen der Sicherheit in der Informationstechnik und stellen ein unabhängiges Unternehmen auf der Leuchtturm als Inbegriff der Sicherheit der Seeschifffahrt wurde später als Artefakt im Rahmen der Corporate Identity des Unternehmens gewählt (siehe Abbildung: 3). Gleichermaßen unterstützt es die deutsche Kreditwirtschaft als Kompetenzzentrum in Fragen der IT-Sicherheit, ist als Unternehmensberater aber auch für jeden Kunden außerhalb der Kreditwirtschaft tätig. Zunehmende Relevanz 4 vgl. [18] 5 Dies sind in diesem Zusammenhang: der Deutscher Sparkassen- und Giroverband e. V., der Bundesverband der Deutschen Volksbanken und Raiffeisenbanken e. V., der Bundesverband deutscher Banken e. V. und der Bundesverband Öffentlicher Banken Deutschlands e. V., daneben gibt es weiterhin den Verband deutscher Pfandbriefbanken e. V., früher war dies der Verband deutscher Hypothekenbanken e. V. Alle fünf Verbände der deutschen Kreditinstitute wiederum sind im Zentralen Kreditausschuss (ZKA) organisiert, siehe [85]. 6 Dieser Überblick wurde aus den Selbstdarstellungen und Image-Broschüren der Unternehmen zusammengestellt, vergleiche mit [13],[15],[6],[68], sowie [58]

13 13 Abbildung 3. Corporate-Identity-Symbol SRC erhält dabei das von MasterCard und Visa ins Leben gerufene Programm SDP/AIS, in dessen Rahmen SRC als akkreditierter Partner und Auditor für E-Commerce-Händler in Sicherheitsfragen tätig wird 7. Mit einem Stammkapital von 1,0 Mio. Euro erwirtschaftete SRC im Jahr 2005 mit 42 Mitarbeitern einen Überschuss von 616 Tausend Euro. Die Unternehmensstruktur der Gesellschafter ist so, dass sich der DG-Verlag aus 1363 Mitgliedern zusammen setzt (Stand Ende 2005), die Gesellschafter des DSV bestehen aus 10 Sparkassen- und Giroverbänden, 4 Landesbanken und 2 Beteiligungsgesellschaften. Anteilseigner der VÖB-ZVD ist zu 75% die Deutsche Post AG während der Bank-Verlag eine 100%-ige Tochter des Bundesverbandes deutscher Banken (BdB) ist 8. Neben den vier Hauptgesellschaftern die mit jeweils 22,5% zu gleichen Teilen an SRC beteiligt sind, gibt es eine Mitarbeiterbeteiligungsgesellschaft MAB-GbR, die 10% der Unternehmensanteile trägt Kunden und Kundenumfeld im Bereich Netzwerksicherheit Entsprechend dem Aufbau der Gesellschafterstruktur der Firma SRC, entstammt ein wesentlicher Teil der Aufträge und Kunden für den Geschäftsbereich Netzwerksicherheit den vier in Abschnitt 1.2 aufgeführten Kreditverlagen und den darüber organisierten, sowie angegliederten Kreditinsti- 7 vgl. [18] 8 siehe [14, Seiten 27f, 42],[16, Seiten 28 und 31],[5], [12, Seiten 10 und 12] 9 vgl. [61]

14 14 tuten. Ein weiteres Aufgabenfeld mit hohem Wachstumspotenzial entsteht aus den Anforderungen des Payment Card Industry Data Security Standard (PCI-DSS). Dieser Standard ist ursprünglich eine Zusammenfassung von Eigenentwicklungen der beiden internationalen Kredikartenfirmen MasterCard Worldwide und Visa International. Mitte des Jahres 2006 haben sich weitere Kredikartenfirmen angeschlossen, American Express, Discover Financial Services und JCB, und sich im PCI Security Standards Council organisiert. Im September 2006 wurde Version 1.1 des PCI-DSS emittiert 10. Jeder Händler, der auf elektronischem Wege Kreditkartendaten verarbeitet, ist gefordert, die durch die Kreditkartengesellschaften auferlegten Sicherheitsstandards zu beachten. Über die Einhaltung der Maßnahmen sind regelmäßig qualifizierte Nachweise zu erbringen, andernfalls drohen Konventionalstrafen. Darüber hinaus sind auch Finanzdienstleister, die zwischen den Kreditkartenfirmen und den Händlern stehen, die sogenannten Payment Service Provider und Kreditkarten-Acquirer, durch den PCI-DSS verpflichtet. Finanzdienstleister werden anhand von Kriterien in Gruppen eingeteilt, die unterschiedliche hohe Sicherheitsziele erbringen und nachweisen sollen. Um den Nachweis über die Einhaltung der Sicherheitsziele erbingen zu können, um Händler und Dienstleister bei der (Um-) Gestaltung ihrer Sytemlandschaft beraten zu können, sollen unabhänge Dritte als Sicherheitsberater und -auditoren tätig werden. Die Firma SRC ist ein von MasterCard und Visa akkreditierter Partner zur Durchführung von Security Audits, Security Scans und der Auswertung der im Rahmen des Sicherheitsprozesses anfallenden Fragebögen 11. Die meisten der im Rahmen des PCI-DSS anfallenden Dienstleistungen (Auswertung des Fragebogens, Durchführung des Security-Scan), die durch die akkreditierten Partner erbracht werden, haben einen hohen Standardisierungsgrad. Weiterhin ist ein hoher Anteil an wiederholenden Tätigkeiten gegeben, einerseits durch die Richtlinien des PCI-DSS selbst, andererseits durch bereits aquirierte Stammkundschaft mit gleichartigen Anforderungen nach den initialen Security-Audits. Beide Faktoren fordern geradezu auf, den Anteil der Automatisierung bestehender Prozesse immer weiter zu erhöhen, um die Wettbewerbsfähigkeit nachhaltig zu sichern. Für die meisten der im PCI-DSS beschriebenen Anforderungen und Aufgaben ist bereits ein sinnvoll hoher Automatisierungsgrad erreicht. Diese Teile bedürfen lediglich noch regelmäßigen Anpassungen an Änderungen im Standard. Bei der WWW-basierten Anwendungsschnittstelle jedoch besteht noch ein erheblicher Bedarf nach Automatisierung der Abläufe. Diese Bestrebungen kollidieren jedoch mit der Heterogenität der bei Kunden vorgefundenen Systemlandschaft, da 10 vgl. [46] und [45]; die Vorläufer des PCI-DSS waren die Sicherheits-Durchführungskataloge MasterCard Site Data Protection (SDP) und Visa Account Information Security (AIS), für eine Kurzübersicht der Anforderungen siehe [59] oder [60] 11 vgl. [60]

15 15 Händler und Transaktionsdienstleister völlig frei in der Wahl und Gestaltung ihrer Systeme sind Bei Kunden eingesetzte Softwarearchitekturen im Überblick Bis zum heutigen Zeitpunkt gibt es noch nicht sehr viele Standardsoftwareprodukte im E-Commerce-Bereich, die bei Händlern und auch bei Zahlungsabwicklern im großen Stil eingesetzt würden. Es existieren Lösungen als Zusatzmodule, die von Anbietern weit umfangreicherer Unternehmenssoftware oder Datenbanken angeboten werden. Daneben gibt es Anbieter von spezialisierter Shopsoftware, sowie Internet-Provider, die kleinere Shopsysteme als ein standardisiertes (Zusatz-) Produkt zu geschäftsmäßig genutzten Web-Präsenzen anbieten. Allen diesen Systemen ist gemein, dass sie bei den typischen Kunden der SRC GmbH nicht angetroffen werden. Es überwiegen mehrheitlich Eigenentwicklungen, die sich zumeist aus wenigen Technologie-Bausteinen zusammen setzen: Betriebssystem und Web-Plattform: Microsoft Windows mit Microsoft Internet Information Server (IIS) oder mit Apache Webserver, sowie Linux mit Apache Webserver Speichersysteme: typischerweise relationale Datenbanken mit SQL-basierter Anwendungsschnittstelle Generierung von dynamischen Webseiten auf Serverseite mit: PHP Perl Techniken auf Seiten der Präsentationsschnittstelle: Dynamisches HTML (DHTML) mit Hilfe von JavaScript Seitenaufbau zumeist HTML 4.0x, aber auch XHTML 1.0 Bei Kunden vorgefundene Implementierungen beschränken sich aber nicht ausschließlich auf diese Strukturen. Oft anzutreffen sind auch Softwarelösungen, die auf standardisierter und strukturierter Middleware aufsetzen wie Java-basierter Servertechnik (Java Server Pages JSP oder Applikationsserver), dem Microsoft.NET-Framework oder anderen Applikationsservern wie Adobe ColdFusion. Noch ohne größere Bedeutung und nicht im Kundenumfeld anzutreffen sind beidseitig dynamische Web-Techniken nach dem AJAX-Modell 12, sowie generell reine XML-Techniken, die erst im Web- Browser mit Hilfe von Transformationsanweisungen in darstellungsfähiges XHTML umgesetzt werden. 12 Asynchronous JavaScript and XML, siehe [74]

16 Bisherige Vorgehensweise: manuelle Überprüfung der Ergebnisse automatisierter (Vor-) Tests Die grundsätzliche Herangehensweise bei der IT-Sicherheitsüberprüfung einer web-basierten Anwendung in generalisierter Form eine Softwareanwendung mit einer auf dem HTTP-Protokoll basierenden Nutzungsschnittstelle eines Kunden kann grob aus dem Vorgehensmuster des Security-Scans abgeleitet werden. Einem solchen Security-Scan kann zuvor noch ein Security- Audit vorausgehen, dies insbesondere dann, wenn zu einem späteren Zeitpunkt die Einhaltung bestimmter Sicherheitsrichtlinien zertifiziert werden soll. In einem solchen Fall ist der Security-Scan nur ein Teil des gesamten Audit-Prozesses. Der Security-Scan untergliedert sich dabei in die zwei Hauptbereiche des Vulnerability-Scan und des Penetrationstests Vulnerability-Scan Bei einem Vulnerability-Scan werden automatische Werkzeuge eingesetzt, um ein System, ein ganzes Netzwerk von Systemen oder gezielt eine Web- Anwendung auf einem System nach bekannten Sicherheitslücken abzutasten. Die Arbeitsweise eines Vulnerability-Scanners lässt sich ganz grob mit der Technik von Viren-Scannern oder Antiviren-Werkzeugen vergleichen. Der Hersteller des Scanners pflegt regelmäßig Erweiterungen und Ergänzungen sowie neue Einzeldetektoren nach, die sich über Plugin-Mechanismen installieren lassen. Ergänzungen können dabei wie bei Virenscannern aus einfachen Signaturen (Mustererkennung) bestehen, oftmals handelt es sich aber um ganze ausführbare Module, die einen bestimmten Einzeltest ausführen. Einzelne Produkte solcher Vulnerability-Scanner können lediglich als Applikationsdienst angemietet werden, zu dem der Kunde einen Steuerclient erhält. Hier obliegt der gesamte Wartungsprozess inklusive der Aktualisierung der Scanmodule dem Hersteller. Vulnerability-Scanner werden eingesetzt, um in relativ kurzer Zeit einen Überblick über mögliche Schwachstellen oder Gefahrenpotenziale zu erhalten. Daneben spielt für nachgeordnete Tests auch die allgemeine Informationsgewinnung eine Rolle, bei der ein Vulnerability-Scanner ebenfalls hilfreich ist Penetrationstest Beim Penetrationstest werden Angriffsziele einem manuellen Sicherheitstest unterzogen. Ein oder mehrere Vulnerability-Scans werden in den meisten Fällen als Grundlage und Vorbereitung für den anschließenden Penetrationstest herangezogen. Ein vollständiger Security-Scan zielt vor allen Dingen 13 vgl. [75]

17 17 auch darauf ab, durch einen Penetrationstest die Ergebnisse eines Vulnerability-Scan zu verifizieren. Die Vorgehensweise bei einem Penetrationstest kann, ausgehend von einem Klassifikationsschema des Bundesamt für Sicherheit in der Informationstechnik Deutschland (BSI), in 5 Verfahrensschritte aufgeteilt werden 14 : In der Vorbereitungsphase werden mögliche Angriffsziele und -bereiche vereinbart bzw. geplant, hier sollte auch eine scharfe Abgrenzung zu benachbarten System stattfinden. In der Informationsbeschaffungsphase werden zunächst mit vielfältigen Mitteln Informationen über das zu testende System und dessen innere Eigenschaften gewonnen. Die zuvor gewonnenen Informationen sind zunächst einer Bewertung zu unterziehen, um die folgenden Schritte planen zu können. Daran schließen sich die eigentlichen Eindringversuche an Zusammenfassend sind die Ergebnisse aus allen Testphasen in einem Bericht zu dokumentieren, was die Protokollierung wesentlicher Zwischenschritte zuvor voraussetzt. In diesem Bericht sollten stets auch geeignete Gegenmaßnahmen mit aufgenommen werden. Ergänzend ist zu sagen, dass ein Test sinnvollerweise nicht streng linear nach diesem Verfahrensmodell durchgeführt werden sollte. Da in der Bewertungsphase und vielmehr noch in der Phase der Durchführung der Eindringversuche wiederum neue Informationen über das Zielsystem gewonnen werden, wird das Vorgehen zum Teil auch zyklischen Charakter haben. Es ist sinnvoll und entspricht der praktischen Durchführung, an Punkt 4 wiederholt die Phase der Informationsbeschaffung anzuschließen und den Prozess noch einmal zu durchlaufen Bei SRC eingesetzte Werkzeuge für Vulnerability-Scans Um Penetrationstests vorbereiten zu können und um einen schnellen Eindruck von der potenziellen Anfälligkeit zu untersuchender web-basierter Anwendungen bekommen zu können, werden für Vulnerability-Scans bei der Firma SRC unter anderem die folgenden Werkzeuge eingesetzt. QUALYSGUARD ist eine kommerzielle Software, die sowohl bei wiederkehrenden, automatischen Standardscans eingesetzt wird, als auch für die allgemeine Informationsgewinnung in der Vorbereitungsphase zu einem Penetrationstest. Ein sehr nützliches Merkmal dieses Werkzeuges sind implementierte Techniken zum Erkennen 14 vgl. [73] 15 Veranschaulichend kann herangezogen werden, dass durch eine erfolgreiche Penetration unweigerlich neue Detailinformationen über einen spezifischen Aspekt des Zielsystems gewonnen werden. Diese können eine andere Schwachstelle des Zielsystems offenbaren, die zuvor nicht erkennbar gewesen ist. Wenn ein solcher Umstand eintritt, sollten die Prozessschritte 2 bis 4 wiederholt werden.

18 18 NIKTO NESSUS von Systembestandteilen anhand von digitalen Fingerprint-Mechanismen [49]. ist ein spezialisierter Scanner für web-basierte Anwendungen, veröffentlicht unter der GNU General Public License (GPL) Open- Source Lizenz [10]. Dieser spezialisierte Scanner wird in der Programmiersprache Perl entwickelt und ist nicht nur als alleinstehendes Werkzeug verfügbar, sondern als Ergänzung für den im nächsten Punkt vorgestellten Scanner. stellt eine integrierte Kollektion von system-, netzwerk- und plattformübergreifenden Vulnerability-Scannern mit über Plugins für einzelne Tests dar. Darunter befinden sich unter anderem auch spezialisierte Module, die ausschließlich auf web-basierte Anwendungen abzielen [62] Manuelle Nacharbeiten bei einem Vulnerability-Scan Bei allen Werkzeugen für Vulnerability-Scans sind in den anschließenden Security-Scans Überarbeitungen bei den erzeugten maschinellen Reports (Dateien im XML-Format) dringend notwendig. Jedes automatische Werkzeug heutiger Generation erzeugt ein große Anzahl sogenannter false-positives. Das sind berichtete Schwachstellen, die sich bei gründlicher Untersuchung als tatsächlich nicht vorhanden erweisen. Vulnerability-Scanner berichten unter Umständen eine große Anzahl von Falschmeldungen. Dazu kommen nicht erkannte Fehler (false-negatives), weil die Scan-Werkzeuge zum Teil schon mit einfachsten Mitteln ihrer Detektionsfunktion beraubt werden können. Konfiguriert der Betreiber eines Webservers seinen Dienst so, dass jeder Seitenabruf, auch ein fehlerhafter, stets als erfolgreich bearbeitete Anfrage dargestellt wird, dann laufen die Detektionsmechanismen einiger Vulnerability-Scanner bisweilen ins Leere. Bei der Überarbeitung automatisch generierter Reports gilt es also, falsepositives zu entfernen und den Report einem generellen Review zu unterziehen. Für die Überprüfung der Ergebnisse und für die Durchführung nachgelagerter Penetrationstests zur Aufdeckung weiterer, noch unerkannter Fehler kommen weitere spezialisierte Tools zum Einsatz, die auf den interaktiven Gebrauch durch einen Security-Analysten abgestimmt sind: Web-Proxy-Werkzeuge dienen der Analyse und gegebenenfalls der Unterbrechung und Modifikation des nackten Datenstromes zwischen Web-Server und Client-Anwendung. Diese Werkzeuge sind neben weiteren Assessment-Tools in Produkten wie beispielsweise WEBSCARAB oder PAROS PROXY vorhanden 16. Web-Crawler und Artverwandte werden meist im Rahmen der Informationsbeschaffung benötigt. Mit ihnen (z.b. WGET) lässt sich ein lo- 16 siehe [44] und [9]

19 19 kales, strukturell ähnliches Abbild der zu untersuchenden Webapplikation erzeugen. Wenn ein solches Abbild einer Webseite auch nicht immer ausdrücklich erzeugt wird, so erledigen dies viele weitere Werkzeuge dennoch im Hintergrund quasi nebenbei 17. Low-Level-Techniken werden bei der gezielten Untersuchung einzelner mutmaßlicher Sicherheitslücken angewandt, die direkt an der Schnittstelle zum Webserver ansetzen und den HTTP-Datenstrom manipulieren. Für Secure-Socket-Layer (SSL) abgesicherte Webserver ist zunächst die Software OPENSSL im Filtermodus notwendig, darauf aufsetzend oder alternativ dann Terminalemulatoren wie TELNET oder Streamhandler wie NC (NETCAT) Zielsetzung der Arbeit Hauptziel dieser Arbeit ist es, Grundlagen für eine Steigerung der Effektivität automatischer Analysewerkzeuge zu erarbeiten. Insbesondere sollen bestehende Werkzeuge auf den Stand der Technik untersucht und Verbesserungsoptionen aufgezeigt werden. Im Vordergrund steht dabei, die im Prozess der Überprüfung der Ergebnisse anstehende Arbeit deutlich zu verringern. Zu diesem Zwecke sind in erster Linie möglichst viele der false-positives zu vermeiden. In zweiter Linie sind neue, intelligente Wege beim Aufdecken möglicher Gefahren zu identifizieren, die mit den eher schablonenhaften Analysemethoden gängiger Werkzeuge derzeit noch nicht machbar erscheinen. Denn nur, wenn sich mit automatisierten Werkzeugen auch neue, bisher unbekannte Softwareschwächen aufdecken lassen und dem menschlichen Security-Berater Arbeit abnehmen, kann sich die Gesamteffektivität eines Security-Scans wesentlich steigern lassen. Hierin liegt ein besonderes Potenzial, mit automatisierten Verfahren langfristig und nachhaltig die Wettbewerbsfähigkeit gegenüber anderen Sicherheitsdienstleistern zu erhalten oder sogar zu steigern. Anhand einer prototypischen Implementierung soll weiterhin eine der vorgeschlagenen Verbesserungsoptionen umgesetzt werden. Die Implementierung soll dabei so ausgelegt werden, dass Basistechniken in einem Framework zusammengefasst sind, während einzelne Tests wie bei anderen Vulnerability-Scannern auch in Plugin-Module ausgelagert sind. Die Organisationsstruktur der Plugins soll dabei mit Hilfe eines Dateisystems hierarchisch gegliedert werden können. Das generelle Framework sollte möglichst viele der von den Plugins allgemein benötigten Funktionalitäten auf generischem Wege implementieren. 17 Werkzeuge mit denen beispielsweise die Verlinkungsstruktur einer Webseite geprüft werden kann (Suche nach ungültigen Links), legen lokale Kopien der geladenen Seiten als Strukturen im Hauptspeicher oder als temporäre Dateien im Filesystem ab.

20 20 Insgesamt soll diese Arbeit Grundlage für zukünftig darauf aufbauende Arbeiten sein. Zu diesem Zweck sollen zunächst die notwendigen Grundlagen aufgearbeitet werden. Eine Bestandsaufnahme der Arbeitsprozesse zur Durchführung von Penetrationstests bei SRC soll der Aufbereitung von Erfahrungswissen dienen und zukünftigen Bearbeitern in diesem Themenbereich die Einarbeitung verkürzen. Die prototypische Implementierung soll auch deswegen als Framework mit Plugintechnik ausgelegt sein, damit in Nachfolgearbeiten entstehende Module mit Konzentration auf die wesentlichen Eigenschaften entwickelt werden können.