Schlagwortarchiv für: Pentest

Von Cyberangriffen geht eine immer größere Bedrohung für Unternehmen aus. Laut Bitkom beläuft sich der Schaden für die deutsche Gesamtwirtschaft pro Jahr auf über 200 Milliarden Euro. Viele Firmen gehen davon aus, die wichtigste Schutzmaßnahme sei, sich eine Reihe von teuren IT-Sicherheitsprodukten einzukaufen und zu betreiben. Dies ist allerdings eine Fehlannahme, die weitreichende Konsequenzen mit sich ziehen kann, denn in der Praxis ist IT-Sicherheit kein Produkt, das man kaufen kann, sondern wird nur durch einen kontinuierlichen und ganzheitlichen Prozess erreicht.

Die IT-Sicherheitswelt ist übersät mit Buzzword-gefüllten Marketingversprechen, hinter denen sich oft nur heiße Luft verbirgt. Wichtige Grundlagen, die für einen sicheren IT-Betrieb essenziell sind, geraten dadurch im Diskurs leider in den Hintergrund. Der Grund dafür liegt auf der Hand: Softwarelösungen, die versprechen, nur durch eine unkomplizierte Installation Abhilfe zu schaffen, lassen sich wesentlich besser vermarkten als ein kontinuierlicher Prozess, bei dem das Unternehmen selbst tätig werden muss.

Produkte wie Antiviruslösungen können zwar im Kontext eines Defense-in-Depth Modells eine zusätzliche Hürde für Angreifer darstellen, dürfen aber nie die Hauptschutzmaßnahme sein. Beispielsweise erleben wir bei unseren Ransomware-Simulationen immer wieder, dass unsere eigens entwickelte Ransomware nicht vom Antivirenprogramm erkannt wird. Dies spiegelt auch die Realität von Ransomware-Angriffen wieder, denn fast alle Opfer setzen eine Virenschutzlösung ein. Die Kriminellen scheint das allerdings nicht zu stören: Bundesweit wird jeden Tag mindestens ein neuer Ransomware-Angriff polizeilich erfasst, bei einer geschätzten Dunkelziffer von bis zu 90 Prozent.

Im Betrieb von Webapplikationen setzen viele Firmen sogenannte Web Application Firewalls (WAFs) ein, die bösartige Requests erkennen und blockieren können, und gehen davon aus, dass Schwachstellen in der darunterliegenden Webanwendung nicht mehr ins Gewicht fallen. Zwar machen WAFs es in der Tat schwerer, vorhandene Schwachstellen auszunutzen, können aber durchaus umgangen werden, was uns in unseren Penetrationstests regelmäßig gelingt. Es ist also wichtig, IT-Sicherheit in den Softwareentwicklungsprozess zu integrieren, sodass Schwachstellen erst gar nicht entstehen.

In einem IT-System, in dem wichtige Grundprinzipien nicht befolgt werden, wirken solche Produkte also wie ein Heftpflaster auf einer klaffenden Fleischwunde. Eines dieser Prinzipien ist ein effektives Patchmanagement, denn auf der technischen Seite ist veraltete Software das größte Einfallstor für Angreifer, die bekannte Sicherheitslücken ausnutzen um in Systeme einzudringen. Das schnelle Einspielen von Sicherheitsupdates ist daher essentiell, um es Angreifern so schwer wie möglich zu machen.

Des Weiteren stellen wir in unseren Penetrationstests häufig fest, dass einfache, aber wichtige Maßnahmen zur Härtung des internen Netzes nicht umgesetzt werden. Leicht abschaltbare Defaulteinstellungen der Active Directory-Umgebung ermöglichen es einem ins interne Netz vorgedrungenen Angreifer sich ungehindert auszubreiten, und das gesamte IT-System zu übernehmen. Auch hier kann kein Produkt das Problem beseitigen, sondern das bestehende System muss vonseiten der Systemadministration sicher konfiguriert werden.

