Unternehmensbezogenes Google Hacking

Transcription

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
2
3
Einführung
1.1 Motivation . . . . . . . . . . . . . . . . .
1.2 Suchmaschinen . . . . . . . . . . . . . .
1.3 Google Hacking . . . . . . . . . . . . . .
1.4 Ziele und Strukturierung der Diplomarbeit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
3
4
5
Grundlagen
2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Einführung in Google Hacking . . . . . . . . . . . . . . . . . . . . .
2.2.1 Die Google-Syntax . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Klassifizierung von Suchmustern . . . . . . . . . . . . . . .
2.2.3 Erweiterung der Google-Hacking-Datenbank / Suche nach neuen Suchmustern . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Exkurs: Die Verwendung von Google als Proxy-Server . . . .
2.2.5 Die Suche nach E-Mail-Adressen mittels Google . . . . . . .
2.3 Weitere Suchmaschinen . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Windows Live Search . . . . . . . . . . . . . . . . . . . . .
2.3.2 Yahoo Search . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Vergleich verschiedener Suchmaschinen bezüglich ihrer Eignung für
Suchmaschinen-Hacking . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Die Reichweite von Webcrawlern der Suchmaschinen . . . . . . . . .
2.6 Suchmaschinen-Caches und ein Internet-Archiv . . . . . . . . . . . .
2.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
16
17
Google Scanning
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Vulnerability Scanning . . . . . . . . . . . . . . . . . . . . . .
3.3 Anwendung von Google Hacking . . . . . . . . . . . . . . . .
3.3.1 Voraussetzungen . . . . . . . . . . . . . . . . . . . . .
3.3.2 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Ablauf des Google-Scans . . . . . . . . . . . . . . . . . . . . .
3.4.1 Probleme / Einschränkungen des Google Hackings . . .
3.4.2 Finden aller relevanter Domains bzw. Webapplikationen
3.4.3 Finden sinnvoller Suchmuster . . . . . . . . . . . . . .
3.4.4 Langfristiger Ablaufplan . . . . . . . . . . . . . . . . .
3.4.5 Tiefe der Suche . . . . . . . . . . . . . . . . . . . . . .
3.4.6 Analyse der Ergebnisse . . . . . . . . . . . . . . . . . .
3.4.7 Kurzfristige Maßnahmen nach einem Fund . . . . . . .
18
18
18
19
19
19
20
21
22
22
24
25
27
29
V
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
7
8
11
12
12
13
13
14
3.5
4
5
6
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entwicklung des Google-Hacking-Tools „GooScanner“
4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Arbeitsweise des Programms . . . . . . . . . . . . . . . . .
4.3 Aufwandsabschätzung . . . . . . . . . . . . . . . . . . . .
4.4 Schema für die Anwendung von GooScanner . . . . . . . .
4.5 Andere Vulnerability-Scanner, die Google Hacking einsetzen
4.5.1 Sitedigger . . . . . . . . . . . . . . . . . . . . . . .
4.5.2 gooscan . . . . . . . . . . . . . . . . . . . . . . . .
4.5.3 Acunetix . . . . . . . . . . . . . . . . . . . . . . .
4.5.4 Athena . . . . . . . . . . . . . . . . . . . . . . . .
4.5.5 Wikto . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Google Web Services . . . . . . . . . . . . . . . . . . . . .
4.7 Google Alerts . . . . . . . . . . . . . . . . . . . . . . . . .
4.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Vergleich mit anderen Scanning-Methoden
5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Scanning-Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 QualysGuard . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 WebInspect . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4 Parallelen bzw. Unterschiede zum Google Hacking . . . . . .
5.3 Maximierung des Sicherheitsgewinns durch Google Scanning . . . .
5.3.1 Die Effektivität des Google Scannings . . . . . . . . . . . . .
5.3.2 Auswirkung der Aktualität des Suchindex auf die Abwehrrate
5.3.3 Auswirkung der Aktualität bzw. des Inhalts der SuchmusterDatenbasis auf die Abwehrrate . . . . . . . . . . . . . . . . .
5.4 Kurze Einführung in Penetration Testing . . . . . . . . . . . . . . . .
5.4.1 Resultate durch etablierte Penetration-Testing-Verfahren . . .
5.5 Der betriebliche Mehrwert durch Google Hacking . . . . . . . . . . .
5.5.1 Ungeschützte Systeme . . . . . . . . . . . . . . . . . . . . .
5.5.2 Durch Vulnerability Scanning geschützte Systeme . . . . . .
5.5.3 Durch Penetration Testing geschützte Systeme . . . . . . . .
5.5.4 Durch Vulnerability Scanning und Penetration Testing geschützte Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.5 Kosten-/Nutzen-Verhältnisse auf Basis des messbaren Anteils
am Sicherheitsgewinn . . . . . . . . . . . . . . . . . . . . .
5.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . .
Präventive Abwehr
6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Alarmsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Server-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Google Hacking Honeypots / Verbreitung von Falschinformationen . .
6.5 Blockieren des Zugriffs für offensichtliche
Google-Hacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Betrachtung des Inhalts von Websites unter Verwendung eines Webcrawlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VI
33
34
34
34
37
41
42
42
42
43
43
43
43
44
44
46
46
46
46
49
50
50
53
53
54
56
56
57
57
58
59
59
60
62
63
65
65
65
66
68
70
70
6.7
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
Zusammenfassung
7.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
73
A Quellcode
A.1 Das Scheduling-Modul von GooScanner . . . . . . . . . . . . . . . .
A.2 Das Google-Scan-Modul von GooScanner . . . . . . . . . . . . . . .
74
74
77
B Fallbeispiele
B.1 Einleitung . . . . .
B.2 Firma 1 . . . . . .
B.3 Firma 2 . . . . . .
B.4 Firma 3 . . . . . .
B.5 Zusammenfassung
82
82
83
87
89
93
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
VII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abbildungsverzeichnis
1.1
1.2
Ergebnis der Anwendung eines einfachen Suchmusters . . . . . . . .
Die Google-Startseite . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
Ergebnis der Suche nach einer Drucker-Schnittstelle . . . . .
Ergebnisse der Suche nach Index of: inurl:private
Ergebnis der Suche nach inurl:passwd . . . . . . . . . . .
Ergebnis der Suche nach filetype:pwd inurl:service .
Ergebnis der Suche nach @gmail.com -www.gmail.com .
.
.
.
.
.
8
9
9
9
13
3.1
Ablaufplan Google Scanning in Pseudocode . . . . . . . . . . . . . .
26
4.1
4.2
4.3
4.4
Datenmodell von GooScanner . . . . . . . . . . . . .
Konfiguration eines Jobs in GooScanner . . . . . . . .
Bewertung eines Fundes in GooScanner . . . . . . . .
Bewertung mehrerer Funde gleichzeitig in GooScanner
.
.
.
.
35
38
38
39
5.1
Quellcode eines Nessus-Plugins . . . . . . . . . . . . . . . . . . . .
48
6.1
6.2
Beispiel einer sitemap.xml . . . . . . . . . . . . . . . . . . . . . . .
Honeypot-Funktion zum Sammeln von Informationen über Angreifer
68
69
VIII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
Tabellenverzeichnis
2.1
Zeit zwischen Besuch durch Webcrawler und Aktualisierung des Cache
17
3.1
3.2
3.3
Limitierung der Anzahl gelieferter Ergebnisse . . . . . . . . . . . . .
Funde und Gegenmaßnahmen . . . . . . . . . . . . . . . . . . . . .
Vergleich von Entfernungszeiten . . . . . . . . . . . . . . . . . . . .
27
30
32
4.1
4.2
4.3
Zeitbedarf von Google Scanning . . . . . . . . . . . . . . . . . . . .
Grundlagen der Statistik in Tabelle 4.1 . . . . . . . . . . . . . . . . .
Verlauf der Anzahl neuer Treffer bei Scans von t-mobile.de . . . . . .
37
37
40
5.1
5.2
5.3
Vergleich von Google Hacking und Vulnerability Scanning . . . . . .
Die UserAgents der Suchmaschinen . . . . . . . . . . . . . . . . . .
Vergleich von Google Hacking und Vulnerability Scanning bzgl. Mehrwerts durch Google Hacking . . . . . . . . . . . . . . . . . . . . . .
Vergleich von Google Hacking und Penetration Testing bzgl. Mehrwerts durch Google Hacking . . . . . . . . . . . . . . . . . . . . . .
Vergleich von Google Hacking und Penetration Testing zusammen mit
Vulnerability Scanning bzgl. Mehrwerts durch Google Hacking . . . .
52
55
Konfiguration der Scan-Jobs für Firma 1 . . . . . . . . . . . . . . . .
Der erste Scan für Firma 1 . . . . . . . . . . . . . . . . . . . . . . .
Verlauf der Anzahl neuer Treffer bei Scans der Domains von Firma 1 .
Falschtreffer bei Scans der Domains von Firma 1 . . . . . . . . . . .
Dauer eines Scans der Domains von Firma 1 . . . . . . . . . . . . . .
Falschtreffer bei Scans der Domains von Firma 2 . . . . . . . . . . .
Beispielhafte Falschtreffer bei Scans der Domains von Firma 3 . . . .
83
83
84
85
86
87
87
88
88
88
89
89
90
91
92
5.4
5.5
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
B.10
B.11
B.12
B.13
B.14
B.15
IX
59
60
61
Zusammenfassung
„Google Hacking“ ist eine Methode, mit welcher Suchmaschinen als Hacker-Werkzeuge verwendet werden. Mittels Google Hacking kann man beispielsweise die Angreifbarkeit von Webservern erforschen, Zugangsdaten aufspüren und Informationen sammeln, die den Angriff auf ein Netzwerk mittels anderer Methoden erleichtern. Hierzu
werden keine geheimen Funktionen der Suchmaschinen verwendet, sondern hochspezialisierte Suchmuster als Anfragen an die Suchmaschinen gesendet.
Diese Diplomarbeit bietet einen Überblick über die beim Google Hacking verwendeten Techniken. Zudem werden verschiedene Möglichkeiten der Abwehr untersucht. Der Schwerpunkt liegt hierbei auf der Untersuchung und Entdeckung möglicher
Schwachstellen der Web-Applikationen und Netze eines Unternehmens mittels regelmäß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 erfolgsversprechend der Einsatz der Methoden des Google Hackings für eine unternehmensinterne 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 VulnerabilityScanning-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 Allgemeinen um die Suche nach Informationen im World Wide Web geht. Für die Suchmaschinen 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 Gefahrenpotential für ihren Eigner mit sich bringen – aber indirekt Angriffsmöglichkeiten eröffnen. 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 bereits mit Hilfe einfacher Suchmuster wie etwa „intitle:index of parent directory inurl:private“ interessante Funde gemacht werden. Hier wurde zwar
nur relativ ungezielt nach allgemeinen, privaten Daten gesucht, jedoch wird daran deutlich, 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 Informationen 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 Spezialfällen ein direkter Angriff auf ein Netz durchführen, welcher dem klassischen Verstä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 Suchmaschine 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 Google sollten noch „Yahoo! Search“ [yahb] (im Folgenden „Yahoo Search“ genannt) und
„Windows Live Search“ [livb] (vormals „MSN“, im Folgenden kurz „Live Search“ genannt) 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 übergeben wird. Es definiert, welchen Inhalt bzw. welche Eigenschaften ein gesuchtes Dokument 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 Geschwindigkeit 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 Sperrung 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 Suchmaschinen 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 entweder auf das Google Hacking spezialisiert sind oder es als Zusatz-Feature anbieten, greifen 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 Sicherheitslücken mit Hilfe dieser Suchmaschine soll innerhalb dieser Arbeit allerdings nicht weiter 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
State Transfer
2 Representational
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 hinsichtlich möglicher Sicherheitsschwächen
3. Entwicklung einer automatisierten Schnittstelle, über welche täglich neu hinzugekommene 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 Entwicklung 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 werden 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 WebApplikationen und Netze von IT-Firmen mit Hilfe des entwickelten Werkzeugs auf
Anfälligkeit gegenüber Google Hacking untersucht werden. Hierdurch wird die Eignung 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 formulierten 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 weiteren, 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 Argument 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 verknü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 bestimmten 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 „Xerox 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 beispielsweise Verzeichnisse, in denen Software zum Download angeboten wird, deren
Versionsnummer und – damit zusammenhängend – deren Dateiname sich so oft ändert, dass die Pflege der HTML-Oberfläche zu aufwendig wäre.
Ein Verzeichnis ohne eigene HTML-Oberfläche kann allerdings auch unbeabsichtigt der Öffentlichkeit zugänglich gemacht sein. Dies kann etwa bei unzureichender
Konfiguration eines Webservers passieren. Solche Verzeichnisse findet man beispielsweise 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 Beispiel 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 Schwachstellen sein. Der Fund eines Login-Portals eines Intranets ist noch weitaus schwerwiegender, 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 allerdings 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 etwa seine interne Verzeichnis- oder Datenbankstruktur, Software-Versionsnummern und
Teile von Code. Fehlermeldungen enthalten oft signifikante Phrasen, also kann beispielweise 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 beispielsweise eine Konfigurationsseite über das HTTP-Protokoll an. Neben der Konfiguration 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 werden. 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 Versionsnummer 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, vertrauliche 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-Anwendungs-Version auch neue Muster von Fehlermeldungen, bestimmte Namen von Konfigurationsdateien 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-HackingCommunity findet man unter [ghd07].
Ein sinnvoller Weg, nach neuen Suchmustern zu forschen, ist, mit dem Betrachten einer bekannten Sicherheitsschwäche zu beginnen, zum Beispiel einer bestimmten 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 Eingabefeld für URLs. Nach Eingabe einer Adresse und Klick auf „Übersetzen“ befindet
sich in der resultierenden URL unter Anderem der Parameter „langpair“. Das Argument 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 Übersetzung 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-Engineering-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, Mailadressen zu finden. Die Suche nach dem „@“-Zeichen bzw. Zeichenketten, die dieses beinhalten, 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“ gefunden – 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 Kriterium für die Verwendbarkeit stellen Größe und Aktualität der Suchindizes von Suchmaschinen 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 Informationen darüber zu veröffentlichen. Ergänzend wären noch „Ask“ [ask] und „Exalead“ [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 kommen 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 verlinken, 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-AnkerTags 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 vorkommen.
• 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
Object Access Protocol
4 Representational State Transfer
3 Simple
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 Domain 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 Suchmaschinen-Datenbank wieder – falls vorhanden.
• inurl: Wie Live Search.
• originurlextension: Begrenzt die Ergebnisse auf den angegebenen Dateityp.
• feature: acrobat, applet, activex, audio, flash, form, frame,
homepage, image, index, javascript, meta, script, shockwave,
table, video, vrml – Durch den jeweiligen Parameter wird angegeben, welche 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 Geschwindigkeit 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 Verfügung.
Die Ähnlichkeit der drei Suchmaschinen zeigt sich wohl am deutlichsten in der
Syntax der Anfragen. Die Auswertung der bei der Suche angegebenen Parameter (siehe Abschnitte 2.2.1, 2.3.1 und 2.3.2) hat bei den verschiedenen Suchmaschinen allerdings 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 Treffer, wobei nur das Wort „queen“ wirklich in der URL auftritt. Entfernt man den Begriff „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 automatisiertes 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 anfragenden IP oder Beschaffung weiterer Lizenzschlüssel lässt sich dies aber ggf. umgehen.
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ängig davon, dass sich dies im Laufe der Verwendung der drei Suchmaschinen nicht abgezeichnet 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 verschiedenen 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 Suchmaschinen
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 wohlgeformten 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 HREFTag 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 Inhalt 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 Seite 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 Anhä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 Version 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 InternetBrowser die Möglichkeit, das Laden von Grafiken komplett abzuschalten. Zudem existiert ein Online-Archiv, welches sich auf das Festhalten von Schnappschüssen beliebiger Webseiten konzentriert hat: Das so genannte „Internet Archive“ [arc] mit seiner
so genannten „Wayback Machine“. Hier finden sich sogar Schnappschüsse zu mehreren 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 vorhandenem 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 überprü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 dieser 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 Zeitangabe, 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 eingelesene 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 Aktualisierung
Google
Yahoo Search
Ø
Min.
Max.
45,2h
15,6h
18,8h
2,5h
65,5h
61,5h
Anz. Messungen
4
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 Google Hackings gegeben. Es wurde deutlich gemacht, dass sich nicht nur Google für die
Suche nach sensiblen Informationen eignet, sondern auch einige andere Suchmaschinen, 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 Webcrawler 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 Dokumenten-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 Google 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 Vulnerability Scanning eignet. Diese Art des Überprüfens von IT-Systemen auf Verwundbarkeit 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 GoogleHacking-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 automatisiert auf Anfälligkeiten gegenüber bestimmten Angriffsmustern überprüft. Bei
einem so genannten „Penetrationtest“ hingegen wird ein IT-System auf seine Anfälligkeit gegenüber Angriffen durch größtenteils manuelles Hacking getestet. Hierbei
wird weniger automatisiert gearbeitet, um individuelle Möglichkeiten nutzen zu können, 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 bezeichnen. Die Automatisierung ist sinnvoll, da die Anzahl der möglichen Google-HackingSuchmuster zu groß ist, als dass sie alle in regelmäßigen Zeitabständen manuell eingegeben werden könnten. Eine automatisierte, in einem festgelegten Zeitintervall durchgefü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 teilweise von Software-Herstellern oder privaten Entwicklern umgesetzt. Diese Programme
werden kurz vorgestellt. In den weiteren Abschnitten werden die eingangs erwähnten „Google Web Services“ und „Google Alerts“ betrachtet und hinsichtlich ihrer Verwendbarkeit für systematisches Google Hacking bewertet. Abschließend werden – aufbauend auf den Erfahrungen aus den vorhergehenden Kapiteln – die für das „Google“
Hacking verwendbaren Suchmaschinen ebenfalls in Bezug auf diesen Aspekt verglichen.
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 Vulnerability 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 gering. Für die Eingabe eines einzelnen Suchmusters in das Eingabefeld einer Suchmaschine genügt ein Internet-Zugang und ein installierter Browser auf dem Computer
des Google Hackers. Geht es allerdings um komplette Google-Scans, sind die Voraussetzungen 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 seitens 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 Antworten 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 mittels bestimmter Suchmaschinen entdecken?
2. Welche Suchergebnisse wurden bereits betrachtet und bewertet, bzw. bei welchen 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öglich genutzt werden. Zudem muss eine Möglichkeit gefunden werden, auch die öffentlich zugänglichen Informationen zu finden, welche zwar noch nicht in einen öffentlichen Suchindex aufgenommen wurden, aber theoretisch gefunden und dort aufgenommen 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 wirklich 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 betrachteten und bewerteten Funden, und den stetig weiter auftretenden Funden notwendig. 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 SeitenFragments 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 Suchmaschine nicht geändert hat. Diese Annahme wird aus Effizienzgründen getroffen, da
eine weitergehende Untersuchung eines jeden Wiederauftritts eines Fundes in der Praxis wohl kaum zu bewältigen wäre. Eine Bewertung eines Fundes ist erfahrungsgemäß
kaum automatisiert zu bewältigen, sondern erfordert stets einen geschulten Administrator 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 gefundenen 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-Anwendungen 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üssen 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 Domains 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 öffentliche 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 diesem 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 gegeben.
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 textuellen Inhalt, Hyperlinks, den Titel und die URL einer Seite betrifft dies alle anderen
HTML-Tags oder Script-Bestandteile. Somit können beispielsweise keine Eingabeformulare gesucht werden.
Eine weitere, stets präsente Einschränkung besteht in der Unvollständigkeit der Suchindizes. Ein Suchindex ist immer nur so aktuell, wie es die Arbeitsgeschwindigkeit
seines zugehörigen Webcrawlers zulässt, bzw. von der Frequenz der Besuche des Webcrawlers auf allen relevanten Webseiten. Außerdem hängt die Vollständigkeit des Suchindexes 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 unterstü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üssel
21
• Live Search: 1 Lizenzschlüssel pro Person; 10000 Anfragen pro Tag, Lizenzschlü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 Unternehmen sensibel sind. Da aber ein Vulnerability-Scan mittels Google Hacking stets auf
bestimmte Domains eingeschränkt werden sollte, ist es wichtig, alle relevanten Domains 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 darstellen.
Der Ansatz, etwa über die Google-Bildersuche nach dem Dateinamen eines Firmenlogos zu suchen, führt zu keinem sinnvollen Ergebnis, wie die Suche nach „tmobile-logo.gif“ zeigt. Die hier gefundenen Webseiten gehören nur in einem geringen 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 GoogleScan 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üssen ins Blaue
3. Untersuchung von Webapplikationen und Anpassung von StandardSuchmustern
4. „Leetspeech“-Varianten von Domainnamen
In einem umfassenden Vulnerability Scan gilt grundsätzlich, dass man stets das Unerwartete 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 Suchmustern 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 sensible 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 Suchmuster:
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 Sicherheitsschwächen oder sensible Daten. Jedoch kann sie erstens Aufschluss darüber geben, welche bisher womöglich unbeachteten Webanwendungen auf den Firmendomains 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 spezifiziertere 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 Formular 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 Webserver 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 aufzuspü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. Vielmehr können diese Domainnamen die Basis für Phishing-Attacken bilden, indem beispielsweise ein Login-Portal vorgetäuscht wird, auf welchem Firmenkunden zur Eingabe 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 untergeordnete Rolle.
3.4.4
Langfristiger Ablaufplan
Google Hacking bezüglich des eigenen Web-Inhalts eines Unternehmens sollte sinnvollerweise 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 denkbar, dass nicht unbedingt jeden Tag ein kompletter Scan einer Suchmaschine durchgefü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 eines 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 Indizieren 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 Scannen 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 Zeitdauer 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 angewiesen 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 Aufwand 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 gesagt 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 Da25
1
2
3
/ / Entweder :
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 {
Für j e d e Suchmaschine {
4
5
6
7
8
/ / Oder :
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
b i s Informationsaufnahme in Index {
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
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
/ / In j e d e r Variante :
F ü r j e d e r e l e v a n t e Domain {
Für j e d e s bekannte Suchmuster {
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 {
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 ;
Für j e d e n T r e f f e r {
Ü 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 ;
Falls ja {
Ü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 ;
}
Sonst {
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 ;
}
}
}
}
}
}
}
Abbildung 3.1: Ablaufplan Google Scanning in Pseudocode
26
Anzahl
gelieferter
Treffer pro Anfrage
Google SOAP-API
Live Search SOAPAPI
Yahoo Search RESTAPI
10
50
Obere Grenze der
Stellenpositionen
gelieferter Treffer
1000
1000
100
1000
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 probehalber bewusst für alle Suchmuster einzugehen. Um in diesem Fall alle möglichen
Falschtreffer zu erhalten, sollte hierbei auch das Leerzeichen als Suchmuster miteinbezogen werden.
3.4.6
Analyse der Ergebnisse
Ein wesentlicher Schritt des Ablaufs eines Google-Scans, wie in Abschnitt 3.4.4 skizziert, ist die Aufforderung an den Administrator, den Treffer zu bewerten. Das menschliche 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 Informationen 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 Pfadinformation 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 einer 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 beabsichtigt 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öglicherweise 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 angezeigte 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) Passwort 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 dieselbe 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 Benutzeraccounts 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 Betreiber 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 allerdings so gut wie nie, da eine Versionsinformation erlaubt, gezielt nach passenden Exploits 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 Gefahr 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. welche 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 Seitentitel 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öglichkeit 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 Ergreifen 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 Schadensbegrenzung: 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
Index von Verzeichnissen
Login-Daten
Login-Portale
Persönliche Daten
Kreditkartennummern
Fehlermeldungen
Logdateien
Web-Schnittstellen
von
Hardware
Versions-Informationen
Gegenmaßnahme(n)
Ändern der Verzeichnisstruktur, Verhindern der
Auflistung des Inhalts durch Rekonfiguration
des Servers, Entfernen des Inhalts aus dem
Suchmaschinen-Index
Ändern der Login-Daten, Rekonfiguration des
Portals, Verhinderung des Zugriffs
Entfernung
der
Information
aus
dem
Suchmaschinen-Index, Rekonfiguration robots.txt
Verhinderung des Zugriffs, Entfernung aus dem
Suchmaschinen-Index
Verhinderung des Zugriffs, Kreditkarte deaktivieren
Rekonfiguration des Servers, Entfernung aus dem
Suchmaschinen-Index
Suchmaschinen-Index
Suchmaschinen-Index
Änderung der Version und Belassen der Information im Suchmaschinen-Index. Oder: Absicherung
gegen evtl. existierende Exploits (Mittels Update oder – falls möglich – eines eigenen Workarounds) 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 Index 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 entsprechende 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 Sicherheitsschwä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öglichkeit betrachtet werden, dass die Informationen bereits von potentiellen Angreifern
gesehen wurden (Worst-Case-Fall). Wenn allerdings ein auf diesen Informationen basierender 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 entsprechenden Meta-Tags in den HTML-Code der Seite einfügen. (...) Sie
können Ihre URL zur Entfernung aus Googles Suchergebnissen einreichen. URLs werden entfernt, nachdem wir Ihre Anforderung geprüft haben. Beachten Sie, dass diese Prüfung mehrere Tage oder länger in Anspruch 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 erlä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 Indizierung 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 Webserver 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 Indizierung abgeschlossen hat und Ihre Änderungen wirksam werden. Hinweis: 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.pizzabestellen.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 Bestandteile der Seite aus den jeweiligen Bestandteilen von entfernt wurde, aufgelistet. Der
Suchmaschine
Google
Inhalt aus Cache entfernt
01.02.2007,
18:00 Uhr
Fragment aus
Index entfernt
02.02.2007,
13:00 Uhr
URL aus Index entfernt
02.02.2007,
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 unbedeutend 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 prinzipiell 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 langfristige Ablaufplan ist teils vom Einfluss, den man auf das Verhalten der SuchmaschinenWebcrawler hat, abhängig. Jedoch kann er – wie die Tiefe der Suche – auch von der Anzahl 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 Ergebnisse von verschiedenen Zeitpunkten vergleicht. Mit Hilfe dieses Tools soll die Überprü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 Arbeitsweise 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 Datenbank 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 bestimmte 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 Anfragen 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 gleichnamige Datenbank-Tabelle in Abb. 4.1). Zu jedem Scan wiederum werden die Ergebnisse zu jeder Anfrage in der Tabelle „result“ gespeichert. Jedes Ergebnis besteht aus
keinem, einem oder mehreren Treffern. Diese einzelnen Treffer werden den Ergebnissen in der Tabelle „hit“ zugeordnet. Der Titel der gefundenen Seite und der von
der Suchmaschine gelieferte Ausschnitt werden mit gespeichert. Mittels des Flags „hitEvaluated“ 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 überprü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-SearchModul 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 errechnet, 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 Anfrage 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ücksichtigt. 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 Suchmuster 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 auftreten. Allerdings sollte ein Treffer nur einmal – und nicht bei jedem Scan erneut – als
harmlos oder schwerwiegend eingestuft werden müssen. Als eindeutige Charakterisierung eines bestimmten Treffers sollte die Kombination aus Webseiten-Ausschnitt,
(„Fragment“) URL und Seitentitel genügen. Wenn also eine Kombination aus Fragment, URL und Titel zu einem früheren Zeitpunkt zu demselben Ergebnis wie im aktuellen 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 einem 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 Oberflä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 gleichzeitig 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 Punkten gemessen bzw. abgeschätzt:
• Anfragen pro Zeiteinheit
• Genutzte Internet-Bandbreite
• Personeller bzw. zeitlicher Aufwand
• CPU-Belastung
• Bedarf an nichtflüchtigem Speicher
Google
2,307 s
Ø-Zeit zwischen Anfrage und Antwort
Live Search
2,412 s
Yahoo Search
1,243 s
Tabelle 4.1: Zeitbedarf von Google Scanning
Suchmaschine
Google
Yahoo
Live Search
Umfang der Grundlage der Messergebnisse
10 Scans mit insgesamt 13733 Anfragen
Tabelle 4.2: Grundlagen der Statistik in Tabelle 4.1
Das bedeutet: Ein Scan einer Domain mittels 1600 Suchmustern dauert mit Google 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 Scanning 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äteren 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 untersuchten Web-Auftritts zusammen.
In Tabelle 4.3 ist beispielhaft der Verlaufs der Anzahl zu bewertender (neuer) Treffer anhand eines täglichen Scans der Domain t-mobile.de zu sehen. Die für eine Bewertung 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 genauere 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 Gestaltung der Schnittstelle ab, über welche die Bewertung vorgenommen wird. Bei einer
„Einzelbetrachtung“ wie in Abbildung 4.3 ist sowohl der Aufwand, als auch die Aufmerksamkeit gegenüber dem einzelnen Treffer relativ hoch. Die benötigte Zeit wurde
39
Tag 1
Tag 2
Tag 3
Tag 4
Tag 5
Tag 6
Tag 7
Google
61
39
12
2
2
1
5
Yahoo Search
123
3
6
2
3
1
14
Live Search
109
14
0
24
7
1
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 steigender Erfahrung auch weniger Zeit in Anspruch nimmt. Unter Verwendung der Benutzerschnittstelle 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 derselbe Treffer bei einem abermaligen Fund nicht erneut bewertet werden muss, kann
ein realistischer Mittelwert für die tägliche Zeitbelastung aufgrund der Bewertungsvorgä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 Suchmuster im Rahmen der Untersuchung der IT-Systeme eines Unternehmens können ebenfalls 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-Anwendungen 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 Dokumenten im Doc-Format bereitstellt, die auch für die Öffentlichkeit gedacht sind, ergeben 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 entsprechenden „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 eingerichtete Untersuchungs-Routine eines IT-Systems ist proportional zum Umfang dieses ITSystems. Gründe hierfür sind:
• Die gesamte Anzahl von Treffern ist direkt proportional zum Umfang des ITSystems 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 gespeicherten 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 davon abhängig gemacht werden, wie oft der Cache der Suchmaschine aktualisiert 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
4.5.1
Andere Vulnerability-Scanner, die Google Hacking
einsetzen
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 gesendet. Das Ergebnis der Anfragen wird als Liste der gefundenen URLs in einer Tabelle 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 gehalten 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 HTMLDatei.
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 welchem 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 Acunetix 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 Google. 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 angegeben 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 Untersuchung 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 Anfragen 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 hinsichtlich der Programmierung eines automatischen Google-Scanners eine große Erleichterung, da die Ergebnisse von Anfragen nicht im HTML-Format, sondern als Array geliefert werden. Der Nutzen der Google Web Services für das unternehmensbezogene 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 Suchmaschinen-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 Zeitpunkt 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 derzeitigen 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 eigenen 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 allerdings 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 systematisch zum Schutz der IT-Systeme eines Unternehmens eingesetzt werden kann.
Hierzu wurde der Begriff „Google Scanning“ eingeführt, der das Senden großer Mengen 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 Scanning 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 Basis eines SQL-Servers. Es bietet die Möglichkeit, frei festgelegte Mengen von Domains mittels einer ebenso frei definierten Menge von Suchmustern in regelmäßigen
Zeitabständen zu „scannen“, wobei die Suchmaschinen Google, Live Search und Yahoo Search verwendet werden. Außerdem steht innerhalb des Programms eine Schnittstelle 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 Schnittstelle zur Google-Suchmaschine ist, über welche große Mengen von Anfragen gesendet 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. Aufgrund 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 Restriktionen 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 sinnvolle Ergänzungen zueinander erwiesen, zumal die Syntax der Anfragen jeweils sehr
ähnlich ist.
Nachdem nun mit Google Scanning eine spezielle Form des Vulnerability Scannings ausführlich vorgestellt wurde, folgt nun eine Betrachtung herkömmlicher Methoden. 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-ScanningMethoden
5.1
Einleitung
Im Allgemeinen wird die Verwundbarkeit eines Webservers durch Vulnerability Scanning und/oder Penetration Testing überprüft. Google Hacking würde nach der Vorgehensweise, 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 ScanningMethoden 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-Werkzeug. Es hat Portscanning-Funktionalitäten, die Teilweise auf dem Tool „Nmap“ beruhen. 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 Server 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., welche Ports von welchen Systemen offen sind - also welche Dienste aktiv sind.
2. Versionserkennung: Auf Grundlage von offenen Ports wird versucht, zu erkennen, welche Version von welcher Software oder welchem Betriebssystem zu diesem Port gehört.
3. Erkennung von Paketfiltern und Firewalls
4. Hardware-Erkennung
Es wird festgestellt, auf welche Arten und Weisen Netzwerkverbindungen mit den untersuchten Computern aufgebaut werden können – bzw., welche Möglichkeiten für
einen Angriff bestehen. Zudem können Computer in Netzen entdeckt werden, die eigentlich 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 Intervalle 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 Sicherheitsschwä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 installierten Server liefert. Die Funktion „safe_checks()“ gibt die Information, ob Nessus
darauf konfiguriert ist, eine Sicherheitslücke probehalber auszunutzen. Falls nicht, würde 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
2
include ( " http_func . inc " ) ;
include ( " backport . inc " ) ;
3
4
port = get_http_port ( default :80) ;
5
6
7
8
if ( get_port_state ( port ) ) {
banner = get_backport_banner ( banner : get_http_banner ( port :
port ) ) ;
i f ( ! banner ) e x i t (0) ;
9
s e r v = s t r s t r ( banner , " Server " ) ;
i f ( safe_checks () ) {
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 ) )
{
security_hole ( port ) ;
}
}
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 ) ) {
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) ;
soc = open_sock_tcp ( p o r t ) ;
f o r ( i = 0 ; i < 1 0 1 ; i ++) {
n = s e n d ( s o c k e t : soc , d a t a : s t r i n g ( " \ r \ n " ) ) ;
i f ( n <= 0 ) e x i t ( 0 ) ;
}
10
11
12
13
14
15
16
17
18
19
20
21
22
23
r = h t t p _ r e c v ( socket : soc ) ;
if (! r ) security_hole ( port ) ;
24
25
}
26
27
}
Abbildung 5.1: Quellcode eines Nessus-Plugins
48
Ausdrucks ermittelt, welche Server-Version vorliegt. Falls eine bekanntermaßen verwundbare 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 überprüft, ob eine anfällige Server-Version vorliegt. Falls nicht, wird der Test mittels „exit(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 wurde.
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 Schwachstellen
– 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 TicketSysteme
• Automatische Aktualisierung der eigenen Datenbank von Verwundbarkeits-Signaturen
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 Ebenen von IT-Systemen zu finden sind.
Der Hauptunterschied zwischen den Verfahren von QualysGuard und von Google Scanning ist das Ziel, welches in beiden Fällen jeweils untersucht wird. Qualysguard hat die Möglichkeit, ein Netzwerk bis auf die Netzwerk-Ebene des ISO/OSIModells 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ähigkeiten 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 Seiten
• 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-Versionen
Die Möglichkeiten des Webcrawlers dieses Vulnerability-Scanners gehen also über diejenigen 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-Informationen. 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 weniger weit entfernten Vergangenheit, während bei einer direkten Untersuchung eines Servers 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: Vertrauliche Dokumente, Log-Dateien, Listen von Usernamen, Fehlermeldungen etc..
50
Eine Parallele zwischen Vulnerability Scanning und Google Hacking kann in gewisser Weise im Idle Scanning gesehen werden. Hier kann – genau wie beim Google
Hacking – eine Information über die Angreifbarkeit eines Servers durch eine dritte Instanz 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 allerdings 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 Information 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 festgelegten Systematik eher generischer Natur sind.
Während mit Hilfe von üblichen Vulnerability Scans eher die tiefere Struktur eines 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 Gefahrenpotential 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 Vulnerability 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 verfü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
Feststellen von Verwundbarkeit anhand v. Versionsinformationen
„Dritte Instanz“ zwischen
Angreifer und Ziel
Automatisiertes Scanning
mit Meldung von Funden
Suchmuster individuell anpassbar
Feststellen von Verwundbarkeit anhand probehalber Angriffe
Vulnerability Scanning
Parallelen
Fingerprinting
Google Hacking
Zombie-Rechner
Informationen
auf
Webseiten oder in
Dokumenten
Suchmaschine
ja
ja
ja
ja (in einem eingeschränkteren Rahmen)
Unterschiede
Ja
Aktualität der gewonnenen
Informationen
Portscanning
größtmöglich
Scanning von Dokumenten
ja
Auswahl der Ziele
dynamisch
Verwendung regulärer Ausdrücke
Bemerkbarkeit des Testers
bzw. Angreifers
ja
Nein; es sei denn,
Google Hacking ist
der komplette Angriff
Abhängig von Suchmaschine
nicht direkt; ggf.
durch Rückschlüsse
aus
anderen
Informationen
eingeschränkt
auf
DOC, XLS, PDF,
PPT etc.
Beschränkung
auf
bestimmte Domains
bzw.
IPs
(Live
Search)
nein
möglich
leicht vermeidbar
direkt
Tabelle 5.1: Vergleich von Google Hacking und Vulnerability Scanning
52
Google, Yahoo Search und Live Search gleichermaßen nicht möglich. Bei automatisiertem 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 passiven Scanmethode vergleichbar. Der Umstand, dass ein Angreifer einen für ihn wertvollen Fund im Google-Index oder -Cache macht, wird vom potentiellen Opfer nicht
bemerkt, da zum Zeitpunkt des Fundes keine Daten von seinem Server abgerufen werden (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, AnonymisierungsDienste 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 Charakteristiken 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 System zu verstehen ist. Eine Idee hierfür, die in [BN] erwähnt wird, basiert auf Betrachtung der Erfahrungen mit der Wirksamkeit einer Sicherheits-Policy in der Vergangenheit. Man geht hier davon aus, dass sich der Grad an Sicherheit dadurch definiert, wieviele Sicherheitsschwächen nicht ausgenutzt worden sind, also möglicherweise nicht
ausgenutzt werden konnten. Vereinfachend gesagt: „Sicherheit = 100% aller Daten minus prozentualer Datenverlust durch Sicherheitsschwächen“. Mit Blick auf die Zukunft 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 GoogleHacking-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 festgelegt 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 Abwehr 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 allgemein 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 Abwehrrate
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 „Google Search Appliance“ oder „Google Mini“ verwendet. Diese erlaubt sowohl ständiges Indizieren des Web-Inhalts, als auch die ständige und (in Bezug auf die Anzahl
von Suchanfragen) unlimitierte Auswertung des relativ aktuellen Indexes. Die Grenzen der Aktualität liegen hier in der physischen Übertragungskapazität, bzw. Bandbreite, welche dem Webcrawler der eigenen Suchmaschine zur Verfügung steht. Bei solch
einer Strategie wird hinsichtlich aller bekannten Suchmuster eine höchstmögliche Erkennunggeschwindigkeit erreicht, womit die Voraussetzungen für eine größtmögliche
Abwehrrate geschaffen werden. Um diese zu erreichen, müsste allerdings eine sofortige 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 Falle 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 Crawler entwickeln und damit arbeiten; jedoch wäre es schwierig, die öffentlichen Suchmaschinen exakt zu simulieren, was mittels eines Google-Produkts leichter wäre. Das
Verhalten einer öffentlichen Suchmaschine möglichst genau nachzuvollziehen ist wichtig, 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äventiven 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 Verfü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 entsprechenden Google-Scans
Je länger diese Zeitdauer ist, desto angreifbarer das System. Ziel ist also die Minimierung 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 Abwehrrate 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 erreicht 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 kontrollieren, jedoch kann man sie erkennen – und zwar anhand ihrer IPs und/oder UserAgents. Alle IP-Adressen herauszufinden, von denen aus die Crawler operieren, ist
evtl. möglich; die Crawler anhand der User-Agents zu identifizieren ist jedoch einfacher und wahrscheinlich auch zuverlässig, da die großen Suchmaschinen sich so identifizieren 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 SuchmaSuchmaschine
Live Search
Google
Yahoo
User-Agent
MSNBot
Googlebot
Yahoo! Slurp
Tabelle 5.2: Die UserAgents der Suchmaschinen
schine sollte also sinnvollerweise unmittelbar nach dem Besuch ihres Crawlers (siehe 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 ITSystemen 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 SuchmusterDatenbasis auf die Abwehrrate
Es kann stets vorkommen, dass es Suchmuster gibt, mittels derer zwar ein Angreifer 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 eine vorhandene Verwundbarkeit nicht erkannt. Die Frage danach, wie viele von solchen 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-Sammlungen
• Analyse der eigenen Webseiten und Server-Software und Erstellen von Suchmustern 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. Hierbei wird zwischen Innen- und Außentäter unterschieden. Der Innentäter habe genaue
Kenntnisse über das angegriffene System, weshalb zum Simulieren seiner Möglichkeiten 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 beschrieben:
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 vorstellbar.
Bei einem Portscan werden auf der Netzwerk-Ebene Anfragen an die verschiedenen Ports bzw. Dienste eines Servers gesendet. Aus der Reaktion wird dann geschlossen, 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 Betriebssystem, Server und deren Versionsnummern.
Zur Identifikation von Schwachstellen werden im Penetrationtest persönliche Erfahrung, Exploit-Datenbanken und weitere Verfahren wie etwa Fuzzing benutzt. Ob
diese Schwachstellen auch wirklich ausgenutzt werden können, wird ebenfalls getestet.
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. Dazu 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 allen 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 Google 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ährend 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: Allein eine festgelegte Menge an Suchmustern zu verwenden, reicht nicht aus. Durch die
Untersuchung von Webseiten und Server-Software eines individuellen Systems müssen Suchmuster gefunden werden, durch welche typische Fehlermeldungen, LoginParameter 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 – unterschiedlich 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 Penetration Testing geschützt wird, ist der Sicherheitsgewinn – innerhalb bestimmter Grenzen – 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 Webservers 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 Fehlermeldungen
• Informationen über die Funktionsweise von Anwendungen, z.B. durch Fehlermeldungen
• 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 sichtbar sind
• ...nicht über das Web zugänglich sind
• ...zwar über das Web zugänglich sind, aber weder in einem ungeschützten Verzeichnis 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 Gegenüberstellung behandelt die Frage: Welche Sicherheitsschwächen können durch Google Hacking erkannt werden, die allein durch herkömmliches Vulnerability Scanning
nicht erkannt würden?
Vorfall
Aufdeckung
durch Google
Hacking
Vertrauliche Informationen in den Formaten HTML, Doc, Xls, ... sind über das Web
öffentlich zugänglich
ja
Es existieren im Internet Links mit integrierten Zugangsdaten
Fehlermeldungen oder Versionsinformationen von IT-Systemen sind auf öffentlichen Webseiten sichtbar
ja
Authentifikation voraussetzende Bereiche
mit Web-Oberfläche sind öffentlich zugänglich
ja
Es existieren im Suchmaschinen-Cache
sensible Informationen, die im realen System nicht mehr zugänglich sind
ja
ja
Aufdeckung
durch
Vulnerability
Scanning
ja; mit Ausnahme
von
SuchmaschinenCaches
nein
ja; mit Ausnahme
von
SuchmaschinenCaches
nur, falls Link
von innerhalb
des Systems
aus
nein
Tabelle 5.3: Vergleich von Google Hacking und Vulnerability Scanning bzgl. Mehrwerts durch Google Hacking
Hier sind die Stärken von Google Hacking deutlich erkennbar. Die im Anhang aufgeführten Beispiele zeigen teilweise, dass sich der Mehrwert von Google Hacking gerade 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 werden können, sind durch Google Hacking allein nicht durchführbar. Durch Google Hacking können nur – oder gerade – die Informationen recherchiert werden, die im weiteren 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 Penetration 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 Suchmaschine im Rahmen eines Penetration Tests nicht möglich ist, ist der Mehrwert durch
59
Zielsetzung
Durch Google Hacking
erreicht
Dauerhafte Überwachung der Web-Inhalte
von IT-Systemen
Entdeckung von Links mit integrierten Zugangsdaten od. SQL-Injection-Parametern
im Internet
Entdeckung von Fehlermeldungen oder
Versionsinformationen von IT-Systemen
auf öffentlich sichtbaren Webseiten
Entdeckung der öffentlichen Zugänglichkeit von Authentifikation voraussetzenden
Bereichen mit Web-Oberfläche
Entdeckung sensibler Informationen, die
im realen System nicht mehr zugänglich
sind, im Suchmaschinen-Cache
ja
Durch
Penetration
Testing
erreicht
nein
ja
evtl. ja
ja
evtl. ja
ja
evtl. ja
ja
evtl. ja
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 Bildern 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 geschü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 gesichert werden, in bestimmten Punkten einen Mehrwert. Um zu erkennen, ob es auch
gegen die beiden anderen Schutzmaßnahmen gleichzeitig – und evtl. einen daraus hervorgehenden Synergieeffekt – einen Mehrwert bietet, hier eine weitere Gegenüberstellung.
Durch die Gegenüberstellung in Tabelle 5.5 wird deutlich: Durch Vulnerability
Scanner (insbesondere solche wie WebInspect) können ähnliche Überwachungs-Aufgaben wie durch Google Scanning übernommen werden. Allerdings wird ein Vulnerability Scanner üblicherweise von einem unternehmenseigenen IT-System aus gestartet.
Die Perspektive des Webcrawlers einer Suchmaschine beinhaltet einen größeren Abstand 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
Entdeckung öffentlich über
das Web zugänglicher, vertraulicher Informationen in
den Formaten HTML, Doc,
Xls, ...
Entdeckung von Links im
Internet, die Zugangsdaten od. SQL-InjectionParameter enthalten
Entdeckung von im Web öffentlich sichtbaren Fehlermeldungen und/oder Versionsinformationen
Durch intervallbasierte Überwachung;
von Außen
Entdeckung der Zugänglichkeit von Authentifikation
voraussetzenden Bereichen
mit Web-Oberfläche
Durch intervallbasierte Überwachung
von Außen
Überprüfung der Existenz
von sensiblen Informationen
im Suchmaschinen-Cache
Dauerhafte Überwachung
der Web-Inhalte von ITSystemen
von Innen; evtl.
im Rahmen eines
Pentests
von Innen; evtl.
im Rahmen eines
Pentests
Evtl. im Rahmen eines Pentests
ja; Perspektive: von
Außen
ja; Perspektive: von
Innen
von Außen
von Außen
Vulnerability Scanning mit Penetration
Testing
von Innen; Von Außen evtl. im Rahmen
eines Pentests
Evtl. im Rahmen eines Pentests
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 jedem 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öglicherweise 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 („Return 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 Investition 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 abgeschä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 Angreifer 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 Funden 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 vergleichsweise geringen Investition in Google Hacking bzw. -Scanning verhindert werden – 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 „Nessus“, „QualysGuard“ und „WebInspect“ vorgestellt. Anhand dieser Beispiele wurden
Parallelen und Unterschiede zum Google Scanning untersucht, wobei sich einige theoretische und praktische Parallelen herausstellten, die Berücksichtigung von Suchmaschinen-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. Google Scanning. Hierzu wurde der Einsatz von Google Scanning im Rahmen von verschiedenen Ausgangssituationen betrachtet, in denen entweder überhaupt keine vergleichbare 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 Mehrwert, da es als regelmäßige, automatisierte Schutzmaßnahme – wie im herkömmlichen
Vulnerability Scanning – eingerichtet werden kann. Penetration Testing als Maßnahme 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 zeitnah 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 werden, 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 jedoch schon einen Eindruck davon vermitteln, welche Arten von potentiellen Ursachen
für finanzielle Schäden durch Google Scanning entdeckt und verhindert werden können. Aufgrund der nur geringen Investitionen, die für die Einrichtung eines dauerhaften 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ögli63
cherweise schon über einen längeren Zeitraum vorhanden sind und eventuell zu Schaden geführt haben. Um Schäden im Voraus zu vermeiden, sind präventive Abwehrmaß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 Kapitel 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 Abschnitt dieses Kapitels erläutert wird.
In den weiteren Abschnitten werden ergänzende Schutzmaßnahmen erläutert. Hierzu 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 überhaupt gefunden werden können. Hierauf wird im vorletzten Abschnitt dieses Kapitels
eingegangen.
Zusammenfassend wird im letzten Abschnitt eine Empfehlung zur Einrichtung eines dauerhaften Schutzes gegen Google Hacking gegeben.
6.2
Alarmsysteme
Ziel eines Alarmsystems sollte sein, eine eventuelle Lücke im Zugriffsschutz auf sensible 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 Suchmaschine, hat er keinen zeitlichen Vorsprung vor dem Hacker. Da man davon ausgehen
65
sollte, dass Hacker ebenfalls automatisierte Tools verwenden, ist ein zeitlicher Vorsprung 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 aktuellere Inhalte als die öffentlichen Suchmaschinen hat. Falls hierzu eine selbst entwickelte 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 Aktualitä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öglichkeiten zur Sicherung eines Systems hat, wird in Abschnitt 5.3.2 erläutert.
Dem Autor dieser Diplomarbeit stand allerdings kein Exemplar der Suchmaschinen 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 Basis 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 Indizierungsverbote 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 Suchmaschine 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 Suchmaschinen-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ücksichtigung 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 Suchmaschinen 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 aufzunehmen:
<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 angegeben 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 Website 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 haben sollen. Allerdings gibt es keine Garantie durch Google, dass die Anweisungen in
dieser Datei genau beachtet werden. Zudem bietet das Format keine Möglichkeiten, bestimmte 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
2
3
4
5
6
7
8
9
<? xml v e r s i o n = " 1 . 0 " e n c o d i n g = "UTF−8" ? >
< 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 " >
<url>
< l o c > h t t p : / / www. e x a m p l e . com / < / l o c >
< l a s t m o d >2005−01−01< / l a s t m o d >
< c h a n g e f r e q >monthly< / c h a n g e f r e q >
< p r i o r i t y >0.8</ p r i o r i t y >
</ url>
</ 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ögliche Werte:
– always
– hourly
– daily
– weekly
– monthly
– yearly
– never
Diese Werte dienen allerdings nur als Hinweis an Google. Dadurch ist nicht seitens Google garantiert, dass die Seite auch gemäß dieser Zeitabstände neu indiziert wird.
• <priority> (optional): Priorität der URL gegenüber anderen URLs in derselben Menge von URLs
Das Listing 6.1 einer beispielhaften sitemap.xml stammt aus der offiziellen Dokumentation der Google Webmaster Tools [goof]. Grundsätzlich ist eine sichere Konfiguration
der gesamten IT-Infrastruktur empfehlenswert, um auch gegen Google Hacking weniger 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 Falschinformationen
Webseiten lassen sich so präparieren, dass sie, sobald sie von einer Suchmaschine indiziert wurden, unter Verwendung von typischen Google-Hacking-Suchmustern gefunden werden. Dies ist im Wesentlichen der Ansatz des so genannten „Google Hacking
Honeypots“ [ghh]. Seiten, die exakt den Inhalt haben, der einem bestimmten Suchmuster 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/ / getAttacker () returns attacker profile
function getAttacker () {
$ A t t a c k e r = array ( ) ;
$ 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 ;
$ 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 ;
$ 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 ;
$ 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 ;
$ 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 ;
$ 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 ;
$ 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 ;
$ 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 ;
$ 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 ;
$ 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 ;
return $Attacker ;
}
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 Informationen, 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 Suchmaschine erkennbar sein, aber nicht für „normale“ Besucher der Website. Somit sollten Links
auf die Honeypot-Seiten unsichtbar innerhalb von sichtbaren Webseiten gesetzt werden. 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 diese 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 wirklich wertvoll für ihn sind. Auch ohne eine versteckte Honeypot-Funktion bieten Fehlinformationen den Nutzen, dass Angreifer sie bei geschickter Präparierung kaum von
wahrheitsgemäßen Informationen unterscheiden können, so dass in der Gesamtmenge 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 „Referer“ 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 Aufwand 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 Verwendung eines Webcrawlers
In [spi07] wird als wichtige Maßnahme zur Prävention von Informationslecks durch
Suchmaschinen empfohlen, einen eigenen Webcrawler zu verwenden, der alle WebAuftritte eines IT-Systems durchsucht und alle findbaren Informationen speichert. Diese 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 vollstä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ändigkeit 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 deswegen 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 Google Hacking beschrieben. Eine Möglichkeit, im präventiven Google Hacking einen
Vorsprung gegenüber potentiellen Angreifer zu haben, stellt hierbei eine unternehmenseigene Suchmaschine dar. Durch eine nicht-öffentliche und in ihrem Inhalt oft
aktualisierte Suchmaschine könnte also theoretisch eine Schutzvorrichtung eingerichtet 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 Angreifern 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ßnahme 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 Vergangenen Kapitel zusammengefasst und bewertet.
71
Kapitel 7
Zusammenfassung
Zu Beginn der Diplomarbeit wurde zunächst das Google Hacking in seinen Grundlagen 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 Öffentlichkeit 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 anderen 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 Kapitel beschrieben. Neben der Beschreibung von Vorbereitung und Durchführung eines
Google-Scans wurde gezeigt, auf welche Weise Ergebnisse dieses Vorgangs interpretiert werden können, und welche Maßnahmen im Einzelfall nach einem kritischen Fund
getroffen werden sollten.
Im folgenden Kapitel wurde die Implementierung eines automatisierten GoogleHacking-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 Kategorisierung dieser Funde stellt es eine Web-Schnittstelle zur Verfügung. Die GoogleSOAP-API bzw. „Google Webservices“ erwies sich für die Implementierung als nützlich, 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 unbeabsichtigter Veröffentlichung sensibler Daten, und somit für den Schutz von IT-Systemen.
Nach der Vorstellung von GooScanner wurde im Rahmen eines Vergleichs mit herkömmlichen Scanning-Methoden erörtert, welchen Mehrwert Google Hacking bzw.
-Scanning gegenüber anderen, üblichen Sicherungsmethoden hat. Hierzu wurden mehrere Ausgangslagen von IT-Systemen hinsichtlich ihrer Sicherheit mit- oder ohne Google-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 Vulnerability Scanning üblicherweise nicht gemacht werden; der Mehrwert gegenüber Penetration 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 Suchmaschine 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 ohne 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 Google 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 aufmerksam 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 Programm 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 empfehlenswert.
73
Anhang A
Quellcode aus GooScanner
A.1
1
2
Das Scheduling-Modul von GooScanner
<? php
/ ∗ 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
5
6
7
$ c u r r e n t D a t e = d a t e ( "Y−m−d " ) ; $ c u r r e n t T i m e = d a t e ( "G: i : s " ) ;
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 " ;
i n c l u d e _ o n c e " common / g e n e r a l . php " ;
set_time_limit (60000) ;
8
9
10
11
12
$ s q l = "SELECT ∗ FROM j o b WHERE j o b A c t i v e =TRUE" ;
$ j o b s _ r s = my_query ( $ s q l ) ;
$number_of_all_active_jobs = mysql_affected_rows ( ) ;
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
15
/ / 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 .
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
18
19
20
21
22
23
24
25
26
27
28
/ / I n f o r m a t i o n e n über e i n e n Job :
$jobKey = $ j o b _ d a t a s e t [ ’ jobKey ’ ] ;
$jobSearchMethod = $ j o b _ d a t a s e t [ ’ jobSearchMethod ’ ] ;
$jobCompanyName = $ j o b _ d a t a s e t [ ’ jobCompanyName ’ ] ;
$jobStartDate = $job_dataset [ ’ jobStartDate ’ ];
$jobStartTime = $job_dataset [ ’ jobStartTime ’ ] ;
$jobInterval = $job_dataset [ ’ jobInterval ’ ];
$jobQueriesPerConduct = $job_dataset [ ’ jobQueriesPerConduct ’ ] ;
$jobDescription = $job_dataset [ ’ jobDescription ’ ];
$jobLastDate = $job_dataset [ ’ jobLastDate ’ ] ;
$jobLastTime = $ j o b _ d a t a s e t [ ’ jobLastTime ’ ] ;
$jobForceNewStart = $job_dataset [ ’ jobForceNewStart ’ ] ;
74
29
30
31
32
33
34
35
36
37
38
/ / 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
$ s q l = "SELECT ∗ FROM j o b
INNER JOIN j o b _ h a s _ s c a n
ON j o b . jobKey = j o b _ h a s _ s c a n . jobKey
INNER JOIN s c a n
ON j o b _ h a s _ s c a n . scanKey = s c a n . scanKey
WHERE j o b . jobKey = ’ $jobKey ’ " ;
$ s c a n s _ r s = my_query ( $ s q l ) ;
$ 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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
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 ) ) {
$ n e w _ s c a n _ s h o u l d _ b e _ b e g u n = TRUE;
i f ( $jobForceNewStart ) {
echo "ACHTUNG: A u ß e r p l a n m ä ß i g e r S t a r t ! \ n " ;
$ 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 " ;
$ j o b F o r c e _ r s = my_query ( $ j o b F o r c e _ s q l ) ;
} / / i f ( $jobForceNewStart )
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 " ;
$ 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 ’ " ;
$ r s = my_query ( $ s q l ) ;
} / / 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 ) )
else {
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 " ;
$new_scan_should_be_begun = 0;
} // else
57
58
59
60
61
62
63
64
65
66
67
68
69
/ / 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 .
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) {
while ( $ s c a n _ d a t a s e t = mysql_fetch_array ( $scans_rs ,
MYSQL_ASSOC) ) {
/ / I s t d e r Scan a k t i v ?
i f ( $ s c a n _ d a t a s e t [ ’ s c a n A c t i v e ’ ] == 1 ) {
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 " ;
$scanKey = $ s c a n _ d a t a s e t [ ’ scanKey ’ ] ;
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 .
$new_scan_should_be_begun = 0;
} / / i f ( $ s c a n _ d a t a s e t [ ’ s c a n A c t i v e ’ ] == 1 )
else {
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
71
72
73
74
75
76
77
78
79
80
81
82
83
} // else
/ / 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 .
} / / while ( $scan_dataset = mysql_fetch_array ( $scan_rs ,
MYSQL_ASSOC) )
/ / 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 .
i f ( $ n e w _ s c a n _ s h o u l d _ b e _ b e g u n == 1 ) {
d o _ s c a n ( $jobKey , " " ) ;
} / / i f ( $ n e w _ s c a n _ s h o u l d _ b e _ b e g u n == 1 )
} / / 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)
else {
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 " ;
i f ( $ n e w _ s c a n _ s h o u l d _ b e _ b e g u n == 1 ) {
d o _ s c a n ( $jobKey , " " ) ;
} / / i f ( $ n e w _ s c a n _ s h o u l d _ b e _ b e g u n == 1 )
} // else
84
85
86
} / / while ( $job_dataset = mysql_fetch_array ( $jobs_rs ,
MYSQL_ASSOC) )
?>
76
A.2
1
2
3
4
Das Google-Scan-Modul von GooScanner
<? php
/ / Zur B e n u t z u n g d e r SOAP−API von Google
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 " ) ;
$ 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
9
10
11
12
$ 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 " ) ;
$ 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 ) ) ;
$const_queries_for_this_test = $all_queries_for_this_test ;
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 " ;
$queries_that_we_did_this_time = 0;
13
14
15
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 ++) {
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
18
/ / echo " $num_of_today_queries g r ö ß e r a l s 0 ? " ;
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
21
22
23
24
25
26
27
28
29
30
31
32
33
$currentUrl = $urls [ $urlIndex ] ;
$currentSearchstring = $searchstrings [ $searchstringIndex
];
$ p a r a m e t e r s = array (
’ 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
’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
’ 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
’ 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
’ 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
’ 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 "
’ 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
’ 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
’ i e ’ => ’ ’ , / / K o d i e r u n g d e r E i n g a b e
’ oe ’ => ’ ’ / / K o d i e r u n g d e r Ausgabe
);
34
35
36
37
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 ++) {
$parameters [ ’q ’ ] .= " −s i t e : " . $excluded_urls [
$exclUrlIndex ] ;
} / / 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
40
41
42
43
44
45
/ / 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 .
$ 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 " ,
quote_smart ( $currentUrl ) ,
quote_smart ( $currentSearchstring ) ,
q u o t e _ s m a r t ( $scanKey ) ) ;
$ 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
48
49
50
51
i f ( $do_this_query ) {
$ 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 ’
);
$ n u m _ o f _ t o d a y _ q u e r i e s −−;
$ q u e r i e s _ t h a t _ w e _ d i d _ t h i s _ t i m e ++;
} / / 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
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
if ( $google_result [ ’ faultstring ’ ]) {
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 ’ ];
}
e l s e i f ( $do_this_query ) {
/ / 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 .
$ r e s u l t D a t e = d a t e ( "Y−m−d " ) ;
$ r e s u l t T i m e = d a t e ( "G: i : s " ) ;
$searchstring = $currentSearchstring ;
$url = $currentUrl ;
$resultHits = $google_result [ ’
estimatedTotalResultsCount ’ ];
$ 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 ) " ,
quote_smart ( $resultDate ) ,
quote_smart ( $resultTime ) ,
quote_smart ( $searchstring ) ,
quote_smart ( $url ) ,
quote_smart ( $ r e s u l t H i t s ) ,
q u o t e _ s m a r t ( $scanKey )
);
$ r s = mysql_query ( $ s q l ) ;
i f (! $rs ) {
die ( mysql_error ( ) ) ;
} / / i f (! $rs )
$resultKey = mysql_insert_id ( ) ;
78
79
i f ( $ g o o g l e _ r e s u l t [ ’ estimatedTotalResultsCount ’ ] > 0) {
78
80
81
82
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 .
";
i f ( is_array ( $google_result [ ’ resultElements ’ ]) ) {
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
87
88
/ / 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 .
$ h i t U r l = $ c u r r e n t _ h i t [ ’URL ’ ] ;
$hitSnippet = $current_hit [ ’ snippet ’ ]; $hitTitle
= $current_hit [ ’ t i t l e ’ ];
89
90
91
$ 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 ’) " ;
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
i f ( m y s q l _ a f f e c t e d _ r o w s ( ) == 0 ) {
$ n e w _ h i t _ f o u n d = TRUE;
echo "NEU ! ! " ;
$hitEvaluated = 0;
$hitSuccess = 0;
$categoryKey = 0;
} / / i f ( m y s q l _ a f f e c t e d _ r o w s ( ) == 0 )
else {
echo " Schon mal g e s e h e n : " ;
/ / a b e r wie wurde d a s d a m a l s b e w e r t e t ?
$ 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) ;
$old_hitKey = $ r s _ d a t a s e t [ ’ hitKey ’ ] ;
$ 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 " ;
$ h o w _ r a t e d _ r s = my_query ( $ h o w _ r a t e d _ s q l ) ;
$how_rated_dataset = mysql_fetch_array (
$ h o w _ r a t e d _ r s , MYSQL_ASSOC) ;
$hitSuccess = $how_rated_dataset [ ’ hitSuccess ’ ] ;
$hitEvaluated = $how_rated_dataset [ ’
hitEvaluated ’ ] ; ;
$categoryKey = $how_rated_dataset [ ’ categoryKey ’
];
} // else
112
113
114
$hitTitle = $current_hit [ ’ t i t l e ’ ];
$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
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
(%s , %s , %s , %s , %s , ’ $ h i t E v a l u a t e d ’ , ’
$hitSuccess ’ , ’ $categoryKey ’) " ,
quote_smart ( $hitSnippet ) ,
quote_smart ( $hitUrl ) ,
quote_smart ( $ h i t T i t l e ) ,
quote_smart ( $hitCachedSize ) ,
quote_smart ( $resultKey )
);
$ r s = mysql_query ( $ s q l ) ;
i f (! $rs ) {
die ( mysql_error ( ) ) ;
} / / i f (! $rs )
} / / 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
)
} / / if ( is_array ( $google_result [ ’ resultElements ’]) )
} / / i f ( $google_result [ ’ estimatedTotalResultsCount ’] >
0)
else {
echo " − Kein H i t . " ;
} // else
} / / e l s e i f ( $do_this_query )
} / / 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 ) )
} / / 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 ++)
} / / 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
139
140
i f ( $ n u m _ o f _ t o d a y _ q u e r i e s <= 0 ) {
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 . " ;
} / / i f ( $ n u m _ o f _ t o d a y _ q u e r i e s <= 0 )
141
142
143
144
145
146
147
148
149
150
151
152
153
154
/ / 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 ) ?
i f ( $ a l l _ q u e r i e s _ f o r _ t h i s _ t e s t <= 0 ) {
$ 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 ) ) ;
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 . " ;
} / / i f ( $ a l l _ q u e r i e s _ f o r _ t h i s _ t e s t <= 0 )
else {
$ 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 ) ) ;
$ r s 2 = my_query ( $ s q l 2 ) ;
$number_of_conducted_queries = mysql_affected_rows ( ) ;
$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 ;
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 . " ;
} // 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
157
158
159
160
161
162
163
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 .
i f ( $ n e w _ h i t _ f o u n d == TRUE) {
$ 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" ;
$ 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 " ;
$ 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 " ;
mail_to_admin ( $ n ac h r ic h t ) ;
} / / i f ( $ n e w _ h i t _ f o u n d == TRUE)
?>
81
Anhang B
Fallbeispiele
B.1
Einleitung
Im Folgenden werden die IT-Systeme von vier großen Firmen aus der MobilfunkBranche durch Google Hacking überprüft. Um ggf. keine Informationen zu veröffentlichen, 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 Vorkommen 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 „IDToken1“, „IDToken2“ und „IDToken3“, in welche Kunden-ID, Passwort und MobilfunkRufnummer eingegeben werden sollten. Somit wurden als Suchmuster
• inurl:IDToken1
• inurl:IDToken2
• inurl:IDToken3
mit in die Sammlung aufgenommen.
Konfiguration des Jobs
Suchmaschine
Domains
Anzahl Anfragen pro
Domain und Scan
Verwendete Suchmuster
Startdatum
Intervall zwischen
Neustarts
Google
Live Search
Yahoo
3
1618
Inhalt der GHDB und an Firma 1 angepasste; insgesamt 1616
7 Tage
1 Tag
22.01.2007
1 Tag
Tabelle B.1: Konfiguration der Scan-Jobs für Firma 1
Analyse des ersten Scans
Google
Live Search
Yahoo Search
Treffer Insgesamt
14
39
56
Davon auffällig
2
12
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 waren 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 insgesamt 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 LoginPortale 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.
Scan 1
Scan 2
Scan 3
Scan 4
Scan 5
Scan 6
Scan 7
Google
14
0
0
0
0
0
0
Yahoo Search
90
0
0
0
0
0
0
Live Search
39
0
0
0
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 ungenaue Arbeitsweise von Yahoo Search zurückzuführen. Diese Ungenauigkeit wird auch
in den folgenden Teilen des Anhangs noch Ursache für viele Falschtreffer – oder unbeabsichtigte Zufallstreffer – sein. Weitere Falschtreffer sind auf Suchmuster zurückzufü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 Abbild der jeweiligen Seite.
Es wurde eine Subdomain gefunden:
• sms.firma1.de
84
Suchmuster
Suchmaschine
„Outlook Web Access“
inurl:login.asp
Google
Anzahl Treffer
7
Google
5
Live Search
Live Search
2
9
Live Search
20
Yahoo Search
56
inurl:bin.welcome.sh
|
inurl:bin.welcome.bat |
intitle:eHealth.5.0
inurl:name
(diverse)
Ursache
Vorkommen der Phrase auf
harmlosen Seiten
Dateiname von LoginPortalen für Kunden
Fehlfunktion
Search
von
Live
Seiten von Produktbeschreibungen enthielten diesen Parameter in der URL
Ungenauigkeit bei Auswertung der Suchparameter seitens 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ückschlüsse auf die Struktur der Web-Anwendungen zu.
Als kurzfristige Gegenmaßnahme wäre es für die Firma empfehlenswert, die Entfernung der Inhalte aus dem Suchmaschinen-Cache bei Google zu beantragen. Damit
die Inhalte auch bei Live Search entfernt werden, sollte eine robots.txt angelegt werden. 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 Abschnitt 4.3 zugrunde gelegt. Die Dauer pro Suchmaschine ergibt sich damit aus dem
Produkt der Anzahl der Suchmuster, der Anzahl von Domains und der durchschnittlichen Zeitdauer zwischen Anfrage und Antwort bei der jeweiligen Suchmaschine.
Dauer
Google
1593 × 2, 307s =
61, 25min
Live Search
1593 × 2, 412s =
64min
Yahoo
1593 × 1, 243s =
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 beachten, 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 verschiedene IP’s der Firma gefunden, wodurch wiederum zwei weitere Domains gefunden worden. Somit wurde der Test auf 4 Domains und 2 IPs erweitert.
In Login-Formularen auf den Homepages gab es Eingabefelder mit den Bezeichnungen „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 verwendete schon vorhanden waren.
Suchmaschine
Domains
Anzahl Anfragen pro
Domain und Scan
Startdatum
Intervall zwischen
Neustarts
Google
Live Search
3
1616
Yahoo
Inhalt der GHDB und an Firma 2 angepasste
22.01.2007
1 Tag
7 Tage
1 Tag
Google
Live Search
Yahoo Search
Treffer Insgesamt
7
50
42
Davon auffällig
0
0
0
Im ersten Scan ergaben sich insgesamt 105 Treffer, von denen aber keiner Auffälligkeiten zeigte.
87
Scan 1
Scan 2
Scan 3
Scan 4
Scan 5
Scan 6
Scan 7
Google
7
0
0
0
0
0
0
Yahoo Search
42
22
5
0
0
0
0
Live Search
50
0
1
1
2
0
0
Suchmuster
Suchmaschine
„Outlook Web Access“
inurl:name
Google
Anzahl Treffer
7
Live Search
3
(mehrere)
Live Search
23
Ursache
Vorkommen der Phrase auf
harmlosen Seiten
„name“ war ein Parameter von Webseiten, der allerdings nicht etwa UserNamen enthielt.
Anomalie von Live Search
Tabelle B.9: Falschtreffer bei Scans der Domains von Firma 2
Insgesamt waren nach 7 Durchläufen 130 Treffer zu bewerten, und es wurden 15 Subdomains gefunden.
Dauer
Google
1591 × 2, 307s =
61, 2min
Live Search
1591 × 2, 412s =
64min
Yahoo
1591 × 1, 243s =
33min
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 gefolgert 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 Rahmen 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 Bezeichnungen „loginName“ und „password“. Hieraus wurde das Suchmuster
inurl:loginName
abgeleitet. „inurl:password“ war als Suchmuster schon vorhanden.
Suchmaschine
Domains
Anzahl Anfragen pro
Domain und Scan
Startdatum
Intervall zwischen
Neustarts
Google
Live Search
3
1616
Yahoo
Inhalt der GHDB und an Firma 3 angepasste
22.01.2007
1 Tag
7 Tage
1 Tag
Google
Live Search
Yahoo Search
Treffer Insgesamt
4
30
96
Davon auffällig
0
0
2
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-Webserver. 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 wurde, 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 absolut auszuschließen, dass sich bei intensiverer Nachforschung ein Dekodierverfahren
finden würde. Als neues Suchmuster ergibt sich:
inurl:pwdhash
Scan 1
Scan 2
Scan 3
Scan 4
Scan 5
Scan 6
Scan 7
Google
4
0
0
0
0
0
0
Yahoo Search
96
24
8
0
0
0
0
Live Search
212
0
0
3
1
0
0
90
Suchmuster
Suchmaschine
„http://*:*@www“
domainname
Google
Anzahl Treffer
4
(username | userid |
employee.ID | „your
username is“)
(password | passcode
| „your password is“)
Live Search
5
Live Search
10
inurl:name
Live Search
3
Yahoo Search
10
intitle:admin
le:login
intit-
Ursache
Fehlerhaftes
Suchmuster.
Das Wort „domainname“ ist
nicht nötig.
Das Wort „username“ wurde
in vielen harmlosen Zusammenhängen gefunden.
Das Wort „password“ wurde ebenfalls in vielen harmlosen Zusammenhängen gefunden.
„name“ war ein Parameter von Webseiten, der allerdings nicht etwa UserNamen enthielt.
Wurde von Yahoo völlig
falsch interpretiert - Treffer
enthielten keins der genannten 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 Suchmuster aus der GHDB eine sehr allgemeine Ausrichtung haben – wie etwa die Suche
nach „username“ oder „password“. Allerdings ist die Sinnhaftigkeit solcher Suchmuster 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 besteht 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 Datei 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 unwahrscheinlich. Dennoch sollte der Kunde gebeten werden, den entsprechenden Link zu entfernen
und sein Passwort zu ändern. Langfristig sollte, um solche Vorkommnisse zu unterbinden, über eine Umstellung auf das „POST“-Verfahren nachgedacht werden.
Dauer
Google
1591 × 2, 307s =
61, 2min
Live Search
1591 × 2, 412s =
64min
Yahoo
1591 × 1, 243s =
33min
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 erkennbar, 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öglicherweise 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
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
http://www.icann.org,
[jap]
JAP - Anonymity & Privacy. http://anon.inf.tu-dresden.de/,
for
Assigned
94
Names
and
Features.
Numbers.
[liva]
Entfernen Ihrer Website aus dem Index der Live Search.
http://help.live.com/thinservice.aspx?project=wl_webmasters&mkt=dede&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=dede&querytype=topic&query=WL_WEBMASTERS_REF_GUIDELINESFOR
SUCCESSFULINDEXING.HTM,
[livd]
MSDN:
Getting
Started
with
the
Live
http://msdn2.microsoft.com/en-us/library/bb266187.aspx,
Search
API.
[Lon05] L ONG, Johnny: Google Hacking for Penetration Testers. Syngress Publishing, 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
http://www.qualys.com/products/qgent/features/,
&
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 Assessment
[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
Athena, 43
Referer, 70
Registrierungsschlüssel, 19
REST, 4
robots.txt, 32, 66
Datenmodell, 35
Fehlermeldung, 10
Fingerprinting, 51, 57
Sitedigger, 42
sitemap.xml, 25, 67
SOAP, 4, 43
SQL, 34
Suchmuster, 3
GHDB, 4, 23, 56
Google, 7, 15
Google Alerts, 44
Google Hacking Honeypot, 68
Google Mini, 54, 66
Google Search Appliance, 54, 66
Google Web Services, 43
Google-Cache, 16
Google-Scan, 19
gooscan, 42
Gooscanner, 34
User-Agent, 25, 55
Verzeichnisse, 8
Vulnerability Scanning, 18, 46
Webcrawler, 15
WebInspect, 50
Webserver, 11
Wikto, 43
HTML, 21
Yahoo Search, 14, 15
Idle Scanning, 51, 57
Internet Archive, 16
Zugangsdaten, 8
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

Unternehmensbezogenes Google Hacking

Transcription

Similar documents

METRIX – Die Zahl der Woche - Mercator Institute for China Studies

DB2Handle

Neuroforum 2/08 - Neurowissenschaftliche Gesellschaft