Google Hacking

SEMINARARBEIT
Seminar: Computernetzwerke (Sicherheitsfragen) LVA-Nummer: 353.063, WS 2005/2006

Eingereicht von:

Florian B. Wrter, 0156583, 521

Angefertigt am:

Institut fr Informationsverarbeitung und Mikroprozessortechnik (FIM)

Betreuung:

o. Prof. Dr. Jrg R. Mhlbacher, Dr. Gerhard Eschelbeck Linz, 12. Februar 2006
Seite 1 / 40

Inhaltsverzeichnis
1. Abstract.................................................................................................3 2. Einleitung...............................................................................................4 3. Geschichte von Suchmaschinen im Web.....................................................5 4. Funktionsweise von modernen Suchmaschinen............................................7 5. Google Hacking.......................................................................................9 5.1 Google...........................................................................................9 5.2 Erweiterte Operatoren von Google...................................................10 5.3 Google als Sprungbrett fr eine Attacke............................................17 5.4 Anonymitt durch Benutzen des Google Caches.................................19 5.5 Streng geheim..............................................................................21 5.6 Schutz vor Google Hackern.............................................................24 5.6.1 Verzeichnislisten und Standardeinstellungen...............................24 5.6.2 Schutz durch die Datei robots.txt...............................................24 5.6.3 Schutz durch Meta-Tags...........................................................25 5.6.4 Schutz durch Selbstkontrolle.....................................................26 6. Zusammenfassung.................................................................................28 7. Literaturverzeichnis................................................................................30 A1 Einige Beispielshacks.............................................................................31 A2 Zusammenfassung des Vortrages von Herrn Dr. Gerhard Eschelbeck...........37

Seite 2 / 40

1. Abstract
Google has become one of the most popular search engines over the last years. The good quality of it's search results is the main reason for it's popularity. Google startet as a search engine with a very simple user interface. Over the past years it became more and more sophisticated by offering new features such as advanced operators, caching and many more. The goal of this paper is to give a short overview of how most of the search engines work in general and how to use the advanced features of Google to perform tasks that are at the border of legality. You may be suprised how easy it is to anonymously gather sensitive information about websites and companies by just using Google.

Seite 3 / 40

2. Einleitung
In dieser Seminararbeit wollen wir uns mit dem Thema Google Hacking beschftigen. Dazu ist wichtig, dass man versteht, wie eine moderne Suchmaschine im Internet prinzipiell funktioniert. Wir werden uns deshalb, bevor wir uns dem Thema Google Hacking widmen, kurz die allgemeine Funktionsweise der gngien Suchmaschinen anschauen. Im grssten Teil dieser Arbeit werden wir uns mit den verschiedenen Aspekten des Google Hackings selber beschftigen. Abschliessend werden noch einige Methoden vorgestellt, wie man sein System vor Google Hackern schtzen kann. Durch das gezielte Anwenden nur weniger Tricks kann man das Risiko einer von Google gesttzten Attacke zum Opfer zu fallen schon verringern. Diese Arbeit soll keine Anleitung zum Hacken darstellen. Sie soll vielmehr Systemadministratoren auf das sowohl kritische als auch top aktuelle Thema Google Hacking sensibilisieren und ihnen helfen ihre Domains vor Angriffen zu schtzen.

Seite 4 / 40

3. Geschichte von Suchmaschinen im Web

Als der erste Vorfahre der heute gngigen Suchmaschinen kann Archie genannt werden, aber der erste wirklich bekannte Vertreter der Suchmaschinen war Veronica. Veronica war ein Programm, mit dessen Hilfe man Gopher durchsuchen konnte. Gopher war der Vorgnger des heutigen World Wide Web und wurde an der Universitt von Minnesota zur Vernetzung der Informationssysteme des Campuses verwendet. Als im Jahre 1993 der WWW-Standard freigegeben wurde, begann der Aufstieg des WWW zum grten Informationssystem der Welt. Im gleichen Jahr wurde von einem Studenten des MIT (Mathew Gray) der erste Webcrawler mit dem Namen The Wanderer entwickelt. Dieser Crawler durchsuchte und indizierte alle 6 Monate das Web. Im Oktober 1993 wurde Aliweb verffentlicht. Um von Aliweb indiziert zu werden, musste der Betreiber eines WWW-Servers eine bestimmte Datei auf seinem Server ablegen, in der die Dienste angegeben wurden, die auf diesem Server zur Verfgung standen. Die ersten wirklichen Suchdienste waren der World Wide Web Worm , Jum pStation und RBSE Spider. Alle drei wurden im Dezember des Jahres 1993 der ffentlichkeit prsentiert. JumpStation und der World Wide Web Worm waren Robots die Seiten ber ihre URL und den Seitentitel indizierten. RBSE Spider war der erste Suchdienst, der einen Rankingmechanismus verwendete. Im April 1994 wurde die Suchmaschine WebCrawler verffentlicht. Diese wurde ein Jahr spter an AOL verkauft und ein weiteres Jahr spter an Excite. Im Mai 1994 begann Micheal Mauldins mit der Entwicklung der Suchmaschine Lycos. Im Juli desselben Jahres wurde die Entwicklung abgeschlossen und im Web zur Verfgung gestellt. Lycos zhlte nicht nur Hufigkeit wie oft ein Begriff vorkam, sondern auch die Entfernung der Suchbegriffe zueinander in einem Dokument. Im Jahre 1994 wurde auch der erste Verzeichnisdienst von zwei Studenten der Stanford University, David Filo und Jerry Yang, ins Leben gerufen: Yahoo. Im Jahr 1995 wurden die ersten Suchmaschinen von kommerziellen Unternehmen entwickelt. Die Ergebnisse dieser Entwicklung waren Altavista, Infoseek und Architext (spter Excite). Seite 5 / 40

Ein Jahr spter wurde die Inktomi Corp. gegrndet, die von dieser Firma, unter demselben Namen, entwickelte Suchmaschine, wurde als Basis fr viele sptere Suchmaschinen verwendet. Als Beispiel kann HotBot genannt werden. Marktfhrer in diesem Jahr war Yahoo, aber auch Altavista wurde immer populrer. 1996 wurde mit MetaCrawler die erste Metasuchmaschine auf den Markt geworfen. Bis Google anfing den Markt zu bernehmen, galten Metasuchmaschinen als die besten Suchdienste, da in dem Index einer Suchmaschine nur Teile des WWW erfasst werden knnen und eine Metasuchmaschine ja eine Suchanfrage an mehrere Suchmaschinen weiterleitet und die Metasuchmaschine die Ergebnisse der Suchmaschinen kombiniert, was automatisch zu einem vollstndigeren Ergebnis fhrt. Ende 1998 wurde von Sergey Brin und Larry Page eine neuer Rankingalgorithmus namens PageRank vorgestellt [4]. Dieser Rankingalgorithmus ist auch die Basis der Suchmaschine Google [3], die im September des Jahres 1999 Beta-Status erreichte. Durch die Qualitt der von Google gelieferten Suchergebnisse und der im Vergleich zu anderen Suchmaschinen reltaiv kurzen Antwortzeiten wurde Google bald Marktfhrer. Im Jahre 2004 sind fast alle kleinen Suchmaschinen vom Markt wieder verschwunden und Google, Yahoo und MSN Search teilen den Markt unter sich auf.

Seite 6 / 40

4. Funktionsweise von modernen Suchmaschinen