Ausschließlich technische Maßnahmen zu ergreifen ist allerdings nicht ausreichend, denn für Angreifer sind Social Engineering-Angriffe, wie beispielsweise Phishing-Emails, meist der erste Schritt um ins interne Netz zu gelangen. Der Grund dafür ist, dass der Faktor Mensch in den meisten Fällen leichter auszuhebeln ist als technische Systeme. So gelingt es uns bei unseren Phishing-Kampagnen oft, die Passwörter von über 20 Prozent aller Mitarbeiter zu erbeuten, eine erschreckende Zahl in Anbetracht dessen, dass im Zweifel ein einziger Erfolg reicht, um größeren Schaden anzurichten. Die Sensibilisierung der Mitarbeiter für solche Angriffe ist daher essenziell.

Um sich effektiv vor Cyberangriffen zu schützen muss ein Unternehmen also für seine IT-Sicherheit selbst Verantwortung übernehmen und in seine eigenen Prozesse integrieren. Softwareprodukte und Dienstleistungen können dabei unterstützen, sind aber kein Allheilmittel. Um das aktuelle Sicherheitsniveau zu bestimmen, empfiehlt es sich, regelmäßige Sicherheitsanalysen wie Penetrationstests oder Phishing-Kampagnen durchzuführen. Wir von CRISEC unterstützen Sie gerne dabei.

Dieser Beitrag wurde verfasst von Jonas Mönnig.

Eine berüchtigte Liste … Die OWASP Top 10. Sie führt die relevantesten Sicherheitsrisiken für Webanwendungen auf mit dem Ziel, das Management für die Risiken der Webanwendungssicherheit zu sensibilisieren.

Im Webinar erfahren Sie, welche Risiken das im Detail sind, welche Probleme diese Schwachstellen in der Praxis verursachen können und wie Sie mit einem Pentest für Web-Applikationen für die Schließung dieser Sicherheitslücken sorgen können.

Agenda

  • Die OWASP Top 10 im Detail
  • Schwachstellen aus der Praxis
  • Penetrationstest für Web-Applikationen
  • Q&A

Link zur Anmeldung

Author:

Jens Regel & Jens Gödde

Affected version

TANSS version 5.8.23.2 and earlier

Fixed version

TANSS 5.8.23.3

Timeline

  • 2023-05-18 Vulnerabilities discovered
  • 2023-05-26 Send details to vendor
  • 2023-05-27 Vendor confirmed the vulnerability
  • 2023-05-05 Vendor released fix
  • 2023-07-03 CVE request
  • 2023-07-18 CVE assigned
  • 2023-07-21 Public disclosure

Description

During a penetration test, we identified several vulnerabilities in the TANSS 5.8 ticket system. These include 2 SQL injection vulnerabilities and a reflected cross-site scripting vulnerability. Furthermore, several libraries with already known vulnerabilities were identified, which can be exploited by attackers.

The SQL injection vulnerabilities makes it possible, for example, to read all session IDs from the table tanss.session and to set the session ID as a session cookie in the browser in order to log on in the context of another user.

[1] SQL injection

CVE ID: CVE-2023-37736
CVSS: 8.3 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‚SQL Injection‘)

We have identified 2 SQL injection vulnerabilities in the HTTP GET parameters

  • index.php?section=stammdaten&sub=mitarbeiter_show&maID=[SQLi]
  • index.php?section=stammdaten&sub=domain&task=view&id=[SQLi]

These can be exploited using UNION SELECT statements to inject malicious SQL commands. The content of the table tanss.config can be read out as shown in the screenshot below. It is also possible to escalate privileges by extracting the active session IDs from the tanss.session table and then using them as session cookies to log on to TANSS in the context of another user.

Demo:

[2] Cross-site scripting

CVE ID: CVE-2023-37735
CVSS: 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
CWE-79: Improper Neutralization of Input During Web Page Generation (‚Cross-site Scripting‘)

A reflected cross-site scripting vulnerability exists in the HTTP GET parameter index.php?section=bug&sub=[XSS]. As an example, it is possible to mislead users and obtain sensitive information using a manipulated link. In the screenshot below, the JavaScript variable SessionConfiguration.api.key embedded in the HTML code, which contains the bearer token for the TANSS API, is read out. With the additional use of the Fetch API, it would also be possible to send the API key to the attacker.

Demo:

 

