Freitag, 12. November 2010


Topthema

Donnerstag, 28. Mai 2009 | Topthema

About Security #206: Schwachstellen-Suche: Webserver identifizieren

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/048970)

Angriffe auf den Webserver und die Suche nach dafür ausnutzbaren Schwachstellen sind das Thema dieser und der kommenden Folgen. So, wie eine normale Anwendung auf das Betriebssystem und seine Funktionen angewiesen ist, ist eine Webanwendung auf den Webserver angewiesen. Ein Angreifer, der die Kontrolle über den Webserver erlangt, kann danach auch die Webanwendung kompromittieren.

Angriffe auf Webserver erfolgen i.A. über zwei Klassen von Schwachstellen: Fehler in der Konfiguration und Schwachstellen im Webserver selbst. Der erste Schritt bei der Suche nach entsprechenden Schwachstellen besteht daher darin, das zukünftige Opfer zu erkennen. Bei der Untersuchung der eigenen Webanwendung kann dieser Schritt entfallen, da der verwendete Webserver, seine Version und installierte Patches bekannt sind. Einem Angreifer bleibt aber nichts anderes übrig, als sich diese Informationen selbst zu beschaffen.

Erkennen des Webservers

Das Ermitteln des verwendeten Webservers und seiner Version ist auf den ersten Blick sehr einfach: Die entsprechenden Angaben sind im HTTP-Header 'Server' jeder Response des Servers enthalten. Request- und Response-Header kann man sich z.B. vom Online-Tool Web-Sniffer anzeigen lassen. Probiert man damit einige Server aus, wird man schnell feststellen, das der Server-Header zwar teilweise den Namen und die Versionsnummer des Webservers enthält, manchmal sogar samt Angaben über das Betriebssystem und installierte Erweiterungen wie z.B. Apache-Module, teilweise aber gar nicht vorhanden ist, nur den Namen ohne jede Versionsinformationen oder auch Phantasiedaten enthält.

Der Grund ist leicht ersichtlich: Man möchte einem möglichen Angreifer keine unnötigen Informationen liefern. Da diese Informationen für den Client i.A. uninteressant sind, besteht auch keine Notwendigkeit dazu, sie zu übertragen. Entsprechend wird in der Spezifikation des Hypertext Transfer Protocol (HTTP/1.1), RFC 2616, dieser Header auch als optional definiert:

Note: Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable option.

Entsprechend stellen die meisten Webserver die Möglichkeit bereit, den Server-Header gar nicht zu übertragen oder einen beliebigen Wert auszugeben.

Fingerprinting des Webservers
About Security: Alle Folgen

Aber auch ohne, das der Webserver seinen Namen und Versionsnummer verrät, kann man ihn erkennen. Das Erkennen eines Servers, Betriebssystems etc. an seinem charakteristischen Verhalten wird als "fingerprinting" bezeichnet. Im Fall eines Webservers hilft z.B. die Reihenfolge der einzelnen Header-Einträge bei der Erkennung. Als Beispiel die Header zweier "prominenter" Domains, einmal mit einem Apache-Webserver und einmal mit Microsofts IIS:

Apache.org

HTTP/1.1 200 OK
Date: Sun, 17 May 2009 09:02:57 GMT
Server: Apache/2.2.9 (Unix)
Last-Modified: Thu, 16 Apr 2009 04:33:51 GMT
ETag: "17a484c-5686-467a4922469c0"
Accept-Ranges: bytes
Content-Length: 22150
Cache-Control: max-age=86400
Expires: Mon, 18 May 2009 09:02:57 GMT
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

Microsoft.com

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Length: 1020
Content-Type: text/html
Last-Modified: Mon, 16 Mar 2009 20:35:26 GMT
Accept-Ranges: bytes
ETag: "67991fbd76a6c91:0"
Server: Microsoft-IIS/7.0
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI
  TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
Date: Sun, 17 May 2009 09:03:57 GMT
Connection: keep-alive

Die Reihenfolge der Header-Einträge unterscheidet sich, und wenn man genug Informationen darüber gesammelt hat, kann man anhand der charakteristischen Reihenfolge die verschiedenen Server auch ohne Server-Header erkennen.

Eine weitere Möglichkeit, einen Webserver zu erkennen, sind die für die verschiedenen Webserver spezifischen Icon-Bilder, wie es in About Security #134 für das Erkennen eines Webservers mit Hilfe von JavaScript beschrieben wurde. Dazu dienen z.B. für Microsofts IIS das 36x48 Pixel große Bild /pageerror.gif oder für Apache-Webserver das 20x22 Pixel große Bild /icons/c.gif. Auch die Standard-Fehlerseiten für HTTP-Fehlercodes wie 404 oder 500 können herangezogen werden, um einen Server zu erkennen.

Ein schon etwas älteres Fingerprinting-Tool ist httprint von Net-Square, dessen Grundlagen im Paper 'An Introduction to HTTP fingerprinting' von Saumil Shah beschrieben werden.

Fingerprinting erschweren

Um Fingerprinting zu erschweren, muss der Webserver nur so konfiguriert werden, das sich sein Verhalten von einer Standardkonfiguration unterscheidet. Außer dem Deaktivieren des Server-Headers können dazu z.B. auch weitere nicht benötigte Header deaktiviert und die Reihenfolge der verbleibenden Header geändert werden. Die HTTP-Fehlermeldungen können durch eigene ersetzt werden, ebenso die Standard-Icons. Weitere ggf. vorhandene Standardseiten wie z.B. Begrüßungsseiten für neu angelegte Websites etc. können ebenfalls entfernt oder durch eigene ersetzt werden.

In der nächsten Folge werden Angriffe auf die identifizierten Webserver beschrieben.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

Kommentare

Folgende Links könnten Sie auch interessieren