Die heute gngigen Suchmaschinen bestehen aus folgenden Komponenten (Abbildung 3):

Spider Indexer inverser Index Datenbank Algorithmus Frontend /Schnittstelle zum Benutzer

Abbildung 1 Schematischer Aufbau einer Suchmaschine

Seite 7 / 40

1. Spider: Die Aufgabe einer Web-Spider ist das Besuchen von Webseiten und das Ablegen der besuchten Seiten in der Datenbank der Suchmaschine. Eine Suchmaschine verwaltet eine Liste mit den ihr bekannten URLs und falls die Spinne auf einer von ihr besuchten Seite eine URL findet die noch nicht in dieser Liste eingetragen ist, wird diese URL zur Liste hinzugefgt. Damit von den Suchmaschinen nicht jede Seite blind in den Index aufgenommen wird, hat man einen Mechanismus entwickelt mit dessen Hilfe WebseitenBetreiber das Verhalten von Suchmaschinen-Spiders steuern knnen. Dies geschieht mit Hilfe der Datei robots.txt. In dieser Datei kann ein Web-Master z.B. angeben, dass der Googlebot (Bot der Suchmaschine Google) die Seite kontakt.html (enthlt persnliche Daten) nicht besuchen darf. 2. Indexer: Das Indexer-Subsystem hat die Aufgabe, die von der Spider besuchten Seiten nach bestimmten Schlsselwrtern zu durchsuchen. Des Weiteren durchsucht er die gerade besuchte Seite nach Links auf weitere Seiten. Wenn weitere Links gefunden werden, werden diese in eine Liste eingefgt. Diese Liste enthlt die Seiten, die noch von der Spinne besucht werden sollen/mssen. Wenn diese Liste leer ist und von der aktuellen Seite keine Eintrge mehr in diese Liste eingefgt werden, ist der Crawlvorgang beendet. 3. Inverser Index: Wenn der Benutzer eine Suchanfrage startet, wird vom Inversen Index, die von der Suchmaschine verwaltete Stichwortliste nach den vom Benutzer eingegebenen Schlsselwrtern durchsucht und diejenigen Seiten zurckgegeben, in denen diese Schlsselwrter verkommen. 4. Relevanzbewertung (Rankingalgorithmus): Grundstzlich ist die Aufgabe dieses Teilsystems die Liste aufzubauen, die dann dem Benutzer nach Beendigung der Suche prsentiert wird. Die Bewertung wird mit Hilfe eines Rankingalgorithmus durchgefhrt. Eine bessere Relevanzbewertung resultiert in einer besseren Positionierung (salopp gesagt: weiter oben) in der Rckmeldung an den Benutzer. Fr genaueres bezglich Relevanzbewertung siehe unten. 5. Die Suchmaske: Die Suchmaske besteht typischerweise aus einem Textfeld in das der Benutzer die Suchkritieren fr seine Suche eingeben kann. In den meisten Fllen besteht Seite 8 / 40

auch noch die Mglichkeit eine erweiterte Suchmaske anzeigen zu lassen, mit deren Hilfe man komplexere Suchanfragen definieren kann.

5. Google Hacking
5.1 Google
Die Suchmaschine Google wird von der Firma Google Inc., die 1998 von Larry Page und Sergey Brin gegrndet wurde, betrieben. Google entwickelte sich auf Grund qualitativ hochwertiger Suchergebnisse und im Vergleich zu anderen Suchmaschinen schnelleren Antwortzeiten der Suchanfrage in nur wenigen Jahren zum Marktfhrer unter den Suchmaschinen. Im Jahr 2000 verfgte Google laut [1] verfgte Google im Dezember 2000 ber 6000 Prozessoren und 12000 Festplatten mit einer Gesamtkapazitt von ca. 1 Petabyte. Somit war Google das System mit der grssten Speicherkapazitt im zivilen Sektor. Im Gegensatz zu anderen Systemen verwendet Google keine grossen RAID Systeme. Vielmehr betreibt Google in den verschiedensten Lndern eigenstndige Rechenzentren, in denen relativ gnstige PCs mit Standardkomponenten zu einen Cluster zusammengeschlossen sind. Jedes Rechenzentrum ist eigenstndig und kann Suchanfragen anderer Rechenzentren bernehmen. In den Rechenzentren selber sind die Daten vielfach redundant auf verschiedenen PCs gespeichert. Sollte ein PC ausfallen, so wird ein Ersatzgert in den laufenden Betrieb eingehngt und die fehlenden Daten werden automatisch kopiert. Das so entstehende System ist sehr gut skalierbar, da bei Bedarf einfach neue PCs in den Cluster gehngt werden knnen. Als Betriebssystem wird bei Google eine modifizierte Version von Linux Red Hat verwendet. Programmiert wurde die Software vorwiegend in C, C++ und Python. Im April 2004 bestehen die Rechenzentren von Google bereits aus ber 63000 Rechner mit 127000 Prozessoren. Zusammengerechnet haben die Systeme ca. 127 Terabyte RAM und 5 Petabyte Festplattenkapazitt. Mittlerweile drften sich die Kapazitten wiederum vervielfacht haben.

Seite 9 / 40

5.2 Erweiterte Operatoren von Google

Die erweiterten Operatoren von Google helfen einen Suchenden seine Suche

einzuschrnken bzw. zu konkretisieren. Mit dem site Operator kann man zum Beispiel die Suche auf eine einzige Site einschrnken. Mit
press site:mydomain.com

durchsucht man zum Beispiel nur die Site mydomain.com nach Presseinformationen. Im allgemeinen werden Operatoren wie folgt verwendet:
operator:parameter

Operator und Parameter sind durch einen Doppelpunkt voneinander getrennt. Dabei ist es wichtig, dass der Parameter gleich nach dem Doppelpunkt folgt. Es drfen also keine Leerzeichen oder hnliches zwischen dem Operator, dem Doppelpunkt und dem Parameter stehen.Bei manchen Operatoren ist es mglich sie mit anderen kombiniert einzusetzen. Andere wiederum gestatten dies nicht. Sollte die eingegebene Syntax nicht stimmen, ist es gut mglich, dass Google eine Fehlermeldung ober den gefundenen Seiten anzeigt. Da man eine solche Meldung in der Regel leicht berliest, weil man gleich auf die Ergebnisse schaut, sollte man bei der Verwendung von erweiterten Operatoren besonders darauf achten, ob ober den gefundenen Ergebnissen eine Fehlermeldung steht und gegebenenfalls die Syntax korrigieren. Fr einen Operator gilt nur jener Parameter, der unmittelbar nach dem Doppelpunkt steht. Als Parameter kann man entweder ein einzelnes Wort oder eine Phrase verwenden. Die Phrase muss man jedoch wie gewohnt unter Hochkomma setzen. Auch hier darf zwischen ersten Hochkomma und Doppelpunkt kein Leerzeichen stehen. Mgliche Operatoren sind:

Intitle bzw. Allintitle Dieser Operator bercksichtigt bei der Suche nur den Seitentitel. Es werden also Seiten als Ergebnis geliefert, die den Parameter im Seitentitel enthalten. Der Titel einer Seite ist jener Text, der zwischen den TITLE Tags im HEAD einer HTML Seite steht. Beispielsweise erhlt man mit der Suche intitle:index alle Seiten, in deren Titel das Wort index vorkommt. Mit intitle:index of erhlt man alle Seiten, die im Titel die Seite 10 / 40

