IT-Security (3/4): Ergebnisse des Penetrationstests mit Nmap auswerten und Befunde beheben

Dieser Artikel beginnt mit der Ergebnisauswertung des Nmap-Scans aus dem vorherigen Artikel. Anschließend zeigen wir, wie sich die Befunde, die im Rahmen des Nmap-Scans identifiziert wurden, gezielt beheben lassen. Der vorherige, zweite Artikel dieser Beitragsserie zum Thema »IT-Security« beleuchtete einen wichtigen Bestandteil von IT-Sicherheitsüberprüfungen: die Penetrationstests. Davor beschrieben wir unsere IT-Sicherheitsaudits zur Evaluation und Absicherung einer IT-Infrastruktur.

Rückblick

Im zweiten Teil unserer Beitragsreihe zum Thema »IT-Security« stellten wir unser kleines Testnetzwerk vor. Dabei präsentierten wir, wie Nmap (ein klassisches Tool für Penetrationstests) zur Identifikation von Verwundbarkeiten genutzt werden kann und wie dazu passende Einträge einer Verwundbarkeitsdatenbank aufgelistet werden können. Dazu wurde der Nmap-Schalter -A benutzt, der neben geöffneten Ports auch weitere Informationen ermittelt (wie beispielsweise Zielbetriebssystem, Version und weitere Zusatzinformationen je nach Dienst). Zusätzlich wendeten wir mit dem –script-Schalter das Skript vulscan.nse an. Das Ergebnis (Kurzfassung ohne vulscan.nse-Ergebnisse) ist in der nachfolgenden Grafik zu sehen:

Dabei stellten wir fest, dass die Ergebnisse des Nmap-Scans grundsätzlich ein erwartetes Ergebnis lieferten: Port 80 und 443 sind geöffnet (typisch für Webdienste). Darüber hinaus ließen sich aber auch ungewöhnliche Ergebnisse identifizieren: Zum Beispiel wurde auch Port 445 als offen ermittelt, obwohl es untypisch ist, dass ein Webserver diesen Port zum Internet hin geöffnet hat.

Auswertung der Ergebnisse des Nmap-Scans

Die Ergebnisse des Scans zeigen, dass Nmap eine Vielzahl von Informationen über das Zielsystem ermitteln konnte. In diesem Artikel wird auf eine manuelle Nachprüfung und Verifikation der einzelnen Befunde verzichtet.

Befund »Samba smbd«

Wir beginnen mit einer Auswertung des Befundes in der letzten Zeile: Port 445. In der Liste der standardisierten Ports (Wikipedia) wird dieser in Verbindung mit Diensten wie »Microsoft-DS Active Directory«, »Windows-Freigaben (CIFS)« oder »Microsoft-DS SMB-Freigaben« (auch bekannt unter dem Namen der freien Implementierung »Samba«) gebracht. Windows nutzt diesen Port für verschiedene Zwecke. Beispielsweise nutzen Windows oder auch ältere Programme über diesen Port NetBIOS zur elementaren Kommunikation in einem Netzwerk. Der Port ist außerdem für den gemeinsamen Zugriff auf Drucker oder für Microsoft-DS Dateiaustausch notwendig. In den Ergebnissen sieht man, dass Nmap das Produkt »Samba smbd« hinter dem Port identifizieren konnte. Der Scanner konnte außerdem zusätzliche Informationen wie beispielsweise die Arbeitsgruppe (»Testgroup«) ermitteln und die Version des Produkts auf 3.X – 4.X eingrenzen. Im Abschnitt »Host Script Output« des Nmap-Ergebnisberichts ist zu sehen, dass das Nmap-Skript dafür den »guest«-Account verwenden konnte. Außerdem warnt es davor, dass »message_signing« deaktiviert ist. Zusammengefasst lässt sich sagen, dass ein wohl unsicher konfigurierter Dienst, der für einen Webserver nicht notwendig ist, im Internet angeboten wird. In erster Näherung ist davon auszugehen, dass hier die Firewall zu großzügig konfiguriert wurde. Es ist daher eine entsprechende Filterregel in der Firewall einzuführen bzw. eine vorhandene Regel zu schärfen. Im Sinne der Serverhärtung sollte der Dienst besser komplett deinstalliert werden.