[3] Using Components with Known Vulnerabilities

In the TANSS web application, several JavaScript libraries are integrated in outdated and vulnerable versions, which can be used to execute malicious code.

Library: PHP Mailer Version 5.2.14
URL: https://tanss/vendor/php_mailer/changelog.md
CVE ID: CVE-2016-10033, CVE-2016-10045, CVE-2017-5223, CVE-2017-11503, CVE-2018-19296, CVE-2020-13625, CVE-2021-34551, CVE-2021-3603
CWE-1395: Dependency on Vulnerable Third-Party Component

Library: jQuery 1.10.2
URL: https://tanss/ajax/jquery/jquery-1.10.2.js
CVE ID: CVE-2015-9251, CVE-2016-10707, CVE-2020-11023, CVE-2020-11022
CWE-1395: Dependency on Vulnerable Third-Party Component

Library: jQuery UI 1.10.4
URL: https://tanss/ajax/jquery/jquery-ui-1.10.4.custom.min.js
CVE ID: CVE-2021-41183, CVE-2021-41182, CVE-2021-41184, CVE-2022-31160
CWE-1395: Dependency on Vulnerable Third-Party Component

Während eines Erstgesprächs zu einem Penetrationstest ist es wichtig, die Informationsbasis gemeinsam mit dem Kunden zu definieren. Die Informationsbasis legt fest, welche Informationen wir im Vorfeld als unabhängiger Tester über die zu prüfenden Systeme vom Kunden erhalten. Man unterscheidet dabei im Allgemeinen zwischen den Methodiken Blackbox, Whitebox, und Greybox. Nachfolgend erläutern wir den Unterschied zwischen den einzelnen Methodiken.

Blackbox

Durch die Testmethodik Blackbox erhält der Pentester nur rudimentäre Informationen wie bspw. IP-Adressen oder Hostnamen der zu testenden Objekte. Er hat weder Dokumentationen noch Zugänge zum System. Hierbei wird ein Angriff eines externen Täters simuliert, der keinerlei Insiderwissen besitzt und sich alle notwendigen Informationen erst während des Tests erarbeiten muss.

Whitebox

Bei einem Whitebox-Test erhält der Pentester weitreichende Informationen über das zu testende Objekt. Dies kann bspw. der Sourcecode einer Applikation sein, entsprechend detaillierte Dokumentationen der Infrastruktur oder Accounts mit administrativen Berechtigungen. In dieser Methodik wird die Sicht eines potenziellen Innentäters oder Entwicklers simuliert. Der Whitebox-Test ist die umfangreichste und zeitintensivste Testmethodik, da durch die vorherige Offenlegung aller relevanten Informationen der Umfang der zu durchführenden Tests auf ein Maximum steigt.

Greybox

Der Greybox-Ansatz ist eine Kombination aus den beiden anderen Methoden. Der Pentester hat in diesem Fall bereits grundlegende Kenntnisse über die Infrastruktur oder Applikation. Ein gängiges Szenario wäre bspw. der Zugriff mit Benutzerrechten auf eine Webapplikation oder der Test von internen Netzwerkinfrastrukturen unter Verwendung von Topologieplänen und entsprechenden Dokumentationen der aktiven Netzwerkkomponenten.

Der Greybox-Ansatz ist die am häufigsten zum Einsatz kommende Methode und wird zudem von uns empfohlen. Der Vorteil hierbei besteht darin, dass gemeinsam mit dem Kunden definiert werden kann, auf welche Funktionalitäten einer Applikation oder eines Systems der Fokus festgelegt werden soll. Der Pentester kann sich gezielt auf die angegebenen Systeme konzentrieren und diese zielgerichtet analysieren. Im Blackbox-Ansatz muss erst durch umfangreiche Recherche Informationen über das Ziel gesammelt werden. Durch den Mehraufwand der Informationsbeschaffung bleibt weniger Zeit für die tiefergehenden Prüfungen, was ggf. zur Folge hat, dass wichtige Funktionen ungeprüft bleiben. Kontaktieren Sie uns gerne und wir finden gemeinsam mit Ihnen die passende Testmethodik für einen Penetrationstest.