Phrase index of enthalten. Mit intitle:index of config files erhlt man alle Seiten, die im Titel die Phrase index of und zustzlich config files irgendwo auf der Seite stehen hat. Hierin liegt der Unterschied zwischen intitle und allintitle. Whrend intitle, wie wir gerade gesehen haben, nur den einen Parameter fr den Seitentitel akzeptiert, der direkt nach dem Doppelpunkt steht, verwendet allintitle alle folgenden Phrasen im Querystring. Hieraus sieht man auch, warum sich fast alle ALLOperatoren (also z.B. allintitle) nicht oder nur kaum mit anderen Operatoren in einer Suchanfrage gemeinsam verwenden lassen. allintitle:index of config files liefert eine Liste von Seiten, in deren Titel sowohl die Phrase index of als auch config files vorkommt.

Allintext Mit Hilfe dieses Operators kann man nur im Text eines Dokumentes suchen. Dies mag trivial erscheinen, ist es zugegebenerweise auch. Ohne Verwendung von Operatoren wird nach Suchbegriffen im Titel, in der Url, im Seitentext und in Links gesucht. Dieser Operator kann ntzlich sein, wenn man nach Dingen sucht, die nur im Seitentext selber vorkommen knnen oder drfen. Beispielsweise liefert die Suche allintext:Florian Wrter alle Seiten, in deren Text sowohl der Begriff Florian als auch Wrter vorkommt. Da es sich hier um einen ALL-Operator handelt, werden alle dem Operator folgenden Begriffe fr die Suche verwendet. Jedoch macht es einen kleinen Unterschied, ob man die Suchanfrage allintext:Florian Wrter oder allintext:Florian Wrter sucht. Bei ersterer werden alle Seiten wiedergegeben, die sowohl den Text Florian als auch Wrter enthalten. Die zweite Query sucht gezielt nach der Phrase Florian Wrter.

Inurl bzw. allinurl Eine URL (Uniform Resource Locator) dient im Internet dazu, eine Webresource eindeutig zu kennzeichnen. Sie besteht im allgemeinen aus dem Protokoll (z.B.: http, ftp https), gefolgt von dem String :// und einer Adresse. http://www.google.com ist beispielsweise eine solche URL. Sie beschreibt den Webserver von Goolge. Auch das ist eine URL: http://www.woerter.at/neu/about.html. Sie beschreibt nicht nur einen Webserver, sondern genau die Datei about.html, die im Unterverzeichnis neu liegt. Da HTTP ein zustandsloses Protokoll ist, ist man als Webseitenersteller oft dazu gezwungen gewisse Dinge als Seite 11 / 40

Parameter in der URL zu bergeben (wenn man GET verwendet). Das sieht dann beispielsweise so aus: http://www.woerter.at/neu/about.php?lang=en. Hierbei wird in der URL ein Parameter Namens lang definiert, dem der Wert en zugewiesen wird. Mit dem inurl Operator kann man nun, hnlich wie beispielsweise beim intitle Operator, die Suche auf die URL beschrngen. Dies mag auf den ersten Blick langweilig erscheinen, dennoch erffnet es viele n eue Mglichkeiten. Zum Beispiel kann man mit inurl:config.php.bak site:mydomain.com berprfen, ob des die Datei config.php auf der Domne mydomain.com gibt. Falls ja, hat man gute Chancen darin sensible Informationen ber die Website (z.B. Datenbankbenutzername, -passwort) zu finden. Wie wir es mittlerweise von den ALL-Operatoren schon gewhnt sind, knnen wir mit Hilfe von allinurl nach mehreren Begriffen in einer URL suchen.

Site Mit Hilfe des site Operators knnen wir unsere Suche auf eine Site einschrnken. Er lsst sich ausgezeichnet mit anderen Operatoren kombinieren. z.B.: intitle:New Document site:microsoft.com liefert alle Dokumente von der Domne microsoft.com, bei denen vergessen wurde einen Namen zu vergeben.

Filetype Dieser Operator ermglicht es uns nach bestimmten Dateitypen zu suchen. Suchen wir zum Beispiel nur PDF Dateien, so formulieren wir unsere Suche wie folgt: filetype:pdf userliste. So wird jedes PDF Dokument geliefert, das den Begriff Userliste enthlt. Natrlich kann dieser Operator sehr gut mit anderen Operatoren kombiniert verwendet werden. Der Typ wird auf Grund der Dateiendung in der URL bestimmt.

Link Mit Hilfe dieses Operators kann man nach Verlinkungen zu einer Adresse suchen. Als Parameter wird kein Suchstring, sondern eine Webadresse erwartet. Geliefert werden Seiten, die zu dieser Adresse verlinken. Es wird dabei nicht im Text des Links, der auf der Seite angezeigt wird, gesucht,m sondern im href Parameter des Links selber. Mit link:linux.org sucht man beispielsweise nach Seiten, die auf die Site linux.org verlinken.

Seite 12 / 40

Inanchor Dieser Operator wird hufig mit dem link Operator verwechselt. Er verwendet fr die Suche nmlich nur den Text und nicht die eigentliche Adresse des Links. Beispielsweise liefert inanchor:home alle Seiten, bei denen ein Link mit dem Namen Home existiert.

Cache Wenn Google eine Website besucht, so speichert der Bot die aktuelle Version der Seite im sogenannten Google Cache (mehr dazu spter). Will man sich anschauen, wie sich eine Website dem Googlebot bei seinen Besuch prsentierte, so schreibt man beispielsweise cache:www.woerter.at in die Zeile fr den Suchstring. Alternativ knnte man auch anders nach der gewnschten Seite suchen und bei der Ergebnisdarstellung auf Cache klicken. Mit Hilfe dieses Operators erspart man sich den Zwischenschritt. Wichtig ist, dass man eine korrekte URL angibt, Tut man das nicht, so startet Google eine normale suche nach den Worten cache und dem Suchstring. Auch zu beachten ist, dass dieser Operator nicht mit anderen kombiniert werden kann.

Numrange Mit diesem Operator kann man nach Zahlen suchen, die in einen bestimmten Bereich liegen. Den Bereich gibt man mit zwei durch einen Bindestrich vetrennte Zahlen an. Um beispielsweise Zahlen im Intervall zwischen 950 und 1000 zu suchen, so wrde man numrange:950-1000 als Suchstring formulieren. Will man sich nicht die Mhe machen den Operator auszuschreiben, so gibt es auch eine Kurzform dafr. Bei der Kurzschreibweise trennt man den Bereich einfach durch zwei aufeinanderfolgende Punkte und lsst den eigentlichen numrange Operator weg. Die Query 950..1000 wrde beispielsweise das selbe Ergebnis wie die obige Suche liefern.

Daterange Dieser Operator findet Seiten, die in einen gewissen Datumsintervall vom Google Bot indiziert wurden. Dies sagt nicht direkt etwas ber die Aktualitt der Seite aus. Jedoch ist es so, dass der Google Bot versucht, Seiten, die sich hufig ndern, fter zu besuchen. So kann man mit diesen Operator beispielsweise die Suche auf aktuelle Seiten beschrnken, was sich als sehr praktisch erweisen kann. Einen Haken gibt es jedoch: Das Datum muss als Zahl des Julianischen Kalender angegeben werden. Dies entspricht der Seite 13 / 40