Befund »Apache httpd«

Port 80 und 443 werden üblicherweise zum Ausliefern von Webseiten benutzt bzw. um Dienste mittels einer REST-API anzubieten. Port 80 wird standardmäßig für eine unverschlüsselte Übertragung und Port 443 für eine verschlüsselte Übertragung verwendet. Nmap konnte auch hier viele interessante Informationen sammeln.

HTTP-Methoden

Wie in den Ergebnissen zu sehen, haben die Nmap-Skripte alle erlaubten HTTP-Methoden ermittelt und aufgelistet (GET, POST, HEAD, TRACE, OPTIONS). Hier sollte man individuell und in Abhängigkeit von der Webanwendung entscheiden, welche Methoden tatsächlich notwendig sind. Im untersuchten Fall gehen wir aus Demonstrationsgründen davon aus, dass die Methoden POST und OPTIONS nicht notwendig ist. Die OPTIONS-Methode wird verwendet, um vom Server die unterstützten Methoden und Merkmale abzufragen. Mit der POST-Methode werden üblicherweise große Datenmengen (z.B. Formulardaten oder Bilder) zur weiteren Verarbeitung an den Server gesendet.
Nmap hat außerdem auch die Methode TRACE ermittelt und zurecht als potenziell risikoreiche Methode bezeichnet. Die TRACE-Methode ist für das Debugging von Verbindungen sinnvoll. Denn durch die Methode liefert ein Server die Anfrage so zurück, wie er sie empfangen hat. Es kann damit überprüft werden, ob und wie eine Anfrage auf dem Weg zum Server verändert worden ist. Sind weitere domänenübergreifende Schwachstellen im Browser vorhanden, könnten Angreifer diese Methode missbrauchen, um auf Informationen im HTTP-Header (z.B. auf Cookies oder Authentifizierungsdaten) zuzugreifen, indem sensible Header-Informationen von allen Domänen, die ebenfalls HTTP-TRACE unterstützen, gelesen werden. Für den Produktivbetrieb sollte diese Methode daher auf jeden Fall deaktiviert werden.

HTTP-Header

Mit dem Skript »http-server-header« wurden durch Nmap einige vom Webserver gesendeten Informationen zum Betriebssystem und zu den aktivierten Modulen übermittelt. Mit diesen Informationen kann ein potenzieller Angreifer eine Menge erfahren: verwendetes Betriebssystem (Ubuntu), Version und Hersteller des Webservers (Apache Webserver in der Version 2.2.17) sowie, welche Module (mod_ssl, OpenSSL, PHP) in welcher Version eingesetzt werden. Mit diesen Informationen kann dann gezielt in Verwundbarkeitsdatenbanken gesucht werden und mögliche Exploits können ausgewählt werden. Natürlich geben die Versionsinformationen auch einen Hinweis darauf, ob die jeweilige Software veraltet ist. Sie sind aber auch mit Vorsicht zu genießen, da verschiedene Distributionen Sicherheitspatches einspielen, ohne die Version zu erhöhen. In den vorliegenden Ergebnissen kann man in erster Näherung davon ausgehen, dass es sich um ein veraltetes System handelt. Apache in Version 2.2.17 wurde am 13. Oktober 2015 veröffentlicht und ist mittlerweile stark veraltet. Der 5.3.X-Branch von PHP wurde am 14. August 2014 mit Version 5.3.29 zuletzt mit Updates versorgt. Ausgehend von den Befunden müssen die Komponenten daher auf jeden Fall aktualisiert werden. Es ist außerdem auch nicht ratsam, diese Informationen preiszugeben – generell sollten nur unbedingt notwendige Informationen preisgegeben werden.

HTTP-Titel

Diese Information liefert lediglich den Titel der Indexseite zurück.

Behebung der Befunde des Penetrationstests

