Unternehmensbezogenes Google Hacking

Document Sample
Unternehmensbezogenes Google Hacking Powered By Docstoc
					  Rheinisch-Westfälische Technische Hochschule Aachen
                 Universität Mannheim
            Lehrstuhl Praktische Informatik I
              Prof. Dr.-Ing. Felix Freiling




                  Diplomarbeit
Unternehmensbezogenes Google
          Hacking
                           von

                   Klaus Kröner
                     RWTH Aachen


                     29. August 2007



                         Gutachter:
    Prof. Dr.-Ing. Felix Freiling, Universität Mannheim
     Prof. Christian H. Bischof, Ph.D., RWTH Aachen

                           Betreuer:
 Dipl.-Ing. Matthias Humbert, T-Mobile Deutschland GmbH
     Prof. Dr.-Ing. Felix Freiling, Universität Mannheim
II
Hiermit versichere ich, dass ich die Arbeit selbständig verfasst und keine anderen als
die angegebenen Quellen und Hilfsmittel benutzt, sowie Zitate kenntlich gemacht
habe.

Bonn, den 29. August 2007



_____________________________
(Klaus Kröner)



                                          III
IV
Inhaltsverzeichnis

1   Einführung                                                                                                     2
    1.1 Motivation . . . . . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   2
    1.2 Suchmaschinen . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   3
    1.3 Google Hacking . . . . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   4
    1.4 Ziele und Strukturierung der Diplomarbeit      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   5

2   Grundlagen                                                                                                     6
    2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                 6
    2.2 Einführung in Google Hacking . . . . . . . . . . . . . . . . . . . . .                                     6
        2.2.1 Die Google-Syntax . . . . . . . . . . . . . . . . . . . . . . .                                      7
        2.2.2 Klassifizierung von Suchmustern . . . . . . . . . . . . . . .                                         8
        2.2.3 Erweiterung der Google-Hacking-Datenbank / Suche nach neu-
                en Suchmustern . . . . . . . . . . . . . . . . . . . . . . . . .                                   11
        2.2.4 Exkurs: Die Verwendung von Google als Proxy-Server . . . .                                           12
        2.2.5 Die Suche nach E-Mail-Adressen mittels Google . . . . . . .                                          12
    2.3 Weitere Suchmaschinen . . . . . . . . . . . . . . . . . . . . . . . . .                                    13
        2.3.1 Windows Live Search . . . . . . . . . . . . . . . . . . . . .                                        13
        2.3.2 Yahoo Search . . . . . . . . . . . . . . . . . . . . . . . . . .                                     14
    2.4 Vergleich verschiedener Suchmaschinen bezüglich ihrer Eignung für
        Suchmaschinen-Hacking . . . . . . . . . . . . . . . . . . . . . . . .                                      15
    2.5 Die Reichweite von Webcrawlern der Suchmaschinen . . . . . . . . .                                         15
    2.6 Suchmaschinen-Caches und ein Internet-Archiv . . . . . . . . . . . .                                       16
    2.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . .                                      17

3   Google Scanning                                                                                                18
    3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                           .   .   .   18
    3.2 Vulnerability Scanning . . . . . . . . . . . . . . . . . . . . . .                             .   .   .   18
    3.3 Anwendung von Google Hacking . . . . . . . . . . . . . . . .                                   .   .   .   19
        3.3.1 Voraussetzungen . . . . . . . . . . . . . . . . . . . . .                                .   .   .   19
        3.3.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . .                              .   .   .   19
    3.4 Ablauf des Google-Scans . . . . . . . . . . . . . . . . . . . . .                              .   .   .   20
        3.4.1 Probleme / Einschränkungen des Google Hackings . . .                                     .   .   .   21
        3.4.2 Finden aller relevanter Domains bzw. Webapplikationen                                    .   .   .   22
        3.4.3 Finden sinnvoller Suchmuster . . . . . . . . . . . . . .                                 .   .   .   22
        3.4.4 Langfristiger Ablaufplan . . . . . . . . . . . . . . . . .                               .   .   .   24
        3.4.5 Tiefe der Suche . . . . . . . . . . . . . . . . . . . . . .                              .   .   .   25
        3.4.6 Analyse der Ergebnisse . . . . . . . . . . . . . . . . . .                               .   .   .   27
        3.4.7 Kurzfristige Maßnahmen nach einem Fund . . . . . . .                                     .   .   .   29


                                           V
    3.5   Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . .                33

4   Entwicklung des Google-Hacking-Tools „GooScanner“                                          34
    4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . .   .   .   .   .   .   34
    4.2 Arbeitsweise des Programms . . . . . . . . . . . . . . . . .       .   .   .   .   .   34
    4.3 Aufwandsabschätzung . . . . . . . . . . . . . . . . . . . .        .   .   .   .   .   37
    4.4 Schema für die Anwendung von GooScanner . . . . . . . .            .   .   .   .   .   41
    4.5 Andere Vulnerability-Scanner, die Google Hacking einsetzen         .   .   .   .   .   42
        4.5.1 Sitedigger . . . . . . . . . . . . . . . . . . . . . . .     .   .   .   .   .   42
        4.5.2 gooscan . . . . . . . . . . . . . . . . . . . . . . . .      .   .   .   .   .   42
        4.5.3 Acunetix . . . . . . . . . . . . . . . . . . . . . . .       .   .   .   .   .   43
        4.5.4 Athena . . . . . . . . . . . . . . . . . . . . . . . .       .   .   .   .   .   43
        4.5.5 Wikto . . . . . . . . . . . . . . . . . . . . . . . . .      .   .   .   .   .   43
    4.6 Google Web Services . . . . . . . . . . . . . . . . . . . . .      .   .   .   .   .   43
    4.7 Google Alerts . . . . . . . . . . . . . . . . . . . . . . . . .    .   .   .   .   .   44
    4.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . .        .   .   .   .   .   44

5   Vergleich mit anderen Scanning-Methoden                                                    46
    5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .             46
    5.2 Scanning-Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . .                46
         5.2.1 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                46
         5.2.2 QualysGuard . . . . . . . . . . . . . . . . . . . . . . . . . .                 49
         5.2.3 WebInspect . . . . . . . . . . . . . . . . . . . . . . . . . . .                50
         5.2.4 Parallelen bzw. Unterschiede zum Google Hacking . . . . . .                     50
    5.3 Maximierung des Sicherheitsgewinns durch Google Scanning . . . .                       53
         5.3.1 Die Effektivität des Google Scannings . . . . . . . . . . . . .                 53
         5.3.2 Auswirkung der Aktualität des Suchindex auf die Abwehrrate                      54
         5.3.3 Auswirkung der Aktualität bzw. des Inhalts der Suchmuster-
                Datenbasis auf die Abwehrrate . . . . . . . . . . . . . . . . .                56
    5.4 Kurze Einführung in Penetration Testing . . . . . . . . . . . . . . . .                56
         5.4.1 Resultate durch etablierte Penetration-Testing-Verfahren . . .                  57
    5.5 Der betriebliche Mehrwert durch Google Hacking . . . . . . . . . . .                   57
         5.5.1 Ungeschützte Systeme . . . . . . . . . . . . . . . . . . . . .                  58
         5.5.2 Durch Vulnerability Scanning geschützte Systeme . . . . . .                     59
         5.5.3 Durch Penetration Testing geschützte Systeme . . . . . . . .                    59
         5.5.4 Durch Vulnerability Scanning und Penetration Testing geschütz-
                te Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . .               60
         5.5.5 Kosten-/Nutzen-Verhältnisse auf Basis des messbaren Anteils
                am Sicherheitsgewinn . . . . . . . . . . . . . . . . . . . . .                 62
    5.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . .                  63

6   Präventive Abwehr                                                                          65
    6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .             65
    6.2 Alarmsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .               65
    6.3 Server-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . .                66
    6.4 Google Hacking Honeypots / Verbreitung von Falschinformationen . .                     68
    6.5 Blockieren des Zugriffs für offensichtliche
         Google-Hacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . .               70
    6.6 Betrachtung des Inhalts von Websites unter Verwendung eines Web-
         crawlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .            70


                                           VI
    6.7   Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                            71

7   Zusammenfassung                                                                                                                        72
    7.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                        73

A Quellcode                                                                                                                                74
  A.1 Das Scheduling-Modul von GooScanner . . . . . . . . . . . . . . . .                                                                  74
  A.2 Das Google-Scan-Modul von GooScanner . . . . . . . . . . . . . . .                                                                   77

B Fallbeispiele                                                                                                                            82
  B.1 Einleitung . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   82
  B.2 Firma 1 . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   83
  B.3 Firma 2 . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   87
  B.4 Firma 3 . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   89
  B.5 Zusammenfassung          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   93




                                                       VII
Abbildungsverzeichnis

 1.1   Ergebnis der Anwendung eines einfachen Suchmusters . . . . . . . .                         3
 1.2   Die Google-Startseite . . . . . . . . . . . . . . . . . . . . . . . . . .                  4

 2.1   Ergebnis der Suche nach einer Drucker-Schnittstelle . . . . .         .   .   .   .   .    8
 2.2   Ergebnisse der Suche nach Index of: inurl:private                   .   .   .   .   .    9
 2.3   Ergebnis der Suche nach inurl:passwd . . . . . . . . . . .            .   .   .   .   .    9
 2.4   Ergebnis der Suche nach filetype:pwd inurl:service .                  .   .   .   .   .    9
 2.5   Ergebnis der Suche nach @gmail.com -www.gmail.com .                   .   .   .   .   .   13

 3.1   Ablaufplan Google Scanning in Pseudocode . . . . . . . . . . . . . .                      26

 4.1   Datenmodell von GooScanner . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   35
 4.2   Konfiguration eines Jobs in GooScanner . . . . . . . .     .   .   .   .   .   .   .   .   38
 4.3   Bewertung eines Fundes in GooScanner . . . . . . . .      .   .   .   .   .   .   .   .   38
 4.4   Bewertung mehrerer Funde gleichzeitig in GooScanner       .   .   .   .   .   .   .   .   39

 5.1   Quellcode eines Nessus-Plugins . . . . . . . . . . . . . . . . . . . .                    48

 6.1   Beispiel einer sitemap.xml . . . . . . . . . . . . . . . . . . . . . . .                  68
 6.2   Honeypot-Funktion zum Sammeln von Informationen über Angreifer                            69




                                       VIII
Tabellenverzeichnis

 2.1    Zeit zwischen Besuch durch Webcrawler und Aktualisierung des Cache          17

 3.1    Limitierung der Anzahl gelieferter Ergebnisse . . . . . . . . . . . . .     27
 3.2    Funde und Gegenmaßnahmen . . . . . . . . . . . . . . . . . . . . .          30
 3.3    Vergleich von Entfernungszeiten . . . . . . . . . . . . . . . . . . . .     32

 4.1    Zeitbedarf von Google Scanning . . . . . . . . . . . . . . . . . . . .      37
 4.2    Grundlagen der Statistik in Tabelle 4.1 . . . . . . . . . . . . . . . . .   37
 4.3    Verlauf der Anzahl neuer Treffer bei Scans von t-mobile.de . . . . . .      40

 5.1    Vergleich von Google Hacking und Vulnerability Scanning . . . . . .         52
 5.2    Die UserAgents der Suchmaschinen . . . . . . . . . . . . . . . . . .        55
 5.3    Vergleich von Google Hacking und Vulnerability Scanning bzgl. Mehr-
        werts durch Google Hacking . . . . . . . . . . . . . . . . . . . . . .      59
 5.4    Vergleich von Google Hacking und Penetration Testing bzgl. Mehr-
        werts durch Google Hacking . . . . . . . . . . . . . . . . . . . . . .      60
 5.5    Vergleich von Google Hacking und Penetration Testing zusammen mit
        Vulnerability Scanning bzgl. Mehrwerts durch Google Hacking . . . .         61

 B.1    Konfiguration der Scan-Jobs für Firma 1 . . . . . . . . . . . . . . . .      83
 B.2    Der erste Scan für Firma 1 . . . . . . . . . . . . . . . . . . . . . . .    83
 B.3    Verlauf der Anzahl neuer Treffer bei Scans der Domains von Firma 1 .        84
 B.4    Falschtreffer bei Scans der Domains von Firma 1 . . . . . . . . . . .       85
 B.5    Dauer eines Scans der Domains von Firma 1 . . . . . . . . . . . . . .       86
 B.6    Konfiguration der Scan-Jobs für Firma 2 . . . . . . . . . . . . . . . .      87
 B.7    Der erste Scan für Firma 2 . . . . . . . . . . . . . . . . . . . . . . .    87
 B.8    Verlauf der Anzahl neuer Treffer bei Scans der Domains von Firma 2 .        88
 B.9    Falschtreffer bei Scans der Domains von Firma 2 . . . . . . . . . . .       88
 B.10   Dauer eines Scans der Domains von Firma 2 . . . . . . . . . . . . . .       88
 B.11   Konfiguration der Scan-Jobs für Firma 3 . . . . . . . . . . . . . . . .      89
 B.12   Der erste Scan für Firma 3 . . . . . . . . . . . . . . . . . . . . . . .    89
 B.13   Verlauf der Anzahl neuer Treffer bei Scans der Domains von Firma 3 .        90
 B.14   Beispielhafte Falschtreffer bei Scans der Domains von Firma 3 . . . .       91
 B.15   Dauer eines Scans der Domains von Firma 3 . . . . . . . . . . . . . .       92




                                         IX
                               Zusammenfassung

„Google Hacking“ ist eine Methode, mit welcher Suchmaschinen als Hacker-Werkzeu-
ge verwendet werden. Mittels Google Hacking kann man beispielsweise die Angreif-
barkeit von Webservern erforschen, Zugangsdaten aufspüren und Informationen sam-
meln, die den Angriff auf ein Netzwerk mittels anderer Methoden erleichtern. Hierzu
werden keine geheimen Funktionen der Suchmaschinen verwendet, sondern hochspe-
zialisierte Suchmuster als Anfragen an die Suchmaschinen gesendet.
    Diese Diplomarbeit bietet einen Überblick über die beim Google Hacking ver-
wendeten Techniken. Zudem werden verschiedene Möglichkeiten der Abwehr unter-
sucht. Der Schwerpunkt liegt hierbei auf der Untersuchung und Entdeckung möglicher
Schwachstellen der Web-Applikationen und Netze eines Unternehmens mittels regel-
mäßig durchgeführter Überprüfung von Suchergebnissen. Hierzu wird eine Strategie
erarbeitet sowie ein Programm entwickelt, welches in festgelegten Intervallen große
Mengen von Anfragen an Suchmaschinen schickt und bei auffälligen Funden Alarm
auslöst. Anhand einer exemplarischen Anwendung wird untersucht, wie erfolgsver-
sprechend der Einsatz der Methoden des Google Hackings für eine unternehmensin-
terne Systemüberwachung sind. Ferner werden Vulnerability-Scanner vorgestellt, die
bereits von der Technik des Google Hacking Gebrauch machen. Diese, sowie Google
Hacking im Allgemeinen, werden mit den Möglichkeiten, die etablierte Vulnerability-
Scanning-Werkzeuge bieten, verglichen.




                                        1
Kapitel 1

Einführung

Um die Fülle von Informationen im Internet für den Menschen sinnvoll nutzbar zu
machen, gibt es Suchmaschinen. Sie sind die erste Anlaufadresse, wenn es im Allge-
meinen um die Suche nach Informationen im World Wide Web geht. Für die Such-
maschinen ist es daher wichtig, die charakteristischen Merkmale von möglichst vielen
Seiten im Web zu erfassen, also den in Form von Text erfassbaren Inhalt. Die „Bots“
oder „Webcrawler“ der Suchmaschinen suchen daher unablässig nach Daten und sind
bei deren Aufnahme in ihren Index relativ unkritisch, wobei es für die Eigner der Daten
Methoden gibt, diese Aufnahme von Informationen zu beeinflussen oder zu verhindern.
Wenn diese Methoden allerdings nicht angewendet werden, können Webcrawler auch
Informationen speichern, welche evtl. überhaupt nicht für die Öffentlichkeit gedacht
sind, aber trotzdem – meist unbeabsichtigt – in einem öffentlich zugänglichen Bereich
eines Web-Servers zu finden sind. Dabei kann es sich um Passwörter, Konten-Daten,
oder auch andere Informationen handeln, die auf den ersten Blick gar kein Gefahren-
potential für ihren Eigner mit sich bringen – aber indirekt Angriffsmöglichkeiten eröff-
nen. Genau diese Informationen kann man mit Hilfe von Google und weiteren großen
Suchmaschinen dank ihrer genauen Suchmöglichkeiten gezielt suchen und finden. Dies
bezeichnet man als „Google Hacking“.
    Wie man an der Anzahl von Ergebnissen in Abbildung 1.1 erahnt, können be-
reits mit Hilfe einfacher Suchmuster wie etwa „intitle:index of parent di-
rectory inurl:private“ interessante Funde gemacht werden. Hier wurde zwar
nur relativ ungezielt nach allgemeinen, privaten Daten gesucht, jedoch wird daran deut-
lich, dass private Daten wohl nicht immer ausreichend geschützt sind.


1.1     Motivation
Google Hacking stellt eine Gefahr für jedes Netzwerk dar, in welchem es Informatio-
nen gibt, die nicht für jedermann zugänglich sein sollen - falls dieses Netzwerk an das
Internet angebunden ist. Mit Hilfe von Google Hacking lässt sich zwar nur in Spezi-
alfällen ein direkter Angriff auf ein Netz durchführen, welcher dem klassischen Ver-
ständnis des Begriffs „Hacking“ entsprechen würde. Doch manchmal macht ein Fund
im Speicher einer Suchmaschine den eigentlichen Angriff auch überflüssig, da man
die gewünschte Information schon durch den Zwischenspeicher („Cache“) der Such-
maschine erhält. Je nach Fund kann ein Stück Information den eigentlichen Angriff
manchmal nur ein bisschen, gelegentlich aber auch erheblich erleichtern. Somit stellen


                                           2
       Abbildung 1.1: Ergebnis der Anwendung eines einfachen Suchmusters



sich die folgenden Fragen:

   • Wie funktioniert Google Hacking?

   • Wie findet man systematisch heraus, ob ein Netz für Google Hacking anfällig
     ist?

   • Kann man Google Hacking dafür einsetzen, um mögliche Schwachstellen und
     Sicherheitsmängel (frühzeitig) auf systematische Weise zu entdecken?

   • Wie kann man ein IT-System vor Google Hacking schützen?


1.2    Suchmaschinen
Bisher wurde als Suchmaschine für das Internet nur Google erwähnt, da gerade unter
ihrer Verwendung das „Google Hacking“ entstand. Als wichtige Ergänzungen zu Goo-
gle sollten noch „Yahoo! Search“ [yahb] (im Folgenden „Yahoo Search“ genannt) und
„Windows Live Search“ [livb] (vormals „MSN“, im Folgenden kurz „Live Search“ ge-
nannt) erwähnt werden, da sie eine ähnlich mächtige Anfragesyntax und vergleichbar
große Suchindizes haben.
    Anfragen an diese Suchmaschinen geschehen in Form so genannter Suchmuster.
Ein Suchmuster ist ein Ausdruck, welcher einer Suchmaschine als Parameter überge-
ben wird. Es definiert, welchen Inhalt bzw. welche Eigenschaften ein gesuchtes Doku-
ment haben soll.
    Im Laufe dieser Arbeit wird sich zeigen, dass für systematisches Google Hacking
oft große Mengen an Anfragen an Suchmaschinen gestellt werden müssen. Dies kann
über die wohlbekannten Web-Schnittstellen kaum in zufriedenstellender Geschwindig-
keit bewerkstelligt werden. Zudem würden Anfragen, die automatisiert und in hoher


                                        3
                              Abbildung 1.2: Die Google-Startseite



Frequenz an diese Schnittstellen gestellt würden, in den meisten Fällen zu einer Sper-
rung des Zugriffs auf die jeweilige Suchmaschine für die IP des anfragenden Rechners
zur Folge haben. Für große Mengen von Anfragen stellen die drei genannten Suchma-
schinen allerdings spezielle Schnittstellen zur Verfügung. Diese sind bei Google und
Live Search jeweils eine SOAP1 -API. Yahoo Search ermöglicht Anfragen über das
REST2 -Protokoll.




1.3     Google Hacking

Zum Google Hacking gibt es mindestens eine Community, die sich ausschließlich mit
diesem Thema beschäftigt. Eine große Sammlung von interessanten Suchmustern für
Google, die „Google-Hacking-Database“ (GHDB) befindet sich auf der Homepage des
Begründers dieser Community und Ikone des Google Hacking, Johnny Long [ghd07].
Diese Datenbank wird durch die Community stetig ergänzt und beinhaltet teilweise
auch Suchmuster, die zu weniger interessanten Ergebnissen führen – ist aber dafür sehr
umfangreich. Mehrere Penetration-Testing- bzw. Vulnerability-Scan-Tools, die entwe-
der auf das Google Hacking spezialisiert sind oder es als Zusatz-Feature anbieten, grei-
fen für ihren Test auf die GHDB zurück.
    Für die Suche nach Schwachstellen im Quelltext von Programmen, welche in C,
PHP, Java oder einigen anderen Sprachen programmiert sind, gibt es die spezielle
Code-Suchmaschine „Google Codesearch“ [gcs07]. Auf die Suche nach Sicherheits-
lücken mit Hilfe dieser Suchmaschine soll innerhalb dieser Arbeit allerdings nicht wei-
ter eingegangen werden. Diese Art von Suche ist sicherlich sinnvoll, doch würde sie
einen Schritt weiter als das hier betrachtete Google Hacking führen, denn zunächst
müsste der Quellcode eines Programms gefunden werden.

  1 Simple   Object Access Protocol
  2 Representational  State Transfer


                                               4
1.4    Ziele und Strukturierung der Diplomarbeit
Innerhalb dieser Diplomarbeit soll insbesondere auf die folgenden Punkte eingegangen
werden:

   1. Übersicht über Google Hacking und die verwendeten Techniken
   2. Untersuchung und Bewertung: Eignung der Techniken des Google Hackings für
      die Überprüfung und Überwachung von Web-Applikationen und Netzen hin-
      sichtlich möglicher Sicherheitsschwächen

   3. Entwicklung einer automatisierten Schnittstelle, über welche täglich neu hinzu-
      gekommene Webseiten klassifiziert und überprüft werden
   4. Ist eine Anbindung von „Google Webservices“ bzw. „Google Alerts“ sinnvoll
      möglich?
   5. Gibt es einen betrieblichen Mehrwert beim Einsatz solcher Techniken gegenüber
      den etablierten Vulnerability Scannern (z.B. Qualys)?
   6. Exemplarische Anwendung der Google-Hacking-Techniken auf die Webseiten
      einiger Unternehmen: Welche Erkenntnisse konnten gewonnen werden? Scheint
      „Google Hacking“ ein vielversprechender Ansatz?

    Zu Punkt 1 wird in Kapitel 2 das Google Hacking vorgestellt, indem zunächst auf
die Syntax der Suchmaschine, und danach – unter Verwendung von Beispielen – auf
speziell für das Google Hacking formulierte Suchmuster eingegangen wird.
    Die Punkte 2 bis 4 werden in Kapitel 3 und 4 behandelt. Es wird zunächst auf
die Funktionsweise und Entwicklung einer automatisierten Schnittstelle eingegangen,
welche danach in der praktischen Anwendung zum Einsatz kommt. Bei der Entwick-
lung der Schnittstelle wird sich Näheres über die Relevanz von Google Web Services
und Google Alerts für das Google Hacking herausstellen. Punkt 5 wird in Kapitel 5
auf Basis der Erkenntnisse durch die vorherigen Kapitel behandelt. In Kapitel 6 wer-
den zudem Ideen und Erfahrungen zur Abwehr gegen Google Hacking vorgestellt. In
Kapitel 7 werden die Erkenntnisse aller Kapitel zusammengefasst.
    In Anhang B werden zudem einige Fallstudien beschrieben, in welchen die Web-
Applikationen und Netze von IT-Firmen mit Hilfe des entwickelten Werkzeugs auf
Anfälligkeit gegenüber Google Hacking untersucht werden. Hierdurch wird die Eig-
nung der Techniken des Google Hackings für die Überprüfung und Überwachung von
Applikationen und Netzen hinsichtlich möglicher Schwachstellen in der Praxis erprobt.




                                         5
Kapitel 2

Grundlagen

2.1    Einleitung
In diesem Kapitel soll zunächst ein grundlegender Überblick über das Google Hacking
gegeben werden. Hierzu werden die Möglichkeiten, die sich einem Hacker aufgrund
der Syntax für Anfragen an Google bieten, anhand von Beispielen erläutert. Ähnliche
Möglichkeiten bieten sich auch bei weiteren Suchmaschinen außer Google. Hier sind
besonders Yahoo Search und Live Search hervorzuheben, welche in einem weiteren
Abschnitt hinsichtlich ihrer Syntax betrachtet werden. Die Art und Weise, auf welche
Informationen in die Indizes und Zwischenspeicher der Suchmaschinen gelangen, wird
durch eine Betrachtung der Webcrawler der Suchmaschinen verdeutlicht.
    Viele Möglichkeiten und Gefahren hinsichtlich längerfristiger Offenlegung von
sensiblen Informationen gehen vom „Google Cache“ und dem „Internet Archive“ aus.
Diese werden im letzten Abschnitt dieses Kapitels betrachtet.


2.2    Einführung in Google Hacking
Google Hacking ist die Kunst, mit Hilfe von Suchmaschinen und geschickt formu-
lierten Suchmustern sensible Informationen im World Wide Web zu finden. Zu diesen
sensiblen Informationen können u.a. solche der folgenden Arten gehören:
   • Zugangsdaten / Passwort-Dateien
   • persönliche Daten / vertrauliche Informationen
   • Versionsnummern von - oder genauere Infos über Webapplikationen
   • Fehlermeldungen von Webapplikationen
   • Genaue Verzeichnisinhalte
   • Administrationsschnittstellen (z.B. von Druckern)
   • Intranet-Seiten
   • Authentifikation-voraussetzende Seiten
    Voraussetzung für die Formulierung von möglichst erfolgreichen Suchmustern ist
die genaue Kenntnis der Syntax der Anfragen an Suchmaschinen.


                                         6