Anzahl der Tage seit dem 1. Jnner 4713 v. Ch. Es gibt jedoch Tools im Internet, die das Umrechnen von Daten in den Julianischen Kalender recht einfach machen [7]. Will man sich das nicht antun, so sollte man das Webinterface der erweiterten Suche auf der Google Homepage verwenden. Beispielsweise liefert der Suchstring daterange:2452165-2452164 osama bin laden alle Seiten, auf denen der Name Osama Bin Laden vorkommen, und die am 11. September 2001 vom Google Bot indiziert wurden. Wir sehen hier, dass man den selben Tag zweimal schreiben muss, wenn man nach einem Datumsbereich von nur einen Tag suchen will. Der daterange Operator muss immer mit mindestens einer zustzlichen Suche kombiniert werden, sonst werden keine Ergebnisse geliefert.

Info Dieser Operator zeigt Informationen zu einer Site an. Die gewnschte Site wird als Parameter bergeben. Im Prinzip wird das gleiche Ergebnis geliefert, als wenn man nur die URL selbst als Suchstring verwendet htte. Wichtig ist, dass man die genaue URL als Parameter bergibt, da die Query sonst als normale Suche verwendet und der Operator somit ignoriert wird.

Related Dieser Operator ist im Stande Seiten als Ergebnis zu liefern, die der im Parameter bergebenen Seite hnlich sind. Dies funktioniert mehr oder weniger gut. Wird keine gltige Seite oder Hostname eingegeben, so liefert die Suche irgendwelche Ergebnisse oder ignoriert den Operator einfach. related:www.orf.at liefert beispielsweise Seiten, die der bergebenen Seite hnlich sind. Konkret fr dieses Beispiel werden Seiten von Tageszeitungen und Informationsplattformen geliefert.

Author Dieser Operator wird beim Durchsuchen von Newsgroups verwendet. Dabei werden jene Nachrichten gefunden, deren Autor Angabe den Suchstring enthlt. Als Parameter kann entweder ein Name oder eine Email-Adresse bergeben werden. Wenn man zum Beispiel nach author:florian sucht, findet man massenweise Beitrge, die von einen Florian verfasst wurden. Probleme macht jedoch folgende Suche: author:florian woerter. Hier bricht der author Operator mit der Konvention. Er liefert Beitrge, in deren Seite 14 / 40

Autor zwar Florian vorkommt, der Begriff Wrter wird jedoch im Text gesucht. Das scheint ein Bug von Google zu sein. Jedenfalls funktioniert die Suche mit author:florian.woerter ohne Probleme. Dieser Operator kann mit Suchstrings oder anderen Operatoren kombiniert werden, die bei der Suche unter Google Groups gltig sind.

Group Mit dem group Oprator kann man in Titeln von Groups suchen. Wie der vorherige Operator funktioniert dieser Operator auch nur in der Google Groups Suche. Jedoch wird nicht nur in den Titel gesucht, sondern auch in den Keywords, die der Administrator einer Newsgroup festlegen kann. group:*.forsale liefert zum Beispiel alle Gruppen, deren Name mit forsale endet. Dieser Operator funktioniert sehr gut, wenn man ihn alleine verwendet. In Verbindung mit anderen Operatoren kommt es hufig zu Problemen.

Insubject Dieser Operator sucht in den Betreffen der Newsbeitrge. Da diese mit den Titeln der Newsbeitrge ident sind, liefert eine Anfrage mit intitle die gleichen Ergebnisse wie insubject. insubject:mfc liefert alle Newsbeitrge, deren Betreff das Wort Mfc beinhaltet.

Msgid Findet eine Newsnachricht anhand ihrer eindeutigen Id. Jeder Newsgroupbeitrag hat eine eindeutige Id der Form xxx@domain.com wobei xxx ein fr die Lebensdauer der Nachricht auf der Domain eindeutiger String ist. Domain.com wird natrlich durch die eigentliche Domain ersetzt, auf der der Beitrag erschienen ist.

Stocks Dieser Operator liefert Informationen und Kurswerte zu Aktien. Als Parameter dient die der Ticker Name einer Aktie. Zum Beispiel liefert die Suche stocks:CISCO Informationen ber die Aktie von Cisco MicroSystems.

Phonebook / rphonebook / bphonebook Dieser Operator versucht nach Namenseintrgen in Telefonbchern zu suchen. Wenn

Seite 15 / 40

man nur nach Privatpersonen suchen will, so verwendet man rphonebook. Sucht man nur Geschfte (Gelbe Seiten), so verwendet man am besten bphonebook. Ist man sowohl an Privatpersonen als auch an Geschften interessiert, so sollte man den Operator phonebook verwenden. Zum Beispiel liefert der Befehl phonebook:john smith ny alle Firmen und Privatpersonen, die in New York sesshaft sind und John Smith heissen. Zustzlich kann man bestimmte Suchausdrcke mit den Sonderzeichen +, |, OR, &, AND, -, . oder * miteinander verknpfen. + bedeutet dabei dass nur Seiten geliefert werden, die auch den nach dem Plus stehenden Begriff enthalten. Man kann auch Boolsche Ausdrcke in die Suche einbinden (|, OR, &, AND). Ein Minuszeichen bedeutet dass das angegebene Wort nicht vorkommen darf. Setzt man mehrere Suchausdrcke unter gemeinsame Anfhrungszeichen, so wird nicht nach den einzelnen Worten, sondern genau nach dieser Wortgruppe gesucht. Ein Punkt bedeutet ein Einzelzeichen-Wildcard. Ein Stern bedeutet, hnlich wie bei den meisten Shells, ein Wildcard fr kein oder beliebig viele Zeichen.

Seite 16 / 40

5.3 Google als Sprungbrett fr eine Attacke

Die Bedeutung von Google im Bezug auf Hacking liegt nicht direkt beim eigentlichen Angriff einer Website. Jedoch kann man mit der Hilfe von Google vor dem Angriff ganz bequem, legal und unter Bentzung des Google Caches auch einigermassen anonym wichtige Informationen ber das Ziel finden, die unter Umstnden den Angriff erst ermglichen. So kann man mit der Suche nach Verzeichnislisten oder Fehlermeldungen beispielsweise die genaue Version des Webservers ermitteln. Alle Webserver haben ein bestimmtes Layout fr ihre Fehlermeldungen. Sucht man nach solchen Standardfehlermeldungen kann man leicht die Version des Webservers eroieren. Umgekehrt kann man sich mit einer Einfachen Suche nach dem genauen Versionsstring eines Webservers eine Liste von Domains ausgeben lassen, die einen solchen Server verwenden. Weiss man, dass diese Serverversion eine Schwachstelle hat, so kann man diese gezielt nutzen. Auch spielt Google eine wichtige Rolle beim Herausfinden von Benutzernamen und Passwrtern. Wie wir beim Finden von Verzeichnislisten (mehr dazu bei 5.5 Streng geheim) noch sehen werden, kann man mit einfachen Abfragen Dateien mit Benutzernamen und teilweise sogar Passwrter finden. Hat man einen Benutzernamen gefunden, ist das schon die halbe Miete. Man knnte sich beispielsweise eine Social Engineering Attacke vorstellen. Diese knnte man durch vorherige Google Recherchen sttzen und so leicht an vertrauliche Informationen gelangen. Unter Social Engineering versteht man das Beschaffen von geheimen Daten durch soziale Kontakte. Man knnte sich beispielsweise vorstellen, dass man ber Google erfhrt, dass Herr Maier den Benutzernamen maier78 hat. Zustzlich findet man heraus, dass seine Frau Melissa heisst und dass er einen Hund besitzt. Nun knnte man beispielsweise in seiner Firma anrufen und sich bei der Sekretrin als Herr Maier ausgeben. Man knnte beispielsweise erklren, dass er ganz durcheinander ist, weil seine Frau Melissa