Zur Behebung der Befunde sollten in erster Linie die veralteten Komponenten aktualisiert werden. Dies entschärft bereits eine große Zahl der Verwundbarkeiten. Im untersuchten Fall handelt es sich um das Linux-Betriebssystem Ubuntu. Bei einer näheren Analyse im untersuchten System zeigte sich, dass das Betriebssystem selbst bereits nicht mehr vom Hersteller unterstützt wird und ebenfalls aktualisiert werden muss. Es sollte darauf geachtet werden, dass sich die im Produktivbetrieb befindlichen Systeme immer auf dem aktuellen Patchstand befinden. Da Apache in unserem Beispiel aus den Paketquellen des Betriebssystems installiert wurde, werden diese auch zur Aktualisierung der Komponenten verwendet.

Information Disclosure beheben

Neben der veralteten Version konnte eine »Information Disclosure« identifiziert werden: Viele Informationen werden vom System grundlos an nicht autorisierte Benutzer preisgegeben. Dieses Problem ist durch eine Neukonfiguration bestimmter Parameter in der Apache-Konfiguration behebbar. Bei dem in dieser Demo verwendeten Betriebssystem Ubuntu wechselt man dazu in das Verzeichnis /etc/apache2/conf-enabled und öffnet die Datei security.conf. Bei anderen Distributionen kann sich die Datei bzw. können sich die Einstellungen an einer anderen Stelle befinden. In der Datei wird die Konfiguration der folgenden Parameter angepasst:

Unnötige HTTP-Methoden deaktivieren

Zur Deaktivierung unnötiger HTTP-Methoden muss (falls nicht bereits aktiviert) das Apache-Modul allowmethods aktiviert werden.
Der Befehl hierzu lautet: a2enmod allowmethods
Anschließend können in den entsprechenden <Directory>-Direktiven die erlaubten HTTP-Methoden angegeben werden.

Beispiel:
<Directory />
     # Andere Optionen wurden zur besseren Darstellung ausgeblendet
     AllowMethods GET HEAD
</Directory>

Nachdem die Änderungen erfolgt sind, muss die Konfiguration von Apache neu geladen werden.

Überprüfung der Änderungen

Nachdem die sicherheitsrelevanten Änderungen erfolgt sind, müssen diese auch auf ihre Wirksamkeit hin geprüft werden.
Dazu sind erneute Penetrationstests mit Nmap notwendig. Der Nmap-Scan wird mit folgendem Befehl durchgeführt:
nmap -A –oX result.xml 192.102.162.236

Das Ergebnis sieht besser als nach dem ersten Scan aus:

Aus den Ergebnissen des Nmap-Scans wird ersichtlich, dass alle nicht notwendigen Informationen ausgeblendet und die HTTP-Methoden eingeschränkt wurden. Nmap konnte aufgrund des »Server«-Headers zwar identifizieren, dass ein Apache Webserver eingesetzt wird, aber nicht, welche Version eingesetzt wird. Um auch die verbleibende Informationspreisgabe zu deaktivieren, muss zusätzlich das Modul security2 eingesetzt werden. Nach der Installation über die Paketquellen lässt es sich mit dem Befehl a2enmod security2 aktivieren. In der Datei (Pfad gilt für das Beispielsystem Ubuntu Server) /etc/modsecurity/modsecurity.conf kann hierzu die Option SecServerSignature konfiguriert werden. Wichtig dabei ist, dass dahinter zwei Hochkommata mit einem Leerzeichen dazwischen folgen: SecServerSignature “ „

Mit dieser Konfiguration verschwindet auch der letzte Hinweis auf den Server:

Ausblick

Die in diesem Artikel durchgeführten Maßnahmen bilden nur einen kleinen Teil zur Absicherung eines Servers ab. Im nächsten Artikel (Teil 4 unserer Beitragsserie zum Thema »IT-Security«) werden weitere Aspekte der Serversicherheit beleuchtet. Dabei untersuchen wir eine WordPress-Installation, die Stärke der Transportverschlüsselung eines Servers und die Sicherheitsheader.