Skip to content

Google Hacking - The Next Generation

Was Google Hacking ist, haben Sie in der vorherigen Folge erfahren, in der auch erste Beispiele und die wichtigsten Google-Optionen vorgestellt wurden. Schon damit kann man viele interessante Informationen sammeln, aber mit entsprechenden Anpassungen ist noch mehr möglich.

Google Hacking - Einfach war gestern

Die folgenden Google-Hacking-Techniken wurden von Fran Brown und Rob Ragan von Stach & Liu auf der Black Hat USA 2011 vorgestellt. Der Titel ihres Vortrags: "Pulp Google Hacking: The Next Generation Search Engine Hacking Arsenal".

Von Stach & Liu wurde das Google Hacking Diggity Project ins Leben gerufen, dass sich mit der Untersuchung des Suchmaschinen-Hackings (speziell natürlich über Google und Bing, aber auch über spezielle Suchmaschinen wie Shodan zur Suche nach Online-Devices) und der Entwicklung entsprechender Tools beschäftigt. Die Tools, die zum Teil auch im Folgenden beschrieben werden, werden aktuell auch auf der Black Hat USA 2012 demonstriert, die vom 21. bis 26. Juli statt findet.

Ein echter Angriff als Beispiel

Das erste Beispiel ist ein "Real World"-Beispiel: Die Anfrage

!Host=*.* intext:enc_UserPassword=* ext:pcf

wurde von "Kayla" von LulzSec verwendet, um Zugangsdaten zu VPNs zu finden. Darüber ist dann der Zugriff auf das lokale Netz der betroffenen Unternehmen und Organisationen möglich.

Schwachstellensuche mit Google

Google Code Search konnte vor seiner Einstellung zur Suche nach bekannten oder möglichen Schwachstellen im Sourcecode von Open Source Software genutzt werden. So war z.B. mit der Anfrage

select.*from.*request\.QUERYSTRING

die Suchen über den ASP-Querystring ausnutzbaren SQL-Injection-Schwachstellen möglich. Mit der Einstellung von Code Search ist diese Suche nur noch eingeschränkt möglich: Über Google kann man im Code von bei Google Code Hosting gehosteten Projekten suchen, und auch andere spezialisierte Suchmaschinen wie GrepCode (nur für Java-Sourcecode), Koders.com, Krugle Open Search und search[code] erlauben die Suche im Sourcecode.

Direkt nach der Veröffentlichung von Google Code Search kam es übrigens zu einer Welle von Falschmeldungen wegen angeblicher Remote- und Local-File-Inclusion-Schwachstellen in PHP-Skripten. Einige Leute wollten besonders schlau sein und haben alles, was irgendwie dem Muster
include($parameter);
oder
include("/pfad/zum/skript/".$parameter);
entsprach, als Remote bzw. Local File Inclusion gemeldet. Meist wurde der $parameter direkt oder zumindest nur wenige Zeilen über der angeblichen Fundstelle der Schwachstelle geprüft und/oder von möglichen Manipulationen bereinigt. Aber so weit zu denken waren die "Forscher" nicht in der Lage. Vom Überprüfen der "Schwachstelle" ganz zu schweigen.

Suche nach Drive-by-Infektionen

Möchten Sie wissen, ob eine Website für Drive-by-Infektionen präpariert wurde, also zu einer Seite weiterleitet, auf der den Besuchern dann Schadcode untergeschoben wird, oder allgemein Links zu bösartigen Seiten enthält? Das ist mit zwei Schritten möglich:

  1. Die Option linkfromdomain: von Bing liefert alle von einer Website verlinkten Websites, mit
    linkfromdomain:ceilers-news.de
    erhalten Sie also eine Liste aller Domains, die von meinem Blog aus verlinkt wurden.
  2. Diese Liste mit Domains kann dann über Googles Safe Browsing API auf Schadsoftware verbreitende Domains untersucht werden. Für einzelne Domains kann auch über den Aufruf von
    http://www.google.com/safebrowsing/diagnostic?site=[Domainname]
    die Diagnoseseite von Safe Browsing aufgerufen werden. Die Diagnoseseite des Blogs erhalten Sie also durch den Aufruf von
    http://www.google.com/safebrowsing/diagnostic?site=www.ceilers-news.de