Seite 17 / 40

gerade ein Baby bekommen hat. Er msse aber noch dringend bers Wochenende einen Bericht fertigstellen und hat in der ganzen Aufregung sein Passwort vergessen. Dieses Szenario mag jetzt etwas geknstelt und unrealistisch erscheinen, doch gibt es ganze Bcher ber verschiedene Social Engineering Angriffstaktiken. Solche Attacken erweisen sich in der Praxis als beraus erfolgreich. Sie sind umso erfolgreicher, je mehr man ber sein Opfer weiss und dabei hilft uns Google ungemein. Ausserdem ermglicht Google das bequeme Finden von Systemen, die auf eine gewisse Angriffstechnik verwundbar sind, oder andere sensible Informationen enthalten. Frher hat ein Angreifer eher Systeme attackiert, gegen die er persnlich etwas hatte. Heute kann ein Systemadministrator von nahezu jedem Angreifer attackiert werden, wenn dieser sein System in einer Google Suche als Ergebnis erhlt. Andererseits kann man mit Hilfe von Google ganz einfach Angriffcode finden. Die Suche vulnerable exploit oder remote exploit liefert viele solcher Angriffscodes. Auch gibt es viele fixfertige Tools, die man fr bestimmte Servreversionen einsetzen kann. Hat man den Angriffscode erstmal gefunden, ist das Finden von Opfern, wie wir oben gesehen haben, kein grosses Problem mehr.

Seite 18 / 40

5.4 Anonymitt durch Benutzen des Google Caches

Wenn der Google Bot eine Seite besucht, wird eine Kopie dieser Seite, so wie sie ihm dargeboten wird, im sogenannten Google Cache gespeichert. Sie bemerken das zum Beispiel wenn sie auf der Ergebnisseite den Link Im Cache sehen. Durch diesen Mechamismus kommen bzw. bleiben Informationen im Netz verfgbar, auch wenn man auf dem Webserver die Seite schon lange offline gegeben hat. Wie wir spter sehen werden kann man verhindern, dass Google eine Kopie der eigenen Website im Cache ablegt bzw. kann man nachtrglich eigene Seiten aus dem Cache entfernen lassen. Wenn ein potentieller Angfreifer den Cache von Google verwendet, so kann er Informationen von Ihrer Seite abrufen, ohne auch nur ein einziges Datenpaket an Ihren Webserver zu senden. Dadurch bleibt der Angreifer sozusagen anonym. In der Regel ist es so, dass der Webserver Betreiber nach einen Angfriff auf den Server in den Log-Dateien nachschaut, welche IP verdchtig oft auf den Server zugegriffen hat. Dadurch, dass der Angreifer jedoch die Informationen aus dem Google Cache bezogen und somit auf den Webserver gar nicht zugegriffen hat, werden Sie nie erfahren, wer nun wirklich Ihren Server angegriffen hat. Wenn wir jedoch auf den Im Cache Link auf der Ergebnisseite klicken und nebenbei unseren TCP Verkehr berwachen, so werden wir feststellen, dass trotz der Cache Version eine Verbindung zum Zielwebserver aufgebaut wird. Warum ist das so? Nun, Google versucht Dinge, die nicht im Cache sind, automatisch nachzuladen und kontaktiert deshalb den Webserver. Mehr noch, Google teilt dem Webserver sogar mit, dass wir die Website ber den Google Cache betrachten wollen. Dies ist fr unsere Anonymitt natrlich nicht sehr frderlich. Deshalb werden wir einen kleinen Trick verwenden. Der Trick besteht darin, dass man nicht direkt auf den Im Cache Link klickt, sondern seine Adresse in die Zwischenablage kopiert. Diese Adresse fgen wir nun in der Adressleiste des Browserfensters ein und hngen zustzlich den Parameter &strip=1 an die URL. Seite 19 / 40

Dadurch teilen wir Google mit, dass es die Resourcen, die nicht im Cache gespeichert sind, einfach nicht anzeigen soll. Wie Ihnen ein Netzwerkberwachungsprogramm besttigen wird, wird nun tatschlich keine Verbindung zum Zielrechner hergestellt. Das faszinierende dabei ist dass man so auf vllig legale Art und Weise auf sensible Daten eines Webservers zugreifen kann, ohne dass man auch nur ein Byte an diesen zu schicken braucht. Google macht's mglich.

Seite 20 / 40

5.5 Streng geheim

Viele Administratoren lassen aus Faulheit oder aus Unwissenheit Dateien auf ihren Webservern liegen, die nicht unbedingt fr die ffentlichkeit gedacht sind. Oft vergessen sie aber auch Rechte zu setzen oder nicht zu setzen, sodass ein anonymer Besucher zum Beispiel Verzeichnisse durchblttern kann. Man sollte, wenn sie nicht unbedingt bentigt wird, daher die Browse-Berechtigung stets verweigern. Das Problem ist nmlich, dass der Google Bot, wie auch jeder andere Besucher der Website, die Verzeichnisse durchschauen kann und die Ergebnisse seiner Auswertung jeden Benutzer der Suchmaschine zur Verfgung stellt. Das Hauptproblem an solchen Verzeichnislisten ist, dass sie immer gleich oder zumindest hnlich aussehen. So erhlt man mit der Suchanfrage intitle:index.of eine ganze Reihe von solchen Verzeichnislisten, da in ihren Titeln in der Regel ein String steht, der mit Index Of beginnt. In folgener Abbildung sehen wir ein Beispiel einer solchen Verzeichnisliste.

Seite 21 / 40

Wie wir sehen, befindet sich in einer solchen Auflistung der Inhalt des Webserververzeichnisses. nach Unter anderen entdecken findet wir eine eine ganze Datei, Liste die mit passwords.xls heisst. Was da wohl drin steht? Eine gezielte Google Befragung intitle:index.of +passwords.xls

Verzeichnissen, in denen Passwrter gespeichert sind. Jedoch kann man das durchaus erweitern. So kann man zum Beispiel nach Konfigurationsdateien fr bekannte Dienste suchen und diese auswerten. Oft sind darin fr einen Angreifer interessante Informationen zu finden. Fr einen Angreifer kann es auch interessant sein ein bestimmtes Verzeichnis zu finden. Ein Administratorverzeichnis knnte er beispielsweise mit intitle:index.of.admin finden. Wenn man sich die Verzeichnisliste nochmal anschaut, stellen wir fest, dass sich noch einige zustzliche Informationen darauf befinden. So knnen wir aus einer solchen Liste von Dateien zum Beispiel die genaue Webserverversion erfahren. Im obigen Fall handelt es sich beispielsweise um den Webserver Apache/1.3.33 Server. Zustzlich wissen wir seine genaue Domain und dadurch auch seine IP Adresse. Wir knnten also nun seelenruhig nach verschiedenen Angriffscodes fr einen solchen Webserver dieser Version suchen und anschliessend eine Attacke auf diesen Server starten. Aber nicht nur mit Verzeichnislisten kann man ntzliche Dateien finden. Auch wenn ein Administrator das Browse-Recht entfernt hat, so kann man dennoch bestimmte Dateien finden. Zum Beispiel mit der Suche filetype:log

