. [ Show ] in English
Information gathering – techniques of fingerprinting
The safety of a webserver is measured by many different factors. An important factor is the amount of information
which are published.
There are many information, which can give the attacker valued information about the server.
Often it’s possible to gather information very easily, even if the specific information seems to be not interesting.
Some sources, you can get information from:
1. Server Banner:
While sending a HTTP Request, the Server Banner is transferred too, automatically.
An Exchange of data is divided into request and answer.
Sending a request the user requests a specific document which is saved on the webserver, and
optional the user attaches some extra information like Cookie, Content-Type and more. These options
can be found in the so-called “HTTP Header”.
The header also exists, when the user receives an answer, which was sent by the webserver.
It includes the requested document and some extra information, whose verbosity is dependent on the
webservers settings.
An example for a field in the Answer Header could be the “Server” field, or the “server-banner”.
Server: Apache/2.2.11 (Debian) mod_fastcgi/2.4.6
It’s possible to read out the content with some firefox addons like “Live HTTP Headers” or “Server Spy” but even a simple
HTTP Request via telnet is enough to get the header information.
I’ll explain later, which of the information are important.
2. Behaviour of a webserver
Observing the webservers reaction when changing some values, can be interesting and useful. There are some indications
in output or parsing routines the user can gather information from, about the script language or versions of database systems.
3. Automated fingerprinting
An automated way of using fingerprint procedures can be done using the network tool “nmap”, which is able to find
out detailed information easier than the manually way.
It’s the users decision what he wants to find out about the webserver, but there are some default information,
you should look at in any case.
1. Operating System
2. Webserver
3. Scriptlanguage
4. Database
5. Services + Ports
6. Other websites on server
1. Operating system
There are a couple of indications for the running operating system.
One of the most efficient sources is the webserver itself. Often you
can read out the OS out of the server banner.
If you read s.th. like : „Microsoft-IIS/6.0“ you can be sure, that you’ve discovered a windows system.
It’s not possible to run Microsoft IIS at another operating system than windows.
If you just find s.th. like “Apache” you cannot find out the operating system, because the output is set
at minimal mode.
You can set up one of six options, to regulate the output in the server banner. There options are called
server tokens.
1. Prod (“Apache”)
2. Major (“Apache/2”)
3. Minor (“Apache/2.0”)
4. Min (“Apache/2.0.41”)
5. OS (“Apache/2.0.41 (Unix)”)
6. Full (“Apache/2.0.41 (Unix) mod_fastcgi/2.4.6”)
In this examples you can see outputs reaching from productname till versionnumbers and detailed information about
installed modifications. If the option switched to “OS” or “Full” you don’t need to search longer for the
operating system running at the server.
Another way is to make the server displaying errors, in which you can see the script Path. This can happen by inserting
special chars, the webserver couldn’t handle. Some possible outputs are:
Warning: Header may not contain more than a single header, new line detected. in C:\xampp\htdocs\info.php on line
2
Warning: Header may not contain more than a single header, new line detected. In
/var/www/info.php on line 2
In this case you can see the operating system without problems.
The first one is windows, the second linux.
An automated way is possible with the portscanner called “nmap”.
So you just start a simple portscan:
nmap -v -A Hostaddress
If you discover ports like 3389 or the NetBIOS Port you can be sure that
you’ve found a windows system, or you just count on the OS fingerprint option
in nmap, you can enable with “-A”.
2. Webserver
You can discover the installed webserver very easy if the webservers name isn’t cloaked.
We can use the accosted server banner, displaying the webservers name in the most cases,
even if the output is set to “Prod”.
e.g. „Apache“
If you don’t have the possibility to view the server banner, you can
try to make the webserver responding an error by calling a document which
doesn’t exist. The webserver should respond that the document isn’t there,
and often you also get the webservers name and version number.
Another method is the port and service scanning, where we’ve to look at the
open ports. Sometimes the servicename includes the productname of the webserver.
3. Scriptlanguage
It’s a bit more difficult to find out the active scriptlanguage, because it’s not
always php running, where you’ve got a .php extension.
This issue is possible because you can define more than one extensions for a specific
script language. You can configure this declarations in the “httpd.conf” file like this:
AddType application/x-httpd-php .php .php4 .html
The .html standing at the end of the line means, that in this case also files with
a html extension will be parsed as PHP code and so index.html?id=1 is the same as
index.php?id=1 but in the most cases you can believe the extensions.
If you wanna play it safe you can take a look into the HTTP Header, we can extract
valuable information of:
X-Powered-By: PHP/5.2.9
In this case we know immediately, that the webserver is using PHP but it’s
only possible because the option “expose_php” is switched on.
Error reports, which are specific for a script language are another good indicator too.
A blackboxing method, to get an error is to attach special chars like ‘ ” %00 at a parameter.
A possible error could be:
Warning: fopen(/test'.txt): failed to open stream: Permission denied in
/test.php on line 138
Afterwards you can search for that error messages, to determine the script language.
PHP substitutes variables beginning with a space into a name without leading spaces,
so there’s a simple test, to check if PHP is running.
index.php?page=10
index.php?+page=10
If you get the same output in both examples, it’s possible that
PHP is running. The behaviour of ASP is another one and so another document will be
printed out.
Methods to hide file extensions like mod rewrite don’t
really protect for information gathering. Player gave an example
in his article how to discover a PHP installation.
You can read it here:
http://novusec.com/php-easter-egg-sinnvoll-nutzen/
4. Database
Die Auswahl an großen Datenbanksystemen ist glücklicherweise nicht allzu groß
und es gibt einige Möglichkeiten herauszufinden, welches installiert ist.
Der Trick mit den Sonderzeichen greift in vielen Fällen auch hier sodass man zum
Beispiel folgende Fehlermeldungen bekommen könnte:
The amount of databasesystems is not very large and there are some possibilities
to find out, which database is installed.
You just need to use the way of inserting special chars, so you could
get those error messages:
You have an error in your SQL syntax; check the manual that corresponds to
your MySQL server version for the right syntax to use near '3' at line 1
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL
result resource in /var/www/test.php on line 92
Unclosed quotation mark before the character string
Error 1 and 2 are MySQL based errors and the third one is an
error message coming from Microsoft SQL Server. Furthermore
these error messages can indicate a SQL Injection vulnerability.
You only get those errors if the option “display_errors” is switched
“on”.
The portscanner “nmap” is useful for information gathering concerning
database systems. If you scan for open ports and find the open port 3306
then often it’s a MySQL Server. MSSQL is using other ports and also oracle.
5. Services + Ports
Sofern die Website mitsamt ihren Implementierungen abgesichert ist, gibt es über
Die Seite selbst wenig Möglichkeiten für einen Angreifer Schaden anzurichten.
Die auf dem Server installierten Services können jedoch auch zur Gefahr werden.
Der Befehl:
If the website together with it’s implementations is safe there are
less possibilities to be successfull.
The running services could be dangerous too.
The command
nmap –v –A Hostadresse
lists up the open ports with detailed information about running services.
Those applications can contain vulnerable code like buffer overflows or
format strings, which could be exploited remotely in some cases and give an
attacker all possibilities to gather control about the whole server, if
the processes are suid root (belonging to root user).
In big exploit databases you can look for an exploit fitting to a
specific vulnerable service.
6. Other websites on server
If the attacker isn’t successful at a specific website he can choose the way
to look for other websites hosted at the same server.
The keyword is “Reverse-IP” or “Reverse-DNS”.
Several sites offer such a service, and display websites with same IP.
There are good Reverse-IP Services and there are also some, which are not
very solid. This depends on the domain which is used by the service.
Examples for Reverse-DNS services are:
http://www.myipneighbors.com/
http://www.domaintools.com/reverse-ip/
http://www.protect-x.com/reverse/
These are just some basic information, you gan gather while exploring websites, but these information
could be essential for more practices.
If you want to go further you should look for keywords like “fingerprinting”.
Der Sicherheitsgrad eines Webservers lässt sich an vielen Faktoren messen, ein wichtiger Faktor sind hierbei die Informationen die preisgegeben werden.
Es gibt viele Informationen, die einem Angreifer wichtige Details zum aufgesetzten Server geben können, und bei vielerlei Dingen ist es sehr einfach Informationen zu bekommen, auch
Wenn diese zunächst uninteressant erscheinen.
Einige Quellen aus denen man Informationen beziehen kann sind folgende:
1. Server Banner:
Das Server Banner wird bei jeden HTTP Request mitgeschickt.
Ein Austausch von Nachrichten besteht aus Request und Answer.
Im Request fragt der Nutzer eine bestimmte Quelle auf dem Webserver an,
und versieht diese optional mit einigen Zusatzinformationen wie Cookie, Content-Type o.Ä. Diese stehen im sogenannten Header.
Diesen gibt es auch bei der vom Webserver gelieferten Antwort, in der zum einen
Das angefragte Dokument zu finden ist, und einige Informationen, wie je nach Optionen des Webservers mitgeliefert werden.
Ein Feld im Antwort-Header kann zum Beispiel das „Server“ Feld, oder auch „Server-Banner“ sein. Dieses könnte wie folgt aussehen:
Server: Apache/2.2.11 (Debian) mod_fastcgi/2.4.6
An den Inhalt des Headers kann man mit den Firefox Erweiterungen „Live HTTP Headers“ oder „Server Spy“ kommen. Es würde allerdings auch ausreichen manuell ein HTTP Request abzusetzen, etwa mit Telnet. Dort wird auch direkt der Antwort Header ausgegeben.
Welche Informationen wofür relevant sind werde ich später noch ausführen.
2. Verhalten des Webservers
Am Verhalten, wie der Webserver auf Veränderungen reagiert lässt sich auch sinnvolles extrahieren. Es gibt zum Beispiel bestimmte Anzeichen an Darstellung und
Parsing Routinen an denen man Skriptsprache oder auch Versionen von Datenbanksystemen erkennen lassen.
3. Automatisiertes Fingerprinting
Mit dem Netzwerktool „nmap“ lassen sich automatisiert Fingerprinting Routinen ausführen, die detaillierte Informationen herausfinden können, bei denen man von Hand nicht unbedingt weiterkommt.
Was an also über den Webserver herausfinden möchte liegt am Benutzer selbst, doch gibt es eine Reihe von Standardinformationen, die man sich auf jeden Fall anschauen sollte.
1. Betriebssystem
2. Webserver
3. Scriptsprache
4. Datenbanksystem
5. Services + Ports
6. Weitere Websites auf Server
1. Betriebssystem
Es gibt einige Hinweise die auf das entsprechende Betriebssystem hindeuten können.
Als eine der wichtigsten Quellen steht hier der Webserver. Man kann diesen in den meisten Fällen aus dem Server Banner auslesen.
Steht hier etwa : „Microsoft-IIS/6.0“ kann man sich sicher sein auf ein Windows Betriebssystem gestoßen zu sein. Der Microsoft IIS Server läuft unter keinem anderen System als Windows.
Findet man allerdings nur ein „Apache“ vor kann man sich nicht 100% sicher sein, da hier nur die Minimal-Angabe eingeschaltet ist.
Die Webserver bieten 6 Optionen, mit denen sich die Ausgabe im Server Banner beeinflussen lässt. Diese nennen sich Server Tokens.
1. Prod (“Apache”)
2. Major (“Apache/2”)
3. Minor (“Apache/2.0”)
4. Min (“Apache/2.0.41”)
5. OS (“Apache/2.0.41 (Unix)”)
6. Full (“Apache/2.0.41 (Unix) mod_fastcgi/2.4.6”)
Man erkennt in diesen Beispielen die Ausgaben, die entweder nur vom Produkt, bis hin zu Versionsnummern und detaillierten Server Angaben über installierte Modifikationen reichen können. Ist hier „OS“ oder „Full“ eingeschaltet, ist die Suche nach dem Betriebssystem relativ schnell beendet.
Ein weiterer Weg ist, den Webserver zu Fehlermeldung zu zwingen in denen der Pfad der aktuellen Datei stehen kann. Dies kann durch Sonderzeichen geschehen, die der Webserver nicht verarbeiten kann. Mögliche Ausgaben können folgende sein:
Warning: Header may not contain more than a single header, new line detected. in C:\xampp\htdocs\info.php on line 2
Warning: Header may not contain more than a single header, new line detected. In
/var/www/info.php on line 2
Hier lässt der Pfad auf das Betriebssystem schließen, sofern es sich um den
absoluten Pfad handelt. Beim ersten ist dies Windows, beim zweiten ein auf Linux
basierendes Betriebssystem.
Eine automatisierte Möglichkeit bietet sich auch mit dem bereits angesprochenen
Tool nmap. Man startet also zunächst einen simplen Portscan mit:
Nmap –v –A Host
Findet man Ports vor wie 3389 oder den NetBIOS Port, ist dies mit großer
Sicherheit ein Windows Rechner, oder man verlässt sich einfach auf
die OS Fingerprint Option von nmap, die wir mit „-A“ eingeschaltet haben.
2. Webserver
Der Webserver lässt sich relativ schnell erschließen, sofern nicht besondere
Maßnahmen zur Verschleierung getroffen wurden.
Helfen wird uns wieder der Server Banner in dem bereits oben gezeigt wurde,
dass in den meisten Fällen der Name des Webservers bereits angezeigt wird,
selbst bei minimaler Darstellung.
Z.b. „Apache“
Sollte man nicht sofort Zugriff zu dem Server Banner haben, kann man auch
Versuchen den Webserver zu einer Fehlermeldung zu zwingen, etwa in dem man
Eine Seite aufruft die nicht existiert. In einigen Fällen wird der Webserver dann
zurückmelden, dass die aufgerufene Seite nicht existiert, und auch gleich den
Webserver mitsamt Version zurückgibt.
Eine weitere Methode ist auch hier das Port und Servicescanning wo wir auf die
Offenen Ports schauen sollten. Auch hier erscheint bei den laufenden Services
In manchen Fällen der Webserver.
3. Skriptsprache
Etwas schwieriger gestaltet sich das Herausfinden der aktuellen Skriptsprache,
denn nicht überall wo .php oder .html dransteht, muss es auch darin sein.
Dieses Versteckspiel wird möglich gemacht vom Zuweisen des Typs auf eine
Frei wählbare Endung, was in der httpd.conf geschieht und wie folgt aussehen
kann:
AddType application/x-httpd-php .php .php4 .html
Das .html am Ende macht deutlich, dass in diesem Falle auch Dateien mit der
Endung html auf PHP Code geparsed werden und folglich auch eine
index.html?id=1 als Ersatz für index.php?id=1 dienen kann. In den meisten Fällen
ist aber den Endungen glauben zu schenken.
Wer ganz sicher gehen will schaut in den altbekannten http Header, aus dem wir
Auch diesmal nützliche Informationen ziehen können.
Ausgegeben werden könnte z.B. dies:
X-Powered-By: PHP/5.2.9
In dem Falle wissen wir sofort, dass es sich um PHP handelt. Dies ist aber nur
möglich, wenn die Option „expose_php“ auf „on“ gestellt ist.
Fehlermeldung die für eine Skriptsprache spezifisch sind, können auch ein starkes
Indiz sein. Eine Blackboxing Methode einen Fehler hervorzurufen, wäre das
Anhängen von Sonderzeichen wie ‘ ” %00 etc. an einen Parameter.
Ein möglicher Fehler wäre bei PHP dieser:
Warning: fopen(/test'.txt): failed to open stream: Permission denied in
/test.php on line 138
Über eine Suchmaschine kann man dann anschließend Informationen über die
auftretenden Fehlern beziehen.
PHP wandelt Variablennamen die mit einem Leerzeichen beginnen automatisch in
einen Namen ohne führende Leerzeichen um, also kann man mit folgendem
simplen Test ebenso auf PHP überprüfen:
index.php?page=10
index.php?+page=10
Wird in beiden Fällen das gleiche angezeigt, ist dies ein gutes Indiz für ein
Vorhandensein von PHP. ASP zum Beispiel reagiert in diesem Falle anders, und
wird ein anderes Dokument als zuvor anzeigen.
Techniken, die die Dateiendungen verschleiern, wie zum Beispiel Mod Rewrite
schützen nicht unbedingt vor der Informationsgewinnung. Ein Beispiel hat Player
in seinem Artikel beschrieben, wie man eine PHP Installation erkennen kann.
Zu finden ist dieser hier: http://novusec.com/php-easter-egg-sinnvoll-nutzen/
4. Datenbanksystem
Die Auswahl an großen Datenbanksystemen ist glücklicherweise nicht allzu groß
und es gibt einige Möglichkeiten herauszufinden, welches installiert ist.
Der Trick mit den Sonderzeichen greift in vielen Fällen auch hier sodass man zum
Beispiel folgende Fehlermeldungen bekommen könnte:
You have an error in your SQL syntax; check the manual that corresponds to
your MySQL server version for the right syntax to use near '3' at line 1
Warning: mysql_fetch_array(): supplied argument is not a valid MySQL
result resource in /var/www/test.php on line 92
Unclosed quotation mark before the character string
Während die ersten beiden Meldungen auf MySQL hinweisen, ist die dritte eine
Meldung des Microsoft SQL Servers. Die Meldungen können außerdem auf eine
SQL Injection hindeuten. Dies funktioniert nur, solange die Option
„display_errors“ auf „on“ geschaltet ist.
Der Portscanner „nmap“ erledigt auch für die Informationsgewinnung über
Datenbanken gute Dienste. Scannt man einen Webserver und findet den offenen
Port 3306, dann ist dies ein laufender MySQL Server. MSSQL benutzt wiederum
Andere Ports und Oracle Datenbanken ebenso andere.
5. Services + Ports
Sofern die Website mitsamt ihren Implementierungen abgesichert ist, gibt es über
Die Seite selbst wenig Möglichkeiten für einen Angreifer Schaden anzurichten.
Die auf dem Server installierten Services können jedoch auch zur Gefahr werden.
Der Befehl:
nmap –v –A Hostadresse
liefert bei installiertem nmap eine detaillierte Auflistung über offene Ports und
dessen Services. Die Programme können Schwachstellen enthalten wie Buffer
Overflows oder Format Strings, die unter Umständen sogar aus der Ferne
angegriffen werden können, und dem Angreifer die vollständige Kontrolle über
den Server bieten, solange die Prozesse SUID root sind, also dem root Konto
gehören.
In großen Exploitdatenbanken kann man anschließend nachschauen, ob zu einem
Gefundenen Service ein Exploit existiert.
6. Weitere Websites auf dem Server
Wird man auf einer Seite nicht fündig, kann man einen Umweg über die Websites
gehen, die auf dem gleichen Server wie die Zielseite liegen.
Das Stichwort ist hierbei „Reverse-IP“ oder „Reverse-DNS“.
Einige Seiten bieten solch einen Dienst an, und zeigen die Seiten mit gleicher IP
an. Manche Seiten sind weniger zuverlässig als andere, dies ist von der Domäne
abhängig die für die Suche zurate gezogen wird.
Beispiele für Reverse-DNS Dienste sind:
http://www.myipneighbors.com/
http://www.domaintools.com/reverse-ip/
http://www.protect-x.com/reverse/
Dies stellt nur einen groben Überblick an Informationen dar, die man beziehen kann, doch können diese Informationen essentiell für ein weiteres Vorgehen sein.
Wer tiefer in die Materie einsteigen möchte sollte sich mit dem Stichwort „Fingerprinting“ umsehen.
Lidloses_Auge PHP ASP, Fingerprinting, Header, MySQL, nmap, PHP