Meldet das Safe Browsing API eine bösartige Website, gibt es auf der getesteten Website (mindestens) einen Link zu dieser bösartigen Website. Das kann bekanntlich drei Ursachen haben: Die Zielseite kann ohne Wissen des Websitebetreibers bösartige Inhalte enthalten, es wurde absichtlich ein Link zu der bösartigen Seite gesetzt, oder die Website wurde für eine Drive-by-Infektion präpariert.

Um diese Suche zu vereinfachen, wurde von Stach & Liu das Tool "MalwareDiggity" entwickelt. Damit kann auch nach den Opfern von Massenhacks sowie den für die Angriffe genutzten Domains gesucht werden, wenn mal wieder Websites massenhaft kompromittiert und für Drive-by-Infektionen präpariert werden.

Suche nach Flash-Schachstellen

Speziell für die Suche nach Schwachstellen in .swf-Dateien wurde von Stach & Liu das Tool FlashDiggity entwickelt: Zuerst wird über die Anfrage

filetype:swf site:[Website]

nach allen .swf-Dateien einer bestimmten Website gesucht, danach werden diese heruntergeladen und lokal disassembliert und analysiert.

Suche in Dateien

Dass die Suche auf bestimmte Dateitypen eingeschränkt werden kann, wurde ja bereits in der Einführung beschrieben. Von Stach & Liu gibt es das Tool DLPDiggity, das durch die Verwendung der IFilter in der Lage ist, auch in den Dokumenten selbst und nicht nur in den Metadaten zu suchen. Der Nachteil dabei: Dafür müssen die zuvor über die Suchmaschine gefundenen verdächtigen Dateien herunter geladen werden. Mit dem Tool kann aber z.B. nach Kreditkartennummern oder US-amerikanischen Sozialversicherungsnummern in z.B. PDF-Dateien gesucht werden.

Google contra Google-Hacking

Google findet es verständlicherweise nicht gut, wenn die Suchmaschine für bösartige Zwecke missbraucht wird. Daher wurden in der Vergangenheit bereits des öfteren unerwünschte Anfragen gesperrt. Insbesondere, wenn mal wieder ein Wurm Google zur Suche nach neuen Opfer nutzt, reagiert Google dann sehr schnell, und statt der Suchergebnisse gibt es eine Meldung nach dem Muster "Diese Suche ist zur Zeit nicht möglich, da sie von Schadsoftware genutzt wird. Bitte formulieren Sie sie etwas um, damit wir sie nicht mehr erkennen". Das gleiche gilt sinngemäß. wenn Google einen Bot erkennt: Selbst durchsucht man zwar das Internet mit Hilfe des Google-Bots, für fremde Bots gibt es aber verständlicherweise ein virtuelles "Wir müssen leider draußen bleiben"-Schild.

Die Anfragen kann man oft so umformulieren, dass sie von Google dann doch ausgeführt werden, und die Bot-Erkennung greift nicht bei Nutzung des JSON/ATOM API. Die von Stach & Liu entwickelten Tools nutzen dieses API (und bei Bedarf auch Google Custom Search).

Ab der nächsten Folge geht es um den Einsatz von Google Hacking im Rahmen von Penetration Tests, und danach ist es dann an der Zeit, über mögliche Gegenmaßnahmen nachzudenken.

Carsten Eilers


Übersicht über alle Artikel zum Thema

Google Hacking, ganz einfach
Google Hacking - The Next Generation
Google Hacking: Verzeichnislisten und Intranets
Google Hacking: Webserver finden
Google Hacking: Webanwendungen finden
Google Hacking: Portale und Netzwerkhardware finden
Google Hacking: Interessante Dateien finden
Google Hacking verhindern: Verzeichnisse schützen
Google Hacking verhindern, Teil 2

Trackbacks

Keine Trackbacks