inurl:install.log. Damit wrde man eine Logdatei finden, die vielleicht Informationen ber Benutzernamen oder hnliches in sich birgt. Sucht man gezielt nach Konfigurationsdateien, so kann es oft auch ntzlich sein, ein .bak an ihren Namen anzuhngen. Damit wrde man Backups von Konfigurationsdateien finden, die oft nicht so gut geschtzt sind wie ihr Original, meistens aber die selben Informationen beinhalten. Einen weiteren Vorteil bietet Seite 22 / 40

dieser Trick, wenn man nach Informationen in .php Dateien sucht. Oft werden Verbindungspasswrter und globale Variablen in einer Datei namens config.php gespeichert. Will man diese Datei jedoch abrufen, so wird sie, bevor man sie am Webbrowser sieht, vom Webserver abgearbeitet und man erhlt nur das Ergebnis angezeigt. In diesen Ergebnis ist nichts mehr zu sehen von Passwrtern oder Benutzernamen. Sucht man jedoch nach Sicherungen von solchen Dateien, zeigen die Webbrowser eine Textdarstellung des php Codes an, und die Benutzernamen und Passwrter knnen in Klartext gelesen werden. Die Suche intitle:index.of +config.php.bak wrde beispielsweise solche

Sicherungsdateien anzeigen.

Seite 23 / 40

5.6 Schutz vor Google Hackern

Wie wir gesehen haben gibt es sehr viele verschiedene Tricks, Informationen von einer Website zu erhalten, die einen potentiellen Angreifer ntzen knnten. Das allerwichtigste beim Schutz vor Google Hackern ist, dass der Administrator den Webserver nicht als sicheren Datenspeicher erachtet und dass er nicht an die Gutmtigkeit der Internetbenutzer glaubt. Sensible Informationen gehren nicht auf einen ffentlichen Webserver. Diese kann man am Besten auf einen internen Server speichern, auf den nur befugte Personen Zutritt haben. Diesen Personen muss man klar machen, dass sie diese Daten unter keinen Umstnden, auch nicht temporr, auf den Webserver kopieren drfen oder es ihnen von vorn herein durch setzen der entsprechenden Berechtigungen verbietet.
5.6.1 Verzeichnislisten und Standardeinstellungen

Bei der Konfiguration von Webservern ist es wichtig die Features abzudrehen, die nicht bentigt werden. So sollte man das Directory Browsing unbedingt unterbeinden, wenn man es nicht dringend bentigt. Auch sollten bei der Konfiguration von allen Systemen (inklusive Datenbanken) unter keinen Umstnden Standardbenutzernamen und/oder Passwrter verwenden. Auch sollte man nicht eine einfache Abnderung solcher Benutzernamen oder Passwrter verwenden, da diese oft leicht zu durchschauen sind.
5.6.2 Schutz durch die Datei robots.txt

Um zu verhindern, dass Webcrawler gewisse Bereiche Ihrer Site durchforsten, kann man eine Datei in das Root Verzeichnis des Webservers legen, die laut Konvention robots.txt heissen muss. In Ihr kann man Anweisungen an die einzelnen Webcrawler richten. Im ursprnglichen Standard sind die Befehle useragent und disallow erlaubt. Zustzlich wird eine Zeile als Kommentar ignoriert, wenn sie mit # beginnt. Hier sehen wir ein Beispiel fr eine robots.txt Datei:

Seite 24 / 40

user-agent: Googlebot Disallow: /

In dieser Datei wird dem Googlebot (der Suchspider von Google) es nicht gestattet, ab dem Root Verzeichnis die Site zu durchsuchen und indizieren. Wenn man ein Sternzeichen als User-Agent angibt, bedeutet das, dass man sich auf alle Useragents bezieht. Wichtig zu wissen ist dabei, dass sich ein Webcrawler an diese Konventino halten kann (alle Crawler von grsseren Suchmaschinen tun das auch), aber nicht daran halten muss.
#robots.txt fr meine Site User-Agent: * Disallow: / #Googlebot darf zugreifen User-Agent: Googlebot Disallow:

In der obigen Datei erlauben wir das Crawlen unserer Website nur dem Googlebot. Indem wir nach dem Disallow: in der selben Zeile nichts mehr schreiben, erlauben wir alles. Zustzlich zum herkmmlichen robots.txt Standard erlaubt Google einige