2.2.1   Die Google-Syntax
Die Parameter, welche Google bei der Suche zulässt, sind (abgesehen von einigen wei-
teren, hier aber nicht relevanten) die folgenden [ses07]:

   • site: Einschränkung der Suche auf Seiten, die sich unterhalb der als Argument
     eingesetzten Domäne befinden.
   • inurl: Das Argument muss sich irgendwo in der URL befinden.
   • allinurl: Alle hierauf folgenden Worte müssen sich in der URL befinden.
   • link: Auf der gesuchten Seite muss sich ein Link auf das hier eingesetzte Ar-
     gument befinden.
   • related: Findet Seiten mit ähnlichem Themenkontext, wie die Seite, deren
     URL als Parameter angegeben wird.
   • intitle: Das Argument muss sich im Titel der Seite befinden (also innerhalb
     des Title-Tags des Headers der HTML-Datei).
   • allintitle: Alle folgenden Worte müssen sich im Titel der Seite befinden.
   • intext: Das Argument muss sich im Text, also nicht etwa im Titel oder der
     URL befinden.
   • allintext: Alle folgenden Worte müssen sich im Text befinden.
   • filetype: Das gesuchte Dokument hat diese Dateiendung. Wenn nur dieser
     Parameter ein Argument erhält, wird von Google kein Ergebnis geliefert.
   • ext: Selbe Funktion wie filetype.
   • cache: Als Argument wird eine URL eingesetzt. Das Suchergebnis liefert dann
     bei Vorhandensein die in den Google-Cache aufgenommene Version der Seite.
   • define: Sucht in Online-Nachschlagewerken wie Wikipedia Definitionen des
     Begriffs, der als Argument angegeben wurde.
   • numrange:x − y Es werden Zahlen z im Bereich x ≤ z ≤ y gesucht.

   Operatoren für die einzelnen Parameter:

   • + bzw. AND: Logisches „und“; hiermit werden Suchbegriffe standardmäßig ver-
     knüpft.
   • - : Negation
   • | bzw. OR: Logisches „Oder“
   • ...: Exakter Match des Ausdrucks zwischen den Anführungszeichen
   • [#] . . . [#]: Suche nach Zahlen zwischen einer Unter- und einer Obergrenze

   Joker-Symbole:

   • *: Beliebiges Wort von beliebiger Länge


                                          7
          Abbildung 2.1: Ergebnis der Suche nach einer Drucker-Schnittstelle



   • .: Beliebiges Zeichen

    In Abbildung 2.1 ist das Ergebnis der Suche nach einer Web-Schnittstelle einer be-
stimmten Art von Drucker zu sehen. Diese Schnittstelle wurde im vorliegenden Fall
offensichtlich nur unzureichend geschützt. Die Suche wurde mit Hilfe des „site:“-
Parameters auf eine bestimmte Domain eingeschränkt. Hier hat das Suchmuster „Xe-
rox Phaser 6250“ ausgereicht, um zu dem Fund zu gelangen. Noch effektiver für das
Finden von sensiblen Bereichen dieser speziellen Art von Schnittstellen wäre etwa das
Suchmuster „Delete Secure Jobs“.


2.2.2     Klassifizierung von Suchmustern
Es gibt typische Arten von Informationen, die man mittels Google Hacking finden
möchte. Die zugehörigen Suchmuster lassen sich aufgrund ihrer ähnlichen Ziele zu
Gruppen zusammenfassen. Im Folgenden werden diese Gruppen kurz vorgestellt. Zu
jeder Gruppe wird ein Beispiel eines Suchmusters angegeben.

2.2.2.1   Suche nach Verzeichnissen
In den meisten Fällen von Webserver-Verzeichnissen, die per HTTP zugänglich sind,
wird für jedes Verzeichnis eine Oberfläche in HTML gestaltet. Ausnahmen sind bei-
spielsweise Verzeichnisse, in denen Software zum Download angeboten wird, deren
Versionsnummer und – damit zusammenhängend – deren Dateiname sich so oft än-
dert, dass die Pflege der HTML-Oberfläche zu aufwendig wäre.
    Ein Verzeichnis ohne eigene HTML-Oberfläche kann allerdings auch unbeabsich-
tigt der Öffentlichkeit zugänglich gemacht sein. Dies kann etwa bei unzureichender
Konfiguration eines Webservers passieren. Solche Verzeichnisse findet man beispiels-
weise durch:

 Beispiel 1 Suche nach Verzeichnissen ohne Index-Datei

 intitle:Index of:
Dieses Suchmuster in Verbindung mit Stichworten wie „private“, „backup“ etc. führt
schnell zu interessanten Ergebnissen.

2.2.2.2   Login-Daten
Zugangsdaten können in verschiedenen Formen zu finden sein. Ein User kann zum Bei-
spiel seine Login-Daten als URL hinterlegt haben, falls das zugehörige Login-Portal


                                          8
    Abbildung 2.2: Ergebnisse der Suche nach Index of: inurl:private




             Abbildung 2.3: Ergebnis der Suche nach inurl:passwd



die Annahme von GET-Parametern unterstützt. Ein passendes Suchmuster könnte so
oder ähnlich aussehen:

 Beispiel 2 Suche nach Zugangsdaten in URLs

 inurl:passwd

Bei der Suche nach Zugangsdaten für bestimmte Portale kann der Name des relevanten
Parameters noch angepasst werden. Die Daten können allerdings auch in Form von
Listen vorliegen, welche je nach Server-Software bestimmte Namen und Speicherorte
haben. Ein einfaches Beispiel (Ergebnis der Suche in Abb. 2.4):

 Beispiel 3 Suche nach User-Datenbanken

 inurl:admin inurl:userlist
 oder
 filetype:pwd inurl:service




     Abbildung 2.4: Ergebnis der Suche nach filetype:pwd inurl:service




                                        9
2.2.2.3   Login-Portale
Login-Portale für Administratoren können Ausgangspunkte der Suche nach Schwach-
stellen sein. Der Fund eines Login-Portals eines Intranets ist noch weitaus schwer-
wiegender, da der Zugriff auf dieses (in den meisten Fällen) nicht vom Internet aus
möglich sein sollte. Die gezielte Suche nach Formularen für Login-Vorgänge ist al-
lerdings nicht auf Basis von charakteristischen HTML-Elementen möglich. Allerdings
gibt es charakteristische Formulierungen im Text mancher Login-Seiten, anhand derer
sich diese finden lassen. Ein allgemeines Beispiel:
 Beispiel 4 Suche nach Login-Portalen von Intranets

 intitle:Employee Intranet Login

2.2.2.4   Persönliche Daten / Kreditkartennummern
Diese Daten sollten natürlich in keinem Falle an die Öffentlichkeit gelangen und somit
auch nicht im Index einer Suchmaschine auftauchen. Beispiel:
 Beispiel 5 Suche nach Kundendaten

 Comersus.mdb inurl:database
Hiermit wird die Kunden-Datenbank der e-Shopping-Anwendung Comersus gesucht.

2.2.2.5   Fehlermeldungen
Fehlermeldungen geben oft zu viele Informationen über einen Server preis, wie et-
wa seine interne Verzeichnis- oder Datenbankstruktur, Software-Versionsnummern und
Teile von Code. Fehlermeldungen enthalten oft signifikante Phrasen, also kann bei-
spielweise das folgende Suchmuster zum Erfolg führen:
 Beispiel 6 Suche nach SQL-Fehlermeldungen

 SQL syntax error

2.2.2.6   Logdateien
In Logdateien könnten evtl. Usernamen oder Passwörter oder zumindest Daten, die
einen Angriff erleichtern würden, enthalten sein, wie Versionsnummern von Software.
Die Suche nach solchen Dateien ist denkbar einfach:
 Beispiel 7 Suche nach Logdateien

 ext:log

2.2.2.7   Web-Schnittstellen von Hardware
Eine oft unterschätzte Art von Sicherheitslücke kann ein Gerät wie beispielsweise ein
Drucker, eine WebCam, ein Scanner o.Ä. darstellen. Viele Druckermodelle bieten bei-
spielsweise eine Konfigurationsseite über das HTTP-Protokoll an. Neben der Konfigu-
ration kann auf solchen Seiten oft auch eine Liste der zuletzt gedruckten Dokumente –
zusammen mit einer ID des Users, der den Druck in Auftrag gegeben hat – aufgerufen


                                         10
werden. Mit etwas Geschick und Kenntnis über die Funktionsweise des Geräts kann
möglicherweise auch der Inhalt dieser Dokumente gefunden und heruntergeladen wer-
den. Wenn diese Geräte nicht vom Internet abgeschnitten werden, kann beispielsweise
das folgende Suchmuster Ergebnisse bringen:

 Beispiel 8 Suche nach Epson-Druckerschnittstellen

 intitle:EpsonNet WebAssist Rev
Hiermit wird die Administrations-Schnittstelle von Epson-Druckern gesucht.

2.2.2.8   Angreifbare Server
Webserver wie Apache oder der Microsoft Internet Information Server sind häufige
Ziele von Angriffen. Daher ist es nicht schwierig, zu einem Webserver mit bestimmter
Versionsnummer einen funktionierenden Exploit1 zu finden. Das Herausfinden der Ver-
sionsnummer eines Servers kann somit schon einen wesentlichen Schritt eines Angriffs
darstellen. Man kann also nach den typischen Formulierungen suchen, die Webserver
verwenden, um ihre Version zu verraten. Beispiel:

 Beispiel 9 Suche nach IIS-Servern

 Microsoft-IIS/5.0 server at
oder allgemeiner

 Beispiel 10 Suche nach Webserver-Informationen

 intitle:index.of  server at

2.2.2.9   Vertrauliche Daten
Diese Art von Suche bezieht sich nicht auf Informationen, die dabei helfen sollen, ver-
trauliche Daten aufzuspüren, sondern auf die vertraulichen Daten selbst. Dokumente,
die diese enthalten, haben oft das Format „doc“ (welches von Google, Live Search
und Yahoo Search indiziert und gecacht wird) und beinhalten oft typische Phrasen -
wie eben „vertraulich“. Daher kann eine Suche nach solchen Dokumenten sehr simpel
funktionieren, wie im folgenden Beispiel:

 Beispiel 11 Suche nach vertraulichen Dokumenten

 filetype:doc intitle:vertraulich
    Auf weitere, auf speziellere Ziele ausgerichtete Suchmuster soll hier zunächst nicht
eingegangen werden.

2.2.3     Erweiterung der Google-Hacking-Datenbank / Suche nach
          neuen Suchmustern
Die Technik des Google Hackings ist beliebt genug, um eine ganze Community mit
dem Finden von neuen, erfolgreichen Suchmustern zu beschäftigen. Grenzen liegen
  1 Programm,   das eine Sicherheitslücke für einen Angriff ausnutzt


                                                    11
hier nur in der Kreativität des Einzelnen. Zudem gibt es zu jeder neuen Web-Anwen-
dungs-Version auch neue Muster von Fehlermeldungen, bestimmte Namen von Konfi-
gurationsdateien etc.. Für einen guten Schutz ist es somit wichtig, über alle gängigen
Suchmuster auf dem Laufenden zu sein. Hierzu sollte man sich die Kreativität der
Gemeinschaft zunutze machen und die eigene Datenbank an Suchmustern regelmäßig
aktualisieren und erweitern. Ein Beispiel für die Datenbank einer Google-Hacking-
Community findet man unter [ghd07].
    Ein sinnvoller Weg, nach neuen Suchmustern zu forschen, ist, mit dem Betrach-
ten einer bekannten Sicherheitsschwäche zu beginnen, zum Beispiel einer bestimm-
ten Webserver-Version. Ein einfaches Beispiel: Angenommen, es ist bekannt, dass die
Datei passwords.pwd des Webservers xy v1.0 nicht ordentlich von der Öffentlichkeit
abgesichert ist. Dann lautet ein passendes Suchmuster: „inurl:passwords.pwd“.
    Das systematische Finden sinnvoller Suchmuster wird in Abschnitt 3.4.3 genauer
behandelt.


2.2.4    Exkurs: Die Verwendung von Google als Proxy-Server
Über den Übersetzungs-Dienst von Google kann man sich den Inhalt von Webseiten
anzeigen lassen, ohne sie direkt aufzurufen. Auf der Seite [goob] befindet sich ein Ein-
gabefeld für URLs. Nach Eingabe einer Adresse und Klick auf „Übersetzen“ befindet
sich in der resultierenden URL unter Anderem der Parameter „langpair“. Das Argu-
ment lautet an dieser Stelle beispielsweise „en|de“ für eine Übersetzung von Englisch
nach Deutsch. Wenn man dieses in „en|en“ oder „de|de“ ändert, findet keine Überset-
zung statt, und der User sieht die Webseite, wie sie im Original aussieht. Unabhängig
von diesem inhaltlichen Aspekt, kann man durch den Übersetzerdienst URLs aufrufen,
ohne von dem zugehörigen Server als Aufrufer registriert zu werden. Als aufrufender
Client wird vom jeweiligen Server ein Google-Server registriert.


2.2.5    Die Suche nach E-Mail-Adressen mittels Google
Das Ziel, E-Mail-Adressen zu finden, kann unterschiedliche Motivationen haben. Für
Versender von E-Mail-Werbung („Spammer“) ist die Motivation offensichtlich. Für
Angreifer eines Firmen-Netzwerkes können Mailadressen wertvoll für Social-Enginee-
ring-Attacken oder Ziel für Spionage-Code als Mailanhang sein. Aus diesem Grunde
machen es Google, Yahoo Search und Live Search ihren Usern nicht leicht, Mailadres-
sen zu finden. Die Suche nach dem „@“-Zeichen bzw. Zeichenketten, die dieses bein-
halten, bringt auf diese direkte Art und Weise kein Ergebnis. Es existiert allerdings
ein Weg, diese Einschränkung zu umgehen. Johnny Long demonstriert dies durch ein
Perl-Script (siehe [Lon05], S.128-134), welches auf das Sammeln von Mail-Adressen
aus dem World Wide Web und den „Google Groups“ spezialisiert ist. Der Trick besteht
hier darin, die Suche folgendermaßen zu formulieren:

 Beispiel 12 Suche nach Mail-Adressen

 @domain.com -www.domain.com

Hierdurch werden bei Google Mail-Adressen mit der Endung „@domain.com“ gefun-
den – allerdings nicht ausschließlich, sondern auch jede beliebige Formulierung, die
mit „@domain.com“ endet. Auch bei Yahoo Search führt diese Art von Suche zu dem
gewünschten Ergebnis, bei Live Search allerdings nicht.


                                          12
        Abbildung 2.5: Ergebnis der Suche nach @gmail.com -www.gmail.com



2.3      Weitere Suchmaschinen
Als Alternativen zu Google im Zusammenhang mit Suchmaschinen-Hacking sollten
vor Allem Live Search und Yahoo Search beachtet werden, denn ein wichtiges Kriteri-
um für die Verwendbarkeit stellen Größe und Aktualität der Suchindizes von Suchma-
schinen dar. Darüber verlässliche und glaubwürdige Aussagen zu machen ist natürlich
denkbar schwierig. Zudem haben die Marktführer zuletzt damit aufgehört, genaue In-
formationen darüber zu veröffentlichen. Ergänzend wären noch „Ask“ [ask] und „Ex-
alead“ [exa] zu erwähnen. Ein Aspekt, der insbesondere für eine Automatisierung der
Abfrage eine tragende Rolle spielt, ist das Vorhandensein einer API2 . Auch hier kom-
men einem die führenden Suchmaschinen entgegen: Google und Live Search mit einer
SOAP3 -API, Yahoo Search mit dem REST4 -Protokoll.

2.3.1     Windows Live Search
Die folgenden Parameter können bei einer Abfrage von Live Search benutzt werden
[ses07]:

   • contains: Das Suchergebnis wird auf Seiten eingegrenzt, die auf Dateien ver-
     linken, die den Dateityp haben, der als Parameter angegeben wird.

   • filetype: Grenzt das Suchergebnis auf einen bestimmten Dateityp ein.

   • inanchor: Der angegebene Suchbegriff muss als Bezeichner einer HTML-Anker-
     Tags in der Seite vorkommen.

   • inbody: Der angegebene Suchbegriff muss zwischen dem öffnenden und schlie-
     ßenden HTML-Body-Tag der Seite vorkommen.

   • intitle: Der angegebene Suchbegriff muss im HTML-Titel der Seite vorkom-
     men.

   • inurl: Der angegebene Suchbegriff muss in der URL der Seite vorkommen.

   • ip: Der Host der gefundenen Seite(n) muss die angegebene IP-Adresse haben.

   • language: Die Ergebnisseite muss in der Sprache verfasst sein, die durch einen
     zwei-Buchstaben-Code als Parameter angegeben wird (Bsp.: de = Deutsch, en =
     Englisch)
  2 Application Programming Interface
  3 Simple Object Access Protocol
  4 Representational State Transfer




                                         13
   • link: Es muss sich auf der Seite ein Link auf die als Parameter angegebene
     URL befinden.

   • linkdomain: Ein Link auf der Seite muss irgendwo unterhalb der angegebenen
     Domain liegen.

   • linkfromdomain: Gibt alle Links an, die von Seiten auf der angegebenen Do-
     main auf Seiten außerhalb dieser Domain verweisen.

   • loc:, location: Hier kann in Form eines zwei-Buchstaben-Codes angegeben
     werden, aus welchem Land die Ergebnisseiten stammen müssen.

   • prefer: Verändert die Reihenfolge der Suchergebnisse. Bsp.: „prefer:review“

   • site: Die Ergebnisseiten liegen alle unterhalb dieser Domain.

   • feed: Es werden Newsfeeds gesucht, die den hier als Parameter angegebenen
     Begriff beinhalten.

   • hasfeed: Findet Webseiten, die auf Feeds verweisen, die den hier angegebenen
     Begriff beinhalten.

   • url: Das Ergebnis dieser Anfrage informiert, ob der Inhalt der angegebenen
     URL im Index der Suchmaschine gespeichert ist.

   Ein sehr nützlicher Parameter, der in dieser Funktionalität bei keiner der anderen
Suchmaschinen vorhanden ist, ist die „ip:“-Suche. Hiermit ist es unter Umständen
möglich, mehrere Domains in einer Suche abzudecken.

2.3.2   Yahoo Search
Die Syntax der Yahoo-Suche ist derjenigen von Live Search und Google sehr ähnlich
[ses07].

   • intitle: Wie Live Search.

   • site:, domain: Wie „domain:“ bei Live Search.

   • link: Wie Live Search.

   • linkdomain: Wie Live Search.

   • url: Gibt als Suchergebnis den Eintrag genau dieser URL aus der Suchmaschi-
     nen-Datenbank wieder – falls vorhanden.

   • inurl: Wie Live Search.

   • originurlextension: Begrenzt die Ergebnisse auf den angegebenen Datei-
     typ.

   • feature: acrobat, applet, activex, audio, flash, form, frame,
     homepage, image, index, javascript, meta, script, shockwave,
     table, video, vrml – Durch den jeweiligen Parameter wird angegeben, wel-
     che Art von Elementen auf der Seite vorhanden sein soll.


                                         14
2.4     Vergleich verschiedener Suchmaschinen bezüglich
        ihrer Eignung für Suchmaschinen-Hacking
Grundsätzlich eignen sich die drei Suchmaschinen Google, Yahoo Search und Live
Search ähnlich gut für das Google Hacking. Größe, Verfügbarkeit und Geschwindig-
keit sind erfahrungsgemäß ähnlich (wobei die Ähnlichkeit der Größe der Indizes nur
ein Schätzwert sein kann). Zudem stellen alle drei eine API und einen Cache zur Ver-
fügung.
     Die Ähnlichkeit der drei Suchmaschinen zeigt sich wohl am deutlichsten in der
Syntax der Anfragen. Die Auswertung der bei der Suche angegebenen Parameter (sie-
he Abschnitte 2.2.1, 2.3.1 und 2.3.2) hat bei den verschiedenen Suchmaschinen aller-
dings minimale Unterschiede. So werden von Google bestimmte Parameter, die keinen
inhaltlichen Bezug zu den anderen – in derselben Anfrage angegebenen – Parameter
haben, aber verhindern, dass die Suche Treffer ergibt, missachtet. Die Anfrage nach
„inurl:(queen AND co.uk AND bundeskanzler)“ ergibt bei Google einen Tref-
fer, wobei nur das Wort „queen“ wirklich in der URL auftritt. Entfernt man den Be-
griff „bundeskanzler“ aus der Anfrage, liefert Google hingegen die erwarteten Treffer
– nämlich Seiten, deren URLs die Zeichenfolgen „queen“ und „co.uk“ enthalten.
     Ein (bereits erwähnter) Unterschied der Suchmaschine, welcher relevant für auto-
matisiertes Google Hacking ist, besteht in der Anzahl von Anfragen, die mittels der
jeweiligen API pro Tag möglich sind. Über bestimmte Umwege wie Wechsel der an-
fragenden IP oder Beschaffung weiterer Lizenzschlüssel lässt sich dies aber ggf. um-
gehen.
     Es stellt sich noch die Frage, ob eine Suchmaschine erfahrungsgemäß mehr Treffer,
die für das Google Hacking relevant sind, liefert als andere Suchmaschinen. Unabhän-
gig davon, dass sich dies im Laufe der Verwendung der drei Suchmaschinen nicht ab-
gezeichnet hat, ist die Frage irrelevant – denn da die Suchmaschinen unterschiedliche
Webcrawler verwenden und unterschiedliche Inhalte in ihren Indizes speichern, ist es
nicht vorhersehbar, ob ein Fund im Index der einen Suchmaschine auftaucht, im Index
der anderen Suchmaschine aber nicht.
     Insgesamt hat die Erfahrung gezeigt, dass ein einzelnes Suchmuster aus den ver-
schiedenen Suchmaschinen oft verschiedene, aber gleichermaßen wertvolle (im Sinne
der Erkennung von Sicherheitsschwächen) Ergebnisse zutage fördert. Somit sind die
drei Suchmaschinen im Google Hacking eine sinnvolle Ergänzung füreinander.



2.5     Die Reichweite von Webcrawlern der Suchmaschi-
        nen
Das Crawling von Webseiten erfolgt bei Google, Live Search und Yahoo Search nur,
soweit es durch die Konfiguration einer evtl. vorhandenen robots.txt – bzw. im Falle
von Google zusätzlich in einer sitemap.xml (siehe Abschnitt 6.3– erlaubt ist. Google’s
Webcrawler („Googlebot“) ruft – soweit erlaubt – alle URLs oder relativen Links auf,
welche mittels eines HREF- oder SRC-Tags in einer bereits indizierten HTML-Datei
vermerkt sind [gooe]. Zudem werden Links in Shockwave-Flash-Objekten erkannt. Die
Erfahrung zeigt zudem, dass absolute URLs innerhalb von Javascript ebenfalls erkannt
werden. Der Webcrawler von Live Search („Msnbot“) verarbeitet ebenfalls alle wohl-
geformten HTML-Link-Tags [livc]. Der Crawler von Yahoo Search („Slurp“) ruft im


                                         15
Gegensatz zu den beiden anderen Suchmaschinen nur Links auf, die in einem HREF-
Tag genannt sind, und beachtet Links in SRC-Tags nicht [yahc].


2.6     Suchmaschinen-Caches und ein Internet-Archiv
Eins der interessantesten – und im Bezug auf Google Hacking auch gefährlichsten –
Features von Google ist der so genannte „Google-Cache“. Dieser Zwischenspeicher
enthält so genannte „Schnappschüsse“ von Seiten, deren Inhalt sich im Google-Index
befindet. Das heißt: Die Grundzüge des Seitenaufbaus und sein gesamter textueller In-
halt werden zum Zeitpunkt des Fundes auf einem Google-Server abgespeichert. Mit
Hilfe des „Cache:“-Operators und einer URL als Parameter kann der Schnappschuss
dann vom Google-User betrachtet werden. Hierbei werden Grafiken, die auf der Sei-
te vorhanden sind, normalerweise vom Original-Server nachgeladen. Der Aufrufer der
Grafiken ist hierbei der User, der den Google-Cache betrachtet. Seine Anonymität ist
somit also nicht geschützt. Das Nachladen der Grafiken kann allerdings durch An-
hängen des Parameter „&strip=1“ an die URL des Google-Cache verhindert werden.
Somit erhält der Betreiber der betrachteten Seite keinen Hinweis darauf, dass jemand
die Grafiken evtl. im Zusammenhang mit dem Google-Cache und einer älteren Versi-
on seiner Seite betrachtet. Wenn nun ein Google-Hacker durch die Suchmaschine die
URL einer Seite gefunden hat, welche vertrauliche Informationen beinhaltet, kann es
sein, dass der Eigentümer der vertraulichen Informationen das Dokument schon aus
dem Internet entfernt hat, und dieses somit nicht mehr zugänglich ist. Allerdings sind
die vertraulichen Informationen ggf. immer noch im Google-Cache zu finden.
     Das gleiche Angebot existiert auch jeweils bei Yahoo Search und Live Search. Die
„Caches“ dieser Anbieter bieten allerdings nicht die Möglichkeit, Grafiken nicht vom
Server des Urhebers des Inhalts nachzuladen. Allerdings bieten die meisten Internet-
Browser die Möglichkeit, das Laden von Grafiken komplett abzuschalten. Zudem exis-
tiert ein Online-Archiv, welches sich auf das Festhalten von Schnappschüssen belie-
biger Webseiten konzentriert hat: Das so genannte „Internet Archive“ [arc] mit seiner
so genannten „Wayback Machine“. Hier finden sich sogar Schnappschüsse zu mehre-
ren Zeitpunkten von zahlreichen Internet-Seiten. Je „populärer“ eine Webseite, desto
mehr verschiedene Zeitpunkte wurden zur Aufnahme eines Schnappschusses gewählt.
Nach eigenen Angaben hat das Internet Archive derzeit etwa 55 Billionen verschiedene
Seiten mit jeweils mehr oder weniger Versionen in seinem Schnappschuss-Archiv. Die
eigene Suchmaschine von Internet Archive, durch welche dieses Archiv durchsucht
werden kann, liefert eher unzuverlässige Ergebnisse – das heißt, dass trotz vorhande-
nem Schnappschuss einer Seite diese durch die Eingabe eines Stichwortes, welches auf
dieser Seite auftritt, nicht unbedingt gefunden wird. Zum Suchmaschinen-Hacking ist
die Seite daher nur bedingt geeignet. Sollte man allerdings durch Hacking über eine
andere Suchmaschine kritische bzw. vertrauliche Daten gefunden haben, sollte über-
prüft werden, ob diese Informationen im Internet Archive ebenfalls zu finden sind.

    Im Laufe der Arbeit mit den Suchmaschinen entstand die Frage, wie aktuell der
Inhalt der Suchmaschinen-Caches ist. Das heißt: Wie lange dauert es, nachdem ein
Webcrawler einer Suchmaschine eine Webseite gelesen hat, bis der gelesene Inhalt die-
ser Webseite im jeweiligen Suchmaschinen-Cache erscheint? Hierfür wurde über einen
Zeitraum von 7 Tagen das Abbild der Homepage der Firma T-Mobile in den Caches
der Suchmaschinen betrachtet. Im Quelltext dieser Homepage befindet sich eine Zeit-
angabe, die anzeigt, zu welchem Zeitpunkt die Seite gelesen wurde. Zu dem Zeitpunkt,


                                         16
zu welchem sich diese Angabe im Cache einer Suchmaschine ändert, weiß man, dass
die Differenz zwischen dem aktuellen Zeitpunkt und dem im Quelltext angegebenen
Zeitpunkt die Dauer ist, die das Suchmaschinen-System benötigt hat, um die eingele-
sene Information an den Cache zu übermitteln. Die Erfahrungswerte dafür konnten für
Google und Yahoo Search ermittelt werden und sind in Tabelle 2.1 aufgeführt.

        Zeit bis zur Aktuali-   Ø         Min.      Max.     Anz. Messun-
        sierung                                              gen
        Google                  45,2h     18,8h     65,5h    4
        Yahoo Search            15,6h     2,5h      61,5h    26

 Tabelle 2.1: Zeit zwischen Besuch durch Webcrawler und Aktualisierung des Cache




2.7    Zusammenfassung
In diesem Abschnitt wurde ein grundlegender Überblick über die Techniken des Goo-
gle Hackings gegeben. Es wurde deutlich gemacht, dass sich nicht nur Google für die
Suche nach sensiblen Informationen eignet, sondern auch einige andere Suchmaschi-
nen, die aufgrund der Syntax der an sie zu sendenden Anfragen ähnliche Möglichkeiten
bieten. Dass dies nicht der einzige Faktor ist, der Einfluss auf die Möglichkeiten des
Hackings mittels Suchmaschinen Einfluss hat, wurde durch einen Blick auf die Web-
crawler der Suchmaschinen verdeutlicht.
    Ein Aspekt, der eine besondere Dimension der Möglichkeiten des Google Hackings
eröffnet, sind die so genannten Suchmaschinen-Caches. Hier können vollständige Do-
kumenten-Inhalte zu finden sein, auch wenn sie vom betroffenen Server längst entfernt
wurden.
    Im Folgenden wird die Systematisierung und Automatisierung des Google Hackings
beschrieben. Ziel wird hierbei sein, die Grundlage für ein Werkzeug zu schaffen, das
automatisiertes Google Hacking durchführt.




                                        17
Kapitel 3

Vulnerability-Scanning mittels
Google Hacking

3.1     Einleitung
In diesem Kapitel werden die Möglichkeiten für systematische Anwendung von Goo-
gle Hacking bei der Überprüfung von Webservern auf Verwundbarkeit betrachtet. Es
soll also erörtert werden, ob sich Google Hacking prinzipiell als Methode für das Vul-
nerability Scanning eignet. Diese Art des Überprüfens von IT-Systemen auf Verwund-
barkeit wird dafür zunächst erläutert. Dann wird eine systematische Vorgehensweise
bei einem „Google Scan“ beschrieben. Das betrifft die Planung, Durchführung und
Nachbereitung eines solchen Vorgangs.
    Dieses Kapitel soll die Grundlage für die Entwicklung eines automatisierten Google-
Hacking-Tools bilden, welche in Kapitel 4 detailliert beschrieben wird.


3.2     Vulnerability Scanning
Im Allgemeinen wird durch einen „Vulnerability Scan“ ein IT-System größtenteils au-
tomatisiert auf Anfälligkeiten gegenüber bestimmten Angriffsmustern überprüft. Bei
einem so genannten „Penetrationtest“ hingegen wird ein IT-System auf seine Anfäl-
ligkeit gegenüber Angriffen durch größtenteils manuelles Hacking getestet. Hierbei
wird weniger automatisiert gearbeitet, um individuelle Möglichkeiten nutzen zu kön-
nen, einen erfolgreichen Angriff durchzuführen.
    Nach diesem Verständnis der beiden Begriffe wäre automatisiertes Google Hacking
zum Schutz eines Netzwerks somit eher als eine Art Vulnerability Scan zu bezeich-
nen. Die Automatisierung ist sinnvoll, da die Anzahl der möglichen Google-Hacking-
Suchmuster zu groß ist, als dass sie alle in regelmäßigen Zeitabständen manuell einge-
geben werden könnten. Eine automatisierte, in einem festgelegten Zeitintervall durch-
geführte Suche nach einer Menge von Suchmustern, die regelmäßig durchgeführt wird,
kann einen Administrator zeitnah zum Auftreten eines Informtionslecks informieren –
ohne dass hierbei für ihn ein zu großer Aufwand entsteht. Hierbei ist wichtig, dass
möglichst alle Treffer der Suche ausgewertet – d.h. in Augenschein genommen und
hinsichtlich ihrer Kritikalität bewertet – werden, und dass der Administrator nicht öfter
als einmal über ein und denselben Fund informiert wird.

                                           18
    Für die Bezeichnung einer automatisierten Suche mittels vieler Suchmuster wird
im Folgenden der Begriff „Google-Scan“ verwendet. Ein Google-Scan ist somit das
automatisierte Senden (großer) Mengen von Suchmustern an eine Suchmaschine wie
Google mit nachfolgender Entgegennahme aller Suchergebnisse.
    Die Idee des Vulnerability Scanning mittels Google Hacking wurde bereits teilwei-
se von Software-Herstellern oder privaten Entwicklern umgesetzt. Diese Programme
werden kurz vorgestellt. In den weiteren Abschnitten werden die eingangs erwähn-
ten „Google Web Services“ und „Google Alerts“ betrachtet und hinsichtlich ihrer Ver-
wendbarkeit für systematisches Google Hacking bewertet. Abschließend werden – auf-
bauend auf den Erfahrungen aus den vorhergehenden Kapiteln – die für das „Google“
Hacking verwendbaren Suchmaschinen ebenfalls in Bezug auf diesen Aspekt vergli-
chen.


3.3     Anwendung von Google Hacking
Google Hacking kann in verschiedenen Größendimensionen durchgeführt werden und
verschiedene Zielsetzungen haben - zum Beispiel eher auf allgemeine Verwundbarkeit
eines Severs ausgerichtet, oder aber auf eine spezielle Information. Für einen Vulnera-
bility Scan sind alle prinzipiell möglichen Ziele zu beachten; die Anzahl der Anfragen
an Suchmaschinen wird dabei folglich sehr hoch.

3.3.1    Voraussetzungen
Die Voraussetzungen für angewandtes Google Hacking sind im Allgemeinen sehr ge-
ring. Für die Eingabe eines einzelnen Suchmusters in das Eingabefeld einer Suchma-
schine genügt ein Internet-Zugang und ein installierter Browser auf dem Computer
des Google Hackers. Geht es allerdings um komplette Google-Scans, sind die Voraus-
setzungen evtl. etwas höher – jedoch auch nicht bedeutend. Ein systematischer Scan
basiert auf einem Algorithmus. Dieser kann auf verschiedenste Weise implementiert
werden. Wichtig ist, dass das Programm die Fähigkeit besitzt, auf die Web-Dienste
von Google bzw. anderer Suchmaschinen zuzugreifen. Im Falle der Dienste von Live
Search und Google ist hierzu jeweils die Beantragung eines Registrierungsschlüssels
notwendig. Während des Zeitraums der Fertigstellung dieser Diplomarbeit wurde sei-
tens Google die Herausgabe neuer Registrierungsschlüssel jedoch gestoppt [good]. Für
Live Search sind jedoch weiterhin Registrierungsschlüssel erhältlich [livd].

3.3.2    Ziele
Ein Vulnerability Scan bezüglich Google Hacking bzw. ein „Google-Scan“ sollte Ant-
worten auf die folgenden Fragen liefern:

   1. Welche sensiblen Informationen oder Angriffspunkte innerhalb des per Internet
      zugänglichen Netzwerk-Bereichs bzw. Webauftritts einer Firma lassen sich mit-
      tels bestimmter Suchmaschinen entdecken?

   2. Welche Suchergebnisse wurden bereits betrachtet und bewertet, bzw. bei wel-
      chen Ergebnissen ist dies noch nicht geschehen?

   3. Sind Funde von sensiblen Informationen, die schon gemacht (und ggf. bewertet)
      wurden, weiterhin in der jeweiligen Suchmaschine verfügbar?


                                          19
Die Lösungsansätze zu diesen Punkten beziehen sich auf die konkrete Implementierung
eines Google-Scans.
     Um Punkt 1 zufriedenstellend zu klären, sollten so viele Suchmaschinen wie mög-
lich genutzt werden. Zudem muss eine Möglichkeit gefunden werden, auch die öf-
fentlich zugänglichen Informationen zu finden, welche zwar noch nicht in einen öf-
fentlichen Suchindex aufgenommen wurden, aber theoretisch gefunden und dort auf-
genommen werden könnten. Um alle potentiellen Angriffspunkte zu erkennen, ist es
wichtig, eine möglichst umfassende und aktuelle Liste von möglichen Suchmustern
einzusetzen. Hierbei sollte grundsätzlich klar sein, dass man wohl niemals eine wirk-
lich vollständige Liste von Suchmustern haben wird. Somit sollte eine Strategie zur
regelmäßigen Aktualisierung der Liste verfolgt werden.
     Für Punkt 2 ist eine sinnvolle Methode für den Vergleich zwischen bereits be-
trachteten und bewerteten Funden, und den stetig weiter auftretenden Funden notwen-
dig. Die Bewertung eines Fundes sollte aussagen, welche Gefahr von ihm ausgeht,
bzw. implizieren, welche Maßnahmen zum Schutz vor dieser Gefahr einzuleiten sind.
Von den Suchmaschinen erhält man auf eine Anfrage eine Menge von Kombinationen
aus URLs, Seiten-Fragmenten und Titel-Beschriftungen. Falls der Inhalt des Seiten-
Fragments und des Titels in Kombination mit einer bestimmten URL sich zu einem
späteren Zeitpunkt eines Fundes im Vergleich zum vorherigen Zeitpunkt nicht geändert
haben, ist davon auszugehen, dass sich auch der Inhalt der Seite im Index der Such-
maschine nicht geändert hat. Diese Annahme wird aus Effizienzgründen getroffen, da
eine weitergehende Untersuchung eines jeden Wiederauftritts eines Fundes in der Pra-
xis wohl kaum zu bewältigen wäre. Eine Bewertung eines Fundes ist erfahrungsgemäß
kaum automatisiert zu bewältigen, sondern erfordert stets einen geschulten Adminis-
trator oder Experten für Web-Sicherheit. Ein gewisses Maß an personellem Aufwand
ist somit nicht zu vermeiden. Falls also eine Kombination aus URL, Seiten-Fragment
und Seitentitel zu einem Zeitpunkt gefunden wird, zu welchem dieselbe Kombination
bereits gesichtet und bewertet worden ist, sollte diese Bewertung für den neuen Fund
übernommen werden.
     Punkt 3 hat vor allem in den Fällen eine hohe Bedeutung, in denen sich die gefunde-
nen Informationen im Suchmaschinen-Index nicht auf eine Sicherheitslücke beziehen,
die leicht zu schließen ist, sondern so sensibel sind, dass sie zu keinem Zeitpunkt an
die Öffentlichkeit gelangen sollten (wie etwa geheime Firmendokumente). Das Datum
des letzten Fundes sollte somit stets aktualisiert und zur leichten Betrachtung verfügbar
sein.


3.4     Ablauf des Google-Scans
Ziele eines Vulnerability-Scans mittels Google Hacking sind Webseiten, Web-Anwen-
dungen und Computer-Netzwerke, was im Folgenden unter dem Begriff „IT-Systeme“
zusammengefasst wird.
    Ein Google-Scan eines IT-Systems bezüglich Google Hacking erfordert Vorarbeit.
Hinsichtlich Punkt 1 der Liste aus Abschnitt 3.3.2 müssen noch folgende Punkte müs-
sen geklärt werden:
   1. Welche Domains sollen untersucht werden?
   2. Wo außerhalb der ausgesuchten Domains laufen Webapplikationen bzw. gibt es
      sensible Informationen, die geschützt werden sollen? Gibt es also weitere Do-
      mains oder URLs, die einbezogen werden sollten?


                                           20
   3. Welche Suchmuster sollten sinnvollerweise für den Scan benutzt werden?

   4. Welche Suchmaschinen sollten verwendet werden?

   5. Welche kurzfristigen Maßnahmen sind nach einem kritischen Fund einzuleiten?

   6. Wie können sensible Informationen schon entdeckt werden, bevor sie in öffent-
      liche Suchindizes aufgenommen werden?

Diese Punkte sollen in den folgenden Abschnitten im Einzelnen geklärt werden. Um
die bestehenden Möglichkeiten im Google Hacking genauer zu sehen, wird zunächst
einleitend in Abschnitt 3.4.1 geklärt, welche Einschränkungen hier bestehen. Punkte
1 und 2 werden in Abschnitt 3.4.2 behandelt, Punkt 3 in Abschnitt 3.4.3. Zu Punkt 4
wurde bereits in Abschnitt 2.3 erläutert, warum zum jetzigen Zeitpunkt Live Search
und Yahoo Search als Ergänzung zu Google zu empfehlen sind. Diese Empfehlung
kann sich im Laufe der Zeit und Marktentwicklung natürlich ändern.
    Unter Berücksichtigung der weiteren Punkte aus Abschnitt 3.3.2 wird in Abschnitt
3.4.4 ein langfristiger Ablaufplan für einen Vulnerability Scan entwickelt. Auch in die-
sem langfristigen Plan stellt sich stets erneut die Frage, wie Funde als kritisch erkannt
und bewertet werden können. Um diesen entscheidenden Punkt geht es in Abschnitt
3.4.6. Zu Punkt 5 aus der obigen Liste werden Empfehlungen in Abschnitt 3.4.7 gege-
ben.
    Der sich aus dem Gesamtablauf ergebende Aufwand wird separat in Abschnitt 4.3
betrachtet. Punkt 6 bezieht sich bereits auf eine präventive Abwehrmaßnahme gegen
Google Hacking (siehe Kapitel 6) und wird daher in Abschnitt 6.2 behandelt.


3.4.1    Probleme / Einschränkungen des Google Hackings
Durch die Suchmaschinen Google, Yahoo Search und Live Search können nicht alle
Elemente aus dem Quellcode von Webseiten gefunden werden. Bis auf den rein tex-
tuellen Inhalt, Hyperlinks, den Titel und die URL einer Seite betrifft dies alle anderen
HTML-Tags oder Script-Bestandteile. Somit können beispielsweise keine Eingabefor-
mulare gesucht werden.
    Eine weitere, stets präsente Einschränkung besteht in der Unvollständigkeit der Su-
chindizes. Ein Suchindex ist immer nur so aktuell, wie es die Arbeitsgeschwindigkeit
seines zugehörigen Webcrawlers zulässt, bzw. von der Frequenz der Besuche des Web-
crawlers auf allen relevanten Webseiten. Außerdem hängt die Vollständigkeit des Su-
chindexes immer von den Fähigkeiten zur Link-Erkennung durch den Webcrawler ab.
Spezielle Link-Formate in Javascripts, Flash-Objekten oder anderen Inhalten werden
vielleicht nicht momentan, aber möglicherweise in zukünftigen Versionen des Crawlers
erkannt.
    Zudem können nicht alle Dokumenten-Formate zuverlässig erkannt werden.Von
Google beispielsweise werden txt, pdf, ps, doc, xls, ppt, rtf und weitere Formate unter-
stützt, wobei diese Fähigkeiten laut Google kontinuierlich erweitert werden. Dennoch
werden beispielsweise textuelle Inhalte von Bildern nicht in den Inhalt aufgenommen.
    Eine Grenze des Google Hacking besteht zudem in der Anzahl von Suchmustern,
die an die Suchmaschine gesendet werden dürfen. Diese Restriktion wurde von jeder
der drei hier betrachteten Suchmaschinen unterschiedlich gesetzt:

   • Google: 1 Lizenzschlüssel pro Person; 1000 Anfragen pro Tag und Lizenzschlüs-
     sel

                                           21
   • Live Search: 1 Lizenzschlüssel pro Person; 10000 Anfragen pro Tag, Lizenz-
     schlüssel und anfragender IP

   • Yahoo Search: 5000 Anfragen pro Tag und anfragender IP

Die Limitation der Anzahl von Anfragen kann also in den Fällen von Live Search und
Yahoo durch die Verwendung verschiedener IPs abgeschwächt werden.

3.4.2   Finden aller relevanter Domains bzw. Webapplikationen
Zum Finden aller für das Google Hacking bzgl. einer bestimmten Firma relevanten
Domains gibt es verschiedene Vorgehensweisen:

   • Information durch eine zentrale Domainverwaltung

   • Erkennen Unternehmens-eigener Webseiten durch spezielle Merkmale

   • Nutzung einer Domain-Suche wie beispielsweise „Domaxx“ [dom]

     Gerade bei einem größeren Unternehmen ist oft nicht klar, welche Domains zu ihm
gehören bzw. auf welchen Domains Anwendungen des Unternehmens laufen, oder auf
welchen Internetseiten Informationen zu finden sein könnten, die für das Unterneh-
men sensibel sind. Da aber ein Vulnerability-Scan mittels Google Hacking stets auf
bestimmte Domains eingeschränkt werden sollte, ist es wichtig, alle relevanten Do-
mains zu kennen und mit einzubeziehen. Hilfreich wäre an dieser Stelle, wenn alle
Domains, welche vom Unternehmen oder in Projekten eines Unternehmens eingesetzt
werden, an einer zentralen Stelle verwaltet werden. Aber dies ist in der Praxis nicht
immer der Fall. Ähnlich zu dieser Herangehensweise ist die Idee, beispielsweise bei
der DENIC [denb] oder ICANN [ica] die Information einzuholen, welche Domains auf
das Unternehmen registriert sind. Im allgemeinen wird diese Art von Anfrage jedoch
nicht ermöglicht (siehe [dena]). Ein freier Zugriff auf eine WHOIS-Datenbank könnte
das Problem jedoch lösen.
     Eine Idee wäre, alle Webseiten eines Unternehmens durch eine bestimmte, in den
Text integrierte Zeichenfolge – eine Art Wasserzeichen – kenntlich zu machen. In der
Praxis könnte dies eine Hilfe darstellen, doch könnte man auch hierbei nicht davon
ausgehen, wirklich alle relevanten Seiten zu finden. Für Inhalte, die unbeabsichtigt in
die Öffentlichkeit gelangten, könnte man nicht von einer vorherigen Kennzeichnung
ausgehen. Zudem könnte diese Markierung eine Hilfe für potentielle Angreifer darstel-
len.
     Der Ansatz, etwa über die Google-Bildersuche nach dem Dateinamen eines Fir-
menlogos zu suchen, führt zu keinem sinnvollen Ergebnis, wie die Suche nach „t-
mobile-logo.gif“ zeigt. Die hier gefundenen Webseiten gehören nur in einem ge-
ringen Anteil wirklich zu der Firma T-Mobile.
     Eine weitere Idee ist die Suche nach Stichworten innerhalb von Domainnamen, was
zum Beispiel mit der speziellen Domain-Suchmaschine „Domaxxx“ [dom] möglich ist.
Die Möglichkeit der Suche nach Stichworten innerhalb von Domainnamen wird von
Google, Yahoo Search und Live Search nicht geboten.

3.4.3   Finden sinnvoller Suchmuster
Grundsätzlich gibt es verschiedene Wege, Suchmuster zu finden, die für einen Google-
Scan sinnvoll sind. Diese sind im Wesentlichen:

                                         22
   1. Verwendung aller bekannten Suchmuster

   2.   (a) „Schüsse ins Blaue“
        (b) Verwendung charakteristischer Muster von relevanten Treffern nach Schüs-
            sen ins Blaue

   3. Untersuchung von Webapplikationen und Anpassung von Standard-
      Suchmustern

   4. „Leetspeech“-Varianten von Domainnamen

In einem umfassenden Vulnerability Scan gilt grundsätzlich, dass man stets das Uner-
wartete erwarten sollte. Die gefährlichsten Sicherheitslücken sind oft diejenigen, von
deren Existenz man noch nicht mal etwas ahnt. Darum sollten stets alle Suchmuster
eingesetzt werden, die zur Verfügung stehen. Als Basis für eine Sammlung an Such-
mustern bietet sich die Google Hacking Database (GHDB) [ghd07] der Community
um Johnny Long an.

    Der „Schuss ins Blaue“ klingt zunächst nach einer unzuverlässigen Methode, um
systematisch Sicherheitsschwächen auf die Spur zu kommen. In der Praxis sollte sie
allerdings nicht unterschätzt werden, da hierdurch auch solche Schwächen oder sensi-
ble Informationen gefunden werden können, die von den bekannten Suchmustern nicht
erfasst werden können. Ein Beispiel für den Schuss ins Blaue ist das folgende Such-
muster:

 Beispiel 13 Suche nach beliebigen Subdomains

 site:domain.de -www.domain.de

    Was dieses Suchmuster findet, sind alle Subdomains der Domain „domain.de“ –
ausgenommen „www.domain.de“. Die Suche bezieht sich also keinesfalls auf Sicher-
heitsschwächen oder sensible Daten. Jedoch kann sie erstens Aufschluss darüber ge-
ben, welche bisher womöglich unbeachteten Webanwendungen auf den Firmendo-
mains laufen. Zweitens kommt es in der Praxis regelmäßig vor, dass eine dermaßen
unspezifische Suche überraschende Fehlermeldungen oder unerwartete Offenlegungen
privater Daten zu Tage fördert, welche eben durch die bisher eingesetzten Suchmuster
nicht gefunden werden konnten. Auf Basis dieser neuen Funde können dann spezifi-
ziertere Suchmuster erstellt und in zukünftigen Scans eingesetzt werden.

    Eine weitaus systematischere Art des Findens sinnvoller Suchmuster liegt in der
Analyse vorhandener und bekannter Webapplikationen. Ein Beispiel: Angenommen,
eine Firma besitzt auf ihrer Website ein Portal, auf welchem sich Geschäftskunden
einloggen können, um Bestellungen vorzunehmen. Der HTML-Code dieses Portals
könnte u.a. den folgenden Ausschnitt beinhalten:

 Beispiel 14 Code-Fragment eines Login-Portals

 <form name="login" type="GET">
    <input type="text" name="id">
    <input type="password" name "pword">
    <button type="submit">Login</button>
 </form>

                                         23
Aus den Namen der beiden Input-Felder ergeben sich Ansätze für die Suche. Wie man
in diesem Falle deutlich sieht, erlaubt das Formular die Übertragung der Login-Daten
durch die „GET“-Methode. Somit ist es möglich, Daten mittels einer URL an das For-
mular zu übergeben. Ein Kunde könnte seine Login-Daten also als Link ablegen. Das
wäre natürlich genauso wenig im Interesse des Kunden, wie in dem der Firma, wenn
man den Sicherheitsaspekt betrachtet. Finden könnte man solche Links beispielsweise
durch das folgende Suchmuster:
 Beispiel 15 Spezialisierte Suche nach Zugangsdaten

 site:firmenname.de inurl:pword
Als Nächstes sollte untersucht werden, welche Software auf den Hosts der Webser-
ver installiert ist, auf welchen die Inhalte zu den relevanten Domains liegen. Zu jeder
Software gibt es normalerweise eine Menge von typischen Fehlermeldungen. Manche
dieser Fehlermeldungen können Informationen preisgeben, die etwas über die innere
Struktur eines Servers verraten. Ein Beispiel dafür ist PHP, die Basis vieler Webseiten.


 Beispiel 16 PHP-Fehlermeldung
 Fatal error: Call to undefined function:
 exif_read_data() in E:\Webpool\Album01\showpic.php
 on line 91.
Wie man an Beispiel 16 sehen kann, ist bei einer vorhandenen PHP-Installation die
Suche nach „Fatal Error:“ also ein sinnvoller Ansatz, um Fehlermeldungen aufzu-
spüren, die sensible Informationen veröffentlichen.

    Die Suche nach so genannten „Leetspeech“-Varianten von Domainnamen eines
Unternehmens ist keine Art von Suchmuster, wie sie von Google-Hackern verwendet
wird, um Informationen zu finden, die auf den Servern des Unternehmens liegen. Viel-
mehr können diese Domainnamen die Basis für Phishing-Attacken bilden, indem bei-
spielsweise ein Login-Portal vorgetäuscht wird, auf welchem Firmenkunden zur Einga-
be ihrer Login-Daten aufgefordert werden. Die Leetspeech-Schreibweise soll hierbei
der Original-Schreibweise möglichst ähnlich sehen und optisch nicht unterscheidbar
sein. Dies wird ansatzweise in Beispiel 17 deutlich, in welchem in der gefälschten
Version der Domain das „l“ durch eine „1“ ausgetauscht wurde. Bei Verwendung von
anderen Zeichensätzen kann der sichtbare Unterschied deutlich geringer ausfallen.
 Beispiel 17 Optische Fälschung eines Domainnamens

 Original: http://www.t-mobile.de
 Fälschung: http://www.t-mobi1e.de
Die Suche nach solcherlei Domains ist allerdings auch ohne Hilfe von Google ohne
großen Aufwand automatisiert durchführbar und spielt hier daher eher eine unterge-
ordnete Rolle.

3.4.4    Langfristiger Ablaufplan
Google Hacking bezüglich des eigenen Web-Inhalts eines Unternehmens sollte sinn-
vollerweise ein langfristiger, ständig überprüfender Vorgang sein. Maßgeblich für die

                                          24
Anzahl der täglich durchgeführten Anfragen kann die Limitation an durchführbaren
Anfragen an eine Suchmaschine pro Tag sein. Allerdings wäre es prinzipiell denk-
bar, dass nicht unbedingt jeden Tag ein kompletter Scan einer Suchmaschine durchge-
führt werden muss. Ein erneuter Scan ist schließlich nur dann sinnvoll, wenn die Daten
im Index der Suchmaschine von denen zum letzten Zeitpunkt der Durchführung ei-
nes Scans abweichen. Also sollte zwischenzeitlich der Crawler der Suchmaschine den
Inhalt des zu schützenden Servers erneut indiziert haben. Wie oft dieser Crawler das
tut, ist – mit Ausnahme von Google, da dort eine Kontrollmöglichkeit mit Hilfe der
sitemap.xml besteht – schwierig vorherzusagen. Ein Crawler kann allerdings beim In-
dizieren des Web-Inhalts eines Servers erkannt werden, da das Feld „User-Agent“ im
HTTP-Header ihrer Anfragen jeweils charakteristische Bezeichnungen enthält, oder
der Crawler von bestimmten IPs aus agiert. Denkbar wäre also, das regelmäßige Scan-
nen der Suchmaschinen so zu organisieren, dass ein neuer Scan genau dann fällig wird,
wenn ein erneuter Besuch durch einen Webcrawler der Suchmaschinen aufgetreten ist.
Allerdings setzt dies voraus, dass die Crawler ihre Bezeichnungen tatsächlich stets in
Form der „User-Agent“-Information übermitteln oder eine feste bekannte Menge von
IPs verwenden. Sie müssten also immer identifizierbar sein. Zudem müsste bekannt
sein, wie lange es nach Besuch eines Webcrawlers dauert, bis die neu gesammelten
Informationen im Suchmaschinen-Index bzw. -Cache verfügbar sind. Für diese Zeit-
dauer könnte man einen Erfahrungswert verwenden. In Tabelle 2.1 sind einige dieser
Erfahrungswerte zu sehen.
     Langfristig wird für die Suchmaschinen-Scans der Algorithmus aus Abbildung 3.1
durchgeführt. Hierbei sind für die beiden äußeren Schleifen alternative Definitionen
angegeben – je nach Planungsweise neu durchzuführender Scans. Durch den Teil von
Z.15-23 des Listings wird dauerhaft sichergestellt, dass jeder Fund mindestens einmal
betrachtet und bewertet wird. Dieser Algorithmus in Pseudocode soll allerdings nur
einen ersten Eindruck von der langfristigen Vorgehensweise vermitteln und ist daher
nicht vollständig. Eine konkrete Implementierung (mit der ersten Variante der äußeren
Schleifen) ist in Listing A.1 zu sehen.

3.4.5    Tiefe der Suche
Durch die Suchmaschinen wird nach einer Anfrage stets nur eine begrenzte Menge von
Treffern als Antwort geliefert. Angenommen eine Anfrage ergibt 10.000 Treffer. Von
Google erhielte man nach einer Anfrage nur 10 Ergebnisse innerhalb einer Antwort (in
der Web-Schnittstelle der Google-Suche kann dieser Wert zwar auf 100 erhöht werden;
das ist bei der SOAP-Schnittstelle, auf die man im automatisierten Google-Hacking an-
gewiesen ist, allerdings nicht möglich.). Inkrementell können nun Treffer 11-20, 21-30,
usw. durch weitere Anfragen geliefert werden. Obwohl es nun aber (laut Angaben der
Suchmaschine) insgesamt 10.000 Treffer gibt, können Treffer, die über die 1000. Stelle
(im Einzelfall bis ca. 200 Stellen darunter) hinausgehen, nicht mehr abgerufen werden.
Diese Limitierungen sind bei den Suchmaschinen unterschiedlich: Um ein IT-System
also wirklich vollständig zu durchsuchen, muss man berücksichtigen, ggf. bis zu 1000
Treffer pro Anfrage zu untersuchen. Dies kann allerdings im Falle eines ungenauen
Suchmusters oder einer unerwartet ungenauen Reaktion der Suchmaschine (was in der
Praxis durchaus der Fall sein kann) zu sehr vielen Falschtreffern führen, was den Auf-
wand für die Bewertung der Treffer zu hoch werden ließe. Die „Tiefensuche“ bis zur
Grenze von 1000 Treffern sollte also nur durchgeführt werden, wenn aus Erfahrung ge-
sagt werden kann, dass nicht zu viele Falschtreffer geliefert werden, die den Aufwand
zu sehr erhöhen würden. Um Verwundbarkeiten zu finden, die durch die in der Da-


                                          25
 1   / / Entweder :
 2   Für j e d e n f e s t g e l e g t e n I n t e r v a l l a b s c h n i t t {
 3      Für j e d e Suchmaschine {
 4

 5   / / Oder :
 6   Zu jedem Besuch e i n e s W e b c r a w l e r s + e r f a h r u n g s g e m ä ß e W a r t e z e i t
 7            b i s Informationsaufnahme in Index {
 8      F ü r d i e zum W e b c r a w l e r g e h ö r i g e S u c h m a s c h i n e {
 9

10   / / In j e d e r Variante :
11        F ü r j e d e r e l e v a n t e Domain {
12           Für j e d e s bekannte Suchmuster {
13              F a l l s A n f r a g e n −L i m i t n i c h t d u r c h b r o c h e n {
14                  S t e l l e A n f r a g e an S u c h m a s c h i n e ;
15                  Für j e d e n T r e f f e r {
16                      Ü b e r p r ü f e , ob T r e f f e r b e r e i t s g e s i c h t e t und
                                 bewertet ;
17                      Falls ja {
18                          Übernehme B e w e r t u n g f ü r d i e s e n a b e r m a l i g e n
                                     Treffer ;
19                      }
20                      Sonst {
21                          Sende A u f f o r d e r u n g an A d m i n i s t r a t o r , den T r e f f e r
                                     zu b e w e r t e n ;
22                      }
23                  }
24              }
25           }
26        }
27      }
28   }


                     Abbildung 3.1: Ablaufplan Google Scanning in Pseudocode




                                                           26
                                Anzahl     gelieferter   Obere Grenze der
                                Treffer pro Anfrage      Stellenpositionen
                                                         gelieferter Treffer
        Google SOAP-API         10                       1000
        Live Search SOAP-       50                       1000
        API
        Yahoo Search REST-      100                      1000
        API

              Tabelle 3.1: Limitierung der Anzahl gelieferter Ergebnisse


tenbank vorhandenen Suchmuster nicht abgedeckt werden, ist es allerdings durchaus
empfehlenswert, dieses Risiko der großen Mengen von Falschtreffern zumindest pro-
behalber bewusst für alle Suchmuster einzugehen. Um in diesem Fall alle möglichen
Falschtreffer zu erhalten, sollte hierbei auch das Leerzeichen als Suchmuster miteinbe-
zogen werden.

3.4.6    Analyse der Ergebnisse
Ein wesentlicher Schritt des Ablaufs eines Google-Scans, wie in Abschnitt 3.4.4 skiz-
ziert, ist die Aufforderung an den Administrator, den Treffer zu bewerten. Das mensch-
liche Urteilsvermögen in Bezug auf die Gefährlichkeit eines Fundes ist also ein Punkt,
an welchem sich entscheiden kann, ob das langfristige Google Scanning gelingt – oder
scheitert. Nach welchen Kriterien sollte ein Fund also bewertet werden? Wir betrachten
einführend ein paar beispielhafte Suchmuster und Fragmente von Webseiten, welche
nach Anfrage durch das Suchmuster als Funde geliefert wurden.

 Beispiel 18 Fund einer unklaren Fehlermeldung

 Suchmuster: Warning: Cannot
 Fragment:
 Warning: Cannot modify header information - headers
 already sent eExhibitions Portal - Home <b>Warning:
 Cannot modify header information - headers already
 sent</b> by (output <b>...</b> <br> <b>Warning: Cannot
 modify header information - headers already sent</b> by
 (output <b>...</b>

    In Beispiel 18 ist eine Fehlermeldung zu sehen, die zunächst keine sensiblen Infor-
mationen preiszugeben scheint und daher harmlos wirken könnte. Trotzdem sollte ein
Fund dieser Art nicht ohne weitere Untersuchung als harmlos eingestuft werden. Wenn
man diese durchführt, erkennt man, dass eine Fehlermeldung dieser Art beispielsweise
von einem PHP-Script generiert werden kann. Üblicherweise ist hier auch eine Pfad-
information mit inbegriffen. In diesem Fragment ist sie zwar nicht zu sehen, aber im
Google-Cache wahrscheinlich verfügbar. Daher sollte dieser Fund vor einer weiteren
Untersuchung als „auffällig“ eingestuft werden.

 Beispiel 19 Fund eines Login-Portals

 Suchmuster: intitle:login

                                          27
 Fragment:
 Contenido 4.6.8 Login. Login:. Password:. Language:
 . German (Germany), English (United States)

    Ein Teil eines Login-Portals als Fund über eine Suchmaschine wie in Beispiel 19
stellt noch keine direkte Bedrohung für den zugrundeliegenden Server dieses Portals
dar. Allerdings können Login-Portale stets Startpunkte von Angriffsversuchen sein. Im
Falle des Beispiels bieten sich aufgrund der gegebenen Informationen sogar mehrere
Angriffsstrategien an: Das Erraten von Zugangsinformationen oder das Ausnutzen ei-
ner evtl. bekannten Sicherheitslücke des Content-Management-Systems Contenido in
der Version 4.6.8. Somit ist dieser Fund in mindestens einer Hinsicht kritisch.

 Beispiel 20 Fund einer Verzeichnisstruktur

 Suchmuster: intitle:Index of
 Fragment:
 [DIR] Parent Directory - [DIR] debian/ 15-Oct-2005 14:53 - [DIR]
 freebsd/ 15-May-2005 16:35 - [DIR] linux/ 31-May-2005 23:23
 - [DIR] windows/ 15-May-2005 ...

    In Beispiel 20 wurde im Index der Suchmaschine der Inhalt eines Verzeichnisses
gefunden. Bei einem solchen Fund sollte man zunächst klären, ob die Auflistung eines
Verzeichnis-Inhalts beabsichtigt ist oder nicht. Solange die Auflistung nicht explizit be-
absichtigt ist, sollte sie vermieden werden. Konkrete Begründungen für die Gefahr, die
von einer genauen Verzeichnisauflistung zum Zeitpunkt des Fundes ausgeht, müssen
für diese Einschätzung nicht unbedingt vorliegen, denn sie könnte beispielsweise erst
zu einem späteren Zeitpunkt Aufschluss über die Arbeitsweise einer dann installierten
Web-Applikation geben. Dann wäre diese Fehlkonfiguration des Webservers mögli-
cherweise schädlich. Es ist also in diesem Fall evtl. noch Zeit, zukünftige Schäden zu
vermeiden. Der Fund ist vorsorglich als kritisch einzustufen.

 Beispiel 21 Fund von Login-Informationen

 Suchmuster: inurl:passwd
 Fragment:
 Try the following hints. , Is the Caps Lock or A light on
 your keyboard on? If so, hit Caps Lock key before trying
 again. ...
 URL des Fundes:
 n16.login.scd.yahoo.com/config?login=E_Shaw&passwd=bubbles

    Das in Beispiel 21 gefundene Passwort ist offenbar nicht gültig, wie das ange-
zeigte Fragment des Fundes impliziert. Allerdings bedeutet dieser Fund dennoch, dass
dieser oder mehrere Benutzer-Accounts der betreffenden Anwendung in Gefahr sind.
Dieser Account im Speziellen ist gefährdet, da es durch das gegebene (falsche) Pass-
wort evtl. vereinfacht wird, auf das gültige, vielleicht ähnliche Passwort zu schließen.
Alle Accounts des Systems sind in Gefahr, da weitere Login-Informationen auf diesel-
be Art und Weise wie diese hier in den Index der Suchmaschine geraten könnten. In
diesem Falle ist die Ursache für diesen Vorfall sowohl bei dem Eigentümer des Benut-
zeraccounts als auch bei dem Betreiber des Login-Portals zu suchen. Die URL kann
nur in den Index der Suchmaschine geraten sein, indem sie als Link auf einer dem

                                           28
Webcrawler der Suchmaschine zugänglichen Seite platziert wurde. Hierfür muss der
Benutzer oder eine weitere beteiligte Person verantwortlich gemacht werden. Dass es
überhaupt Nutzen ergibt, Links dieser Art zu erstellen, liegt allerdings an dem Betrei-
ber des Login-Portals, welches das GET-Verfahren für die Annahme der Login-Daten
zulässt. Aufgrund beider Missstände ist der Fund als kritisch einzustufen.
 Beispiel 22 Fund einer Versions-Information

 Suchmuster: intitle:index.of Apache server at
 Fragment:
 archive.<b>apache</b>.org. This <b>site</b> contains the
 historical archive of old software <br> releases. <b>...</b>
 <b>Apache</b> /2.3.0-dev (Unix) <b>Server at</b> archive.
 <b>apache</b>.org Port 80.
    Informationen über die Version einer serverseitigen Anwendung zu veröffentlichen,
gehört in vielen Fällen zu ihrer Standardkonfiguration. Wünschenswert ist dies aller-
dings so gut wie nie, da eine Versionsinformation erlaubt, gezielt nach passenden Ex-
ploits zu suchen und damit evtl. einen erfolgreichen Angriff durchzuführen. Ein Fund
wie in Beispiel 22 ist somit in den meisten Fällen als äußerst kritisch einzustufen.

    Wie diese Beispiele ahnen lassen, gibt es nahezu unzählige verschiedene Funde,
die – indirekt oder direkt – eine Gefahr für einen Webserver darstellen. Um diese Ge-
fahr einschätzen zu können, ist eine Kenntnis der in der Google Hacking Community
gängigen Suchmuster sehr hilfreich. Die Person, welche die Funde eines Google-Scans
evaluiert, muss wissen, was ein böswilliger Google-Hacker suchen könnte, bzw. wel-
che Funde für einen Angreifer im Allgemeinen Sinne hilfreich sein könnten.
    Für einen effizienten, langfristigen Ablauf eines Google-Scans ist es sinnvoll, dass
jede Kombination aus URL und zu dieser URL geliefertem Fragment und Seitenti-
tel nur ein einziges Mal bewertet werden muss und nicht bei jedem Durchlauf des
Scans erneut. Dies lässt sich durch entsprechende Programmierung leicht einrichten.
Jedoch ist es vereinzelt der Fall, dass sich zwei Funde nur durch eine Session-ID in der
URL unterscheiden. Dies kommt vor, wenn eine Seite, welche bei jedem Besuch eine
Session-ID vergibt, mehrmals von dem Webcrawler einer Suchmaschine besucht wird.
Die bei jedem Besuch erneuerte Session-ID wird dabei in den Index der Suchmaschine
übernommen. Somit ist es sinnvoll, dem Benutzer bei einem Google-Scan die Mög-
lichkeit zu geben, den Vergleich mehrerer Funde toleranter zu gestalten, also in diesem
Fall einen bestimmten Parameter einer gefundenen URL bei zukünftigen Vergleichen
nicht zu beachten.
    Der nächste Schritt nach der Bewertung eines Fundes als gefährlich ist das Ergrei-
fen von Gegenmaßnahmen.

3.4.7    Kurzfristige Maßnahmen nach einem Fund
Nach einem Sicherheits-relevanten Fund sind sowohl kurzfristige, als auch langfristige
Maßnahmen notwendig. Die kurzfristigen Maßnahmen beziehen sich auf Schadensbe-
grenzung: Die offengelegten Informationen müssen entfernt oder unschädlich gemacht
werden. Daraus folgende, langfristige Maßnahmen beziehen sich auf das Verhindern
abermaligen Vorkommens einer Offenlegung von Informationen dieser Art. In diesem
Abschnitt geht es um die kurzfristigen Maßnahmen. Wie langfristiger Schutz erreicht
wird, wird in Kapitel 6 erläutert.


                                          29
 Art des Fundes                  Gegenmaßnahme(n)
 Index von Verzeichnissen        Ändern der Verzeichnisstruktur, Verhindern der
                                 Auflistung des Inhalts durch Rekonfiguration
                                 des Servers, Entfernen des Inhalts aus dem
                                 Suchmaschinen-Index
 Login-Daten                     Ändern der Login-Daten, Rekonfiguration des
                                 Portals, Verhinderung des Zugriffs
 Login-Portale                   Entfernung     der    Information    aus    dem
                                 Suchmaschinen-Index, Rekonfiguration robots.txt
 Persönliche Daten               Verhinderung des Zugriffs, Entfernung aus dem
                                 Suchmaschinen-Index
 Kreditkartennummern             Verhinderung des Zugriffs, Kreditkarte deaktivie-
                                 ren
 Fehlermeldungen                 Rekonfiguration des Servers, Entfernung aus dem
                                 Suchmaschinen-Index
 Logdateien                      Verhinderung des Zugriffs, Entfernung aus dem
                                 Suchmaschinen-Index
 Web-Schnittstellen     von      Verhinderung des Zugriffs, Entfernung aus dem
 Hardware                        Suchmaschinen-Index
 Versions-Informationen          Änderung der Version und Belassen der Informati-
                                 on im Suchmaschinen-Index. Oder: Absicherung
                                 gegen evtl. existierende Exploits (Mittels Upda-
                                 te oder – falls möglich – eines eigenen Worka-
                                 rounds) und Entfernung der Information aus dem
                                 Suchmaschinen-Index

                      Tabelle 3.2: Funde und Gegenmaßnahmen



     Bei den verschiedenen Arten von Funden sind unterschiedliche Gegenmaßnahmen
möglich und/oder sinnvoll. Ein nahe liegender, aber nicht unbedingt sinnvoller Schritt
ist das in-die-Wege-leiten einer Entfernung der sensiblen Information(en) aus dem In-
dex bzw. Cache der jeweiligen Suchmaschine. Es kann eben gerade das Belassen der
Information in dem Index ein sinnvoller Schritt sein – etwa in dem Fall der Offenlegung
einer Versions-Information. Falls eine Gegenmaßnahme darin besteht, die entsprechen-
de Software auf eine andere Version zu aktualisieren und die Versions-Information
zu verstecken, kann es zur Irreführung von Angreifern durchaus sinnvoll sein, eine
(falsche) Versions-Information weiterhin der Öffentlichkeit zur Verfügung zu stellen.
Der Nutzen einer Gegenmaßnahme muss also sowohl in Bezug auf die Art der Si-
cherheitsschwäche, als auch in Bezug auf die anderen Gegenmaßnahmen betrachtet
werden. Bevor man in Erwägung zieht, Suchmaschinen-Betreiber mit dem Ziel der
Entfernung von Informationen aus dem Index zu kontaktieren, sollte stets die Mög-
lichkeit betrachtet werden, dass die Informationen bereits von potentiellen Angreifern
gesehen wurden (Worst-Case-Fall). Wenn allerdings ein auf diesen Informationen ba-
sierender Angriff nicht wirkungsvoll verhindert werden kann – oder die Informationen
keine Hilfe bei einem Angriff, sondern allgemein privater Natur sind – sollte nach dem
Motiv „Besser spät als nie“ die möglichst baldige Entfernung der Information aus dem
Index angestrebt werden. Hier eine Auflistung aller prinzipiell möglichen, kurzfristigen
Maßnahmen.

                                          30
   • Kontaktierung des Suchmaschinen-Betreibers bzgl. Entfernung des Inhalts aus
     dem Suchmaschinen-Index
   • Schließen der Sicherheitslücke durch Rekonfiguration:
          – Verstecken von Versions-Informationen
          – Ändern der Pfadstruktur eines Servers
          – Aktualisierung von Software
          – ...
   • Entwertung der gestohlenen Information:
          – Ändern von Passwörtern
          – Deaktivieren von Kreditkarten
          – ...
Eine Zuordnung zu verschiedenen Arten von Funden befindet sich in Tabelle 3.2.

3.4.7.1   Angebote der Suchmaschinen-Betreiber zur Entfernung von Inhalten
Falls es sich als dringend notwendig erweisen sollte, Informationen aus den Indizes
der Suchmaschinen zu entfernen, bieten einem ihre Betreiber auf mehr oder weniger
entgegenkommende Weise ihre Hilfe an. Das wohl hilfreichste Angebot im Vergleich
kommt von Google, da hier eine explizite Entfernung von Inhalt veranlasst werden
kann. Hierzu der Wortlaut aus der Online-Hilfe von Google [gooa]:
           „(...) Hinweis: Wenn Ihre Anforderung Ihrer Meinung nach dringend
      ist und nicht bis zum nächsten Google-Crawling warten kann, verwenden
      Sie unser automatisches System zum Entfernen von URLs. Damit dieser
      automatische Prozess funktioniert, muss der Webmaster zunächst die ent-
      sprechenden Meta-Tags in den HTML-Code der Seite einfügen. (...) Sie
      können Ihre URL zur Entfernung aus Googles Suchergebnissen einrei-
      chen. URLs werden entfernt, nachdem wir Ihre Anforderung geprüft ha-
      ben. Beachten Sie, dass diese Prüfung mehrere Tage oder länger in An-
      spruch nehmen kann und alle Seiten, die über unser automatisches System
      zum Entfernen von URLs eingereicht wurden, vorübergehend für sechs
      Monate aus dem Google Index entfernt werden. (...)“
Die erwähnten Meta-Tags dienen der Beeinflussung des Indizierungs-Verhaltens des
Webcrawlers von Google („GoogleBot“) und werden in Abschnitt 6.3 genauer er-
läutert. Die Betreiber von Live Search und Yahoo Search bieten kein Formular zur
ausdrücklichen Entfernung von Inhalten an. Hierzu aus den Hilfe-Seiten von Live
Search [liva]:
         „(...) Damit Ihre Website oder Ihre Webseiten nicht im Index von Live
      Search angezeigt werden, stehen Ihnen folgende Methoden zur Verfügung:
          • Sie können auf Ihrer Site die Datei robots.txt erstellen und die Indi-
            zierung Ihrer Site durch MSNBot blockieren. Weitere Informationen
            über die Datei robots.txt finden Sie auf den Webrobotseiten.
          • Sie können den Seiten, die nicht indiziert werden sollen, das Metatag
            noindex hinzufügen.

                                           31
         • Sie können für Ihre Site einen sicheren Speicherort auf dem Webser-
           ver verwenden (z. B. eine Benutzeranmeldung erforderlich machen
           oder HTTPS verwenden).
         • Entfernen Sie die Seiten aus Ihrer Site.
      Es kann mehrere Tage dauern, bis Live Search die Aktualisierung der In-
      dizierung abgeschlossen hat und Ihre Änderungen wirksam werden. Hin-
      weis: Wenn andere Sites Links zu Ihrer Site bereitstellen, werden die URL
      Ihrer Site und Text, den Sie in HTML-Ankertags aufnehmen, trotzdem zu
      unserem Index hinzugefügt. Der Inhalt Ihrer Site wird jedoch nicht in den
      Index aufgenommen. (...)“
Zur Vervollständigung noch die entsprechende Äußerung der Betreiber von Yahoo
Search [yaha]:
          „(...) As our index contains billions of web pages we cannot manually
      make changes to the index and rely on our automated crawl systems to
      update the search index. If you want the status of pages that have been
      crawled and indexed to change, you will need to make changes to the site
      content or control documents that communicate to our crawler how these
      pages should be handled by the search engine. When changes are made
      to a web page, those changes will be properly reflected in our database
      the next time the page is crawled, indexed, and the index-update cycle is
      complete. (...)“
Letztlich relevant ist bei den drei Verfahren die Zeit bis zur Entfernung des Inhalts,
die in der Praxis vergeht. Hierzu ein Test: Die Testseite mit der URL www.pizza-
bestellen.de1 befindet sich mit URL und Inhalt zum 01.02.2007 um 16:09 Uhr in allen
drei Suchmaschinen-Indizes. Nun wird die Datei robots.txt (Siehe Beispiel 23) in das
Hauptverzeichnis der Seite abgelegt. Weiterhin wird der Inhalt der Seite geändert. Dann
wird bei Google die Entfernung der URL aus dem Index beantragt.
 Beispiel 23 Inhalt der Datei robots.txt für den Test zum Entfernen von Content
 aus den Suchmaschinen-Indizes
 User-agent: *
 Disallow: /
In Tabelle 3.3 sind die festgestellten Zeitpunkte, zu denen die aufgeführten Bestand-
teile der Seite aus den jeweiligen Bestandteilen von entfernt wurde, aufgelistet. Der

             Suchmaschine           Inhalt aus Ca-        Fragment aus     URL aus In-
                                    che entfernt          Index entfernt   dex entfernt
             Google                 01.02.2007,           02.02.2007,      02.02.2007,
                                    18:00 Uhr             13:00 Uhr        13:00 Uhr

                         Tabelle 3.3: Vergleich von Entfernungszeiten

Test wurde auch für die beiden anderen Suchmaschinen versuchsweise durchgeführt,
was sich jedoch bald als zwecklos erwies, da die jeweiligen Webcrawler die Seite nicht
besuchten. Dies lag höchst wahrscheinlich daran, dass die Testseite als relativ unbedeu-
tend eingestuft und daher seltener neu eingelesen wurde. Je „populärer“ eine Webseite,
  1 Domain   im Besitz des Autors


                                                     32
desto schneller dürfte es möglich sein, Inhalte aus den Indizes und Caches von Live
Search und Yahoo Search zu entfernen. Jedoch kann bei keiner dieser Suchmaschinen
genau eingeschätzt werden, wie lange es dauern wird, bis der Inhalt wirklich entfernt
wurde.


3.5     Zusammenfassung
In diesem Kapitel wurde gezeigt, auf welche Art und Weise sich Google Hacking prin-
zipiell automatisieren lässt. Hierzu wurde zunächst kurz das Prinzip des Vulnerability
Scannings erläutert. Im Bezug auf das Google Hacking wurde im Detail erklärt, wie
ein Google-Scan vorbereitet, durchgeführt und nachbereitet werden sollte. Es sollten
also zunächst die relevanten Domains und Suchmuster gefunden werden. Der langfris-
tige Ablaufplan ist teils vom Einfluss, den man auf das Verhalten der Suchmaschinen-
Webcrawler hat, abhängig. Jedoch kann er – wie die Tiefe der Suche – auch von der An-
zahl von Anfragen, die man pro Tag zu stellen in der Lage ist, abhängen. Abschließend
wurden neben der Analyse der Funde einige kurzfristige Maßnahmen als Reaktionen
auf kritische Funde angesprochen und erläutert.
    Im Folgenden wird auf Grundlage dieses Kapitels die konkrete Implementierung
eines automatisierten Google-Hacking-Werkzeugs beschrieben.




                                         33
Kapitel 4

Entwicklung des
Google-Hacking-Tools
„GooScanner“

4.1    Einleitung
In diesem Abschnitt wird die Entwicklung eines Tools beschrieben, welches große
Mengen von Suchmustern automatisch an Suchmaschinen senden kann und die Ergeb-
nisse von verschiedenen Zeitpunkten vergleicht. Mit Hilfe dieses Tools soll die Über-
prüfung der Anfälligkeit eines IT-Systems gegenüber Google Hacking mit möglichst
wenig Arbeitsaufwand überprüft werden.
    Im Folgenden werden zunächst die wesentlichen Module des Programms anhand
ihrer Quellcodes vorgestellt. Danach wird der Aufwand, der sich durch die Arbeits-
weise des Programms ergibt, abgeschätzt. Für die Anwendung des Tools wird eine
schematische Vorgehensweise konkretisiert.
    Da es schon einige Werkzeuge gibt, die die Idee des Google Hackings aufgreifen,
werden diese in einem Abschnitt untersucht und teilweise mit dem hier entwickelten
Tool verglichen.
    Abschließend werden die „Google Web Services“ und „Google Alerts“ bezüglich
ihrer Verwendbarkeit für Google Hacking betrachtet.


4.2    Arbeitsweise des Programms
GooScanner speichert seine Daten in einer SQL-Datenbank. Das Schema dieser Daten-
bank ist in Abbildung 4.1 zu sehen. Zunächst eine Erläuterung der einzelnen Tabellen
dieser Datenbank, anhand welcher die Arbeitsweise von GooScanner deutlich werden
sollte.
    Zweck des Programms ist es, in regelmäßigen Abständen bestimmte Mengen von
Google-Hacking-Anfragen durchzuführen. Die Anfragen sollen sich dabei auf bestimm-
te Mengen von Domains beziehen. Welche Suchmuster und welche Domains für die
Anfragen verwendet werden sollen, wird als so genannter „Job“ in der gleichnamigen
Tabelle festgehalten. Hier wird zudem gespeichert, wann und wie oft der Job gestartet
werden soll, und wie viele Anfragen pro Durchführung gestellt werden sollen. Dies ist

                                         34
Abbildung 4.1: Datenmodell von GooScanner



                   35
wichtig, da die Suchmaschinen, wie schon erwähnt, Grenzen in der Anzahl der Anfra-
gen pro Tag setzen. Welche Suchmaschine für den Job genutzt werden soll, wird im
Feld „jobSearchMethod“ festgehalten.
     Als Instanz einer Durchführung eines Jobs wird ein „Scan“ definiert (siehe gleich-
namige Datenbank-Tabelle in Abb. 4.1). Zu jedem Scan wiederum werden die Ergeb-
nisse zu jeder Anfrage in der Tabelle „result“ gespeichert. Jedes Ergebnis besteht aus
keinem, einem oder mehreren Treffern. Diese einzelnen Treffer werden den Ergeb-
nissen in der Tabelle „hit“ zugeordnet. Der Titel der gefundenen Seite und der von
der Suchmaschine gelieferte Ausschnitt werden mit gespeichert. Mittels des Flags „hi-
tEvaluated“ wird gekennzeichnet, ob der Benutzer des Programms den Treffer schon
bewertet hat, oder nicht. Jeder Treffer kann einer Kategorie zugeordnet werden.
     Das Programm wurde in PHP implementiert. Eine zentrale Rolle in seinem Ablauf
spielt der so genannte „Scheduler“. Sein Quelltext ist in Listing A.1 (siehe Anhang,
S. 74ff) zu sehen. Dieses Script muss ein Mal am Tag gestartet werden. Es wird über-
prüft, ob ein noch nicht komplett durchgeführter Scan weitergeführt werden soll (siehe
Z.59), und ob laut Definition eines Jobs ein neuer Scan gestartet werden soll (siehe
Z.42). Mittels der Funktion „do_scan“ (Z.65 u. 75) werden die Scans durchgeführt.
Abhängig von der dem Job zugewiesenen Suchmaschine, wird ein speziell auf diese
Suchmaschine ausgerichtetes Modul, wie das für Google in Listing A.2 (siehe Anhang,
S.77ff), gestartet. Google und Live Search stellen zwar beide eine SOAP-Schnittstelle
zur Verfügung, jedoch ist die Handhabung dieser Schnittstellen so unterschiedlich, dass
eine einheitliche Programmierung des Scan-Parts umständlich wäre. Das Live-Search-
Modul steht zudem in einer leicht modifizierten Variante zur Verfügung, in welcher die
Suche nicht mit Hilfe des „site:“-Parameters, sondern mittels „ip:“ gesteuert wird. Als
viertes Modul gibt es eine Implementierung für die REST-Schnittstelle von Yahoo.
     In dem hier gezeigten Google-Modul wird in Z.8 festgestellt, wie viele Anfragen
an die Suchmaschine an diesem Tag noch aufgrund deren Limitierung möglich sind. In
Z.9 wird das Produkt aus der Anzahl von URLs und der Anzahl von Suchmustern er-
rechnet, was die Anzahl von durchzuführenden Anfragen an die Suchmaschine ergibt.
Die ineinander geschachtelten Schleifen von Z.14 und Z.15 laufen genau über diese
Anzahlen von URLs und Suchmustern. Aus deren Kombination ergibt sich dann die
Formulierung der Anfrage an die Suchmaschine in Z.24. Um jede im Job ausgewählte
URL zu berücksichtigen, muss tatsächlich für jede einzelne URL eine explizite Anfra-
ge gestellt werden. Eine Anfrage der Form „(site:url1.de OR site:url2.de“ funktioniert
bei keiner der drei Suchmaschinen. Hierbei würde stets nur eine der URLs berücksich-
tigt. Der Ausschluss einzelner URLs (Z.35-37) funktioniert hingegen wie gewünscht.
     Wenn ein Scan über mehrere Tage verteilt ist, kommt es vor, dass er mehrmals von
vorne gestartet wird und sich mehrmals dieselbe Kombination aus URL und Suchmus-
ter ergibt. Dies soll innerhalb eines Scans allerdings nur genau einmal zu einer Anfrage
an die Suchmaschine führen (Zur Erinnerung: Ein Scan ist eine Instanz eines Jobs). Ob
innerhalb eines Scans eine Kombination schon vorkam, wird durch die Anfrage in Z.40
überprüft.
     Zu jedem Job existieren ab einem bestimmten Zeitpunkt mehrere Scans. Bestimmte
(harmlose oder schwerwiegende) Treffer können in jedem dieser Scans erneut auftre-
ten. Allerdings sollte ein Treffer nur einmal – und nicht bei jedem Scan erneut – als
harmlos oder schwerwiegend eingestuft werden müssen. Als eindeutige Charakteri-
sierung eines bestimmten Treffers sollte die Kombination aus Webseiten-Ausschnitt,
(„Fragment“) URL und Seitentitel genügen. Wenn also eine Kombination aus Frag-
ment, URL und Titel zu einem früheren Zeitpunkt zu demselben Ergebnis wie im aktu-
ellen Scan geführt hat und dieser Treffer in der Vergangenheit schon vom Benutzer als


                                          36
harmlos oder schwerwiegend eingestuft und evtl. in eine Kategorie eingeordnet wurde
(Z.100), soll dieser Arbeitsvorgang nicht nochmal durchgeführt werden müssen. Daher
werden Bewertung und Kategorisierung übernommen (Z.101-110). Bei mindestens ei-
nem neuen, noch nicht bewerteten Treffer wird der Benutzer per Mail benachrichtigt
(Z.157-162).
     In Abbildung 4.2 sieht man die Beschreibung eines Jobs in der Web-basierten Ober-
fläche des Programms. Die Schnittstelle zur Bewertung eines einzelnen Treffers ist in
Abbildung 4.3 zu sehen. Alternativ möglich ist die Bewertung vieler Treffer gleichzei-
tig innerhalb einer einzigen Auflistung (siehe Abbildung 4.4).


4.3     Aufwandsabschätzung
Der Aufwand für die Durchführung des Google Scannings wird in den folgenden Punk-
ten gemessen bzw. abgeschätzt:

   • Anfragen pro Zeiteinheit

   • Genutzte Internet-Bandbreite

   • Personeller bzw. zeitlicher Aufwand

   • CPU-Belastung

   • Bedarf an nichtflüchtigem Speicher


                                              Google    Live Search     Yahoo Search
  Ø-Zeit zwischen Anfrage und Antwort         2,307 s     2,412 s          1,243 s

                    Tabelle 4.1: Zeitbedarf von Google Scanning



            Suchmaschine      Umfang der Grundlage der Messergebnisse
               Google          10 Scans mit insgesamt 13733 Anfragen
               Yahoo           11 Scans mit insgesamt 17097 Anfragen
             Live Search       49 Scans mit insgesamt 77471 Anfragen

                 Tabelle 4.2: Grundlagen der Statistik in Tabelle 4.1


    Das bedeutet: Ein Scan einer Domain mittels 1600 Suchmustern dauert mit Goo-
gle 1600 × 2, 390 = 3824 Sekunden, also 63,7 Minuten. Für Live Search bzw. Yahoo
Search ergeben sich 78,6 bzw. 58,5 Minuten.
    Aufgrund der langen durchschnittlichen Zeiten zwischen Anfragen und Antworten
liegt die Übertragungsrate, die durch einen Google-Scan zustande kommt, in einem
Bereich von unter 1kb/s.

   Im personenbezogenen Bereich ergibt sich der zeitliche Aufwand von Google Scan-
ning langfristig durch die benötigte Zeit für die folgenden Aktivitäten:

   1. Bewerten von neuen Suchergebnissen


                                         37
Abbildung 4.2: Konfiguration eines Jobs in GooScanner




Abbildung 4.3: Bewertung eines Fundes in GooScanner




                        38
       Abbildung 4.4: Bewertung mehrerer Funde gleichzeitig in GooScanner


   2. Korrektur/Anpassung vorhandener Suchmuster
   3. Erstellen neuer Suchmuster
Die Zeit des Einrichtens einer regelmäßig durchzuführenden Aufgabe bzw. eines Jobs
ist im Vergleich relativ gering. Falls ein Programm wie GooScanner bereits vorliegt, ist
auch die für die Programmierung benötigte Arbeitszeit nicht sehr hoch.
     Zur Bewertung neuer Suchergebnisse: Da jede Kombination aus URL, Fragment
und Seitentitel insgesamt nur einmal bewertet werden muss, werden bei den ersten
Durchgängen eines Jobs noch relativ viele Funde bewertet werden müssen. Bei späte-
ren Durchgängen liegt diese Anzahl in der Regel bedeutend niedriger. Die Gesamtzahl
der durchzuführenden Bewertungen hängt natürlich auch eng mit der Größe des unter-
suchten Web-Auftritts zusammen.
     In Tabelle 4.3 ist beispielhaft der Verlaufs der Anzahl zu bewertender (neuer) Tref-
fer anhand eines täglichen Scans der Domain t-mobile.de zu sehen. Die für eine Be-
wertung benötigte Zeit hängt neben der Anzahl von neuen Treffern natürlich auch vom
jeweiligen Fund ab. Ein Fund kann „auf den ersten Blick“ als harmlos oder gefährlich
einzustufen sein, oder zunächst einer genaueren Untersuchung bedürfen. Eine genaue-
re Untersuchung wiederum kann beliebig lang dauern, wobei im Einzelfall abgeschätzt
werden sollte, ob sich der Aufwand lohnt.
     Der zeitliche Aufwand für die Bewertung hängt allerdings auch von der Gestal-
tung der Schnittstelle ab, über welche die Bewertung vorgenommen wird. Bei einer
„Einzelbetrachtung“ wie in Abbildung 4.3 ist sowohl der Aufwand, als auch die Auf-
merksamkeit gegenüber dem einzelnen Treffer relativ hoch. Die benötigte Zeit wurde


                                           39
                           Google     Yahoo Search    Live Search
                   Tag 1     61           123             109
                   Tag 2     39            3               14
                   Tag 3     12            6               0
                   Tag 4     2             2               24
                   Tag 5     2             3               7
                   Tag 6     1             1               1
                   Tag 7     5            14               0

       Tabelle 4.3: Verlauf der Anzahl neuer Treffer bei Scans von t-mobile.de


– mit dem Autor als Versuchsperson – bei der Bewertung von 173 Treffern gemessen,
was eine Durchschnittszeit von 6,54 Sekunden pro Treffer ergab.
    Bei einer Anzeige von beispielsweise 1000 Treffern pro Seite sind Aufwand und
Aufmerksamkeit pro Treffer relativ niedrig.
    Ein weiterer Faktor für die Zeitdauer einer Bewertung ist der Mensch selbst, der
sie vornimmt. Hierzu lässt sich im Wesentlichen sagen, dass die Bearbeitung mit stei-
gender Erfahrung auch weniger Zeit in Anspruch nimmt. Unter Verwendung der Be-
nutzerschnittstelle des hier implementierten GooScanner, kann die durchschnittliche
Bearbeitungszeit eines Treffers berechnet werden, indem die Gesamtarbeitszeit für die
Treffer-Bewertung durch die Anzahl bewerteter Treffer geteilt wird. Da ein und der-
selbe Treffer bei einem abermaligen Fund nicht erneut bewertet werden muss, kann
ein realistischer Mittelwert für die tägliche Zeitbelastung aufgrund der Bewertungs-
vorgänge erst nach langfristiger Durchführung gebildet werden. Hier wollen wir den
ersten Monat nach Einrichtung eines Jobs betrachten.
    Die Zeit, die für das Erstellen eines neuen Suchmusters aufgewendet werden muss,
kann pauschal nicht eingeschätzt werden. Für die Anzahl neu zu erstellender Suchmus-
ter im Rahmen der Untersuchung der IT-Systeme eines Unternehmens können eben-
falls nur Erfahrungswerte herangezogen werden. Hier die Anzahl der Suchmuster, die
in den einzelnen Untersuchungen im Rahmen dieser Diplomarbeit (siehe Anhang B)
neu erstellt wurden:
   • T-Mobile: 8
   • Firma 1: 3
   • Firma 2: 1
   • Firma 3: 11
Je nach Umfang und Zusammensetzung der zu untersuchenden IT-Systeme kann die
Anzahl möglicherweise erheblich von diesen Erfahrungswerten abweichen; bei einer
Zusammensetzung eines IT-Systems aus einer Vielzahl verschiedenster Web-Anwen-
dungen ist eine Abweichung nach oben sehr wahrscheinlich.
    Relativ umfangreich kann auch die Zeit sein, die für die Korrektur vorhandener
Suchmuster aufgewendet wird. Bei Verwendung der Google-Hacking-Database von
Johnny Long [ghd07] gehören beispielsweise auch Suchmuster wie „filetype:doc“
mit zum Scan. Falls eine Firma jedoch in ihrem Web-Auftritt große Mengen von Do-
kumenten im Doc-Format bereitstellt, die auch für die Öffentlichkeit gedacht sind, er-
geben sich durch dieses Suchmuster viele Fehltreffer, so dass der Aufwand für die
Bewertung der Treffer zu hoch sein könnte. In so einem Fall sollte das Suchmuster so

                                         40
modifiziert werden, dass die für die Öffentlichkeit gedachten Dokumente explizit von
der Suche ausgeschlossen sind – beispielsweise durch Hinzufügen eines entsprechen-
den „site:“-Parameters.
    Zum Anspruch an Rechenzeit: Die Auslastung einer Intel-Centrino-CPU mit 1.4Ghz,
die in einem Rechner arbeitet, der mit 1GB RAM und Windows XP ausgestattet ist,
liegt bei der Durchführung eines Google-Scans laut des Windows-Task-Managers stets
bei unter 10%.
    Der Platzbedarf auf nichtflüchtigen Speichermedien für eine dauerhaft eingerich-
tete Untersuchungs-Routine eines IT-Systems ist proportional zum Umfang dieses IT-
Systems. Gründe hierfür sind:

   • Die gesamte Anzahl von Treffern ist direkt proportional zum Umfang des IT-
     Systems und der Anzahl benutzter Suchmuster.

   • Wie in Tabelle 4.3 zu erkennen, bewegt sich die Anzahl neuer Treffer gegen
     0 (Was bei häufig aktualisierten, von den Suchmaschinen oft neu eingelesenen
     Seiten allerdings anders sein kann).

   • Jeder Treffer, der nicht neu ist, muss nicht abgespeichert werden – bzw.: Die
     einzigen Treffer, die (zum späteren Vergleich) abgespeichert werden müssen,
     sind die neuen Treffer.

   • Somit bewegt sich der Platzbedarf gegen einen festen Wert.

Insgesamt ist der Bedarf an nichtflüchtigem Speicher – wohl dank der Effizienz von
SQL-Datenbanksystemen – extrem gering und liegt auch bei mehreren 10.000 gespei-
cherten Treffern im Bereich von 2-4MB.


4.4    Schema für die Anwendung von GooScanner
Für die gesamte Vorgehensweise wird das nun folgende Schema angewandt. In Anhang
B wird dieses Schema in mehreren beispielhaften Scans angewandt.

  1. Vorbereitung

       (a) Suche nach relevanten Domains
       (b) Suche nach sinnvollen Suchmustern durch Untersuchung von Webseiten

  2. Konfiguration des Jobs

       (a) Festlegung des Intervalls zwischen Starts von neuen Scans. Dieser kann da-
           von abhängig gemacht werden, wie oft der Cache der Suchmaschine aktua-
           lisiert wird, kann aber auch durch die Limitierung der möglichen Anfragen
           höher sein, als wünschenswert wäre.
       (b) Festlegung der Anzahl von Anfragen pro Tag
       (c) Auswahl der zu verwendenden Suchmuster

  3. Analyse des ersten Scans

       (a) Suche nach neuen Suchmustern
       (b) Ausschluss von Subdomains und/oder Unterverzeichnissen


                                        41
        (c) Löschen von Treffern, falls massenhafte Falschtreffer
   4. Analyse des Verlaufs der weiteren Scans
        (a) Wie viele neue Treffer ergeben sich pro Durchlauf?
        (b) Wie viele Falschtreffer ergeben sich, und warum?
        (c) In welchem Durchlauf werden welche kritischen Treffer gefunden?
        (d) Wie wertvoll war der Inhalt des Suchmaschinen-Cache?
        (e) Welche Suchmuster sind am erfolgreichsten?
        (f) Welche Suchmaschine ist am erfolgreichsten?
        (g) Wie viele Treffer sind insgesamt zu bewerten?
        (h) Welche Subdomains wurden gefunden?
   5. Analyse der kritischen Treffer
        (a) Welche Ursachen gibt es für das Auftreten der kritischen Treffer?
        (b) Welche Gefahr stellen die kritischen Treffer dar?
        (c) Welche kurzfristigen Gegenmaßnahmen sind zu ergreifen?
        (d) Welche langfristigen Gegenmaßnahmen?
   6. Analyse des Aufwands
        (a) Wie ist die Dauer der einzelnen Scans?
        (b) Welche Zeit war zum Bewerten der Treffer notwendig?
   7. Fazit


4.5     Andere Vulnerability-Scanner, die Google Hacking
        einsetzen
4.5.1    Sitedigger
Das Programm „SiteDigger 2.0“ der Firma Foundstone nutzt wie GooScanner die
SOAP-API von Google. Nach Eingabe einer Domain werden alle Suchmuster einer
zuvor ausgewählten Datenbank – erweitert durch „site:<Domain>“ – an Google ge-
sendet. Das Ergebnis der Anfragen wird als Liste der gefundenen URLs in einer Tabel-
le präsentiert. Diese lässt sich in das HTML-Format exportieren. Eine Möglichkeit des
Vergleichs von Funden zu verschiedenen Zeitpunkten steht nicht zur Verfügung.
    Als Suchmuster-Datenbanken stehen die der Firma Foundstone sowie die GHDB
zur Verfügung. Sie können durch ein manuelles Update auf dem neuesten Stand gehal-
ten werden.

4.5.2    gooscan
Dieses Perl-Script wurde von Johnny Long geschrieben. Es erhält als Parameter eine
Liste von Suchmustern und eine URL. Danach fragt es den Google-Index nicht durch
die API ab, sondern über die Web-Schnittstelle, was zu einer Sperrung des Zugriffs
führen kann. Die Ausgabe der Ergebnisse der Suche erfolgt in Form einer HTML-
Datei.


                                          42
4.5.3   Acunetix
Acunetix konzentriert sich auf Google als einzige Suchmaschine. Die auf Anfälligkeit
zu untersuchende Web-Site wird durch einen Webcrawler auf den Rechner, auf wel-
chem die Acunetix-Anwendung läuft, heruntergeladen und dort von Acunetix selbst
auf Anfälligkeit gegenüber Google Hacking untersucht. Der Google-Index oder -Cache
hingegen wird nicht untersucht. Somit ist unklar, welche Informationen wirklich im
Google-Index sind. Die Korrektheit der Untersuchung hängt davon ab, inwieweit Acu-
netix den Webcrawler von Google imitieren kann.


4.5.4   Athena
Athena ist eine Datenbank von Suchmustern mit grafischer Oberfläche. Hier gibt es
die Möglichkeit, ein Suchmuster manuell auszuwählen und per Mausklick die Suche
auszuführen. Das Ergebnis präsentiert sich durch das bekannte Web-Interface von Goo-
gle. Falls dem Benutzer das Ergebnis interessant erscheint, kann er die URL der Suche
als „interessant“ markieren. Die Liste von bisher betrachteten Such-URLs kann in das
Microsoft-Word-Format exportiert werden. Es können zudem weitere Suchmaschinen
neben Google definiert werden, indem zu jeder Suchmaschine eine Basis-URL ange-
geben wird, an welche das Suchmuster dann durch den Mausklick angehängt wird.
    Auch hier gibt es keinen automatischen Vergleich von Ergebnissen von Suchen mit
demselben Suchmuster zu verschiedenen Zeitpunkten.


4.5.5   Wikto
Wikto ist ein Vulnerability-Scanner, der sich nicht auf das Google Hacking beschränkt,
sondern dieses als Teil einer Untersuchung eines Webservers bereitstellt. Diese Un-
tersuchung ist hier kein umfassender Vulnerability Scan – Ziel von Wikto ist es (laut
Dokumentation), „interessante Verzeichnisse und Dateien“ auf Webservern zu finden.
Wikto bietet - wie die meisten anderen Scanner für Google Hacking - die Möglichkeit,
die GHDB zu importieren. Die Suche lässt sich auf eine Domain einschränken. Wikto
arbeitet nur mit Google und keiner anderen Suchmaschine. Große Mengen von Anfra-
gen lassen sich automatisiert durchführen. Die Ergebnisse werden in Form einer Liste
von URLs pro Anfrage präsentiert. Einen Vergleich von Ergebnissen zu verschiedenen
Zeitpunkten gibt es hier nicht.


4.6     Google Web Services
Die Bezeichnung von „Google Web Services“ bezieht sich auf die SOAP-Schnittstelle
für Anwendungen, welche die Google-Suche nutzen. Wie schon aus der Beschreibung
der Implementierung eines Google-Hacking-Tools in Abschnitt 4 hervorgeht, ist ihre
Verwendung unerlässlich. Bei Verwendung der Web-Schnittstelle für große Mengen
von Anfragen in hoher Frequenz würde der Zugriff auf sie bald gesperrt werden. Doch
ist die Verwendung der SOAP-Schnittstelle nicht nur unvermeidbar, sondern auch hin-
sichtlich der Programmierung eines automatischen Google-Scanners eine große Er-
leichterung, da die Ergebnisse von Anfragen nicht im HTML-Format, sondern als Ar-
ray geliefert werden. Der Nutzen der Google Web Services für das unternehmensbezo-
gene Google Hacking ist somit als positiv zu bewerten.

                                         43
   Die SOAP-API von Live Search und die REST-API von Yahoo Search sind aus
genau denselben Gründen als ebenfalls positiv in Bezug auf die Verwendung im Such-
maschinen-Hacking zu bewerten.


4.7    Google Alerts
Mittels des Google-eigenen Dienstes „Google Alerts“ könnte es prinzipiell erreicht
werden, dass Funde, die auf Suchmustern beruhen, die zu einem vorherigen Zeit-
punkt definiert worden sind, zu jedem Zeitpunkt des erneuten Auftretens an einen
Administrator gemeldet werden. Die Meldung eines neuen Treffers hätte im Idealfall
die größtmögliche Zeitnähe zum Auftreten einer kritischen Information im Index der
Suchmaschine. Die große Anzahl von Suchmustern macht es allerdings im derzeiti-
gen Google-Alerts-Index schwierig, diese zu verwalten. Zudem zeigt die Praxis, dass
„Google Alerts“ unzuverlässig arbeitet: Bereits gemeldete Funde werden erneut als
neue Funde erkannt und gemeldet.
    Der Autor dieser Diplomarbeit hat dies dadurch überprüft, indem er seinen eige-
nen Namen als Suchbegriff für „Google Alerts“ (im Suchbereich „Web“) eingab. Die
erste „Alert-Mail“, die dann an ihn gesendet wurde, enthielt Hinweise auf 11 Funde.
Zur gleichen Zeit konnte derselbe Suchbegriff über das Google-Web-Interface aller-
dings 90(!) mal gefunden werden. Die weiteren Funde wurden ihm dann im Laufe der
nächsten Wochen inkrementell zugesendet.
    Ein sinnvoller Einsatz als „Alarmsystem“ zum Schutz eines Netzwerks kommt für
„Google Alerts“ somit nicht in Frage.


4.8    Zusammenfassung
In diesem Kapitel wurde beschrieben, auf welche Art und Weise Google Hacking sys-
tematisch zum Schutz der IT-Systeme eines Unternehmens eingesetzt werden kann.
Hierzu wurde der Begriff „Google Scanning“ eingeführt, der das Senden großer Men-
gen von Anfragen an Suchmaschinen und Entgegennehmen der Ergebnisse umschreibt.

    Ziel war es, eine Vorgehensweise zu finden, mittels derer regelmäßiges Google
Scanning langfristig automatisiert durchgeführt werden kann. Hierzu wurde zunächst
die Vorarbeit für das Einrichten einer solchen Routine beschrieben, wozu das Finden
aller relevanten Domains und sinnvoller Suchmuster gehörte. Das eigentliche Scan-
ning wurde anhand eines Algorithmus in Pseudo-Code dargestellt. Weiterhin wurde
beispielhaft die manuelle Analyse der Ergebnisse des Google Scannings umschrieben.
Für den Fall des Fundes von sensiblen Informationen wurden mögliche kurzfristige
Gegenmaßnahmen dargestellt.

    Im weiteren Verlauf wurde das Google Scanning-Tool „GooScanner“ vorgestellt,
das im Laufe dieser Diplomarbeit entwickelt wurde. Das Programm wurde komplett
in der Scriptsprache PHP implementiert und arbeitet als Web-Applikation auf der Ba-
sis eines SQL-Servers. Es bietet die Möglichkeit, frei festgelegte Mengen von Do-
mains mittels einer ebenso frei definierten Menge von Suchmustern in regelmäßigen
Zeitabständen zu „scannen“, wobei die Suchmaschinen Google, Live Search und Ya-
hoo Search verwendet werden. Außerdem steht innerhalb des Programms eine Schnitt-
stelle zur Auswertung der Suchergebnisse zur Verfügung, in welcher Treffer der Suche

                                        44
als „auffällig“ oder „unauffällig“ eingestuft und in beliebige Kategorien sortiert werden
können. Das Programm hat die Fähigkeit, bei neuen oder abermaligen Treffern zu spä-
teren Zeitpunkten zu erkennen, ob diese bereits bewertet wurden oder nicht, und meldet
noch nicht bewertete, neue Treffer per E-Mail an den Administrator des Programms.
    Da schon weitere Vulnerability-Scanner auf Basis von Google Hacking existierten,
wurden diese ebenfalls vorgestellt.

    Zu den Zielen der Diplomarbeit gehört die Bewertung der Dienste „Google Web
Services“ und „Google Alerts“. Es stellte sich heraus, dass die „Google Web Services“
im Zusammenhang mit Google Hacking unverzichtbar sind, da dies die einzige Schnitt-
stelle zur Google-Suchmaschine ist, über welche große Mengen von Anfragen gesen-
det werden können, ohne dass mit einer Abblockung der Anfragen zu rechnen ist. Für
das Benutzen dieser Schnittstelle ist allerdings ein Registrierungsschlüssel notwendig –
welcher zum Zeitpunkt des Abschlusses der Diplomarbeit nicht mehr beantragt werden
kann. Das im „GooScanner“ vorhandene Exemplar funktioniert jedoch weiter. Auf-
grund dieser Knappheit an Registrierungsschlüsseln und der ohnehin vergleichsweise
strengen Limitierung von Anfragen pro Tag sind die Schnittstellen von Live Search
(SOAP) und Yahoo Search (REST) mit ihren vergleichsweise sehr viel geringeren Re-
striktionen sehr nützliche Alternativen zur Google-Schnittstelle.
    „Google Alerts“ stellten sich schon nach einem kurzen Versuch als unbrauchbar für
systematisches Google Scanning heraus.

    Abschließend wurden die drei mittels GooScanner verwendeten Suchmaschinen
hinsichtlich ihrer Eignung für Google Hacking verglichen, wobei sich diese als sinn-
volle Ergänzungen zueinander erwiesen, zumal die Syntax der Anfragen jeweils sehr
ähnlich ist.

    Nachdem nun mit Google Scanning eine spezielle Form des Vulnerability Scan-
nings ausführlich vorgestellt wurde, folgt nun eine Betrachtung herkömmlicher Metho-
den. Im Zuge eines Vergleichs soll ein möglicherweise vorhandener Mehrwert durch
die Verwendung von Google Hacking erörtert werden.




                                           45
Kapitel 5

Google Hacking im Kontext
anderer Vulnerability-Scanning-
Methoden

5.1     Einleitung
Im Allgemeinen wird die Verwundbarkeit eines Webservers durch Vulnerability Scan-
ning und/oder Penetration Testing überprüft. Google Hacking würde nach der Vor-
gehensweise, die in dieser Diplomarbeit beschrieben wird, eher dem Vulnerability
Scanning zugeordnet werden. Auf jene Art der Überprüfung von Webservern soll im
Folgenden genauer eingegangen werden. Hierzu wird ein Überblick von Scanning-
Methoden anhand etablierter Vulnerability Scanner gegeben. Weiterhin wird Google
Hacking im breiteren Kontext des Penetration Testing betrachtet. Zunächst wird er-
örtert, ob ein Sicherheitsgewinn durch Google Hacking überhaupt messbar ist. Auf
Grundlage dieser Überlegungen und der Erfahrungen im praktischen Einsatz soll eine
Antwort auf die Frage gefunden werden, ob der Einsatz von Google Hacking einen
betrieblichen Mehrwert mit sich bringt.


5.2     Scanning-Methoden
Man unterscheidet zwischen passivem und aktivem Scanning. Bei passivem Scanning
wird Netzverkehr belauscht, woraus dann Rückschlüsse auf die Quellen oder Ziele der
aufgefangenen Datenpakete gezogen werden. Es wird allerdings kein direkter Kontakt
zu der zu untersuchenden IP-Adresse aufgenommen. Dies hingegen wird beim aktiven
Scanning getan, wodurch eine gezieltere Suche möglich ist.
Die im Folgenden beschriebenen zwei Werkzeuge – Nessus und Qualysguard – führen
aktives Scanning durch.

5.2.1   Nessus
Nessus [nesa] ist ein semi-kommerzielles (vormals freies) Vulnerability-Scanning-Werk-
zeug. Es hat Portscanning-Funktionalitäten, die Teilweise auf dem Tool „Nmap“ beru-
hen. Nessus führt darüberhinaus automatisiert Schritte von bekannten Angriffsmustern


                                         46
durch, welche durch eine integrierte Scriptsprache definiert werden können.

    Nmap ist ein freies Portscanning-Werkzeug, welches dazu dient, Dienste und Ser-
ver in einem Netzwerk zu erkennen. Hierzu verfolgt es verschiedene Strategien, wobei
auf der TCP-/IP-Schicht gearbeitet wird.

   1. Die Erkennung von Hosts: Beispielsweise mittels PING wird herausgefunden,
      welche Computer in einem Netz online sind, also Antworten geben - bzw., wel-
      che Ports von welchen Systemen offen sind - also welche Dienste aktiv sind.

   2. Versionserkennung: Auf Grundlage von offenen Ports wird versucht, zu erken-
      nen, welche Version von welcher Software oder welchem Betriebssystem zu die-
      sem Port gehört.

   3. Erkennung von Paketfiltern und Firewalls

   4. Hardware-Erkennung

Es wird festgestellt, auf welche Arten und Weisen Netzwerkverbindungen mit den un-
tersuchten Computern aufgebaut werden können – bzw., welche Möglichkeiten für
einen Angriff bestehen. Zudem können Computer in Netzen entdeckt werden, die ei-
gentlich nicht Bestandteil des Netzes sein sollten. Die Reichweite eines Scans kann bei
Nmap beispielsweise in Form von Intervallen von IP-Adressen eingestellt werden. So
kann man zum Beispiel alle IP-Adressen zwischen 192.168.10.0 und 192.168.10.256
untersuchen. Es können somit natürlich auch einzelne Adressen oder mehrere Interval-
le untersucht, sowie bestimmte Adressen oder Intervalle ausgeschlossen werden.

    Für Nessus können mit Hilfe eines Plugin-Systems und der Programm-eigenen
Scriptsprache Exploit-Module erstellt werden, welche genau auf bestimmte Sicher-
heitsschwächen ausgerichtet sind. Hier ein Auszug aus der Beschreibung eines solchen
Plugins [nesb]:

      „The remote host appears to be running a version of Apache 2.x which is
      older than 2.0.45
      This version is vulnerable to various flaws :
      - There is a denial of service attack which may allow an attacker to disable
      this server remotely
      - The httpd process leaks file descriptors to child processes, such as CGI
      scripts. An attacker who has the ability to execute arbitrary CGI scripts on
      this server (including PHP code) would be able to write arbitrary data in
      the file pointed to (in particular, the log files)“

     Anhand des Codes des Plugins aus Abbildung 5.1 kann man die Arbeitsweise von
Nessus (für diesen beispielhaften Fall) erkennen. In Z.10 wird geprüft, ob der Banner,
den eine Anfrage an einen Server geliefert hat, eine Information über den dort instal-
lierten Server liefert. Die Funktion „safe_checks()“ gibt die Information, ob Nessus
darauf konfiguriert ist, eine Sicherheitslücke probehalber auszunutzen. Falls nicht, wür-
de nur die Version des Servers überprüft, was als Grundlage für die Aussage, ob ein
Server verwundbar ist oder nicht, ausreichen müsste. Falls safe_checks() also eine
positive Antwort gibt (im Sinne von: „Es ist für den Betrieb des Systems sicherer, die
Lücke nicht probehalber auszunutzen“), wird zunächst in Z.12 mittels eines regulären

                                          47
 1   include ( " http_func . inc " ) ;
 2   include ( " backport . inc " ) ;
 3

 4   port = get_http_port ( default :80) ;
 5

 6   if ( get_port_state ( port ) ) {
 7      banner = get_backport_banner ( banner : get_http_banner ( port :
                 port ) ) ;
 8      i f ( ! banner ) e x i t (0) ;
 9

10       s e r v = s t r s t r ( banner , " Server " ) ;
11       i f ( safe_checks () ) {
12           i f ( e r e g ( p a t t e r n : " ^ S e r v e r : . ∗ Apache(− A d v a n c e d E x t r a n e t S e r v e r )
                       ?/2\.0\.([0 −9][^0 −9]|[0 −3][0 −9]|4[0 −4]) " , s t r i n g : serv ) )
                        {
13               security_hole ( port ) ;
14           }
15       }
16       e l s e i f ( e g r e p ( p a t t e r n : " Apache(− A d v a n c e d E x t r a n e t S e r v e r ) / 2 " ,
                   string : serv ) ) {
17           i f ( e g r e p ( p a t t e r n : " Apache(− A d v a n c e d E x t r a n e t S e r v e r )
                       ?/([3 −9]\.|2\.([1 −9]|0\.([5 −9][0 −9]|4[6 −9]) ) ) " , string :
                       serv ) ) exit (0) ;
18           soc = open_sock_tcp ( p o r t ) ;
19           f o r ( i = 0 ; i < 1 0 1 ; i ++) {
20               n = s e n d ( s o c k e t : soc , d a t a : s t r i n g ( " \ r \ n " ) ) ;
21               i f ( n <= 0 ) e x i t ( 0 ) ;
22           }
23

24           r = h t t p _ r e c v ( socket : soc ) ;
25           if (! r ) security_hole ( port ) ;
26       }
27   }


                               Abbildung 5.1: Quellcode eines Nessus-Plugins




                                                             48
Ausdrucks ermittelt, welche Server-Version vorliegt. Falls eine bekanntermaßen ver-
wundbare Server-Version vorliegt, wird diese Verwundbarkeit gemeldet und der Test
beendet.
    Falls safe_checks() zulässt, die Lücke zu testen, wird mittels Z.16 und 17 über-
prüft, ob eine anfällige Server-Version vorliegt. Falls nicht, wird der Test mittels „ex-
it(0)“ beendet. Andernfalls wird mittels Z.18-22 der Code ausgeführt, der einen DoS1
auslösen soll. In Z.24-25 wird überprüft, ob der Angriff erfolgreich war, also der Server
auf Anfragen nicht mehr reagiert.
    Das Plugin veranlasst Nessus also – abhängig davon, wie es konfiguriert ist – die
Sicherheitslücke aktiv auszunutzen; zumindest, was das Auslösen eines DoS betrifft.
Das wäre mittels Google Hacking nicht möglich; wohl aber – unter Umständen – das
Herausfinden der Version der Server-Software. Jedoch ist man beim Google Hacking
davon abhängig, dass diese Information in einem seiner unterstützten Formate vorliegt.
Falls man nur die Ausgabe des Seiten-Fragments in einem Treffer einer Google-Suche
oder den Inhalt des Google-Cache betrachtet, besteht zudem die Möglichkeit, dass die
Information veraltet ist und die Version der Server-Software inwzischen geändert wur-
de.

5.2.2      QualysGuard
Zu den Fähigkeiten von QualysGuard Enterprise gehören die nun folgenden [qua]:
   • Automatisiertes Scanning auf Verwundbarkeiten; vgl. Nessus
           – Entdeckung aller Bestandteile von Netzwerken
           – Internes und Externes Scanning
           – Anpassbarkeit von Scans auf bestimmte Ports, Dienste oder Schwachstel-
             len
           – Scheduling-System für regelmäßige Scans
   • Generierung von Reports
           – Visualisierung von Netzwerk-Topologien
           – Statistik-Funktionen: Am Häufigsten gefundene Angriffspunkte
           – Generierung von Nachrichten an Administratoren; Integration in Ticket-
             Systeme
   • Automatische Aktualisierung der eigenen Datenbank von Verwundbarkeits-Si-
     gnaturen
    Da es sich bei der Kernfunktionalität von QualysGuard um ein automatisiertes
Scanning-Verfahren handelt, findet sich damit die Hauptparallele zu Google Scanning.
Beide Scanning-Verfahren lassen sich in Umfang, Art der Ziele und Berichtverhalten
individuell anpassen, wobei die Art der untersuchten Ziele auf unterschiedlichen Ebe-
nen von IT-Systemen zu finden sind.
    Der Hauptunterschied zwischen den Verfahren von QualysGuard und von Goo-
gle Scanning ist das Ziel, welches in beiden Fällen jeweils untersucht wird. Qualys-
guard hat die Möglichkeit, ein Netzwerk bis auf die Netzwerk-Ebene des ISO/OSI-
Modells zu untersuchen. Diese Möglichkeit ist durch Google Scanning nicht gegeben;
  1 DoS   = „Denial of Service“


                                           49
hier bleibt man sogar nur auf der Anwendungsebene und untersucht Ausgaben von
Programmen.
    Demzufolge lässt sich mit Hilfe von Qualysguard auch die physische Struktur eines
Netzwerkes veranschaulichen, wohingegen mittels Google Scanning die Struktur von
Web-Inhalten eines Netzwerks sichtbar gemacht werden könnte.

5.2.3    WebInspect
Der Vulnerability-Scanner „WebInspect“ der Firma SPI Dynamics [web] hat Fähig-
keiten für das Erkennen von Sicherheitsschwächen in IT-Systemen auf verschiedenen
Ebenen des ISO/OSI-Schichtenmodells. Hierzu gehören:

   • Durchsuchen eines Netzwerks nach Servern

   • Portscanning

   • Fingerprinting

   • Bei Fund eines Webservers: Webcrawling und Indizierung der auffindbaren Sei-
     ten

   • Suche nach „versteckten“ Links innerhalb von Kommentaren

   • Suche nach Verzeichnissen; Durchsuchen gefundener Verzeichnisse und Dateien
     nach weiteren Verzeichnis- und Dateinamen

   • Simulation von Angriffen auf Hosts, Server und Web-Applikationen; hierbei
     Rückgriff auf eine Datenbank von Angriffsmustern für spezifische Server-Ver-
     sionen

Die Möglichkeiten des Webcrawlers dieses Vulnerability-Scanners gehen also über die-
jenigen einer Suchmaschine und somit über diejenigen des Google Hackings hinaus;
die Suche nach Links innerhalb von Kommentaren ist durch Google Hacking nicht
möglich.

5.2.4    Parallelen bzw. Unterschiede zum Google Hacking
Eine Parallele zwischen herkömmlichem Vulnerability Scanning und Google Hacking
besteht also im Feststellen von Anfälligkeiten allein aufgrund von Versions-Informatio-
nen. Mit Hilfe von Nessus können diese Anfälligkeiten allerdings auch direkt getestet
bzw. ausgenutzt werden, was mit Hilfe von Google nicht möglich ist.
    Ein Unterschied besteht stets in der Aktualität der gewonnen Information(en). Im
Google-Index bzw. -Cache findet man stets Information(en) aus einer mehr oder weni-
ger weit entfernten Vergangenheit, während bei einer direkten Untersuchung eines Ser-
vers jede Information aus der Gegenwart stammt. Dem Google Hacker liegt also nie ein
absolut aktueller Inhalt einer Webseite vor. Möglicherweise dient einem Google Hacker
die Information, die er mit Hilfe der Suchmaschinen findet, um sich – außerhalb des
Google Hackings – aktuelle Informationen zu beschaffen. Oder er findet Informationen
im Suchmaschinen-Cache, die im aktuellen Web-Inhalt seines Ziels schon längst nicht
mehr vorliegen. Dies bezieht sich auf verschiedene Arten von Informationen: Vertrau-
liche Dokumente, Log-Dateien, Listen von Usernamen, Fehlermeldungen etc..



                                          50
    Eine Parallele zwischen Vulnerability Scanning und Google Hacking kann in ge-
wisser Weise im Idle Scanning gesehen werden. Hier kann – genau wie beim Google
Hacking – eine Information über die Angreifbarkeit eines Servers durch eine dritte In-
stanz beschafft werden – in einem Fall durch den „Idle“-Rechner bzw. „Zombie“, und
im anderen Fall durch eine Suchmaschine.
    Ein direkter Portscan ist mit Hilfe von Google Hacking nicht möglich. Falls al-
lerdings mit Hilfe einer Suchmaschine HTTP- bzw. Ftp-Inhalte gefunden werden, ist
somit immerhin klar, dass auf den betreffenden Servern zumindest Port 80 bzw. 21 ge-
öffnet zu dem Zeitpunkt, zu welchem der Webcrawler der Suchmaschine den Server
untersucht hat, offen waren. Fingerprinting ist durch Google Hacking ebenfalls nicht
auf dem klassischen, sondern nur indirekten Wege durchführbar. Jedoch können durch
Google Hacking Informationen beschafft werden, die darauf schließen lassen, welche
Software auf einem Host läuft – zum Beispiel durch ungeschützte FTP-Verzeichnisse,
wo oft am Ende der ausgegebenen Seite die Version des Web-Servers ausgegeben wird.

    Mit Nessus und Nmap kann ein Server in seiner tieferen Struktur im Vergleich zu
Google Hacking weitaus detaillierter untersucht werden – zum Beispiel hinsichtlich
offener oder geschlossener Ports. Beim Google Hacking wäre man für eine solche In-
formation auf den selten auftretenden Fund von Konfigurations-Informationen in einem
seitens der Suchmaschinen unterstützten Format angewiesen.
    Die Vielfältigkeit von durch Suchmaschinen erkannten Formaten – wie PDF, DOC,
XLS und PPT – ist ein hilfreicher Aspekt des Google Hackings. Vulnerability-Scanner
mit einem breiten Spektrum wie WebInspect haben allerdings sogar die Möglichkeit,
jede Art von Datei zu durchsuchen, unabhängig von deren Format.

    Ob eine vertrauliche Information unbeabsichtigt an die Öffentlichkeit gelangt ist,
kann allerdings durch einen herkömmlichen Vulnerability-Scanner nicht hinreichend
überprüft werden. Das Google Hacking zeichnet somit eine gewisse Flexibilität aus;
neue Suchmuster lassen sich leicht integrieren und können verschiedene Arten von
Zielen haben, wohingegen herkömmliche Vulnerability Scans aufgrund ihrer festge-
legten Systematik eher generischer Natur sind.

    Während mit Hilfe von üblichen Vulnerability Scans eher die tiefere Struktur ei-
nes Systems analysiert werden kann, ist mit Hilfe von Google Hacking auf gewisse
Weise eine größere Breite in der Suche möglich. Dadurch, dass eine Suche allein auf
eine Domain eingeschränkt werden kann (und auch das nicht unbedingt muss), kann
es vorkommen, dass im Laufe eines Scans Subdomains oder Verzeichnisse entdeckt
werden, welche ursprünglich nicht berücksichtigt worden waren, aber dennoch ein Ge-
fahrenpotential darstellen. Für einen herkömmlichen Vulnerability Scan ist es dagegen
notwendig, dass vorher alle Ziele bekannt sind.
    Ein Unterschied besteht zwischen Google Hacking und den Methoden des Vulne-
rability Scanning liegt in der Auswahl des Ziels. Google Hacking bezieht sich stets
auf Webseiten. Hierbei können alle Webseiten in einem Suchindex durchsucht werden,
oder die Suche wird auf bestimmte URLs – im Falle von Live Search auch von IPs –
eingeschränkt. Ein Vulnerability Scanner wie Nessus untersucht IPs; WebInspect ver-
fügt zudem über einen Webcrawler, der Web-Inhalte genau untersuchen und indizieren
kann.

    In Nessus und WebInspect können bei der Untersuchung von Zeichenfolgen und
der Suche danach reguläre Ausdrücke verwendet werden. Dies ist bei Anfragen an


                                         51
                                Vulnerability Scan-   Google Hacking
                                ning
                                  Parallelen
Feststellen von Verwundbar-     Fingerprinting        Informationen auf
keit anhand v. Versionsinfor-                         Webseiten oder in
mationen                                              Dokumenten
„Dritte Instanz“ zwischen       Zombie-Rechner        Suchmaschine
Angreifer und Ziel
Automatisiertes Scanning        ja                    ja
mit Meldung von Funden
Suchmuster individuell an-      ja                    ja (in einem ein-
passbar                                               geschränkteren Rah-
                                                      men)
                                 Unterschiede
Feststellen von Verwundbar-     Ja                    Nein; es sei denn,
keit anhand probehalber An-                           Google Hacking ist
griffe                                                der komplette An-
                                                      griff
Aktualität der gewonnenen       größtmöglich          Abhängig von Such-
Informationen                                         maschine
Portscanning                    direkt                nicht direkt; ggf.
                                                      durch Rückschlüs-
                                                      se    aus    anderen
                                                      Informationen
Scanning von Dokumenten         ja                    eingeschränkt    auf
                                                      DOC, XLS, PDF,
                                                      PPT etc.
Auswahl der Ziele               dynamisch             Beschränkung     auf
                                                      bestimmte Domains
                                                      bzw.     IPs   (Live
                                                      Search)
Verwendung regulärer Aus-       ja                    nein
drücke
Bemerkbarkeit des Testers       möglich               leicht vermeidbar
bzw. Angreifers

  Tabelle 5.1: Vergleich von Google Hacking und Vulnerability Scanning




                                         52
Google, Yahoo Search und Live Search gleichermaßen nicht möglich. Bei automatisier-
tem Google Hacking wäre dies höchstens bei der Nachbearbeitung der Suchergebnisse
in Erwägung zu ziehen.
    Eine Besonderheit des Google Hackings liegt in der geringeren Entdeckbarkeit des
Angreifers. Wie zuvor erläutert, gibt es bei Vulnerability Scannern die Unterscheidung
in aktive und passive Scanmethoden. Google Hacking wäre hier eher mit einer passi-
ven Scanmethode vergleichbar. Der Umstand, dass ein Angreifer einen für ihn wert-
vollen Fund im Google-Index oder -Cache macht, wird vom potentiellen Opfer nicht
bemerkt, da zum Zeitpunkt des Fundes keine Daten von seinem Server abgerufen wer-
den (vorausgesetzt, im Falle der Betrachtung des Google-Caches wird auf das Laden
von Grafiken und Multimedia-Inhalten verzichtet – diese würden vom Original-Server
nachgeladen.). Der Google-Hacker muss also keine Verbindung mit dem angegriffenen
Server aufnehmen; dies erledigt der Webcrawler der Suchmaschine für ihn.
    Die Identität des Betrachters des Fundes könnte nur möglicherweise mit Hilfe des
Betreibers der entsprechenden Suchmaschine aufgeklärt werden. Allerdings besteht
bei der Benutzung von Google für den Angreifer die Möglichkeit, Anonymisierungs-
Dienste wie JAP [jap] oder TOR zu verwenden. Inwieweit die Anonymisierung hierbei
wirkungsvoll ist, soll hier nicht genauer beleuchtet werden. Tatsache ist jedoch, dass
Google Hacking eine der unauffälligsten Scanning-Methoden darstellt.
    Zusammenfassend eine tabellarische Gegenüberstellung (Tabelle 5.1) der Charak-
teristiken von herkömmlichem Vulnerability Scanning und Google Hacking.


5.3     Maximierung des Sicherheitsgewinns durch Google
        Scanning
Es gibt verschiedene Betrachtungsweisen dafür, was als Sicherheitsgewinn für ein Sys-
tem zu verstehen ist. Eine Idee hierfür, die in [BN] erwähnt wird, basiert auf Betrach-
tung der Erfahrungen mit der Wirksamkeit einer Sicherheits-Policy in der Vergangen-
heit. Man geht hier davon aus, dass sich der Grad an Sicherheit dadurch definiert, wie-
viele Sicherheitsschwächen nicht ausgenutzt worden sind, also möglicherweise nicht
ausgenutzt werden konnten. Vereinfachend gesagt: „Sicherheit = 100% aller Daten mi-
nus prozentualer Datenverlust durch Sicherheitsschwächen“. Mit Blick auf die Zu-
kunft stellt sich dann die Frage: Welcher Bruchteil eines möglichen Neu-Verlustes
kann durch welche Maßnahmen – wie zum Beispiel präventives Google Hacking bzw.
-Scanning – verhindert werden, bzw.: Wie kann die Abwehrrate möglicher Google-
Hacking-Angriffe im Rahmen der gegebenen Möglichkeiten maximiert werden?


5.3.1    Die Effektivität des Google Scannings
Um feststellen zu können, wie effektiv Google Scanning funktioniert, muss zuvor fest-
gelegt werden, welches maximale Maß an Aufgaben theoretisch erfüllt werden könnte
– also inwieweit man sich einer (nur theoretisch möglichen) sofortigen, umfassenden
Erkennung jeder Angreifbarkeit gegenüber Suchmaschinen-Hacking annähern kann.
Zu welchem Anteil man dies erreicht, soll hier genauer untersucht werden.
    Eine umfassende Erkennung, welche die Voraussetzung für eine vollständige Ab-
wehr wäre, wäre nur möglich, wenn stets alle möglichen Google-Hacking-Suchmuster
in der Datenbank des Abwehrsystems vorhanden wären. Das zu erreichen, ist natürlich
nahezu unmöglich. Was man tun kann, ist:

                                          53
   • Die Basis an Suchmustern durch regelmäßiges Laden der GHDB auf dem allge-
     mein bekannten Stand halten

   • Die vorhandenen Suchmuster individualisieren und an die eigenen Webseiten
     anpassen

In den folgenden Überlegungen wird zunächst davon ausgegangen, dass dies getan
wurde. Zu dem Einfluss der Aktualisierungsstrategie auf die Abwehrrate später mehr.
Zunächst wollen wir uns klar machen, dass der Erfolg von Google Hacking auch stets
von der oder den benutzten Suchmaschine(n) abhängt.


5.3.2   Auswirkung der Aktualität des Suchindex auf die Abwehr-
        rate
Es ist kaum möglich, zu erreichen, dass eine Sicherheitsschwäche zu dem Zeitpunkt
entdeckt wird, zu dem sie entsteht. Jedoch kann man im Fall des Google Hackings eine
sehr schnelle Erkennung erreichen, indem man eine eigene Suchmaschine wie „Goo-
gle Search Appliance“ oder „Google Mini“ verwendet. Diese erlaubt sowohl ständi-
ges Indizieren des Web-Inhalts, als auch die ständige und (in Bezug auf die Anzahl
von Suchanfragen) unlimitierte Auswertung des relativ aktuellen Indexes. Die Gren-
zen der Aktualität liegen hier in der physischen Übertragungskapazität, bzw. Bandbrei-
te, welche dem Webcrawler der eigenen Suchmaschine zur Verfügung steht. Bei solch
einer Strategie wird hinsichtlich aller bekannten Suchmuster eine höchstmögliche Er-
kennunggeschwindigkeit erreicht, womit die Voraussetzungen für eine größtmögliche
Abwehrrate geschaffen werden. Um diese zu erreichen, müsste allerdings eine sofor-
tige Reaktion auf einen Fund erfolgen. Hier könnte man entscheiden, den Inhalt eines
IT-Systems, der durch Google Scanning gefunden wurde, automatisch im Sinne einer
Prävention zu sperren, ohne zuvor auf eine Bewertung des Fundes zu warten. Im Fal-
le eines Fehlalarms könnten die auf diese Weise gesperrten Inhalte zu einem späteren
Zeitpunkt manuell wieder frei gegeben werden. Allerdings könnte sich diese Art der
Vorgehensweise nur als praktikabel erweisen, wenn es gelingen würde, die Menge an
Fehlalarmen zu minimieren.
     Möglicherweise steht eine eigene Suchmaschine wie „Google Search Appliance“
oder „Google Mini“ nicht zur Verfügung. Alternativ könnte man einen eigenen Craw-
ler entwickeln und damit arbeiten; jedoch wäre es schwierig, die öffentlichen Such-
maschinen exakt zu simulieren, was mittels eines Google-Produkts leichter wäre. Das
Verhalten einer öffentlichen Suchmaschine möglichst genau nachzuvollziehen ist wich-
tig, um die Gefahr, die von den öffentlichen Suchmaschinen ausgeht, auch möglichst
genau einschätzen zu können.
     Dieser Aspekt – und die Einsparung der Kosten für eine eigene Suchmaschine –
sind Gründe, die für das Arbeiten mittels der öffentlichen Suchmaschine beim präven-
tiven Google Scanning sprechen. In diesem Fall muss man mit allen Einschränkungen
auskommen, die dies mit sich bringt – also die Limitierung der Anzahl von Anfragen,
und die Unvorhersehbarkeit des Crawling-Verhaltens der Suchmaschinen.
     Diese Unvorhersehbarkeit ist der Aspekt, welcher einem potenziellen Angreifer
möglicherweise einen Vorsprung gegenüber der Abwehr ermöglicht. Ihm steht also
mindestens die Zeit zwischen dem neuesten Update des Suchmaschinen-Cache und
-Index, und dem neuesten Google-Scan der Verteidigung für einen Angriff zur Ver-
fügung. Wie lang diese Zeitdauer ist, hängt davon ab, wie oft der bzw. die Crawler
die Webseite erneut einlesen, und wie oft ein erneuter Google-Scan initiiert werden

                                         54
kann. Wie oft dies möglich ist, hängt davon ab, wie viele Domains zu überprüfen sind.
Zusammenfassend sind also dies die entscheidenden Faktoren:
   • Frequenz erneuten Einlesens durch die Webcrawler der Suchmaschinen
   • Frequenz erneut durchgeführter Google-Scans
   • Anzahl zu überprüfender Domains
   • Durchschnittliche Zeitdauer zwischen Besuch des Webcrawlers und des entspre-
     chenden Google-Scans
Je länger diese Zeitdauer ist, desto angreifbarer das System. Ziel ist also die Minimie-
rung dieser Zeitdauer. Diese kann auf zwei Wegen erreicht werden:
   1. Erhöhung der Anzahl möglicher Anfragen an die Suchmaschinen
   2. Kontrolle bzw. Erkennung des Besuchs von Webcrawlern der Suchmaschinen
Die Anzahl möglicher Anfragen hängt im Falle von Yahoo Search von der Anzahl von
Anfragenden IPs, im Falle von Google von der Anzahl an Registrierungsschlüsseln,
und im Falle von Live Search von beidem ab. Welche Möglichkeiten zur Beschaffung
dieser beiden Ressourcen bestehen, muss sich im Einzelfall zeigen. Angenommen, es
seien für die Verwendung jeder Suchmaschine genügend Registrierungsschlüssel und
IPs verfügbar, um den ganzen Tag lang ununterbrochen Anfragen zu senden. Dann
könnte die Anfragerate noch dadurch erhöht werden, indem mehrere IPs zur selben
Zeit die verschiedenen Suchmuster unter sich aufteilen. Die Anfragerate könnte also
theoretisch maximiert werden. Allerdings bedeutete dies keine Erhöhung der Abwehr-
rate mehr, sobald der jeweilige Webcrawler der Suchmaschine seinen Index seltener
aktualisiert - also die fraglichen Webseiten abruft - als das Abwehrsystem Anfragen
an die Suchmaschine sendet. Mit welchem Aufwand das Maximum an Effektivität er-
reicht werden kann, hängt also in erster Linie davon ab, wie oft der Webcrawler einer
Suchmaschine die fraglichen Seiten abruft.
    Daher wäre eine Kontrolle bzw. Erkennung von Besuchen der Webcrawler der
Suchmaschinen wünschenswert. Die Möglichkeiten der Kontrolle des Google-Bots mit
Hilfe der sitemap.xml werden in Abschnitt 6.3 auf S.66 vorgestellt. Die Frequenz der
Besuche durch die Crawler der beiden anderen Suchmaschinen kann man nicht kon-
trollieren, jedoch kann man sie erkennen – und zwar anhand ihrer IPs und/oder User-
Agents. Alle IP-Adressen herauszufinden, von denen aus die Crawler operieren, ist
evtl. möglich; die Crawler anhand der User-Agents zu identifizieren ist jedoch einfa-
cher und wahrscheinlich auch zuverlässig, da die großen Suchmaschinen sich so iden-
tifizieren sollten, um ihre Seriosität zu wahren. Hier eine Liste der bei den drei großen
Suchmaschinen üblichen User-Agents: Ein Google-Scan auf der jeweiligen Suchma-

             Suchmaschine                    User-Agent
             Live Search                     MSNBot
             Google                          Googlebot
             Yahoo                           Yahoo! Slurp

                   Tabelle 5.2: Die UserAgents der Suchmaschinen

schine sollte also sinnvollerweise unmittelbar nach dem Besuch ihres Crawlers (sie-
he Tabelle 2.1 auf S.17) durchgeführt werden, falls die Limitierung der Anfragen das


                                          55
zulässt. Falls Wege gefunden wurden, die Limitierung beliebig zu überschreiten, ist
mit dieser prompten Reaktion die bestmögliche Abwehr-Strategie gefunden. Jedoch
ist diese Strategie nur hinsichtlich aller Gefahren, die von unternehmenseigenen IT-
Systemen ausgehen, als „bestmöglich“ zu bezeichnen. Wie die Erfahrung gezeigt hat,
können sensible Informationen auch auf nicht-unternehmenseigenen Webservern zu
finden sein – wie zum Beispiel Zugangsdaten, die in eine URL eingebettet sind. Diese
URL wird dann zwar durch einen Google-Scan über die (bekannte) Domain entdeckt;
jedoch könnte kein optimaler Zeitpunkt für einen Scan festgelegt werden, da in diesem
Fall kein Besuch eines Webcrawlers festgestellt werden könnte.


5.3.3   Auswirkung der Aktualität bzw. des Inhalts der Suchmuster-
        Datenbasis auf die Abwehrrate
Es kann stets vorkommen, dass es Suchmuster gibt, mittels derer zwar ein Angrei-
fer sensible Inhalte aufspüren kann, welche aber der Suchmuster-Datenbasis des für
die Abwehr eingesetzten Google-Scanners nicht bekannt sind. In diesem Fall wird ei-
ne vorhandene Verwundbarkeit nicht erkannt. Die Frage danach, wie viele von sol-
chen unbekannten Suchmustern es gibt, ist stets offen. Es gibt für den Betreiber eines
Google-Scanners zwei Möglichkeiten, die Basis an Suchmustern aktuell zu halten, und
dies sind:

   • Regelmäßiges Laden der GHDB [ghd07] oder anderer Google-Hacking-Samm-
     lungen

   • Analyse der eigenen Webseiten und Server-Software und Erstellen von Such-
     mustern aufgrund individueller Merkmale

Innerhalb dieser Möglichkeiten die Basis an Suchmustern aktuell zu halten, ermöglicht
zumindest ein Maximum des erreichbaren Maßes an Sicherheit.


5.4     Kurze Einführung in Penetration Testing
In [Eck05] wird ein Penetrationtest als ein Verfahren beschrieben, mittels dessen man
„die Erfolgsaussichten eines vorsätzlichen Angriffs“ (S.85) einschätzen möchte. Hier-
bei wird zwischen Innen- und Außentäter unterschieden. Der Innentäter habe genaue
Kenntnisse über das angegriffene System, weshalb zum Simulieren seiner Möglichkei-
ten ein Whitebox-Test sinnvoll sei. Analog sei für die Einschätzung der Chancen eines
Außentäters ein Blackbox-Test sinnvoll.
    Ein Penetrationtest wird in [Eck05] als ein aus 5 Phasen bestehender Vorgang be-
schrieben:

   1. Recherche

   2. Portscanning

   3. Fingerprinting

   4. Identifikation von Schwachstellen

   5. Ausnutzen von Schwachstellen


                                         56
Im Rahmen eines Penetrationtests können alle Angriffsmöglichkeiten auf ein IT-System
überprüft werden.
     Die Recherche kann sich allerdings über beliebige Ebenen erstrecken, und somit
auch über die Web-Ebene. Google Hacking ist als Teil der Recherche durchaus vor-
stellbar.
     Bei einem Portscan werden auf der Netzwerk-Ebene Anfragen an die verschiede-
nen Ports bzw. Dienste eines Servers gesendet. Aus der Reaktion wird dann geschlos-
sen, ob der Port offen ist bzw. der Dienst aktiviert ist oder nicht. Auf dem Wege des
so genannten „Idle Scanning“ wird dies auf indirekte Weise gemacht, wobei bei der
Anfrage die IP eines dritten Rechners vorgetäuscht wird, und aus den Unterschieden
seiner IPIDs geschlossen wird, ob der Port des angefragten Rechners offen ist oder
nicht.
     Beim Fingerprinting wird die Reaktion, die man auf eine Anfrage erhält, genauer
analysiert, um auf die Software, die auf dem Server läuft, zu schließen, also Betriebs-
system, Server und deren Versionsnummern.
     Zur Identifikation von Schwachstellen werden im Penetrationtest persönliche Er-
fahrung, Exploit-Datenbanken und weitere Verfahren wie etwa Fuzzing benutzt. Ob
diese Schwachstellen auch wirklich ausgenutzt werden können, wird ebenfalls getes-
tet.

5.4.1    Resultate durch etablierte Penetration-Testing-Verfahren
Ein Penetrationtest ist ein umfassender Sicherheitscheck und sollte somit im Idealfall
auch alle Angriffsmöglichkeiten, die sich auf ein IT-System bieten, aufdecken. Da-
zu sollten auch die Angriffsmöglichkeiten gefunden werden, die man durch Google
Hacking aufdeckt. Da allerdings der Mehrwert von Google Hacking gegenüber allen
anderen Arten des Penetration Testing bzw. Vulnerability Scanning erörtert werden
soll, sollten hier Arten von Resultaten betrachtet werden, die ohne Hilfe von Google
Hacking erzielt werden können. Da sich Google Hacking explizit auf Suchmaschinen
bezieht, ist eigenständiges Webcrawling in diesem Vergleich im Pentesting erlaubt. Auf
diese Weise können also auch Suchmuster eingesetzt werden, um bestimmte Inhalte der
Webseiten eines Systems zu finden. Somit können mit Hilfe von Pentesting – neben al-
len anderen allgemeineren Sicherheitsschwächen – Web-Inhalte entdeckt werden, die
nicht genügend vor öffentlichem Zugriff geschützt werden.
    Es gibt eine Ähnlichkeit der Vorgehensweisen im Penetration Testing und im Goo-
gle Hacking. In einem Penetration Test werden durch eine Person oder ein Team alle
ihm bekannten Möglichkeiten für einen Angriff auf ein System probiert, wobei wäh-
rend des Tests auch neue Angriffsmethoden ersonnen werden, die nur im Angriff auf
das einzelne System greifen könnten. Hier liegt die Parallele zum Google Scanning: Al-
lein eine festgelegte Menge an Suchmustern zu verwenden, reicht nicht aus. Durch die
Untersuchung von Webseiten und Server-Software eines individuellen Systems müs-
sen Suchmuster gefunden werden, durch welche typische Fehlermeldungen, Login-
Parameter usw. gefunden werden.


5.5     Der betriebliche Mehrwert durch Google Hacking
Der Mehrwert, der durch den Einstatz von Google Hacking erzielt werden kann, ist
immer davon abhängig, welche Schutzsysteme oder -prozesse in einem Betrieb bereits
vorhanden sind. Der Vergleich der Sicherheitszustände in Situationen mit- bzw. ohne

                                          57
Google Hacking kann – je nach Ausgangslage ohne Google Hacking – unterschied-
lich ausfallen, wobei der Einsatz an Mitteln für Google Hacking in jedem Fall gleich
ist. Im Folgenden wird der Sicherheitsgewinn für die folgenden Ausgangssituationen
betrachtet:

   • Ungesicherte IT-Systeme

   • Durch automatisiertes Vulnerability Scanning gesicherte IT-Systeme

   • Durch manuelles Pentesting gesicherte IT-Systeme

   • Durch Vulnerability Scanning und Pentesting gesicherte IT-Systeme


5.5.1   Ungeschützte Systeme
Bei einem IT-System, welches weder durch Vulnerability-Scanning, noch durch Pene-
tration Testing geschützt wird, ist der Sicherheitsgewinn – innerhalb bestimmter Gren-
zen – erheblich, da jede Sicherheitsschwäche, die durch Google Hacking aufgedeckt
wird, durch kein anderes Verfahren bemerkt werden könnte.
     Erkannt werden können die folgenden Arten von Sicherheitsschwächen:

   • Vertrauliche Daten, die in öffentlich zugänglichen Verzeichnissen eines Webser-
     vers liegen

   • In URLs integrierte Zugangsdaten

   • Versions-Informationen von Webservern, Webapplikationen und ggf. weiteren
     Arten von Software

   • Informationen über die innere Struktur von Webservern, z.B. durch Fehlermel-
     dungen

   • Informationen über die Funktionsweise von Anwendungen, z.B. durch Fehler-
     meldungen

   • Ungeschützte Zugänge zu Intranets, Hardware-Administrationsschnittstellen und
     allen Seiten, deren Betrachtung eigentlich Authentifikation voraussetzen

    Die Grenzen des Sicherheitsgewinns bestehen aus all denjenigen Sicherheitsschwä-
chen, die durch Google Hacking prinzipiell nicht erkannt werden können. Dies betrifft
alle Informationen, die...

   • ...nicht in Form von HTML oder einem unterstützten Dokumentenformat sicht-
     bar sind

   • ...nicht über das Web zugänglich sind

   • ...zwar über das Web zugänglich sind, aber weder in einem ungeschützten Ver-
     zeichnis aufgelistet werden, noch durch einen Hyperlink zu finden sind

   • ...nur unter Verwendung von regulären Ausdrücken zu finden wären


                                         58
5.5.2   Durch Vulnerability Scanning geschützte Systeme
Wie bereits in Tabelle 5.1 deutlich geworden, gibt es mehrere Unterschiede zwischen
herkömmlichem Vulnerability-Scanning und Google Scanning. Die nun folgende Ge-
genüberstellung behandelt die Frage: Welche Sicherheitsschwächen können durch Goo-
gle Hacking erkannt werden, die allein durch herkömmliches Vulnerability Scanning
nicht erkannt würden?

    Vorfall                                       Aufdeckung       Aufdeckung
                                                  durch Google     durch      Vul-
                                                  Hacking          nerability
                                                                   Scanning
    Vertrauliche Informationen in den Forma-      ja               ja; mit Aus-
    ten HTML, Doc, Xls, ... sind über das Web                      nahme      von
    öffentlich zugänglich                                          Suchmaschinen-
                                                                   Caches
    Es existieren im Internet Links mit inte-     ja               nein
    grierten Zugangsdaten
    Fehlermeldungen oder Versionsinforma-         ja               ja; mit Aus-
    tionen von IT-Systemen sind auf öffentli-                      nahme       von
    chen Webseiten sichtbar                                        Suchmaschinen-
                                                                   Caches
    Authentifikation voraussetzende Bereiche       ja               nur, falls Link
    mit Web-Oberfläche sind öffentlich zu-                          von innerhalb
    gänglich                                                       des Systems
                                                                   aus
    Es existieren im Suchmaschinen-Cache          ja               nein
    sensible Informationen, die im realen Sys-
    tem nicht mehr zugänglich sind

Tabelle 5.3: Vergleich von Google Hacking und Vulnerability Scanning bzgl. Mehr-
werts durch Google Hacking

    Hier sind die Stärken von Google Hacking deutlich erkennbar. Die im Anhang auf-
geführten Beispiele zeigen teilweise, dass sich der Mehrwert von Google Hacking ge-
rade in den hier aufgeführten Punkten zeigt.


5.5.3   Durch Penetration Testing geschützte Systeme
Die unterschiedlichsten Angriffsmöglichkeiten, die durch Pentesting durchgeführt wer-
den können, sind durch Google Hacking allein nicht durchführbar. Durch Google Hac-
king können nur – oder gerade – die Informationen recherchiert werden, die im wei-
teren Penetrationtest hilfreich sind. Zur Konkretisierung dieses Unterschieds nun eine
ähnliche Gegenüberstellung wie in Tabelle 5.3.
    Hier zeigt sich, dass der eigentliche Vorteil von Google Hacking gegenüber Pe-
netration Testing in der Möglichkeit der automatisierten Überwachung besteht. Alle
Funde, die durch Google Hacking gemacht werden können, können auch im Rahmen
eines Penetration Tests gemacht werden – zumal die Verwendung einer Suchmaschine
durchaus Teil eines Penetration Tests sein kann. Wenn die Verwendung einer Such-
maschine im Rahmen eines Penetration Tests nicht möglich ist, ist der Mehrwert durch


                                         59
    Zielsetzung                                   Durch Goo-        Durch     Pe-
                                                  gle Hacking       netration
                                                  erreicht          Testing
                                                                    erreicht
    Dauerhafte Überwachung der Web-Inhalte        ja                nein
    von IT-Systemen
    Entdeckung von Links mit integrierten Zu-     ja                evtl. ja
    gangsdaten od. SQL-Injection-Parametern
    im Internet
    Entdeckung von Fehlermeldungen oder           ja                evtl. ja
    Versionsinformationen von IT-Systemen
    auf öffentlich sichtbaren Webseiten
    Entdeckung der öffentlichen Zugänglich-       ja                evtl. ja
    keit von Authentifikation voraussetzenden
    Bereichen mit Web-Oberfläche
    Entdeckung sensibler Informationen, die       ja                evtl. ja
    im realen System nicht mehr zugänglich
    sind, im Suchmaschinen-Cache

Tabelle 5.4: Vergleich von Google Hacking und Penetration Testing bzgl. Mehrwerts
durch Google Hacking


Google Hacking in den in Tabelle 5.4 aufgelisteten Punkten vorhanden. Dann zeigt sich
der Unterschied in der Art und Weise, auf welche in beiden Verfahren versucht wird,
an sensible Informationen zu gelangen. Beim Google Hacking können Informationen
über den Umweg des Suchindexes oder Caches entwendet werden. Ein Seiteneffekt ist
hierbei, dass es dem Google Hacker deutlich leichter fällt, dabei unerkannt zu bleiben.
Der Zugriff auf den Google Cache bleibt zumindest dann, wenn das Anzeigen von Bil-
dern deaktiviert wird, vom Zielsystem absolut unbemerkt. Es bleibt noch zu bemerken,
dass die Ressourcen des Zielsystems – wie Bandbreite und Rechenzeit – durch Google
Hacking nicht belastet wird, wie es beim klassischen Penetrationtest etwa durch einen
Portscan allerdings der Fall sein kann.


5.5.4    Durch Vulnerability Scanning und Penetration Testing ge-
         schützte Systeme
Wie schon aus den letzten beiden Abschnitten hervorgeht, bietet Google Hacking für
IT-Systeme, die nur durch eine der beiden anderen genannten Schutzmaßnahmen ge-
sichert werden, in bestimmten Punkten einen Mehrwert. Um zu erkennen, ob es auch
gegen die beiden anderen Schutzmaßnahmen gleichzeitig – und evtl. einen daraus her-
vorgehenden Synergieeffekt – einen Mehrwert bietet, hier eine weitere Gegenüberstel-
lung.
     Durch die Gegenüberstellung in Tabelle 5.5 wird deutlich: Durch Vulnerability
Scanner (insbesondere solche wie WebInspect) können ähnliche Überwachungs-Auf-
gaben wie durch Google Scanning übernommen werden. Allerdings wird ein Vulnera-
bility Scanner üblicherweise von einem unternehmenseigenen IT-System aus gestartet.
Die Perspektive des Webcrawlers einer Suchmaschine beinhaltet einen größeren Ab-
stand zu einem IT-System und repräsentiert somit möglicherweise eher eine Sicht auf
ein System, die derjenigen eines externen Angreifers entspricht. Zudem wird durch

                                          60
    Schutzmaßnahme                Google Hacking         Vulnerability Scan-
                                                         ning mit Penetration
                                                         Testing
    Entdeckung öffentlich über    Durch intervallba-     Durch intervallba-
    das Web zugänglicher, ver-    sierte Überwachung;    sierte Überwachung
    traulicher Informationen in   von Außen              von Innen; Von Au-
    den Formaten HTML, Doc,                              ßen evtl. im Rahmen
    Xls, ...                                             eines Pentests
    Entdeckung von Links im       Durch intervallba-     Evtl. im Rahmen ei-
    Internet, die Zugangsda-      sierte Überwachung     nes Pentests
    ten od. SQL-Injection-        von Außen
    Parameter enthalten
    Entdeckung von im Web öf-     Durch intervallba-     Durch intervallba-
    fentlich sichtbaren Fehler-   sierte Überwachung     sierte Überwachung
    meldungen und/oder Versi-     von Außen              von Innen; evtl.
    onsinformationen                                     im Rahmen eines
                                                         Pentests
    Entdeckung der Zugänglich-    Durch intervallba-     Durch intervallba-
    keit von Authentifikation      sierte Überwachung     sierte Überwachung
    voraussetzenden Bereichen     von Außen              von Innen; evtl.
    mit Web-Oberfläche                                    im Rahmen eines
                                                         Pentests
    Überprüfung der Existenz      Durch intervallba-     Evtl. im Rahmen ei-
    von sensiblen Informationen   sierte Überwachung     nes Pentests
    im Suchmaschinen-Cache
    Dauerhafte Überwachung        ja; Perspektive: von   ja; Perspektive: von
    der Web-Inhalte von IT-       Außen                  Innen
    Systemen

Tabelle 5.5: Vergleich von Google Hacking und Penetration Testing zusammen mit
Vulnerability Scanning bzgl. Mehrwerts durch Google Hacking




                                       61
Google Scanning im Gegensatz zum herkömmlichen Vulnerability Scanning in je-
dem Aspekt die Problematik berücksichtigt, dass eine Information auch dann noch im
Suchmaschinen-Cache vorhanden sein kann, wenn sie im realen System schon nicht
mehr vorhanden ist.

5.5.5    Kosten-/Nutzen-Verhältnisse auf Basis des messbaren Anteils
         am Sicherheitsgewinn
Wie schon in [Fre] bemerkt wird, gibt es einen steigenden Bedarf dafür, Kosten und
Nutzen von Investitionen in Sicherheit abzuwägen. Investitionen in (Daten-)Sicherheit
unterscheiden sich (siehe [Wei]) von anderen unternehmerischen Investitionen darin,
dass sie nicht etwa einen steigenden Gewinn zur Folge haben, sondern möglicherwei-
se die Vermeidung von Verlust. Diese Perspektive macht es schwierig, eine sinnvolle
Höhe der Investition zu finden.
     Um dies zu erleichtern, wurden betriebswirtschaftliche Messwerte wie ROSI („Re-
turn on Security Investments“), „risk leverage“ eingeführt. Anhand von Werten wie
diesem soll aufgezeigt werden, welchen Wert eine Investition in Sicherheit hat, indem
sie ins Verhältnis zum Verlust, der durch die gestiegene Sicherheit verhindert wurde,
gesetzt wird. Dies setzt Kenntnisse darüber voraus, welche Gefahren durch die Inves-
tition abgewehrt werden. Hierbei kann man sich ausschließlich auf Erfahrungswerte
stützen.

    In den beispielhaften Google-Scans, die in Anhang B beschrieben werden, sind die
folgenden Arten von Funden aufgetreten:

   1. Zugangsdaten von Kunden zu einem Business-Portal

   2. Zugangsdaten zu einer Kunden-Homepage

   3. Auflistung von Verzeichnis-Inhalten

   4. Konfigurationsdatei für „Virtual Hosts“

   5. PHP-Testseiten mit detaillierten Konfigurations-Informationen

    Die Möglichkeiten des Missbrauchs dieser Informationen können jeweils nur ab-
geschätzt werden. Bei den hier aufgelisteten Arten von Funden ist die Art von Punkt
1 diejenige, durch die am wahrscheinlichsten ein erheblicher finanzieller Schaden für
eine Firma entstehen könnte. Alle weiteren Arten von Funden können es einem Angrei-
fer allerdings unter Umständen erheblich erleichtern, eine Strategie für einen Angriff
auf die IT-Systeme der jeweiligen Firmen zu finden.

    Wenn zudem nur anhand dieser Erfahrungswerte über das Vorkommen von Fun-
den von sensiblen Daten einer Investition in Sicherheit, also in diesem Falle in Google
Hacking / Google Scanning, zugrundegelegt wird, bringt dies allerdings die Frage mit
sich: Sollten bei einer Investition in Security nur diejenigen Gefahren berücksichtigt
werden, bei denen aus Erfahrung bekannt wurde, welche Verluste und Folgekosten
durch sie entstehen können? Die Höhe eines möglichen, zukünftigen Verlustes kann
zwar nicht leicht eineschätzt werden. Jedoch könnte er möglicherweise durch die ver-
gleichsweise geringen Investition in Google Hacking bzw. -Scanning verhindert wer-
den – wobei der Hauptteil dieser Investition aus Personalkosten bestehen würde.

                                          62
5.6     Zusammenfassung
Für den Vergleich mit herkömmlichem Vulnerability Scanning wurden die Tools „Nes-
sus“, „QualysGuard“ und „WebInspect“ vorgestellt. Anhand dieser Beispiele wurden
Parallelen und Unterschiede zum Google Scanning untersucht, wobei sich einige theo-
retische und praktische Parallelen herausstellten, die Berücksichtigung von Suchma-
schinen-Speichern aber stets einen Unterschied ausmachte.
    Im Folgenden wurden die Möglichkeiten, die Abwehrrate gegen Google Hacking
durch präventives Google Scanning zu maximieren, betrachtet. Hierbei zeigte sich,
dass die Aktualität der Indizes der verwendeten Suchmaschine, sowie der Inhalt der
verwendeten Menge von Suchmustern wesentlichen Einfluss auf diese Möglichkeiten
haben.

    Ein Ziel der Diplomarbeit war die Beurteilung eines möglichen Mehrwertes für
die Sicherung der IT-Systeme eines Unternehmens durch Google Hacking bzw. Goo-
gle Scanning. Hierzu wurde der Einsatz von Google Scanning im Rahmen von ver-
schiedenen Ausgangssituationen betrachtet, in denen entweder überhaupt keine ver-
gleichbare Schutzmaßnahme eingesetzt wird; ausschließlich Vulnerability Scanning,
ausschließlich Penetration Testing oder beide diese Verfahren. Hier zeigte sich, dass
Google Scanning im ersten Fall zwar einen erheblichen Sicherheitsgewinn darstellen
kann, allerdings nur in bestimmten Bereichen.
    Im Falle der Ergänzung zu Vulnerability Scanning zeigt sich der Mehrwert von
Google Scanning darin, dass hierdurch zwar ähnliche Aspekte berücksichtigt werden
wie durch Vulnerability Scanner der Art von WebInspect; mit Fokussierung auf die
Suchmaschinen liefert Google Scanning jedoch darüber hinaus gehende Informationen,
die einen Mehrwert bedeuten.
    Zu Penetration Testing liefert Google Scanning allein schon deshalb einen Mehr-
wert, da es als regelmäßige, automatisierte Schutzmaßnahme – wie im herkömmlichen
Vulnerability Scanning – eingerichtet werden kann. Penetration Testing als Maßnah-
me zu vereinzelten Zeitpunkten kann zwar aufgrund der allgemeineren Fokussierung
alle Ergebnisse, die durch Google Hacking entstehen können, mit berücksichtigen, da
dieses im Rahmen eines Pentests durchaus angewendet werden kann. Jedoch werden
durch Penetration Testing die Funde, die durch Google Scanning entstehen, nicht zeit-
nah zu ihrem Auftreten gemacht.
    Somit liefert Google Scanning auch für den Schutz von IT-Systemen, die sowohl
schon durch Vulnerability-Scanning, als auch durch Penetration Testing gesichert wer-
den, einen Mehrwert. Es wird ebenso wie herkömmliches Vulnerability Scanning als
automatisiertes Schutzsystem eingesetzt, liefert jedoch teilweise Ergebnisse, die sonst
nur durch Penetration Testing entstehen würden.

    Das Kosten-/Nutzen-Verhältnis von Google Scanning ist zwar auch nach diesen
Erkenntnissen nicht genau zu quantifizieren und könnte nur aufgrund von Erfahrungen
mit Ergebnissen durch Google Scanning gemacht werden. Diese Ergebnisse können je-
doch schon einen Eindruck davon vermitteln, welche Arten von potentiellen Ursachen
für finanzielle Schäden durch Google Scanning entdeckt und verhindert werden kön-
nen. Aufgrund der nur geringen Investitionen, die für die Einrichtung eines dauerhaf-
ten Schutzes durch Google Scanning notwendig wären, und der sehr wahrscheinlichen
Reduktion der dauerhaften Personalkosten auf ein akzeptables Maß, ist das Kosten-
/Nutzen-Verhältnis somit zugunsten der Investition anzusehen.
    Durch Vulnerability Scanning werden Sicherheitslücken aufgedeckt, die mögli-


                                          63
cherweise schon über einen längeren Zeitraum vorhanden sind und eventuell zu Scha-
den geführt haben. Um Schäden im Voraus zu vermeiden, sind präventive Abwehr-
maßnahmen notwendig. Welche Möglichkeiten hierfür bestehen, wird im folgenden
Kapitel erläutert.




                                       64
Kapitel 6

Präventive Abwehr von Google
Hacking

6.1    Einleitung
Einem Google-Hacker soll es im Sinne des Datenschutzes unmöglich gemacht werden,
sensible Informationen zu finden. Daher ist es für den Eigner dieser Informationen
wichtig, frühzeitig zu erkennen, ob diese Gefahr besteht, so dass er die Möglichkeit
hat, sich vor der Preisgabe seiner Informationen zu schützen. Wie im letzten Kapi-
tel beschrieben wurde, besteht diese Möglichkeit durch Google Scanning mittels eines
Werkzeugs wie GooScanner. Diese Art der Vorgehensweise hat jedoch den Nachteil,
dass eine Gefahr erst erkannt wird, wenn sie schon gegenwärtig ist – nämlich in Form
von Inhalt einer öffentlichen Suchmaschine. Potentiellen Angreifern kann man daher
mit Hilfe einer eigenen Suchmaschine effektiver zuvorkommen, was im ersten Ab-
schnitt dieses Kapitels erläutert wird.
     In den weiteren Abschnitten werden ergänzende Schutzmaßnahmen erläutert. Hier-
zu gehört grundsätzlich eine sichere Konfiguration von schützenswerten Servern. Der
Einsatz von so genannten „Google Hacking Honeypots“ kann ggf. Angreifer ablenken
oder Informationen über sie liefern. Unvorsichtige Google Hacker können zudem ggf.
erkannt und abgeblockt werden.
     Bei Überlegungen zur Abwehr von Google Hacking ist es wichtig, zu wissen, wie
weitgehend Informationen von Web-Crawlern wie den Bots der Suchmaschinen über-
haupt gefunden werden können. Hierauf wird im vorletzten Abschnitt dieses Kapitels
eingegangen.
     Zusammenfassend wird im letzten Abschnitt eine Empfehlung zur Einrichtung ei-
nes dauerhaften Schutzes gegen Google Hacking gegeben.


6.2    Alarmsysteme
Ziel eines Alarmsystems sollte sein, eine eventuelle Lücke im Zugriffsschutz auf sen-
sible Informationen vor Interessenten mit böswilligen Absichten, in unserem Falle vor
Google-Hackern, zu finden. Wenn zum Aufspüren solcher Lücken ein Administrator
dieselbe Ressource verwendet wie eventuelle Angreifer, nämlich die originale Such-
maschine, hat er keinen zeitlichen Vorsprung vor dem Hacker. Da man davon ausgehen

                                         65
sollte, dass Hacker ebenfalls automatisierte Tools verwenden, ist ein zeitlicher Vor-
sprung eigentlich überhaupt nicht möglich.
    Eine auf Google Scanning basierende Abwehrmaßnahme wäre effektiver, wenn
durch das Einlesen von sensiblen Informationen durch Webcrawler von öffentlichen
Suchmaschinen nicht nur im Nachhinein sondern vorher erkannt würde, dass diese
Möglichkeit besteht. So könnten die Informationen rechtzeitig geschützt werden. Durch
Google Scanning kann dies allerdings nur erreicht werden, wenn ein Webcrawler nebst
zugehöriger Suchmaschine verwendet wird, die nicht öffentlich zugänglich ist und ak-
tuellere Inhalte als die öffentlichen Suchmaschinen hat. Falls hierzu eine selbst entwi-
ckelte Kombination aus Webcrawler und Suchmaschine verwendet würde, könnte man
im Betrieb allerdings nicht sicher gehen, alle möglichen Funde zu machen, die auch
durch die öffentlichen Suchmaschinen gemacht werden könnten, da die Quellcodes
ihrer Webcrawler und Such-Algorithmen nicht öffentlich zugänglich sind. Allerdings
bietet Google seinen Crawler und seine Suchmaschine als geschlossenes System zum
Einsatz innerhalb von Unternehmen an. Google Mini und Google Search Appliance
können auf „Dauer-Crawling“ konfiguriert werden (siehe [gooc]). Somit hängt die Ak-
tualität der Daten nur davon ab, wie viel Bandbreite man dem Crawler zur Verfügung
stellt - und natürlich von der internen Arbeitsgeschwindigkeit des Google-Mini- oder
-Search-Appliance-Servers. Welche Auswirkungen diese Aktualität auf die Möglich-
keiten zur Sicherung eines Systems hat, wird in Abschnitt 5.3.2 erläutert.
    Dem Autor dieser Diplomarbeit stand allerdings kein Exemplar der Suchmaschi-
nen zur Verfügung, so dass die praktische Verwendung im Zusammenhang mit Google
Hacking nicht getestet werden konnte.


6.3     Server-Konfiguration
Mittels einer Datei namens robots.txt, welche im Wurzelverzeichnis einer Website
liegt, kann man Suchmaschinen mitteilen, welche Bestandteile einer Website möglichst
durch sie indiziert werden sollten und welche nicht. Zudem kann man die Indizierung
der Seite durch bestimmte Suchmaschinen erlauben oder verbieten. An diese auf Ba-
sis des so genannten „Robots Exclusion Standard“ verfassten Anweisungen halten sich
jedoch nicht unbedingt alle Webcrawler, jedoch definitiv die Webcrawler der hier für
Google Hacking verwendeten Suchmaschinen.
    Das Problem auf der Opferseite des Google Hacking besteht oftmals darin, dass ein
Verzeichnis oder Dateien vom Internet aus zugänglich sind, obwohl sie es nicht sein
sollten. Diese Verzeichnisse sind somit nicht durch vorher definierte Indizierungsver-
bote schützbar, da ohnehin die Möglichkeit der Indizierung nicht in Erwägung gezogen
worden war. Eine Blacklist mit bestimmten Verboten ist somit nicht sehr wirkungsvoll.
Stattdessen sollte eine robots.txt als Whitelist konfiguriert werden. In Belegungen der
Parameter „Allow“ und „Disallow“ darf wie bei „User-agent“ das Jokerzeichen „*“
verwendet werden.
 Beispiel 24
 User-agent: *
 Disallow: /*
 Allow: /news/daily.html
In Beispiel 24 wird durch die erste Zeile das Indizieren der Website jeder Suchma-
schine erlaubt. In der zweiten Zeile wird das komplette Indizieren des Verzeichnisses
„/news/“ verboten. Das Indizieren der Datei „/news/daily.html“ wiederum wird


                                          66
durch die dritte Zeile erlaubt.
Auf diese Weise kann sichergestellt werden, dass nur genau diejenigen Seiten in Such-
maschinen-Indizes auffindbar sind, von denen man dieses auch möchte. Einen Schutz
vor Web-Spidern oder -Crawlern, die sich nicht an die Konvention der Berücksichti-
gung einer robots.txt halten, bietet diese Maßnahme natürlich nicht.
    Im Falle des MsnBot kann zusätzlich noch auf folgende Weise die minimale Zeit
zwischen zwei Crawling-Vorgängen angegeben werden:
 Beispiel 25
 User-agent: msnbot
 Crawl-delay: 120
    Ergänzend zur robots.txt können die Webcrawler von Google und weiterer Such-
maschinen mittels spezieller Meta-Tags in den indizierten HTML-Dateien in ihrem
Indizierungs-Verhalten beeinflusst werden. Durch den folgenden Tag im Header einer
HTML-Datei werden Crawler dazu veranlasst, die Seite nicht in ihren Cache aufzuneh-
men:

         <META NAME=ROBOTS CONTENT=NOARCHIVE>

    Wenn von der Seite außerdem keine Fragmente gespeichert werden sollen, die in
der Liste der Suchergebnisse gezeigt werden, lautet der Tag mit der entsprechenden
Anweisung folgendermaßen:

         <META NAME=ROBOTS CONTENT=NOSNIPPET>

   Im Falle des MsnBot sind die Bezeichnungen dieser Meta-Tags abweichend. Das
Verbot einer Aufnahme in den Cache lautet hier:
         <META NAME=msnbot CONTENT=NOCACHE />
Verbot der Aufnahme in den Index:
         <META NAME=msnbot CONTENT=NOINDEX />
Zudem kann hier verboten werden, Links zu folgen, welche auf der Hauptseite ange-
geben werden:
         <META NAME=msnbot CONTENT=NOFOLLOW />
    Speziell im Hinblick auf Google ist eine etwas genauere Konfiguration möglich.
Mittels einer Datei namens sitemap.xml, welche im Wurzelverzeichnis einer Websi-
te abgelegt wird, kann der Google-Bot angewiesen werden, welche Seite einer Website
er wie oft besuchen soll, und welche Seiten als Suchergebnis eine höhere Priorität ha-
ben sollen. Allerdings gibt es keine Garantie durch Google, dass die Anweisungen in
dieser Datei genau beachtet werden. Zudem bietet das Format keine Möglichkeiten, be-
stimmte URLs von der Indizierung auszuschließen. Dafür muss weiterhin die robots.txt
verwendet werden. Die folgenden XML-Tags können in einer sitemap.xml verwendet
werden:
   • <urlset> (erforderlich): Menge von URLs
   • <url> (erforderlich): Beschreibung der Behandlung einer URL
   • <loc> (erforderlich): Wortlaut der URL


                                         67
1   <? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF−8" ? >
2   < u r l s e t xmlns = " h t t p : / / www. g o o g l e . com / s c h e m a s / s i t e m a p / 0 . 8 4 " >
3      <url>
4           < l o c > h t t p : / / www. e x a m p l e . com / < / l o c >
5           < l a s t m o d >2005−01−01< / l a s t m o d >
6           < c h a n g e f r e q >monthly< / c h a n g e f r e q >
7           < p r i o r i t y >0.8</ p r i o r i t y >
8      </ url>
9   </ urlset>


                                 Abbildung 6.1: Beispiel einer sitemap.xml


        • <lastmod> (optional): Datum der letzten Änderung des Inhalts
        • <changefreq> (optional): Häufigkeit der Änderung des Inhalts der Seite. Mög-
          liche Werte:
                – always
                – hourly
                – daily
                – weekly
                – monthly
                – yearly
                – never
            Diese Werte dienen allerdings nur als Hinweis an Google. Dadurch ist nicht sei-
            tens Google garantiert, dass die Seite auch gemäß dieser Zeitabstände neu indi-
            ziert wird.
        • <priority> (optional): Priorität der URL gegenüber anderen URLs in dersel-
          ben Menge von URLs
    Das Listing 6.1 einer beispielhaften sitemap.xml stammt aus der offiziellen Dokumen-
    tation der Google Webmaster Tools [goof]. Grundsätzlich ist eine sichere Konfiguration
    der gesamten IT-Infrastruktur empfehlenswert, um auch gegen Google Hacking weni-
    ger anfällig zu sein. Da eine allgemeine Absicherung sich nicht explizit auf Google
    Hacking bezieht, wird sie hier nicht weiter erläutert.


    6.4       Google Hacking Honeypots / Verbreitung von Falsch-
              informationen
    Webseiten lassen sich so präparieren, dass sie, sobald sie von einer Suchmaschine indi-
    ziert wurden, unter Verwendung von typischen Google-Hacking-Suchmustern gefun-
    den werden. Dies ist im Wesentlichen der Ansatz des so genannten „Google Hacking
    Honeypots“ [ghh]. Seiten, die exakt den Inhalt haben, der einem bestimmten Such-
    muster entspricht, tauchen bei einer Suche an oberster Stelle der Ergebnisliste auf. Auf
    diese Weise kann ein Angreifer also auf eine Seite gelockt werden, die allerdings keine
    sensiblen Informationen enthält. Falls möglich, können an dieser Stelle Informationen


                                                           68
1    / / getAttacker () returns attacker profile
2    function getAttacker () {
3        $ A t t a c k e r = array ( ) ;
4        $ A t t a c k e r [ ’ I P ’ ] = i s s e t ( $_SERVER [ ’REMOTE_ADDR ’ ] ) ? s a n i t i z e (
                  $_SERVER [ ’REMOTE_ADDR ’ ] . g e t P r o x y ( ) ) : n u l l ;
5        $ A t t a c k e r [ ’ r e q u e s t ’ ] = i s s e t ( $_SERVER [ ’REQUEST_URI ’ ] ) ?
                  s a n i t i z e ( $_SERVER [ ’REQUEST_URI ’ ] ) : n u l l ;
6        $ A t t a c k e r [ ’ r e f e r e r ’ ] = i s s e t ( $_SERVER [ ’HTTP_REFERER ’ ] ) ?
                  s a n i t i z e ( $_SERVER [ ’HTTP_REFERER ’ ] ) : n u l l ;
7        $ A t t a c k e r [ ’ a g e n t ’ ] = i s s e t ( $_SERVER [ ’HTTP_USER_AGENT ’ ] ) ?
                  s a n i t i z e ( $_SERVER [ ’HTTP_USER_AGENT ’ ] ) : n u l l ;
8        $ A t t a c k e r [ ’ a c c e p t ’ ] = i s s e t ( $_SERVER [ ’HTTP_ACCEPT ’ ] ) ?
                  s a n i t i z e ( $_SERVER [ ’HTTP_ACCEPT ’ ] ) : n u l l ;
9        $ A t t a c k e r [ ’ c h a r s e t ’ ] = i s s e t ( $_SERVER [ ’HTTP_ACCEPT_CHARSET ’ ] )
                    ? s a n i t i z e ( $_SERVER [ ’HTTP_ACCEPT_CHARSET ’ ] ) : n u l l ;
10       $ A t t a c k e r [ ’ e n c o d i n g ’ ] = i s s e t ( $_SERVER [ ’HTTP_ACCEPT_ENCODING ’
                  ] ) ? s a n i t i z e ( $_SERVER [ ’HTTP_ACCEPT_ENCODING ’ ] ) : n u l l ;
11       $ A t t a c k e r [ ’ l a n g u a g e ’ ] = i s s e t ( $_SERVER [ ’HTTP_ACCEPT_LANGUAGE ’
                  ] ) ? s a n i t i z e ( $_SERVER [ ’HTTP_ACCEPT_LANGUAGE ’ ] ) : n u l l ;
12       $ A t t a c k e r [ ’ c o n n e c t i o n ’ ] = i s s e t ( $_SERVER [ ’HTTP_CONNECTION ’ ] )
                  ? s a n i t i z e ( $_SERVER [ ’HTTP_CONNECTION ’ ] ) : n u l l ;
13       $ A t t a c k e r [ ’ k e e p _ a l i v e ’ ] = i s s e t ( $_SERVER [ ’HTTP_KEEP_ALIVE ’ ] )
                  ? s a n i t i z e ( $_SERVER [ ’HTTP_KEEP_ALIVE ’ ] ) : n u l l ;
14       return $Attacker ;
15   }


     Abbildung 6.2: Honeypot-Funktion zum Sammeln von Informationen über Angreifer


     über den potentiellen Angreifer gesammelt werden, wie etwa die IP, der verwendete
     Browser, der Referrer und – im Einzelfall möglicherweise vorhanden – weitere Infor-
     mationen, welche durch den HTTP-Header des Angreifers in Erfahrung zu bringen
     sind. Eine mögliche Maßnahme wäre daraufhin das Blockieren des Zugriffs auf die
     gesamte Website für die IP des potentiellen Angreifers.
         Die präparierten Honeypot-Seiten sollten hierbei nur für den Bot der Suchmaschi-
     ne erkennbar sein, aber nicht für „normale“ Besucher der Website. Somit sollten Links
     auf die Honeypot-Seiten unsichtbar innerhalb von sichtbaren Webseiten gesetzt wer-
     den. Das versteckte Sammeln von Daten über Besucher ist beispielsweise mit Hilfe
     Server-seitiger Scriptsprachen durchführbar. So können PHP-Scripte beispielsweise in
     txt-Dateien versteckt werden, wobei nach Aufruf der Datei durch den Angreifer nur die
     Ausgabe, die das PHP-Script produziert, sichtbar ist. In Zeile 4 des Listings 6.2 soll die
     IP-Adresse des Angreifers ermittelt werden. Zur Identifizierung des Angreifers ist die-
     se allerdings nur dann hilfreich, wenn der Angreifer keinen Anonymisierungsdienst
     wie JAP [jap] verwendet.
         Ein Nebeneffekt dieser Methode ist die Verbreitung falscher Informationen – also
     derjenigen Informationen, die einen Google-Hacker anlocken sollen, aber nicht wirk-
     lich wertvoll für ihn sind. Auch ohne eine versteckte Honeypot-Funktion bieten Fehl-
     informationen den Nutzen, dass Angreifer sie bei geschickter Präparierung kaum von
     wahrheitsgemäßen Informationen unterscheiden können, so dass in der Gesamtmen-
     ge von Informationen diejenigen, die für den Angreifer interessant sein könnten, nicht
     mehr als solche erkannt werden können. Ein Beispiel hierfür wäre die Angabe von


                                                    69
falschen Server-Versions-Informationen, oder die Ablage von PHP-Fehlermeldungen,
die auf nichtexistente Pfadstrukturen des Servers hinweisen. Solche Fehlermeldungen
müssen das Erscheinungsbild einer Webseite nicht stören, da Verweise auf sie optisch
unauffällig bis unsichtbar abgelegt werden können.


6.5     Blockieren des Zugriffs für offensichtliche
        Google-Hacker
Falls der Google-Hacker direkt auf der Suchergebnis-Seite von Google den Link auf
sein Ziel anklickt, kann man ihn und seine Absichten ggf. am „Referrer“ erkennen. Im
Allgemeinen wird durch die gängigen Internet-Browser beim Aufruf einer Seite, deren
URL auf einer anderen Seite als Link existiert, im HTTP-Header im Feld namens „Re-
ferer“ die Adresse der Seite, auf welche der Link ausgewählt wird, mit gesendet. Diese
Eigenschaft kann in manchen Browsern allerdings abgeschaltet werden, und kann nicht
ausgenutzt werden, wenn nicht direkt ein Link einer Ergebnisliste einer Suchmaschine
ausgewählt bzw. angeklickt wird. Eine Referrer-Angabe kann auch ohne großen Auf-
wand gefälscht bzw. manipuliert werden. Daher ist dieser Ansatz im Allgemeinen nicht
besonders erfolgsversprechend.
 Beispiel 26 Der Referrer eines Users, der auf eine Webseite gelangt, lautet:
 http://www.google.com/search?q=inurl:password
 +site\%3Atarget.com
 Hier hat jemand über Google nach dem folgenden Suchmuster gesucht:
 inurl:password site:target.com
Wenn die Suche aus Beispiel 26 vorher vom Administrator der gefährdeten Website
in Erwägung gezogen wurde, kann ein potentieller Google Hacker an seinem Referrer
erkannt werden und auf eine Honeypot-Seite weitergeleitet werden.


6.6     Betrachtung des Inhalts von Websites unter Ver-
        wendung eines Webcrawlers
In [spi07] wird als wichtige Maßnahme zur Prävention von Informationslecks durch
Suchmaschinen empfohlen, einen eigenen Webcrawler zu verwenden, der alle Web-
Auftritte eines IT-Systems durchsucht und alle findbaren Informationen speichert. Die-
se sollten dann in ein leicht lesbares Format gebracht und komplett in Augenschein
genommen werden, um evtl. unerwartete Auffälligkeiten zu finden. Dies ist vor allem
deswegen sinnvoll, da eine Datenbank aus Google-Hacking-Suchmustern niemals voll-
ständig sein kann. Wenn man sich allein auf Google Scanning beschränken würde, um
einen Web-Auftritt zu durchsuchen, könnte man sich aufgrund dieser Unvollständig-
keit in falscher Sicherheit wiegen. Selbst bei Verwendung des „Schusses ins Blaue“
– also der Suche nach einem Leerzeichen – wäre es möglich, dass ein Fund nur des-
wegen nicht gemacht wird, da der Webcrawler der Suchmaschine eine verwundbare
Stelle evtl. erst später finden wird – oder, dass der Fund „zu tief“ in der Ergebnisliste
liegt, d.h., über die Grenze der Anzahl lieferbarer Suchergebnisse hinausgeht (siehe
Abschnitt 3.4.5). Eine ähnliche Maßnahme kann auch mit Hilfe von Suchmaschinen
durchgeführt werden – also die bewusste Suche nach einer maximal möglichen Anzahl
von (teilweise Falsch-)Treffern (siehe ebenfalls Abschnitt 3.4.5).


                                          70
6.7    Zusammenfassung
In diesem Kapitel wurden Ansätze und Methoden der präventiven Abwehr gegen Goo-
gle Hacking beschrieben. Eine Möglichkeit, im präventiven Google Hacking einen
Vorsprung gegenüber potentiellen Angreifer zu haben, stellt hierbei eine unterneh-
menseigene Suchmaschine dar. Durch eine nicht-öffentliche und in ihrem Inhalt oft
aktualisierte Suchmaschine könnte also theoretisch eine Schutzvorrichtung eingerich-
tet werden, mittels derer einer Verwundbarkeit durch die öffentlichen Suchmaschinen
vorgebeugt werden könnte.
    Eine – im allgemeinen Sinne – sichere Konfiguration von IT-Systemen ist jedoch
auch im Falle von Google Hacking die beste Methode, um Anfälligkeit gegenüber An-
greifern zu unterbinden. Einrichtungen wie Google-Hacking-Honeypots können dazu
dienen, Informationen über einen Angreifer zu sammeln, wobei diese nur dann einen
Wert haben, wenn dieser keinen Anonymisierungsdienst verwendet. Die Verbreitung
von Falschinformationen könnte im Vergleich eine wirkungsvollere Abwehrmaßnah-
me sein. Das Blockieren des Zugriffs für offensichtliche Google-Hacker hingegen ist
nur dann von Nutzen, wenn dieser nicht besonders geschickt vorgeht.
    Als letzte Maßnahme, die wie die sichere Konfiguration von IT-Systemen nicht nur
hinsichtlich Google Hacking empfehlenswert ist, wurde das „manuelle“ Betrachten der
Inhalte von Web-Inhalten angesprochen.

   Im folgenden und letzten Kapitel werden nun diese und die Ergebnisse der Vergan-
genen Kapitel zusammengefasst und bewertet.




                                        71
Kapitel 7

Zusammenfassung

Zu Beginn der Diplomarbeit wurde zunächst das Google Hacking in seinen Grundla-
gen beschrieben und eine Übersicht über die verwendeten Techniken gegeben. Mittels
beispielhafter Suchmuster wurde dargestellt, auf welche Art und Weise mit Hilfe von
Suchmaschinen Daten gefunden werden können, die eigentlich nicht für die Öffentlich-
keit bestimmt sind. Dabei beschränkt sich diese Suche nicht nur auf die Suchmaschine,
die namensgebend für diese Art des Hackings war, sondern kann ebenso gut in an-
deren Suchmaschinen wie Live Search und Yahoo Search angewandt werden. Diese
beiden Suchmaschinen haben neben Google eine besondere Bedeutung für das Google
Hacking, da sie aufgrund ihrer APIs für automatisierte Google Scanning-Programme
nutzbar sind.
     Der systematische Ablauf von Google Scanning wurde im darauf folgenden Ka-
pitel beschrieben. Neben der Beschreibung von Vorbereitung und Durchführung eines
Google-Scans wurde gezeigt, auf welche Weise Ergebnisse dieses Vorgangs interpre-
tiert werden können, und welche Maßnahmen im Einzelfall nach einem kritischen Fund
getroffen werden sollten.
     Im folgenden Kapitel wurde die Implementierung eines automatisierten Google-
Hacking-Tools beschrieben. Mit Hilfe des im Rahmen der Diplomarbeit entwickelten
„GooScanner“ können beliebige Domains bezüglich beliebiger Suchmuster überwacht
werden, wobei hierfür eine Untersuchung in regelmäßigen Abständen durchgeführt
wird. Neue Funde werden durch das Programm gemeldet. Zur Bewertung und Kate-
gorisierung dieser Funde stellt es eine Web-Schnittstelle zur Verfügung. Die Google-
SOAP-API bzw. „Google Webservices“ erwies sich für die Implementierung als nütz-
lich, und auch unverzichtbar – ebenso wie die APIs der Suchmaschinen Live Search
und Yahoo Search. Dies trifft allerdings nicht auf „Google Alerts“ zu.
     Im Rahmen der Verwendung von GooScanner für einige Beispielhafte Scans der
Domains einiger IT-Firmen und der Einrichtung eines regelmäßigen Scan-“Jobs“ für
Domains der Firma T-Mobile (siehe Anhang B5 in der nicht-öffentlichen Version des
Dokuments) zeigte sich die Eignung von Google Hacking für die Aufdeckung unbeab-
sichtigter Veröffentlichung sensibler Daten, und somit für den Schutz von IT-Systemen.
     Nach der Vorstellung von GooScanner wurde im Rahmen eines Vergleichs mit her-
kömmlichen Scanning-Methoden erörtert, welchen Mehrwert Google Hacking bzw.
-Scanning gegenüber anderen, üblichen Sicherungsmethoden hat. Hierzu wurden meh-
rere Ausgangslagen von IT-Systemen hinsichtlich ihrer Sicherheit mit- oder ohne Goo-
gle-Scanning betrachtet. Es zeigte sich, dass der Mehrwert von Google Hacking gegen-
über Vulnerability Scanning und Penetration Testing darin besteht, dass durch Google

                                         72
Hacking spezielle Funde gemacht werden können, die durch herkömmliches Vulnera-
bility Scanning üblicherweise nicht gemacht werden; der Mehrwert gegenüber Pene-
tration Testing besteht in der Möglichkeit der Automatisierung von Google Hacking.
     Zu Abwehr von Angriffen durch Google Hacking wurden abschließend einige Maß-
nahmen vorgestellt. Hierzu gehörte auch die Idee, statt einer öffentlichen Suchmaschi-
ne eine private zu verwenden. Hierdurch könnten sensible Informationen gefunden und
geschützt werden, bevor öffentliche Suchmaschinen sie kopieren können.


7.1     Fazit
Bei der Entstehung von Google Hacking gab es noch nicht das Ziel des Angriffs auf
bestimmte IT-Systeme. Es entwickelte sich eher aus allgemeiner Neugier und war oh-
ne Fokussierung auf bestimmte Domains auch weitaus ergiebiger – was es auch heute
noch ist. Wie sich im Rahmen der in dieser Diplomarbeit durchgeführten Scans gezeigt
hat, sind bei der Untersuchung einzelner IT-Systeme auf Verwundbarkeiten durch Goo-
gle Hacking nicht unbedingt sehr viele Ergebnisse zu erwarten. Dennoch können die
wenigen Funde, die gemacht wurden, hilfreich für die Administratoren der jeweiligen
Systeme sein, um diese sicherer zu konfigurieren – bzw., um ihre Kunden darauf auf-
merksam zu machen, weniger nachlässig mit ihren Zugangsdaten umzugehen.
    Dabei ist das Google Hacking bzw. -Scanning durchaus als sinnvolle Ergänzung
zu Vulnerability Scanning zu betrachten, wie der Vergleich in Kapitel 5 gezeigt hat.
Ein Mehrwert gegenüber herkömmlichen Scanning-Methoden ist vorhanden, wobei
sich dieser nicht verallgemeinernd in Zahlen ausdrücken lässt. Für ein Unternehmen
hängt die Entscheidung über den Einsatz von Google Hacking in erster Linie von der
notwendigen finanziellen Investition ab. Diese ist allerdings relativ niedrig – ein Pro-
gramm wie GooScanner hat niedrige Ansprüche an Rechenleistung, Arbeitsspeicher
und nichtflüchtigem Speicherplatz. Die Zeit zum Bewerten neuer Treffer liegt auch bei
der Untersuchung umfangreicher Domains nach ein paar Tagen im Bereich weniger
Minuten. Insofern ist der Einsatz von Google Hacking für Unternehmen empfehlens-
wert.




                                          73
     Anhang A

     Quellcode aus GooScanner

     A.1        Das Scheduling-Modul von GooScanner

 1   <? php
 2   / ∗ g o o s c a n n e r _ s c h e d u l e r . php : S c h a u t nach , w e l c h e J o b s
            e x i s t i e r e n ; w e l c h e davon a u s g e f ü h r t werden können ; w i e v i e l e
              A n f r a g e n p r o S u c h m a s c h i n e am Tag noch g e t a n werden d ü r f e n ;
              und l e g t dann l o s m i t den h e u t e f ä l l i g e n S c a n s . ∗ /
 3

 4                                           −d
     $ c u r r e n t D a t e = d a t e ( "Y−m " ) ; $ c u r r e n t T i m e = d a t e ( "G: i : s " ) ;
 5   i n c l u d e _ o n c e " common / o p e n _ d a t a b a s e . php " ;
 6   i n c l u d e _ o n c e " common / g e n e r a l . php " ;
 7   set_time_limit (60000) ;
 8

 9   $ s q l = "SELECT ∗ FROM j o b WHERE j o b A c t i v e =TRUE" ;
10   $ j o b s _ r s = my_query ( $ s q l ) ;
11   $number_of_all_active_jobs = mysql_affected_rows ( ) ;
12   echo " I n s g e s a m t b e f i n d e n s i c h $ n u m b e r _ o f _ a l l _ a c t i v e _ j o b s a k t i v e
                Jobs i n der Datenbank . " ;
13

14   / / Gehe a l l e a k t i v e n J o b s d u r c h und s c h a u p r o J o b nach , ob e s
              s c h o n e i n e n a n g e f a n g e n e n Scan d a f ü r g i b t , d e r noch n i c h t
              beendet i s t .
15   w h i l e ( $ j o b _ d a t a s e t = m y s q l _ f e t c h _ a r r a y ( $ j o b s _ r s , MYSQL_ASSOC) )
              {
16

17      / / I n f o r m a t i o n e n über e i n e n Job :
18      $jobKey = $ j o b _ d a t a s e t [ ’ jobKey ’ ] ;
19      $jobSearchMethod = $ j o b _ d a t a s e t [ ’ jobSearchMethod ’ ] ;
20      $jobCompanyName = $ j o b _ d a t a s e t [ ’ jobCompanyName ’ ] ;
21      $jobStartDate = $job_dataset [ ’ jobStartDate ’ ];
22      $jobStartTime = $job_dataset [ ’ jobStartTime ’ ] ;
23      $jobInterval = $job_dataset [ ’ jobInterval ’ ];
24      $jobQueriesPerConduct = $job_dataset [ ’ jobQueriesPerConduct ’ ] ;
25      $jobDescription = $job_dataset [ ’ jobDescription ’ ];
26      $jobLastDate = $job_dataset [ ’ jobLastDate ’ ] ;
27      $jobLastTime = $ j o b _ d a t a s e t [ ’ jobLastTime ’ ] ;
28      $jobForceNewStart = $job_dataset [ ’ jobForceNewStart ’ ] ;


                                                            74
29

30   / / Zu d i e s e m J o b e x i s t i e r e n d e Scan−Vorgänge
31   $ s q l = "SELECT ∗ FROM j o b
32          INNER JOIN j o b _ h a s _ s c a n
33          ON j o b . jobKey = j o b _ h a s _ s c a n . jobKey
34          INNER JOIN s c a n
35          ON j o b _ h a s _ s c a n . scanKey = s c a n . scanKey
36          WHERE j o b . jobKey = ’ $jobKey ’ " ;
37   $ s c a n s _ r s = my_query ( $ s q l ) ;
38   $ n u m b e r _ o f _ e x i s t i n g _ s c a n s _ f o r _ t h i s _ j o b = mysql_affected_rows
              () ;
39

40   $ d i f f e r e n c e _ o f _ d a t e s = d a t e D i f f ( "−" , $ c u r r e n t D a t e , $ j o b L a s t D a t e
               );
41

42   i f ( ( $ d i f f e r e n c e _ o f _ d a t e s >= $ j o b I n t e r v a l ) OR (
              $jobForceNewStart ) ) {
43       $ n e w _ s c a n _ s h o u l d _ b e _ b e g u n = TRUE;
44       i f ( $jobForceNewStart ) {
45           echo "ACHTUNG: A u ß e r p l a n m ä ß i g e r S t a r t ! \ n " ;
46           $ j o b F o r c e _ s q l = "UPDATE j o b SET j o b F o r c e N e w S t a r t =FALSE
                     WHERE jobKey = $jobKey " ;
47           $ j o b F o r c e _ r s = my_query ( $ j o b F o r c e _ s q l ) ;
48       } / / i f ( $jobForceNewStart )
49       echo " Neuen Scan a n f a n g e n − v o r a u s g e s e t z t , d i e s c h o n
                  angefangenen Scans s i n d a l l e beendet ? \ n " ;
50       $ s q l = "UPDATE j o b SET j o b L a s t D a t e = ’ $ c u r r e n t D a t e ’ , j o b L a s t T i m e
                  = ’ $ c u r r e n t T i m e ’ WHERE jobKey = ’ $jobKey ’ " ;
51       $ r s = my_query ( $ s q l ) ;
52   } / / i f ( ( $ d i f f e r e n c e _ o f _ d a t e s >= $ j o b I n t e r v a l ) OR (
              $jobForceNewStart ) )
53   else {
54       echo " Kein n e u e r Scan f ä l l i g . S i n d a n g e f a n g e n e und noch
                  n i c h t v o l l e n d e t e Scans vorhanden ? \ n " ;
55       $new_scan_should_be_begun = 0;
56   } // else
57

58   / / Nun Ü b e r p r ü f u n g , ob e s denn noch e i n e n n i c h t −b e e n d e t e n
            s c a n zu d i e s e m J o b g i b t .
59   i f ( $ n um b e r_ o f_ e x is t i ng _ sc a n s_ f or _ t hi s _ jo b > 0) {
60      while ( $ s c a n _ d a t a s e t = mysql_fetch_array ( $scans_rs ,
                MYSQL_ASSOC) ) {
61         / / I s t d e r Scan a k t i v ?
62         i f ( $ s c a n _ d a t a s e t [ ’ s c a n A c t i v e ’ ] == 1 ) {
63             echo " Es g i b t e i n e n noch−n i c h t −b e e n d e t e n Scan zu dem
                        J o b . D i e s e r w i r d nun w e i t e r g e f ü h r t . \ n " ;
64             $scanKey = $ s c a n _ d a t a s e t [ ’ scanKey ’ ] ;
65             d o _ s c a n ( $jobKey , $scanKey ) ; / / D i e s f ü h r t zum
                         e i g e n t l i c h e n Scan−Modul .
66             $new_scan_should_be_begun = 0;
67         } / / i f ( $ s c a n _ d a t a s e t [ ’ s c a n A c t i v e ’ ] == 1 )
68         else {
69             echo " Scan " . $ s c a n _ d a t a s e t [ ’ scanKey ’ ] . " i s t n i c h t
                        mehr a k t i v . \ n " ;


                                                           75
70             } // else
71             / / Nochmal ü b e r p r ü f e n , ob e s j e t z t noch e i n e n n i c h t
                        b e e n d e t e n Scan zu d i e s e m J o b g i b t .
72         } / / while ( $scan_dataset = mysql_fetch_array ( $scan_rs ,
                   MYSQL_ASSOC) )
73         / / Nun ü b e r p r ü f e n , ob h e u t e noch e i n n e u e r Scan zu d i e s e m
                    J o b a u s g e f ü h r t werden s o l l .
74         i f ( $ n e w _ s c a n _ s h o u l d _ b e _ b e g u n == 1 ) {
75             d o _ s c a n ( $jobKey , " " ) ;
76         } / / i f ( $ n e w _ s c a n _ s h o u l d _ b e _ b e g u n == 1 )
77     } / / i f ( $n u m be r _ of _ ex i s ti n g_ s c an s _ fo r _t h i s_ j ob > 0)
78     else {
79         echo " Es gab b i s h e r noch k e i n e n Scan zu d i e s e m J o b . \ n " ;
80         i f ( $ n e w _ s c a n _ s h o u l d _ b e _ b e g u n == 1 ) {
81             d o _ s c a n ( $jobKey , " " ) ;
82         } / / i f ( $ n e w _ s c a n _ s h o u l d _ b e _ b e g u n == 1 )
83     } // else
84

85   } / / while ( $job_dataset = mysql_fetch_array ( $jobs_rs ,
           MYSQL_ASSOC) )
86   ?>




                                                 76
     A.2        Das Google-Scan-Modul von GooScanner
1    <? php
2    / / Zur B e n u t z u n g d e r SOAP−API von Google
3    i n c l u d e _ o n c e ( " n u s o a p / l i b / n u s o a p . php " ) ;
4    $ n u s o a p c l i e n t = new n u s o a p c l i e n t ( " h t t p : / / a p i . g o o g l e . com / s e a r c h /
               beta2 " ) ;
5

6    / / F ü h r e i n S c h l e i f e a l l e A n f r a g e d u r c h , d i e s i c h a u s den
            K o m b i n a t i o n e n d e r g e g e b e n e n Domänen und d e r S u c h m u s t e r
            e r g e b e n . K o m p l e x i t ä t : A n z a h l Domänen ∗ A n z a h l S u c h m u s t e r .
7

8    $ n u m _ o f _ t o d a y _ q u e r i e s = t o d a y _ r e m a i n i n g _ q u e r i e s ( " google_SOAP " ) ;
9    $ a l l _ q u e r i e s _ f o r _ t h i s _ t e s t = bcmul ( c o u n t ( $ u r l s ) , c o u n t (
              $searchstrings ) ) ;
10   $const_queries_for_this_test = $all_queries_for_this_test ;
11   echo " \ n F u e r d i e s e n T e s t muessen w i r e i n e G e s a m t z a h l an
              A n f r a g e n von $ a l l _ q u e r i e s _ f o r _ t h i s _ t e s t e r r e i c h e n . \ n " ;
12   $queries_that_we_did_this_time = 0;
13

14   f o r ( $ u r l I n d e x = 0 ; $ u r l I n d e x < c o u n t ( $ u r l s ) ; $ u r l I n d e x ++) {
15       for ( $ s e a r c h s t r i n g I n d e x =0; $ s e a r c h s t r i n g I n d e x <count (
                $ s e a r c h s t r i n g s ) ; $ s e a r c h s t r i n g I n d e x ++) {
16

17          / / echo " $num_of_today_queries g r ö ß e r a l s 0 ? " ;
18          i f ( ( $ n u m _ o f _ t o d a y _ q u e r i e s > 0 ) AND ( $ q u e r i e s _ f o r _ t h i s _ t e s t
                     > $ q u e r i e s _ t h a t _ w e _ d i d _ t h i s _ t i m e ) AND (
                    $ a l l _ q u e r i e s _ f o r _ t h i s _ t e s t > 0) ) {
19

20              $currentUrl = $urls [ $urlIndex ] ;
21              $currentSearchstring = $searchstrings [ $searchstringIndex
                          ];
22              $ p a r a m e t e r s = array (
23                  ’ key ’ => $ g o o g l e _ a p i _ k e y , / / Google−L i z e n z s c h l ü s s e l
24                  ’q ’        => " s i t e : $ c u r r e n t U r l $ c u r r e n t S e a r c h s t r i n g " , / /
                              Die A n f r a g e an Google
25                  ’ s t a r t ’ => 0 , / / B e g i n n e b e i E r g e b n i s 0
26                  ’ m a x R e s u l t s ’ => 1 0 , / / L i e f e r e 10 E r g e b n i s s e
27                  ’ f i l t e r ’ => f a l s e , / / Ä h n l i c h e E r g e b n i s s e e n t f e r n e n
28                  ’ r e s t r i c t ’ => ’ ’ , / / K e i n e E i n s c h r ä n k u n g a u f " Thema "
29                  ’ s a f e S e a r c h ’ => f a l s e , / / Kein E n t f e r n e n von
                              Erwachsenen −I n h a l t e n
30                  ’ l r ’ => ’ ’ , / / K e i n e E i n s c h r ä n k u n g a u f S p r a c h e
31                  ’ i e ’ => ’ ’ , / / K o d i e r u n g d e r E i n g a b e
32                  ’ oe ’ => ’ ’ / / K o d i e r u n g d e r Ausgabe
33                 );
34

35             for ( $ e x c l U r l I n d e x =0; $ e x c l U r l I n d e x <count ( $ e x c l u d e d _ u r l s )
                       ; $ e x c l U r l I n d e x ++) {
36                 $parameters [ ’q ’ ] .= " −s i t e : " . $excluded_urls [
                           $exclUrlIndex ] ;
37             } / / f o r ( $exclUrlIndex =0; $exclUrlIndex <count (
                       $ e x c l u d e d _ u r l s ) ; $ e x c l U r l I n d e x ++)
38




                                                             77
39   / / D i e s e Suche s o l l t e n w i r n u r g e n a u dann d u r c h f ü h r e n ,
              wenn d i e s im Rahmen d e s g e s a m t e n S c a n s noch n i c h t
              g e s c h e h e n i s t . F a l l s w i r den T e s t n a c h e i n e r P a u s e
              w i e d e r aufnehmen , a l s o s c a n A c t i v e a u f TRUE s t e h t ,
              müssen w i r d a s ü b e r p r ü f e n .
40   $ s q l = s p r i n t f ( "SELECT ∗ FROM r e s u l t WHERE ( u r l =%s ) AND (
              s e a r c h s t r i n g =%s ) AND scanKey=%s " ,
41          quote_smart ( $currentUrl ) ,
42          quote_smart ( $currentSearchstring ) ,
43          q u o t e _ s m a r t ( $scanKey ) ) ;
44   $ r s = my_query ( $ s q l ) ;
45   $ d o _ t h i s _ q u e r y = ( m y s q l _ a f f e c t e d _ r o w s ( ) == 0 ) ;
46

47   i f ( $do_this_query ) {
48       $ g o o g l e _ r e s u l t = $ n u s o a p c l i e n t −> c a l l ( " d o G o o g l e S e a r c h " ,
                  $parameters , ’ urn : GoogleSearch ’ , ’ urn : GoogleSearch ’
                  );
49       $ n u m _ o f _ t o d a y _ q u e r i e s −−;
50       $ q u e r i e s _ t h a t _ w e _ d i d _ t h i s _ t i m e ++;
51   } / / i f ( m y s q l _ a f f e c t e d _ r o w s ( ) == 0 )
52

53   $ a l l _ q u e r i e s _ f o r _ t h i s _ t e s t −−;
54

55   if ( $google_result [ ’ faultstring ’ ]) {
56       echo " \ n $ s e a r c h M e t h o d F e h l e r ! " . $ g o o g l e _ r e s u l t [ ’
                   faultstring ’ ];
57   }
58   e l s e i f ( $do_this_query ) {
59       / / Das E r g e b n i s s o l l nun i n d e r T a b e l l e " r e s u l t "
                   g e s p e i c h e r t werden . Die e i n z e l n e n H i t s wiederum
                   s o l l e n i n d e r T a b e l l e " h i t " g e s p e i c h e r t werden .
60                                                  −d
         $ r e s u l t D a t e = d a t e ( "Y−m " ) ;
61       $ r e s u l t T i m e = d a t e ( "G: i : s " ) ;
62       $searchstring = $currentSearchstring ;
63       $url = $currentUrl ;
64       $resultHits = $google_result [ ’
                   estimatedTotalResultsCount ’ ];
65       $ s q l = s p r i n t f ( " INSERT INTO r e s u l t ( r e s u l t D a t e ,
                  r e s u l t T i m e , s e a r c h s t r i n g , u r l , r e s u l t H i t s , scanKey )
                    VALUES (%s , %s , %s , %s , %s , %s ) " ,
66           quote_smart ( $resultDate ) ,
67           quote_smart ( $resultTime ) ,
68           quote_smart ( $searchstring ) ,
69           quote_smart ( $url ) ,
70           quote_smart ( $ r e s u l t H i t s ) ,
71           q u o t e _ s m a r t ( $scanKey )
72           );
73       $ r s = mysql_query ( $ s q l ) ;
74       i f (! $rs ) {
75           die ( mysql_error ( ) ) ;
76       } / / i f (! $rs )
77       $resultKey = mysql_insert_id ( ) ;
78

79       i f ( $ g o o g l e _ r e s u l t [ ’ estimatedTotalResultsCount ’ ] > 0) {


                                                    78
 80   echo " \ nDie Suche n a c h " . $ g o o g l e _ r e s u l t [ ’
             searchQuery ’ ] . " hat " . $google_result [ ’
             estimatedTotalResultsCount ’ ] . " T r e f f e r ergeben .
             ";
 81   i f ( is_array ( $google_result [ ’ resultElements ’ ]) ) {
 82      foreach ( $ g o o g l e _ r e s u l t [ ’ r e s u l t E l e m e n t s ’ ] as
                $current_hit ) {
 83

 84         $current_hit [ ’ snippet ’ ] = str_replace ( " ’" , "" ,
                 $current_hit [ ’ snippet ’ ]) ;
 85

 86         / / Z u n ä c h s t mal s c h a u e n wir , ob e s den H i t s c h o n
                     mal i n d e r D a t e n b a n k g e g e b e n h a t .
 87         $ h i t U r l = $ c u r r e n t _ h i t [ ’URL ’ ] ;
 88         $hitSnippet = $current_hit [ ’ snippet ’ ]; $hitTitle
                     = $current_hit [ ’ t i t l e ’ ];
 89

 90         $ s q l = "SELECT ∗ FROM h i t WHERE ( h i t U r l = ’ $ h i t U r l ’
                     AND h i t S n i p p e t = ’ $ h i t S n i p p e t ’ AND h i t T i t l e = ’
                    h i t T i t l e ’) " ;
 91         $ r s = my_query ( $ s q l ) ;
 92

 93        i f ( m y s q l _ a f f e c t e d _ r o w s ( ) == 0 ) {
 94            $ n e w _ h i t _ f o u n d = TRUE;
 95            echo "NEU ! ! " ;
 96            $hitEvaluated = 0;
 97            $hitSuccess = 0;
 98            $categoryKey = 0;
 99        } / / i f ( m y s q l _ a f f e c t e d _ r o w s ( ) == 0 )
100        else {
101            echo " Schon mal g e s e h e n : " ;
102            / / a b e r wie wurde d a s d a m a l s b e w e r t e t ?
103            $ r s _ d a t a s e t = m y s q l _ f e t c h _ a r r a y ( $rs ,
                       MYSQL_ASSOC) ;
104            $old_hitKey = $ r s _ d a t a s e t [ ’ hitKey ’ ] ;
105            $ h o w _ r a t e d _ s q l = "SELECT h i t S u c c e s s ,
                        h i t E v a l u a t e d , c a t e g o r y K e y FROM h i t WHERE
                        hitKey=$old_hitKey " ;
106            $ h o w _ r a t e d _ r s = my_query ( $ h o w _ r a t e d _ s q l ) ;
107            $how_rated_dataset = mysql_fetch_array (
                        $ h o w _ r a t e d _ r s , MYSQL_ASSOC) ;
108            $hitSuccess = $how_rated_dataset [ ’ hitSuccess ’ ] ;
109            $hitEvaluated = $how_rated_dataset [ ’
                        hitEvaluated ’ ] ; ;
110            $categoryKey = $how_rated_dataset [ ’ categoryKey ’
                        ];
111        } // else
112

113         $hitTitle = $current_hit [ ’ t i t l e ’ ];
114         $hitCachedSize = $ c u r r e n t _ h i t [ ’ cachedSize ’ ] ;
115

116         $ s q l = s p r i n t f ( " INSERT INTO h i t ( h i t S n i p p e t ,
                    hitUrl , h i t T i t l e , hitCachedSize , resultKey ,
                    h i t E v a l u a t e d , h i t S u c c e s s , c a t e g o r y K e y ) VALUES


                                         79
                                             (%s , %s , %s , %s , %s , ’ $ h i t E v a l u a t e d ’ , ’
                                           $hitSuccess ’ , ’ $categoryKey ’) " ,
117                                   quote_smart ( $hitSnippet ) ,
118                                   quote_smart ( $hitUrl ) ,
119                                   quote_smart ( $ h i t T i t l e ) ,
120                                   quote_smart ( $hitCachedSize ) ,
121                                   quote_smart ( $resultKey )
122                                   );
123                               $ r s = mysql_query ( $ s q l ) ;
124                               i f (! $rs ) {
125                                   die ( mysql_error ( ) ) ;
126                               } / / i f (! $rs )
127                           } / / foreach ( $ g o o g l e _ r e s u l t [ ’ r e s u l t E l e m e n t s ’] as $r
                                       )
128                       } / / if ( is_array ( $google_result [ ’ resultElements ’]) )
129                   } / / i f ( $google_result [ ’ estimatedTotalResultsCount ’] >
                               0)
130                   else {
131                       echo " − Kein H i t . " ;
132                   } // else
133               } / / e l s e i f ( $do_this_query )
134           } / / i f ( ( $ n u m _ o f _ t o d a y _ q u e r i e s > 0 ) AND (
                       $queries_for_this_test > $queries_that_we_did_this_time
                       ) AND ( $ a l l _ q u e r i e s _ f o r _ t h i s _ t e s t > 0 ) )
135       } / / f o r ( $ s e a r c h s t r i n g I n d e x =0; $ s e a r c h s t r i n g I n d e x <count (
                   $ s e a r c h s t r i n g s ) ; $ s e a r c h s t r i n g I n d e x ++)
136   } / / f o r ( $ u r l I n d e x = 0 ; $ u r l I n d e x < c o u n t ( $ u r l s ) ; $ u r l I n d e x ++)
137

138   i f ( $ n u m _ o f _ t o d a y _ q u e r i e s <= 0 ) {
139       echo " \nACHTUNG: H e u t e k e i n e A n f r a g e n mehr m ö g l i c h . " ;
140   } / / i f ( $ n u m _ o f _ t o d a y _ q u e r i e s <= 0 )
141

142   / / Haben w i r i n s g e s a m t f ü r d i e s e n T e s t a l l e A n f r a g e n
                d u r c h f ü h r e n können , d i e u r s p r ü n g l i c h g e p l a n t waren ( A n z a h l
                d e r URLS m u l t i p l i z i e r t m i t A n z a h l A n f r a g e n ) ?
143   i f ( $ a l l _ q u e r i e s _ f o r _ t h i s _ t e s t <= 0 ) {
144       $ s q l = s p r i n t f ( "UPDATE s c a n SET s c a n A c t i v e =FALSE WHERE
                    scanKey=%s " , q u o t e _ s m a r t ( $scanKey ) ) ;
145       $ r s = my_query ( $ s q l ) ;
146       echo " \ n F u e r d i e s e n T e s t wurden a l l e A n f r a g e n d u r c h g e f u e h r t .
                    Er w i r d nun a u f \ " n i c h t a k t i v \ " g e s e t z t . " ;
147   } / / i f ( $ a l l _ q u e r i e s _ f o r _ t h i s _ t e s t <= 0 )
148   else {
149       $ s q l 2 = s p r i n t f ( "SELECT ∗ FROM r e s u l t WHERE scanKey=%s " ,
                    q u o t e _ s m a r t ( $scanKey ) ) ;
150       $ r s 2 = my_query ( $ s q l 2 ) ;
151       $number_of_conducted_queries = mysql_affected_rows ( ) ;
152       $number_of_missing_queries = $ c o n s t _ q u e r i e s _ f o r _ t h i s _ t e s t −
                    $number_of_conducted_queries ;
153       echo " \ n F u e r d i e s e n T e s t b l e i b e n noch
                    $number_of_missing_queries Anfragen durchzufuehren . " ;
154   } // else
155

156   / / Wenn e s i n d i e s e m T e s t i r g e n d w o e i n e n n e u e n H i t gab , s t e h t


                                                          80
                nun $ n e w _ h i t _ f o u n d a u f TRUE . A l s o B e n a c h r i c h t i g u n g an
                Administrator mailen .
157   i f ( $ n e w _ h i t _ f o u n d == TRUE) {
158       $ l i n k _ t o _ r e s u l t p a g e = " h t t p : / / $ h o s t n a m e / goopen / v i e w _ r e s u l t .
                   php ? t o d o = v i e w _ s c a n&scanKey = $scanKey&o n l y H i t s =TRUE" ;
159       $ l i n k _ t o _ l o g f i l e = " h t t p : / / $ h o s t n a m e / goopen / l o g s /
                   j o b l o g _ $ j o b K e y . htm " ;
160       $ n a c h r i c h t = " H a l l o A d m i n i s t r a t o r , \ n \ nGooScanner h a t n e u e
                   E r g e b n i s s e g e f u n d e n zu dem J o b m i t d e r f o l g e n d e n
                   B e s c h r e i b u n g : \ n \ n $ j o b D e s c r i p t i o n \ n \ nAnschauen können S i e
                   s i c h d i e E r g e b n i s s e h i e r : \ n $ l i n k _ t o _ r e s u l t p a g e \ n \ nDas
                   L o g f i l e zu d i e s e m J o b : \ n $ l i n k _ t o _ l o g f i l e " ;
161       mail_to_admin ( $ n ac h r ic h t ) ;
162   } / / i f ( $ n e w _ h i t _ f o u n d == TRUE)
163   ?>




                                                             81
Anhang B

Fallbeispiele

B.1     Einleitung
Im Folgenden werden die IT-Systeme von vier großen Firmen aus der Mobilfunk-
Branche durch Google Hacking überprüft. Um ggf. keine Informationen zu veröffent-
lichen, die das Datenschutzrecht der ersten drei Firmen verletzen könnten, werden die
Firmen nur unter den Namen „Firma 1“ bis „Firma 3“ genannt, und alle anderen Vor-
kommen von Hinweisen auf die Namen entsprechend geändert.




                                         82
B.2     Firma 1
Vorbereitung
Zu dem Unternehmen sind drei Domains bekannt. Unter zweien davon sind (scheinbar
identische) Inhalte für Kunden zu finden; unter der dritten finden sich Informationen
über das Unternehmen. Zudem sind aufgrund dieser Domains zwei verschiedene IPs
für den Web-Inhalt bekannt.
    Auf den Kundenseiten fanden sich Login-Formulare mit den Bezeichnungen „ID-
Token1“, „IDToken2“ und „IDToken3“, in welche Kunden-ID, Passwort und Mobilfunk-
Rufnummer eingegeben werden sollten. Somit wurden als Suchmuster

   • inurl:IDToken1

   • inurl:IDToken2

   • inurl:IDToken3

mit in die Sammlung aufgenommen.

Konfiguration des Jobs

 Suchmaschine             Google           Live Search        Yahoo
 Domains                                                 3
 Anzahl Anfragen pro                                   1618
 Domain und Scan
 Verwendete Such-         Inhalt der GHDB und an Firma 1 angepasste; insgesamt 1616
 muster
 Startdatum                                          22.01.2007
 Intervall zwischen       7 Tage           1 Tag             1 Tag
 Neustarts

                Tabelle B.1: Konfiguration der Scan-Jobs für Firma 1



Analyse des ersten Scans

                                 Treffer Insgesamt        Davon auffällig
        Google                   14                       2
        Live Search              39                       12
        Yahoo Search             56                       0

                       Tabelle B.2: Der erste Scan für Firma 1

    Es ergaben sich insgesamt 12 Treffer mit niedriger Gefährlichkeit. 2 davon wurden
mit Hilfe von Google gefunden, alle 12 mit Hilfe von Live Search. Die Funde wa-
ren alle sehr ähnlich strukturiert, deswegen hier nur ein repräsentatives Beispiel eines
Treffers:

   • Suchmuster: intitle:index.of


                                          83
   • Belegung des Parameters „site“: firma1.de

   • Titel der gefundenen Seite: Index of /Firma1/html/

   • URL der gefundenen Seite: http://sms.firma1.de/Firma1/html/

   • Fragment der gefundenen Seite: „Parent Directory hilfe.htm 04-Jan-2007 15:24
     65K inbox_label.htm 04-Jan-2007 15:24 2K inbox_leer.html 04-Jan-2007 15:24
     1K logout.html 04-Jan-2007 15:24 1K nologin.html 04-Jan ...“

Der Inhalt des Suchmaschinen-Cache stimmte zum Zeitpunkt der Analyse des Scans
noch mit dem Inhalt der aktuellen Version der Firmen-Homepage überein.
    Es mussten keine Subdomains von der Suche ausgeschlossen werden, da sich ins-
gesamt nur wenige Falschtreffer ergaben. Fast alle Falschtreffer waren eine typische
Anomalie von Live Search: Aus nicht nachvollziehbaren Gründen wird zu manchen
Anfragen ein Fund mit der URL, dem Titel und dem Inhalt in Form eines einzigen
Buchstaben geliefert. Zwei weitere Falschtreffer waren zwar Seiten, die den zugehö-
rigen Suchmustern entsprachen, jedoch stellten sich als nicht weiter auffällige Login-
Portale heraus.
    Es ergaben sich durch die Treffer keine neuen Suchmuster.

Analyse des Verlaufs der weiteren Scans
Bei den weiteren Scans ergaben sich stets dieselben Funde, und es kamen kaum neue
Funde hinzu – was darauf hindeutet, dass innerhalb des Test-Zeitraums die IT-Systeme
von Firma 1 entweder nicht neu von den Webcrawlern der Suchmaschinen gescannt
wurden, oder dass die Firma den Inhalt der Webseiten im Zeitraum nicht geändert hat.


                            Google    Yahoo Search     Live Search
                  Scan 1      14          90               39
                  Scan 2       0           0                0
                  Scan 3       0           0                0
                  Scan 4       0           0                0
                  Scan 5       0           0                0
                  Scan 6       0           0                0
                  Scan 7       0           0                2

  Tabelle B.3: Verlauf der Anzahl neuer Treffer bei Scans der Domains von Firma 1


    Wie man in Tabelle B.4 erkennen kann, waren viele Falschtreffer auf eine unge-
naue Arbeitsweise von Yahoo Search zurückzuführen. Diese Ungenauigkeit wird auch
in den folgenden Teilen des Anhangs noch Ursache für viele Falschtreffer – oder un-
beabsichtigte Zufallstreffer – sein. Weitere Falschtreffer sind auf Suchmuster zurück-
zuführen, die bei der Suche nach sensiblen Daten weiterhin – trotz der Falschtreffer –
mit dabei sein sollten.
    Zu jedem Treffer enthielt der jeweilige Suchmaschinen-Cache ein komplettes Ab-
bild der jeweiligen Seite.
    Es wurde eine Subdomain gefunden:

   • sms.firma1.de


                                         84
 Suchmuster                   Suchmaschine   Anzahl Tref-   Ursache
                                             fer
 „Outlook Web Ac-             Google         7              Vorkommen der Phrase auf
 cess“                                                      harmlosen Seiten
 inurl:login.asp              Google         5              Dateiname von Login-
                                                            Portalen für Kunden
                              Live Search    2
 inurl:bin.welcome.sh         Live Search    9              Fehlfunktion    von     Live
 |                   in-                                    Search
 url:bin.welcome.bat |
 intitle:eHealth.5.0
 inurl:name                   Live Search    20             Seiten von Produktbeschrei-
                                                            bungen enthielten diesen Pa-
                                                            rameter in der URL
 (diverse)                    Yahoo Search   56             Ungenauigkeit bei Auswer-
                                                            tung der Suchparameter sei-
                                                            tens Yahoo Search

             Tabelle B.4: Falschtreffer bei Scans der Domains von Firma 1


   Die Suchmuster mit den meisten relevanten Treffern waren:
   1. intitle:index.of (14)
   2. intitle:index.of inbox (3)
   3. intitle:index.of WEB-INF (2)
   Insgesamt waren die Suchmaschinen mit den meisten relevanten Treffern:
   1. Live Search (14)
   2. Google (2)
    Insgesamt gab es 93 verschiedene Kombinationen aus URL, Fragment und Titel
der gefundenen Webseite, welche bewertet wurden.

Analyse der kritischen Treffer
Grund für das Erscheinen der Verzeichnisinhalte in der Öffentlichkeit war vermutlich
ein fehlerhaft konfigurierter Web-Server. Eine konkrete Gefahr, die von den Funden
ausging, konnte nicht gefunden werden. Jedoch lassen die Verzeichnis-Listen Rück-
schlüsse auf die Struktur der Web-Anwendungen zu.
    Als kurzfristige Gegenmaßnahme wäre es für die Firma empfehlenswert, die Ent-
fernung der Inhalte aus dem Suchmaschinen-Cache bei Google zu beantragen. Damit
die Inhalte auch bei Live Search entfernt werden, sollte eine robots.txt angelegt wer-
den. Zudem sollte der Webserver rekonfiguriert werden, so dass eine Auflistung von
Verzeichnisinhalten nicht mehr möglich ist. Im Überblick also:
   • Benantragung der Entfernung der Inhalte bei Google
   • Anlegen einer robots.txt
   • Rekonfiguration des Webservers


                                             85
Analyse des Aufwands
Bei der Berechnung des Zeitbedarfs der Scans werden die Durchschnittswerte aus Ab-
schnitt 4.3 zugrunde gelegt. Die Dauer pro Suchmaschine ergibt sich damit aus dem
Produkt der Anzahl der Suchmuster, der Anzahl von Domains und der durchschnittli-
chen Zeitdauer zwischen Anfrage und Antwort bei der jeweiligen Suchmaschine.

              Google                 Live Search             Yahoo
   Dauer      1593 × 2, 307s =       1593 × 2, 412s =        1593 × 1, 243s =
              61, 25min              64min                   33min

               Tabelle B.5: Dauer eines Scans der Domains von Firma 1


    Bei der Berechnung des zeitlichen Gesamtaufwands für die Bewertung aller Treffer
wird der Durchschnittswert hierfür aus Abschnitt 4.3 zugrunde gelegt. Dabei ist zu be-
achten, dass verschiedene Suchmaschinen auch gleiche Treffer gehabt haben können;
dieser Treffer aber nur einmal bewertet werden musste.

           TBewertung = 6.54s × 113 = 739, 02s = 12, 3min

Fazit
Dieser Fall zeigt, dass die Anwendung von Google Hacking sicherlich im Sinne der
Firma wäre, da die Auflistung der Verzeichnis-Inhalte ihr höchstwahrscheinlich nicht
bewusst ist. Neben einer Verbesserung der Sicherheit würde eine Verbesserung dieses
Missstandes sicherlich auch auf potentielle Kunden einen professionelleren Eindruck
machen – also wäre Google Hacking in diesem Falle auch aus Marketing-Gründen
empfehlenswert.




                                          86
B.3     Firma 2
Vorbereitung
Zu dieser Firma existierten zahlreiche Domains, welche durch ihren Wortlaut zwar
suggerieren sollten, im Besitz der Firma zu sein, es aber tatsächlich nicht waren, oder
zumindest nicht die Firma als Eigner der Domain im Whois-Record trugen. Somit
konzentrierte sich der Scan zunächst auf die beiden deutsch- und englischsprachigen
(Haupt-)Domains der Firma. Durch diese beiden Domains wurden zusätzlich zwei ver-
schiedene IP’s der Firma gefunden, wodurch wiederum zwei weitere Domains gefun-
den worden. Somit wurde der Test auf 4 Domains und 2 IPs erweitert.

    In Login-Formularen auf den Homepages gab es Eingabefelder mit den Bezeich-
nungen „name“, „dummy“ und „Password“. Das Feld „dummy“ war das Eingabefeld
für ein so genanntes „Internetkennwort“. Als neues Suchmuster wurde somit

          inurl:dummy

mit in die Sammlung aufgenommen, da die beiden anderen Bezeichnungen als oft ver-
wendete schon vorhanden waren.


Konfiguration des Jobs

      Suchmaschine             Google           Live Search      Yahoo
      Domains                                         3
      Anzahl Anfragen pro                           1616
      Domain und Scan
      Verwendete Such-           Inhalt der GHDB und an Firma 2 angepasste
      muster
      Startdatum                                 22.01.2007
      Intervall zwischen       7 Tage           1 Tag            1 Tag
      Neustarts

                Tabelle B.6: Konfiguration der Scan-Jobs für Firma 2



Analyse des ersten Scans

                                Treffer Insgesamt        Davon auffällig
        Google                  7                        0
        Live Search             50                       0
        Yahoo Search            42                       0

                       Tabelle B.7: Der erste Scan für Firma 2

    Im ersten Scan ergaben sich insgesamt 105 Treffer, von denen aber keiner Auffäl-
ligkeiten zeigte.


                                          87
                              Google      Yahoo Search   Live Search
                   Scan 1       7             42             50
                   Scan 2       0             22              0
                   Scan 3       0              5              1
                   Scan 4       0              0              1
                   Scan 5       0              0              2
                   Scan 6       0              0              0
                   Scan 7       0              0              0

  Tabelle B.8: Verlauf der Anzahl neuer Treffer bei Scans der Domains von Firma 2


 Suchmuster                 Suchmaschine     Anzahl Tref-    Ursache
                                             fer
 „Outlook Web Ac-           Google           7               Vorkommen der Phrase auf
 cess“                                                       harmlosen Seiten
 inurl:name                 Live Search      3               „name“ war ein Parame-
                                                             ter von Webseiten, der al-
                                                             lerdings nicht etwa User-
                                                             Namen enthielt.
 (mehrere)                  Live Search      23              Anomalie von Live Search

             Tabelle B.9: Falschtreffer bei Scans der Domains von Firma 2



Analyse des Verlaufs der weiteren Scans
Insgesamt waren nach 7 Durchläufen 130 Treffer zu bewerten, und es wurden 15 Sub-
domains gefunden.

Analyse des Aufwands

              Google                   Live Search            Yahoo
   Dauer      1591 × 2, 307s =         1591 × 2, 412s =       1591 × 1, 243s =
              61, 2min                 64min                  33min

              Tabelle B.10: Dauer eines Scans der Domains von Firma 2



           TBewertung = 6.54s × 130 = 850, 2s = 14, 2min

Fazit
Für Firma 2 wurde kein auffälliger Treffer gefunden. Im Allgemeinen sollte – vor dem
Hintergrund der Scans von IT-Systemen anderer Firmen – daraus allerdings nicht ge-
folgert werden, dass sich der Einsatz von Google Hacking für konkret diese Firma nicht
lohne. Die Resultate dieser Scans können daher als ggf. ergänzende Bestätigung einer
funktionierenden Security Policy betrachtet werden.



                                            88
B.4     Firma 3
Vorbereitung
Zu der Firma waren drei Domains zu finden: eine deutsch- und eine englischsprachige
Hauptdomain, sowie die Domain, unter welcher Informationen zu einem von der Firma
gesponserten Sportstadion zu finden waren. Alle drei Domains wurden in den Scan
miteinbezogen.
   Später wurde festgestellt, dass mit Hilfe der 3 verschiedenen IPs der bekannten
Domains noch zahlreiche weitere Domains, die im Besitz des Unternehmens waren,
gefunden werden konnte. Die Einbeziehung dieser Domains in den Test hätte den Rah-
men jedoch gesprengt. Es wurden stattdessen die IPs mit Hilfe des „ip:“-Parameters
von Live Search gescannt.

   Für den Login von Kunden gab es auf den Homepages Felder mit den Bezeichnun-
gen „loginName“ und „password“. Hieraus wurde das Suchmuster

          inurl:loginName
abgeleitet. „inurl:password“ war als Suchmuster schon vorhanden.

Konfiguration des Jobs

      Suchmaschine               Google          Live Search        Yahoo
      Domains                                          3
      Anzahl Anfragen pro                            1616
      Domain und Scan
      Verwendete Such-             Inhalt der GHDB und an Firma 3 angepasste
      muster
      Startdatum                                  22.01.2007
      Intervall zwischen         7 Tage          1 Tag              1 Tag
      Neustarts

                   Tabelle B.11: Konfiguration der Scan-Jobs für Firma 3



Analyse des ersten Scans

                                  Treffer Insgesamt       Davon auffällig
        Google                    4                       0
        Live Search               30                      0
        Yahoo Search              96                      2

                         Tabelle B.12: Der erste Scan für Firma 3

   Der erste Scan ergab insgesamt 2 interessante Treffer.

   1. Treffer 1:

         • Fund durch Suchmaschine: Yahoo


                                           89
         • Suchmuster: intitle:asterisk.management.portal web-access
         • Art des Fundes: Konfigurationsdatei für „Virtual Hosts“
         • Gefahr durch den Fund: Mittel

   2. Treffer 2:

         • Fund durch Suchmaschine: Yahoo
         • Suchmuster: inurl:name
         • Art des Fundes: Zugangsdaten zu einer „Mobile Homepage“ eines Kunden
           in Form von Username und Passwort-Hash
         • Gefahr durch den Fund: Gering

Beim ersten Fund handelt es sich um eine Konfigurationsdatei für einen Apache-Web-
server. Teil des Inhalts sind Informationen über die interne Pfadstruktur eines Servers.
Diese könnten sich für einen Angriff ggf. als sehr hilfreich erweisen. Durch Ansteuern
der verschiedenen Verzeichnisebenen der URL, unter welcher der Fund gemacht wur-
de, konnten leicht die Versionen des zugrunde liegenden Webservers und eines eines
PHP-Servers ausfindig gemacht werden. Als neue Suchmuster ergeben sich Worte, die
typischerweise in einer Datei wie der gefundenen vorkommen:

   • RewriteRule

   • DocumentRoot

   • RewriteEngine

   • ErrorLog

   • CustomLog

Die Daten in Fund 2 konnten nicht für einen Login-Vorgang ausgenutzt werden, da für
den Hash kein Dekodier-Verfahren gefunden wurde. Dennoch ist zumindest nicht ab-
solut auszuschließen, dass sich bei intensiverer Nachforschung ein Dekodierverfahren
finden würde. Als neues Suchmuster ergibt sich:

          inurl:pwdhash

Analyse des Verlaufs der weiteren Scans

                             Google    Yahoo Search     Live Search
                   Scan 1      4           96               212
                   Scan 2      0           24                0
                   Scan 3      0            8                0
                   Scan 4      0            0                3
                   Scan 5      0            0                1
                   Scan 6      0            0                0
                   Scan 7      0            0                0

 Tabelle B.13: Verlauf der Anzahl neuer Treffer bei Scans der Domains von Firma 3




                                          90
 Suchmuster                Suchmaschine    Anzahl Tref-      Ursache
                                           fer
 „http://*:*@www“          Google          4                 Fehlerhaftes     Suchmuster.
 domainname                                                  Das Wort „domainname“ ist
                                                             nicht nötig.
 (username | userid |      Live Search     5                 Das Wort „username“ wurde
 employee.ID | „your                                         in vielen harmlosen Zusam-
 username is“)                                               menhängen gefunden.
 (password | passcode      Live Search     10                Das Wort „password“ wur-
 | „your password is“)                                       de ebenfalls in vielen harm-
                                                             losen Zusammenhängen ge-
                                                             funden.
 inurl:name                Live Search     3                 „name“ war ein Parame-
                                                             ter von Webseiten, der al-
                                                             lerdings nicht etwa User-
                                                             Namen enthielt.
 intitle:admin    intit-   Yahoo Search    10                Wurde von Yahoo völlig
 le:login                                                    falsch interpretiert - Treffer
                                                             enthielten keins der genann-
                                                             ten Wörter im Titel.

    Tabelle B.14: Beispielhafte Falschtreffer bei Scans der Domains von Firma 3



    An den beispielhaften Falschtreffern in Tabelle B.14 sieht man, dass einige Such-
muster aus der GHDB eine sehr allgemeine Ausrichtung haben – wie etwa die Suche
nach „username“ oder „password“. Allerdings ist die Sinnhaftigkeit solcher Suchmus-
ter nicht ganz von der Hand zu weisen, wie der obige – relevante – Fund durch das
Suchmuster „inurl:name“ zeigt.
    Alle kritischen Treffer wurden bereits im ersten Durchlauf der Scans gefunden.
    Der Suchmaschinen-Cache enthielt im Fall des Treffers Nr.1 den kompletten Inhalt
der Konfigurationsdatei. Die Datei war direkt vom Server der Firma ebenfalls weiterhin
abrufbar.
    Insgesamt waren nach 7 Durchläufen 348 Treffer zu bewerten.
    Es wurden insgesamt 26 verschiedene Subdomains gefunden.


Analyse der kritischen Treffer
Im Falle von Fund 1 liegt die Ursache für den Fund sicherlich bei einer fehlerhaften
Konfiguration eines Webservers. Die Konfigurationsdatei für „Virtual Hosts“ müsste
nicht in einem öffentlich zugänglichen Bereich liegen. Die Gefahr dieses Fundes be-
steht darin, dass tatsächlich ein wesentlicher Teil der internen Serverstruktur verraten
wird. Dies kann durch verschiedene Arten von Angriffen ausgenutzt werden.
    Kurzfristige Gegenmaßnahme wäre zunächst entweder die Entfernung der Datei
oder Verbieten des öffentlichen Zugriffs auf das Verzeichnis. Da der Inhalt der Da-
tei wahrscheinlich noch eine Weile im Yahoo-Cache nachgelesen werden kann, wäre
es denkbar, die Verzeichnissstruktur des Servers zu ändern, so dass die Information
aus der Datei nicht mehr stimmt. Um zu erreichen, dass der Inhalt dauerhaft aus dem
Suchmaschinen-Cache entfernt wird, sollte eine robots.txt entsprechend konfiguriert


                                          91
werden.

    Im Falle von Fund 2 liegt die Ursache höchstwahrscheinlich beim Kunden, der
wahrscheinlich aus Gründen der Bequemlichkeit einen Link auf seiner eigenen Seite
angelegt hat. Allerdings ist das Funktionieren solcher Links nur möglich, wenn seitens
des Servers die „GET“-Übergabe von Parametern erlaubt ist.
    Eine Gefahr besteht im Missbrauch des Kundenkontos; jedoch ist dies nur möglich,
falls ein Angreifer den Hash des Passworts knackt; also vermutlich eher unwahrschein-
lich. Dennoch sollte der Kunde gebeten werden, den entsprechenden Link zu entfernen
und sein Passwort zu ändern. Langfristig sollte, um solche Vorkommnisse zu unterbin-
den, über eine Umstellung auf das „POST“-Verfahren nachgedacht werden.

Analyse des Aufwands

              Google                  Live Search              Yahoo
   Dauer      1591 × 2, 307s =        1591 × 2, 412s =         1591 × 1, 243s =
              61, 2min                64min                    33min

              Tabelle B.15: Dauer eines Scans der Domains von Firma 3



           TBewertung = 6.54s × 348 = 2275, 92s = 37, 9min

Fazit
Auch in diesem Fall hat sich Google Hacking als lohnenswert für die Firma erwiesen.
Dass die Konfigurationsdatei des Webservers öffentlich sichtbar ist, stellt sicherlich ein
gewisses Gefahrenpotential dar.




                                           92
B.5     Zusammenfassung
Wie sich an den beispielhaft untersuchten Web-Inhalten von IT-Firmen zeigt, kann
der Wert des Google Hackings als Abwehrmaßnahme von den jeweiligen Firmen als
unterschiedlich hoch eingeschätzt werden.
    Für Firma 1 war keine konkrete Gefahr für ihre IT-Systeme durch die Funde erkenn-
bar, jedoch wäre es sicher wünschenswert für sie, die gefundenen Nachlässigkeiten zu
beseitigen. Firma 2 zeigte gegenüber Google Hacking keine Anfälligkeit, was jedoch
nicht darauf schließen lässt, dass diese auch in Zukunft nicht vorhanden sein wird. Zu
Firma 3 hingegen waren mittels Google Hacking Informationen findbar, die möglicher-
weise bei einem Angriff auf ihre IT-Systeme hilfreich wären. Für dieses Unternehmen
würde sich der Einsatz von präventivem Google Hacking also auszahlen.




                                         93
Literaturverzeichnis

[arc]    Internet Archive. http://www.archive.org,

[ask]    Ask. http://www.ask.com,

[BN]     B ÖHME, Rainer ; N OWEY, Thomas: Economic Security Metrics

[dena]   DENIC eG - Datenschutz. http://www.denic.de/de/domains/recht/datenschutz/index.html,

[denb]   Domain Verwaltungs- und Betriebsgesellschaft eG. http://www.denic.de,

[dom]    Domaxxx. http://www.domaxxx.de/,

[Eck05] E CKERT, Prof. Dr. C.: IT-Sicherheit. Oldenbourg Verlag, 2005

[exa]    Exalead. http://www.exalead.com,

[Fre]    F REILING, Felix: Introduction to Security Metrics

[gcs07] Google Code Search. http://www.google.com/codesearch/, 2007

[ghd07] Google Hacking Database. http://johnny.ihackstuff.com, 2007

[ghh]    GHH - The „Google Hack“ Honeypot. http://ghh.sourceforge.net/,

[gooa]   Google       -      Hilfe      für      Webmaster:       Wie       kann
         ich      Content       aus       dem       Google-Index      entfernen?
         http://www.google.de/support/webmasters/bin/answer.py?answer=35301&ctx=sibling,

[goob]   Google Language Tools. http://www.google.com/language_tools,

[gooc]   Google       Search       Appliance        -       Product         Features.
         http://www.google.com/enterprise/gsa/features.html#enterprise,

[good]   Google SOAP Search API. http://code.google.com/apis/soapsearch/,

[gooe]   Google Webmaster Help Center: What kinds of links does Googlebot follow?
         http://www.google.com/support/webmasters/bin/answer.py?answer=33580&topic=8460,

[goof]   Google Webmaster-Tools. https://www.google.com/webmasters/tools/docs/de/protocol.html,

[ica]    Internet   Corporation      for        Assigned   Names      and   Numbers.
         http://www.icann.org,

[jap]    JAP - Anonymity & Privacy. http://anon.inf.tu-dresden.de/,


                                           94
[liva]   Entfernen Ihrer Website aus dem Index der Live Search.
         http://help.live.com/thinservice.aspx?project=wl_webmasters&mkt=de-
         de&querytype=topic&query=WL_WEBMASTERS_CONC_REMOVESITE.HTM,

[livb]   Live Search. http://www.live.com,
[livc]   Live     Search:    Richtlinien    für   eine   erfolgreiche Indizierung.
         http://help.live.com/thinservice.aspx?project=wl_webmasters&mkt=de-
         de&querytype=topic&query=WL_WEBMASTERS_REF_GUIDELINESFOR
         SUCCESSFULINDEXING.HTM,
[livd]   MSDN:       Getting     Started    with    the   Live      Search     API.
         http://msdn2.microsoft.com/en-us/library/bb266187.aspx,
[Lon05] L ONG, Johnny: Google Hacking for Penetration Testers. Syngress Publis-
        hing, 2005

[nesa]   Nessus. http://www.nessus.org,
[nesb]   Nessus Plugin 11507. http://www.nessus.org/plugins/index.php?view=single&id=11507,
[qua]    QualysGuard         Enterprise        Benefits          &          Features.
         http://www.qualys.com/products/qgent/features/,

[ses07] Search Engine Showdown: The Users’ Guide to Web Searching.
        http://searchengineshowdown.com/, 2007
[spi07] Preventing Google Hacking - Steps to protect your web application.
        http://www.spidynamics.com, 2007

[web]    WebInspect Features and Benefits. http://www.spidynamics.com/products/
         webinspect/datasheet.html,
[Wei]    W EISS, Steffen: Industrial Approaches and Standards for Security Assess-
         ment

[yaha]   How do I have my web site or web pages removed from the Yahoo! Search
         Index? http://help.yahoo.com/help/us/ysearch/indexing/indexing-13.html,
[yahb]   Yahoo Search. http://search.yahoo.com,
[yahc]   Yahoo! Slurp - Yahoo’s Webcrawler. http://help.yahoo.com/help/us/ysearch/slurp/index.html,




                                          95
Index

Acunetix, 43                           Referer, 70
Athena, 43                             Registrierungsschlüssel, 19
                                       REST, 4
Datenmodell, 35                        robots.txt, 32, 66

Fehlermeldung, 10                      Sitedigger, 42
Fingerprinting, 51, 57                 sitemap.xml, 25, 67
                                       SOAP, 4, 43
GHDB, 4, 23, 56                        SQL, 34
Google, 7, 15                          Suchmuster, 3
Google Alerts, 44
Google Hacking Honeypot, 68            User-Agent, 25, 55
Google Mini, 54, 66
Google Search Appliance, 54, 66        Verzeichnisse, 8
Google Web Services, 43                Vulnerability Scanning, 18, 46
Google-Cache, 16
Google-Scan, 19                        Webcrawler, 15
gooscan, 42                            WebInspect, 50
Gooscanner, 34                         Webserver, 11
                                       Wikto, 43
HTML, 21
                                       Yahoo Search, 14, 15
Idle Scanning, 51, 57
                                       Zugangsdaten, 8
Internet Archive, 16

Job, 34

Leetspeech, 24
Live Search, 13, 15
Logdatei, 10
Login-Portal, 10, 23

Nessus, 46
Nmap, 47

Parameter, 7, 13, 14
Penetration Testing, 56
PHP, 24
Portscan, 51, 57
Proxy-Server, 12

QualysGuard, 49


                                  96