Dipl.-Inform. Carsten Eilers

Die einfachste Methode, einen Webserver zu finden, ist ein Portscan. Vereinfacht gilt "Alles, was auf Anfragen an Port 80 antwortet, ist ein Webserver". So ein Portscan ist aber auffällig, darum bietet es sich an, stattdessen einen Dienst zu nutzen, der zum einen sowieso ständig das Internet durchsucht und zum anderen die nötigen Informationen bereits bereit hält: Google (und natürlich die anderen Suchmaschinen, aber der Einfachheit halber wird hier nur Google behandelt).

Wie findet man also über Google Webserver? Das ist natürlich in der Form eine dumme Frage, denn wenn man Googles Websuche benutzt, landet man automatisch bei Webservern (und ab und zu einem FTP-Server). Aber wie oben schon erwähnt, geht es hier ja um die Frage, wie ein Angreifer einen zu seinem Exploit passenden Server findet. Eine mögliche Antwort auf diese Frage haben Sie bereits in der vorherigen Folge kennen gelernt: Viele Webserver verraten in den Verzeichnislisten ihre Identität samt Version. Um z.B. nach Apache-Servern der Version 2.4.1 zu suchen, verwendet man also die Suchanfrage

intitle:index.of server.at "Apache/2.4.1"

Aber das wissen Sie ja bereits, es steht hier nur der Vollständigkeit halber. Für einen Angreifer ist in dem Zusammenhang noch wichtig, dass er die aktuelle Version kennt, er muss also auf jedem Fall die richtige Seite und nicht die aus Googles Cache überprüfen. Ansonsten läuft er Gefahr, sich einen Server mit einer für seinen Exploit unpassenden Version auszusuchen, da sich die Version ja nach dem Besuch des Google-Bots geändert haben kann. Allgemein ist es aber keine schlechte Idee, statt der eigentlichen Seite die Version aus Googles Cache zu analysieren, da der Angreifer dann nicht auf den möglicherweise anzugreifenden Server zugreifen muss und dadurch auch nicht seine IP-Adresse in den Logfiles hinterlässt.

Die Apache-Webserver und die meisten von ihnen abgeleiteten Server sowie Microsofts IIS lassen sich so finden (vorausgesetzt natürlich, dass der Server überhaupt Verzeichnislisten bereitstellt und die Ausgabe dieser Information nicht vom Administrator ausgeschaltet wurde).

Fehlermeldungen als Hinweisschilder?

Gibt ein Webserver keine Verzeichnislisten aus oder sind darin keine Versionsinformationen enthalten, gibt es ja vielleicht in den Fehlermeldungen des Servers entsprechende Informationen. Betrachten wir wieder den Apache Webserver. Durch Eingaben wie z.B.

"Apache/2.0.40" intitle:"Object not found"

kann man nach entsprechenden Fehlermeldungen suchen. Fündig wird man allerdings erst auf den "hinteren Plätzen", wenn überhaupt, denn Fehlermeldungen werden, so sie denn überhaupt vom Google berücksichtigt werden, als nicht besonders relevant eingestuft. Anleitungen zur Konfiguration der Fehlermeldung, zum Beheben der Fehler oder was auch immer sowie entsprechende Forenbeiträge u.s.w. haben natürlich einen höheren Pagerank und stehen in den Ergebnislisten weit vorne. Auch

intitle:"Object not found" "think this is a server error"

liefert verräterische Fehlermeldungen. Nachdem man erneut hat suchen lassen, denn bei der ersten Suche werden vermutlich irrelevante Ergebnisse von Google gar nicht erst ausgegeben - und genau das sind ja die Fehlermeldungen i.A., jedenfalls für die normalen Google-Benutzer.

Ähnlich sieht es bei Microsofts IIS aus. Betrachten wir mal die Fehlermeldung des IIS für den Fehlercode 404. Die hat ein title-Tag:

<title>The page cannot be found</title>

Die nahe liegende Suche nach

intitle:"The page cannot be found"

ist natürlich nicht sehr effektiv: Es gibt viel zu viele Ergebnisse. Sie lässt sich zwar "verbessern", aber auch dieser Versuch geht eher in die falsche Richtung. Microsoft gibt in der Fehlermeldung den Tipp "Please try the following", und außerdem steht in jeder Default-Fehlermeldung der Server: "Internet Information Services". Damit lässt sich dann eine effektivere Suchanfrage zusammenstellen:

intitle:"The page cannot be found" "Please try the following" "Internet Information Services"

Das Dumme daran: Man findet darüber wie beim Apache zum größten Teil Anleitungen, was man beim Auftreten dieses Fehlers machen soll etc., aber keine echten Fehlermeldungen. Und auch wenn man den HTTP-Fehlercode, der als "HTTP Error 404" auf der Seite steht, wird das Ergebnis nicht wirklich besser:

intitle:"The page cannot be found" "Please try the following" "Internet Information Services" "HTTP Error 404"

Generell das gleiche gilt auch für die anderen Standard-Fehlermeldungen des IIS, die andere title-Tags verwenden, z.B.

"The page cannot be displayed" (HTTP Error 405)
"The resource cannot be displayed" (HTTP Error 406)
"Proxy authentication required" (HTTP Error 407)
"The page does not exist" (HTTP Error 410)

Auch damit findet man alles mögliche, aber kaum das Gesuchte.

Google wird immer besser

Vor einigen Jahren war das noch anders, aber inzwischen hat zum einen Google seine Algorithmen ständig verbessert, zum anderen gibt es auch mehr Anleitungen etc., in denen die gesuchten Begriffe ebenfalls vorkommen. Aber das ist ja ein generelles Problem der Google Dorks: Kaum berichtet jemand über einen, macht das die Runde, und statt der eigentlich gesuchten Seiten findet man dann Berichte darüber, wie man sie finden kann. Ein Beispiel gefällig?

Nehmen Sie einen beliebigen Eintrag aus der Exploit-DB, in der ein Google Dork angegeben ist, und verwenden Sie diesen Google Dork als Suchanfrage. Zuerst einmal werden Sie etliche Kopien des Exploits oder Advisories finden, aus dem Sie den Google Dork kopiert haben. Ein willkürliches Beispiel ist der Exploit 20541, "MaxForum v1.0.0 Local File Inclusion" mit dem Google Dork

Powered by MaxForum v1.0.0

Unten den ersten Suchergebnissen finden Sie etliche Versionen des zugehörigen Advisories/Exploits.

In der nächsten Folge geht es um die Frage, wie bestimmte Anwendungen über Google gefunden werden können.

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