Webserver-Pentesting mit Nikto
Besser abdichten
Veröffentlicht in Ausgabe 11/2022 - PRAXIS
Die Liste der erfolgreichen Angriffe über Webserver ist lang. Das liegt zum einen an den Implementierungen der Webserver selbst, die Angreifern durch Programmierfehler Zugriff auf Ressourcen des Betriebssystems ermöglichen, die eigentlich nicht von außen zugänglich sein sollten. Das liegt aber auch an Einstellungen, die Administratoren für Ihre Webserver vornehmen, etwa die Konfiguration von Aliasen, das Erlauben von Verzeichnislistings oder Fehler bei der Absicherung bestimmter Bereiche und Funktionen. Zum Dritten laufen vor allem bei dynamischen Webanwendungen im Hintergrund häufig Interpreter von Skriptsprachen oder Applikationsserver, die selbst wieder Sicherheitsprobleme verursachen können oder einfach unsichere Skripte oder Programme ausführen.
Wenn Sie für die Sicherheit Ihrer Unternehmensinfrastruktur verantwortlich sind, haben Sie vermutlich einen Überblick darüber, welche Webserver aus dem Internet zugänglich sind. Bestenfalls betreiben Sie diese in speziellen Bereichen Ihrer DMZ und setzen Web-Application-Firewalls ein, um Angriffe möglichst zu verhindern. Nikto [1] bietet Ihnen die Möglichkeit, den Webserver, die Konfiguration und die hinterlegten Inhalte zu prüfen, und erstellt Ihnen einen entsprechend ausführlichen Bericht, mit dem Sie die verantwortlichen Kollegen unterstützen können, den Betrieb weiter abzusichern.
Nikto ist in Perl geschrieben und wird bereits seit 2001 entwickelt. Im Gegensatz zu vielen anderen Securityprodukten aus dieser Zeit wird Nikto aber heute noch aktiv weiterentwickelt. Selbst wenn die letzte als stabil gekennzeichnete Version aus dem Jahre 2015 datiert, erhalten Sie über das Git-Repository bei GitHub immer das aktuelle Perl-Skript. Zur Vorbereitung der Tests klonen Sie also zunächst das Git-Repository mit folgendem Kommando:
Die Liste der erfolgreichen Angriffe über Webserver ist lang. Das liegt zum einen an den Implementierungen der Webserver selbst, die Angreifern durch Programmierfehler Zugriff auf Ressourcen des Betriebssystems ermöglichen, die eigentlich nicht von außen zugänglich sein sollten. Das liegt aber auch an Einstellungen, die Administratoren für Ihre Webserver vornehmen, etwa die Konfiguration von Aliasen, das Erlauben von Verzeichnislistings oder Fehler bei der Absicherung bestimmter Bereiche und Funktionen. Zum Dritten laufen vor allem bei dynamischen Webanwendungen im Hintergrund häufig Interpreter von Skriptsprachen oder Applikationsserver, die selbst wieder Sicherheitsprobleme verursachen können oder einfach unsichere Skripte oder Programme ausführen.
Wenn Sie für die Sicherheit Ihrer Unternehmensinfrastruktur verantwortlich sind, haben Sie vermutlich einen Überblick darüber, welche Webserver aus dem Internet zugänglich sind. Bestenfalls betreiben Sie diese in speziellen Bereichen Ihrer DMZ und setzen Web-Application-Firewalls ein, um Angriffe möglichst zu verhindern. Nikto [1] bietet Ihnen die Möglichkeit, den Webserver, die Konfiguration und die hinterlegten Inhalte zu prüfen, und erstellt Ihnen einen entsprechend ausführlichen Bericht, mit dem Sie die verantwortlichen Kollegen unterstützen können, den Betrieb weiter abzusichern.
Nikto ist in Perl geschrieben und wird bereits seit 2001 entwickelt. Im Gegensatz zu vielen anderen Securityprodukten aus dieser Zeit wird Nikto aber heute noch aktiv weiterentwickelt. Selbst wenn die letzte als stabil gekennzeichnete Version aus dem Jahre 2015 datiert, erhalten Sie über das Git-Repository bei GitHub immer das aktuelle Perl-Skript. Zur Vorbereitung der Tests klonen Sie also zunächst das Git-Repository mit folgendem Kommando:
git clone https://github.com/sullo/nikto.git
Wir gehen davon aus, dass Perl bereits auf Ihrem Computer installiert ist. Falls nicht, können Sie das im Repository enthaltene Dockerfile verwenden, um Nikto in einem Alpine-Image zu installieren. Dafür führen Sie innerhalb des Ordners einfach das folgende Kommando aus:
docker build -t nikto .
Anschließend können Sie Nikto ebenso verwenden wie lokal auf Ihrem System. Anstelle von
./nikto.pl
starten Sie einfach den Container mittels
docker run --rm nikto
Mit "--rm" entfernen Sie die erstellte Instanz des Containers direkt nach dem Ende des Programms wieder. So müssen Sie nicht später manuell aufräumen. Testen Sie die generelle Funktionsfähigkeit, indem Sie lokal in den Ordner mit dem Namen "program" wechseln und dort "nikto.pl" ausführen oder alternativ das zuvor erstellte Docker-Image.
Tests gegen den eigenen Webserver
Wählen Sie für Ihren ersten Test bestenfalls einen Webserver, den Sie selbst betreiben. So vermeiden Sie, dass Sie durch entsprechende Angriffserkennung geblockt werden. Während in den anderen Security-Tipps immer die Domain "it-administrator.de" getestet wird, ist der Autor mit Nikto in diesem Monat genau in dieser Angriffserkennung gelandet – ein Aufruf der Webseite ist anschließend von der IP-Adresse nicht mehr möglich. Ersetzen Sie daher in folgendem Aufruf bitte die Domain entsprechend:
./nikto.pl -url it-administrator.de -ssl
Die Sperre bedeutet zwar auf der einen Seite, dass die Angriffserkennung grundsätzlich funktioniert, Sie möchten bei Ihren eigenen Webservern aber (auch) an dieser Angriffserkennung vorbei testen. Der Grund dafür ist relativ einfach: Wenn Sie nach 20 Prozent der Tests von Ihren Sicherheitsmechanismen geblockt werden, dann werden 80 Prozent der Tests am Ende nicht mehr gegen den Webserver beziehungsweise die betriebene Anwendung durchgeführt und Sie erhalten einen Timeout. Natürlich wissen Sie dann am Ende eben nicht, ob Ihre Webanwendung verwundbar ist, und auch nicht, ob Ihre Angriffserkennung auch alle übrigen simulierten Angriffsversuche von Nikto erkannt hätte.
Nikto listet Ihnen derweil auch Informationen über den Server selbst auf, etwa HTTP-Header, Cookies und Redirects. Wir haben testweise einen Ordner "Software" auf dem Webserver angelegt und mit den Logindaten "guest:guest" geschützt. Das herauszufinden, war keine Schwierigkeit für Nikto.
Weitere Tests
Wenn Sie gezielt einzelne Aspekte Ihres Webservers prüfen möchten, bietet Nikto Ihnen einige Optionen dafür an. Möchten Sie etwa auf einen geschützten Bereich zugreifen, können Sie dem Tool die gültigen Credentials mit folgendem Kommando mitteilen:
./nikto.pl -url example.com -id username:password
Möchten Sie nur vereinzelte Tests ausführen, ist dies durch Angabe des "Tuning"-Arguments möglich. Die Ausgabe Ihres ersten Testlaufs stellt Ihnen die Optionen bereit. Um nur SQL-Injections zu testen, führen Sie das folgende Kommando aus:
./nikto.pl -url example.com -Tuning 9
Sie können aber auch nur einzelne Tests von der Testung ausnehmen. Angenommen, Sie möchten alles außer SQL-Injec-tions prüfen, stellen Sie der Abwahl noch ein "x" voran, wie in folgendem Befehl:
./nikto.pl -url example.com -Tuning x9
Nikto unterstützt die Angabe unterschiedlicher Ports für den nächsten Testdurchlauf. Das ist nützlich, weil etwa Tomcat-Umgebungen häufig über unterschiedliche Server beziehungsweise Endpunkte erreichbar sind. Die Auswahl der Ports kann dabei etwa wie bei folgendem Kommando an Nikto übergeben werden:
./nikto.pl -url example.com -p 80,88,443,8080,8443
Wenn Sie Nikto für Ihre Tests weiter konfigurieren möchten, etwa um einen dauerhaften HTTP-Proxy einzustellen, kopieren Sie die Datei "nikto.conf.default" zu "nikto.conf". Hier finden Sie weitere Konfigurationsmöglichkeiten für Ihre Umgebung. Je nachdem, ob Ihr Webserver die anfragenden User-Agents unterscheidet, möchten Sie in der Konfiguration vielleicht die Option "USERAGENT" anpassen. Über das Argument "-useragent" können Sie diese Angabe auch für jeden Aufruf von Nikto individuell mitgeben. Mit der Option "SKIPPORTS" verhindern Sie Anfragen gegen bestimmte Ports, etwa weil Sie schon wissen, dass diese Services verwundbar sind oder Sie hier kein unnötiges Risiko eingehen möchten.
Möchten Sie Nikto ein Cookie mitgeben, etwa für die Authentifikation oder Session-Übernahme bei einer Anwendung, ist dies ebenfalls über die Konfigurationsdatei möglich. Fügen Sie dort dem "STATIC-COOKIE" entsprechende Werte hinzu, werden diese dann bei allen zukünftigen Anfragen mit gesendet. Um an sinnvolle Cookie-Werte wie Session-Variablen zu gelangen, eignet sich etwa Firefox mit eingeschalteten Web-Developer-Tools. Unter dem Punkt "Storage" können Sie dann für jede aufgerufene Domain der letzten Abfrage die Cookie-Werte anzeigen lassen. Von hier kopieren Sie einfach den Inhalt in die Nikto-Konfigurationsdatei. Damit Nikto die Konfiguration verwendet, geben Sie den Pfad einfach beim nächsten Aufruf über die Kommandozeile mit:
./nikto.pl -url example.com -config ./nikto.conf
Sollte Ihnen die Ausgabe auf der Konsole nicht gefallen oder ausreichen, können Sie die Ausgabe auch im HTML-Format erhalten. Hierfür wählen Sie die Argumente wie in folgendem Beispiel:
./nikto.pl -url example.com -ssl -output results.html -Format htm
Neben HTML stehen Ihnen noch CSV, Text oder XML als Ausgabeformate zur Verfügung. Die Darstellung des Reports im HTML-Format erhöht mitunter die Lesbarkeit und die Weitergabe der Ergebnisse. Außerdem hinterlegt Nikto hier noch etwas mehr Informationen und die Links zu den verursachenden Ressourcen. Nikto benötigt je nach durchgeführtem Test unterschiedliche Angaben externer Datenbanken und Plug-ins. Diese sind über die Plattform "cirt.net" des Entwicklers abrufbar. Dort finden Sie beispielsweise eine Default-Passwort-Datenbank, die Sie auch individuell auf der Seite verwenden können. Möchten Sie also Nikto mit den dort hinterlegten Daten aktualisieren, verwenden Sie das folgende Kommando:
./nikto.pl -update
Fazit
Mit Nikto prüfen Sie Ihre Webserver auf bekannte Verwundbarkeiten. Das Werkzeug ist einfach zu bedienen und übersichtlich in seiner Funktion. Es erfüllt seinen Zweck und kann mit anderen Pentesting-Tools mithalten.
(dr)
Link-Codes
[1] Nikto: https://cirt.net/Nikto2