Erweiterungen. So sind im Disallow auch Wildcards mglich, die fr eine beliebige Anzahl von Zeichen stehen. Man knnte zum Beispiel mit Disallow: /*.pdf$ dem Googlebot verbieten, die pdf Dateien zu crawlen. Das $ Zeichen am Ende steht fr das Ende des Strings. Eine zustzliche Erweiterung von Google.
5.6.3 Schutz durch Meta-Tags

Mit Hilfe der robots.txt Datei knnen Crawler, die sich an die Konvention halten, von der Site ferngehalten werden. Es gibt jedoch noch zustzliche Mechamismen in Form von Meta-Tags, um Webcrawler zu steuern. Meta-Tags befinden sich im HEAD einer HTML Seite und besitzen einen Namen und einen Wert. Man kann sie somit als spezielle Konstanten betrachten.
<META NAME=creator CONTENT=florian woerter />

Seite 25 / 40

Im obigen Beispiel wrde man im Meta-Tag eine Konstante namens creator anlegen, der man den Wert florian wrter zuweist. Durch das Verwenden von solchen Meta-Tags kann man fr jede Seite einzeln steuern, wie sie vom Googlebot behandelt werden soll, anstatt dies in der robot.txt fr das gesamte Verzeichnis zu tun. Nun kann man bestimmten Webcrawlern durch die Definition von solchen Konstanten Befehle erteilen. Wenn man zum Beispiel verhindern will, dass Google ein Dokument in den Cache gibt, so erstellt man folgenden Meta-Tag:
<META NAME=GOOGLEBOT CONTENT=NOINDEX, NOFOLLOW />

Damit weist man den Googlebot an, die aktuelle Seite nicht in den Cache zu speichern. Es gibt eine allgemeine Konvention in Bezug auf Cachen von Webseiten:
<META NAME=ROBOTS CONTENT=NOARCHIVE />

Damit verhindert man, dass jeder Crawler, der sich an die Konvention hlt, diese Seite archiviert. Mit dem Meta-Tag NOSNIPPET kann man Google daran hindern, kleine

Ausschnitte der Site in der Google-Zusammenfassung unter dem Suchergebnis anzuzeigen. In der Regel wird beim Anzeigen eines Suchergebnisses direkt unter dem Link zur Seite eine kurze Zusammenfassung angezeigt. Will man dies verhindern, so definiert man folgenden Meta-Tag:
<META NAME=GOOGLEBOT CONTENT=NOSNIPPET />

Interessanterweise verhindert dieser Tag auch, dass Google eine Kopie dieser Seite im Cache speichert.
5.6.4 Schutz durch Selbstkontrolle

Das allerwichtigste beim Schutz vor Google Hackern ist jedoch, dass sie regelmssig berprfen, welche Informationen von Ihrer Website von Google gefunden werden. Probieren Sie am besten die verschiedenen Attacken auf Ihre

Seite 26 / 40

Site aus, indem Sie mit Hilfe des site Operators die Suche auf Ihre Domain einschrnken. Versuchen Sie auch durch regelmssigen Informieren auf dem Laufenden zu bleiben, was neue Google Hacks betrifft. Eine grosse Datenbank mit Googlehacks finden Sie unter http://johnny.ihackstuff.com. Auch hilft Ihnen Google weiter wenn es darum geht hufig auftretende Probleme zu lsen. Sie finden eine Sammlung von FAQs unter http://www.google.com/webmasters. Wenn Sie nun bei einer Eigenkontrolle feststellen, dass Informationen von Ihnen im Internet sind, die sie da nicht haben wollen, ist der erste Schritt das Problem auf Ihren Webserver lokal zu beheben. Jedoch wissen Sie, dass es gut mglich ist, dass Google eine Kopie Ihrer Seite im Cache gespeichert hat. Deshalb mssen Sie nun als nchstes Ihre Seite aus dem Google Cache entfernen. Dazu gibt es von Google Website, mit deren Hilfe Sie dies bewerkstelligen knnen. Sie finden diese Site unter http://services.google.com/urlconsole/controller.

Seite 27 / 40

6. Zusammenfassung
Auch wenn Google beim eigentlichen Angriff auf das System keine Rolle spielt, so haben wir gesehen, dass es im Vorfeld bei der Planung einer Attacke sehr ntzlich ist. Viele Angriffe werden durch die Informationen, die Google liefert, erst ermglicht. Das Problematische ist, dass man auf spielerische und legale Art und Weise an Informationen gelangt, die fr die Sicherheit einer Website sehr kritisch sein knnen. Durch Bentzung der Cache Funktion von Google kann man anonym Webserver ausspionieren, ohne auch nur ein Datenpaket an diesen gesendet zu haben. In frheren Zeiten wurde ein Computersystem meistens von einen Hacker gehackt, der ein persnliches Motiv dazu hatte. Heute kann ein Hacker, der eine Schwachstelle eines bestimmten Systems nutzen kann, sich von Google eine Liste mit auf seinen Hack anflligen Systemen ausgeben lassen. Er kann sich sogar aussuchen, welches er zuerst hacken will. Auch spielt Google eine grosse Rolle beim Herausfinden von Informationen, die anschliessend in einer Social Engineering Attacke verwendet werden knnen. Im Zeitalter des glsernen Menschen ist es speziell unter Verwendung von Google nicht schwierig, bestimmte Informationen ber eine gewnschte Person zu erhalten. Wichtig ist daher, dass man sich als Administrator Gedanken darber macht, wie man sein System mglichst sicher halten kann. Eines der wichtigsten Dinge ist sicherlich eine strikte Sicherheitspolitik. So mssen Mitarbeiter beispielsweise auf die Gefahr des Social Engineerings hingewiesen werden. Auch muss man im Bereich der Berechtigungen strikt vorgehen. Es sollen nur befugte Mitarbeiter Schreibrechte auf einen Webserver erhalten. Eines vom Wichtigsten ist jedoch, die eigene Website mit Hilfe von Google Seite 28 / 40

mglichst regelmssig zu berprfen. Dazu verwendet man wie in 5.6.4 beschrieben bekannte Angriffstechniken auf die eigene Domain an, und wertet das Ergebnis anschliessend aus.

Seite 29 / 40

7. Literaturverzeichnis
[1] John L. Hennessy, David A. Patterson: Computer Architecture, A Quantitative Approach. Morgan Kauffmann Publishers. Third Eddition 2003. [2] Johnny Long's Website (http://johnny.ihackstuff.com/) [3] L. Huang, A Survey On Web Information Retrieval Technologies. SUNY Stony Brook ECSL technical report ECSL-TR-120, 2000 [4] http://news.netcraft.com/ [5] M. Sahami, V. Mittal, S. Baluja, and H. Rowley. "The Happy Searcher: Challenges in Web Information Retrieval", 8th Pacific Rim International [6] CJ. Van Rijsbergen, Information Retrieval, http://www.dcs.gla.ac.uk/Keith/Preface.html [7] Tool zur Datumsumrechnung: http://www.myvasco.com/daterange.htm [8] Johnny Long. Google Hacking. mitp Verlag. 1. Auflage 2005.

Seite 30 / 40

A1 Einige Beispielshacks

Auffinden von zustzlichen Servern zu dem Standardserver site:microsoft.com -site:www.microsoft.com

Seite 31 / 40

Directory Listings. Hat der Administrator vielleicht vergessen das Browse-Recht zu entfernen? Aus verschiedenen Directory Listings kann man sehr viele Informationen erhalten. Intitle:index.of./root

Seite 32 / 40

Man kann auch nach ganz bestimmten Applikationen auf bestimmten Ports suchen. VNC Desktop inurl:5800

Auch kann man leicht Passwortdateien finden intitle:index.of administrators.pwd

Seite 33 / 40

...noch mehr Passwrter inurl:index.of passwords.xls

Seite 34 / 40

Es kann auch lustig sein sich Webcams anzusehen... axis video server inurl:indexFrame Oft ist bei den angezeigten Hits ein Link zur Adminoberflche. Sucht man sich mit Hilfe von Google das Standardpasswort fr den Videoserver, so hat man gute Chancen auch in die Adminoberflche zu kommen.

Auch Datenbanken lassen sich sehr einfach ausspionieren "access denied for user" "using password" -forum Damit erhlt man leicht einen Benutzernamen und einen Datenbanknamen.

Seite 35 / 40

Diese Suche ist auch recht witzig, da man viele wertvolle Informationen aus den Ergebnissen gewinnen kann. "SQL Server Driver][SQL Server]Line 1:Incorrect syntax near" -forum -thread -showthread

Der Fantasie des Einzelnen sind hier keine Grenzen gesetzt. Es macht wirklich sehr viel Spass (natrlich nur zu Studienzwecken) einiges auszuprobieren. Wenn es sich bei der Suche um Fehlerberichte handelt, so sollte man nach der Suche
-forum -thread -showthread

schreiben, da man so fast alle Forumeintrge eliminiert und direkt zu Webservern kommt, bei denen das gesuchte Problem auftritt.

Seite 36 / 40

A2 Zusammenfassung des Vortrages von Herrn Dr. Gerhard Eschelbeck

Im Rahmen des vom Institute for Information Processing and Microprocessor Technology (FIM) organisierten Semianrs Computernetzwerke hatten einige Informatiker, zu denen ich mich glcklicherweise zhlen durfte, die aussergewhnliche Mglichkeit am 18. November 2005 einen Vortrag von Herrn Dr. Gerhard Eschelbeck (Computer and Network Security) beiwohnen zu drfen. Herr Dr. Eschelbeck studierte ebenfalls Informatik an der Johannes Kepler Universitt in Linz und ist ein international anerkannter Experte fr Sicherheitsfragen im Bereich der Informatik. Er wurde unter anderem wegen seiner Verdienste im Bereich der Automatisierung von Sicherheitssystemen mehrmals in Folge zu einen der 25 einflussreichsten Informatikern weltweit gewhlt. Am Vormittag des 18. Novembers erhielten wir zunchst eine kleine Einfhrung in die Thematik, in der einige Grundbegriffe sowie grundlegende Konzepte und Prinzipien erklrt wurden. Anschlieend referierte Herr Dr. Gerhard Eschelbeck ber Netzwerksicherheit im Allgemeinen. Wir versuchten zuerst zu definieren was sicher in Bezug auf Computernetzwerke bedeutet und analysierten diese Fragestellung an Hand eines typischen Firmennetzwerkes. Als nchstes haben wir uns den Aufbau der Header und die Funktionsweise von typischen Protokollen einzelner Netzwerklayer angesehen (IEEE 802.3, IP, TCP) und an Hand dieser Beispiele mgliche Angriffstechniken wie zum Beispiel das SYN-Flooding oder das IP-Spoofing diskutiert. Zum Abschluss dieser Einfhrung wurden uns einige Lsungsanstze fr die eben besprochenen Angriffstechniken prsentiert. Nach der grundlegenden Begriffserklrung und der interessanten Einfhrung in Netzwerksicherheit referierte Herr Dr. Eschelbeck ber das Thema Vulerability Analysis. Eine Vulnerability ist eine Schwachstelle eines Systems. Ein sogenannter Exploit ist das Ausntzen einer solchen Schwachstelle um die Policy des Systems umgehen zu knnen. Bei einer Schwachstellenanalyse eines Systems setzt man sich intensiv mit diesem System auseinander und lernt es somit mitsamt seinen Schwachstellen kennen. Dieses Auseinandersetzen mit dem System kann auf vielerlei Art und Weisen erfolgen. Eine davon ist zum Beispiel das Penetration Testing. Bei diesem Verfahren gibt es mehrere Seite 37 / 40

Mglichkeiten, abhngig davon, wieviele Rechte ein mglicher Angreifer hat. Weiss der Angreifer gar nichts ber das System ausser der IP Adresse, so handelt es sich um den sogenannten Black Box Penetration Test. Neben diesem gibt es noch Penetration Tests bei denen der Angreifer (Tester) mit mehr oder weniger privilegierten Benutzerkonten ausgestattet ist. Ziel dieser Tests ist es immer die Policy des Systems zu verletzen. Bei Penetration Tests werden in der Regel folgende Schritte durchwandert:

Foot Printing Scanning Exploiting / Penetrating Daten sammeln Aufrumen Einen Abschlussbericht vorbereiten

Wird ein solcher Test von Menschen durchgefhrt, so ist dieser sehr zeit- und kostenintensiv. Man sucht daher nach Mglichkeiten autmomatisierte Sicherheitstests von Systemen durchzufhren. Nach der Erluterung von verschiedenen Scan Verfahren (TCP SYN Scanning, TCP FIN Scanning, UDP Scans, Stealth Scans etc.) und Footprint Methoden hat Herr Dr. Eschelbeck ber Network Adm ission Managem ent gesprochen. Dies ist ein sehr interessanter Ansatz, bei dem es darum geht an Netzwerken nur Clients teilnehmen zu lassen, die bestimmten Anforderungen entsprechen. Solche Anforderungen wren zum Beispiel dass ein bestimmter Patch installiert ist, dass das System virenfrei ist etc. Erfllt ein Client beim Anschluss an ein Netzwerk diese Voraussetzungen nicht, so wird er in ein Quarantne-Subnet eingehngt, indem er sich beispielsweise die fehlenden Patches downloaden kann um sein System anschliessend einer erneuten berprfung unterziehen kann. Erfllt ein Client alle definierten Voraussetzungen fr das Firmennetzwerk, so wird er in dieses sofort eingegliedert. Nach dem Kapitel ber Network Admission Management ist Herr Eschelbeck kurz auf das Thema Google Hacking eingegangen. Dabei hat er am Anfang die Advanced Operators von Google betont, die es einen Sucher erlauben seine Suche zu konkretisieren. Jedoch ist es durch solche Operatoren fr einen potentiellen Angreifer auch mglich, bestimmte, sensible Informationen ber ein System zu erfahren. Google ist daher fr Angreifer oft die erste Adresse wenn es gilt, Systeme mit bestimmten Schwachstellen zu finden. Seite 38 / 40

Nach den kurzen Exkurs ber Google Hacking hat Herr Dr. Eschelbeck das von ihm mitentwickelte CVSS (Com m on Vulnerability Scoring System ) vorgestellt. Heutzutage werden sehr viele zueinander unkompatible Skalen benutzt, die versuchen die Dringlichkeit bzw. Gefhrlichkeit eines Exploits zu messen. Diese sind meist herstellerspezifisch. Bei Hersteller A wird zum Beispiel eine Vulnerability mit 1 (fr ungefhrlich) bis 10 (fr extrem gefhrlich) gewertet, whrend Hersteller B die verschiedenen Vulnerabilities mit Low, Medium und High bewertet. Damit ist es fr einen Administrator sehr mhsam herauszufinden, wie bedrohlich nun eine bestimmte Vulnerability fr sein System ist. Ausserdem stellt sich fr einen Systemadmin die Frage, welche Vulnerability er sofort patchen muss, und mit welchen anderen Vulnerabilities er sich noch Zeit lassen kann bis zum nchsten routinemssigen Patch-Durchlauf. CVSS hilft ihm dabei, indem es eine Zahl zwischen 1 und 10 angibt, die sich aus drei Teilen zusammensetzt, nmlich der Base Metric, der Tem poral Metric und der Envirom ental Metric. Die Base Metric bestimmt die Gefhrlichkeit einer Vulnerability fr ein System und wird vom Hersteller des Systems mit Hilfe einer Formel berechnet. Diese Base Metric bleibt immer gleich und hat am meisten Einfluss auf das endgltige Ergebnis, dem CVSS Score. Die Temporal Metric beschreibt die aktuelle Dringlichkeit des Problems und kann sich mit der Zeit ndern. Diese wird auch vom Hersteller des Produktes bestimmt. Die Enviromental Metric wird vom Benutzer durch die Wahl seiner Systemkomponenten angegeben. Diese beschreibt wie dringlich bzw. wie gefhrlich eine bestimmte Vulnerability fr den Benutzer selbst ist. Eine Windows Vulnerability ist fr einen Linux Server in der Regel nicht allzu kritisch. Ich finde das CVSS deswegen so gut, weil somit jeder Administrator einen fr sein System zugeschneiderten Score bekommt, der nur von ihm selbst und vom Hersteller des fehlerhaften Produktes abhngig ist. Dadurch kann er rasch und einfach entscheiden, welche Vulnerabilities nun wirklich gefhrlich sind und welche Patches er sofort installieren sollte. Die Vorteile eines solchen einheitlichen, offenen Systems haben bereits viele fhrende Hersteller erkannt, und man findet auf immer mehr Seiten im Internet, bei denen CVSS als Masszahl fr die Gefhrlichkeit einer Vulnerability angegeben ist. Zum Abschluss dieses grossartigen Tages hat uns Herr Eschelbeck noch eine Prsentation (The Laws of Vulnerabilities) vorgefhrt, die er ebenfalls im November 2005 in Amerika vorgetragen hat. In dieser Prsentation ging es um die Ergebnisse der Qualys Scans, die Herr Dr. Eschelbeck einmal jhrlich zusammenfasst und der ffentlichkeit prsentiert. Seite 39 / 40

Alles in allem bin ich sehr froh bei diesen interessanten Vortrag dabei gewesen sein zu drfen. Es war ein tolles Erlebnis einen international so bekannten erstklassigen Informatiker ber Netzwerksicherheit vortragen zu hren.

Seite 40 / 40