Neue Sicherheitsforschung zeigt gravierende Schwachstellen im HTTP/1.1-Protokoll. Die Angriffstechnik „Request Smuggling“ betrifft auch moderne Webserver und bleibt vielfach unerkannt. Die empfohlene Lösung: Umstieg auf HTTP/2 für eine bessere Absicherung der Webanwendungen.
#Cybersecurity #RequestSmuggling #HTTP2
Lies weiter
Der Artikel beleuchtet, wie eine SQL-Injection-Sicherheitsanalyse zur tiefergehenden Untersuchung der URL-Normalisierung und der Apache-Funktion mod_rewrite führte. Dabei wird erklärt, wie unterschiedliche URL-Darstellungen durch mod_rewrite zu einheitlichen Pfaden umgeleitet werden können – ein Prozess, der jedoch Sicherheitsrisiken birgt, wenn er nicht korrekt umgesetzt wird. Besonders im Fokus steht die Gefahr, dass durch unzureichende Normalisierung Angriffsvektoren entstehen, etwa durch doppelte Slashes oder alternative Kodierungen. Der Beitrag bietet technische Einblicke und zeigt Lösungsansätze zur sicheren Konfiguration von Rewrite-Regeln.
Lies weiter
In einer Zeit, in der Cyberangriffe täglich raffinierter und gezielter werden, ist ein ganzheitlicher Blick auf die eigene IT-Angriffsfläche essenziell. Viele Unternehmen investieren bereits in regelmäßige Penetrationstests, um ihre Systeme und Applikationen auf Schwachstellen zu prüfen.
Was dabei jedoch häufig übersehen wird: Der erste Schritt eines realen Angreifers ist in der Regel nicht der aktive Scan, sondern die passive Informationsgewinnung. Auch bekannt als Open Source Intelligence (OSINT) oder Passive Reconnaissance.
Lies weiterIn diesem Artikel analysieren wir, wie SQL-Injections trotz Anti-CSRF-Maßnahmen mit SQLMap ausgenutzt werden können. Dabei beschreiben wir ein real angetroffenes Pentesting-Szenario, in dem gängige Schutzmechanismen umgangen wurden.
Während unserer Tests stießen wir auf einen bisher unbekannten Bug in SQLMap, der dazu führte, dass das Tool in bestimmten Fällen nicht wie erwartet funktionierte und wie wir dennoch in der Lage waren, die Schwachstelle auszunutzen.
Zum praktischen Nachvollziehen haben wir eine CTF-Challenge erstellt, die es ermöglicht, diese Techniken selbst auszuprobieren. Unser Ziel ist es, praxisnahe Einblicke in moderne Angriffsmethoden und deren Abwehr zu geben.
Lies weiter
So oder so ähnlich lautet bereits ein Werbeslogan einer weltweit bekannten Süßigkeiten-Marke aus den United States of America. Im Bereich Offensive Security und Pentesting geht es hier allerdings weniger um Snacks.
Red Teaming ist eine Methode zur Überprüfung der Cyber-Sicherheit, bei der ein dediziertes Team (das „Red Team“) die Sicherheitssysteme einer Organisation durch simulierte Angriffe testet. Im Gegensatz zu traditionellen Sicherheitsaudits umfasst Red Teaming aktive Angriffssimulationen, bei denen das Team versucht, Schwachstellen zu identifizieren und zu kompromittieren. Dadurch erhalten Organisationen realistische Einblicke in ihre Sicherheitslage und können ihre Verteidigungsstrategien verbessern.
Blue Teaming ist der Gegenpart zum Red Teaming und bezeichnet die interne Sicherheitsabteilung einer Organisation, die sich mit der Erkennung und Abwehr von Angriffen befasst. Im Rahmen von Blue Teaming arbeiten Sicherheitsexperten daran, potenzielle Angriffe zu erkennen, zu analysieren und zu stoppen, die von einem Red Team simuliert werden. Im Gegensatz zum Red Team konzentriert sich das Blue Team darauf, die Verteidigungsfähigkeiten der Organisation zu stärken und Sicherheitslücken zu schließen, um potenzielle Angriffe abzuwehren.
Purple Teaming ist eine Methode, die das Beste aus Red und Blue Teaming kombiniert. Dabei arbeiten das Red und Blue Team eng zusammen, um Angriffsszenarien zu simulieren, Schwachstellen zu identifizieren und die Verteidigungsfähigkeiten der Organisation zu verbessern. Im Gegensatz zu reinem Red oder Blue Teaming legt Purple Teaming den Schwerpunkt darauf, die Zusammenarbeit zwischen Angriffs- und Verteidigungsteams zu stärken, um die Reaktionsfähigkeit der Organisation auf realistische Bedrohungen zu optimieren. Wenn hierfür ein spezielles Team eingesetzt wird spricht man vom Purple Team.
Green Teaming ist ein Konzept, das sich darauf konzentriert, die Sicherheitsbewusstseinskultur innerhalb einer Organisation zu stärken. Im Gegensatz zu Red, Blue oder Purple Teaming liegt der Schwerpunkt beim Green Teaming nicht auf der Simulation von Angriffen oder der Erkennung von Sicherheitslücken, sondern vielmehr auf der Förderung von Sicherheitsbewusstsein und Best Practices bei den Mitarbeitern. Das Green Team bietet Schulungen, Sensibilisierungsmaßnahmen und Ressourcen zur Unterstützung der Mitarbeiter bei der Erkennung und Vermeidung von Sicherheitsrisiken im Arbeitsalltag.
Black-Box-Tests beziehen sich auf Sicherheitsüberprüfungen, bei denen die Tester keinerlei Kenntnisse über die internen Strukturen oder Systeme des zu testenden Systems haben. Sie finden buchstäblich im Dunklen statt und die Tester arbeiten sich hier voran. Im Gegensatz dazu beziehen sich White-Box-Tests auf Tests, bei denen die Tester detaillierte Kenntnisse über die interne Funktionsweise und Implementierung des Systems haben. Dies ermöglicht genaue Ergebnisse mit geringer Fehlerquote gegenüber false/positive-Findings. Grey-Box-Tests liegen dazwischen, wobei die Tester über begrenzte Kenntnisse verfügen, die ihnen einen teilweisen Einblick in das System ermöglichen, aber nicht die gesamte interne Funktionsweise offenlegen. Hier wird versucht das beste aus Black- und White-Box Tests zu kombinieren und möglichst reale und genaue Ergebnisse zu liefern.
Blue Teaming:
Red Teaming:
Purple Teaming:
Green-Teaming:
Die Hauptunterschiede zwischen einem klassischen Penetrationstests und einem Red-Teaming Ansatz liegen im Wesentlichem am Ansatz sowie Ziel des Projektes. Darüber hinaus unterscheidet sich die Projektdauer bei beiden Testarten in der Regel erheblich.
Während ein klassischer Penetrationstest einen festen Projektrahmen bezüglich Zeit und Testinhalt ausfüllt, kann sich ein Red Teaming Assessment potenziell über einen sehr weiten Zeitraum erstrecken. Dies ist darin begründet, dass beim Red Teaming in der Regel nur das Ziel, jedoch nicht der Weg dorthin, definiert wird. Mitglieder eines Red Teams besitzen deshalb verschiedene Möglichkeiten und Wege, um das definierte Ziel zu erreichen. Eine Einschränkung der potenziell kompromittierbaren Zielsysteme oder erlaubten Angriffswege findet in der Regel weniger statt. Bei einem Penetrationstest hingegen wird sehr detailliert vorgegeben, welches Prüfobjekt getestet werden soll, welche Tests exkludiert werden, welche Methologien zum Einsatz kommen und es findet ein reger, transparenter Austausch während des Tests statt.
Darüber hinaus finden Red-Team-Assessments zumeist in der Testart „Black-Box“ statt. Die Mitglieder eines Red Teams, demnach die simulierten Angreifer, besitzen im Vorfeld kaum bis keine Informationen über den Aufbau der IT-Infrastruktur eines Unternehmens. Durch diese „blinde“ Herangehensweise kann zwar ein realistischer Angriff simuliert werden, dieser erfordert jedoch mehr Zeit und Aufwand in der Vorbereitung (OSINT, Recherche zum Unternehmen, Entwurf zugeschnittener Exploits und Möglichkeiten zur Umgehung von AV/EDR).
Sobald ein zuvor definiertes Ziel bei einem Red-Team-Assessment erreicht wurde, gilt das Assessment als abgeschlossen. Der Angriffsweg wird hierbei von den Mitgliedern des Red Teams protokolliert, alle ausgenutzten Schwachstellen und Fehlkonfigurationen in einem Bericht erläutert und Empfehlungen zur Behebung gegeben. Ob es neben diesen einem Angriffsweg noch weitere Wege gibt, um das Ziel des Red Teaming Assessment zu erreichen, bleibt unbekannt.
Um dies durch Stichpunkte kurz darzustellen:
Red-Teaming:
Penetrationstest (Pen-Test):
Especially for companies that operate larger infrastructures, a pentest can often provide more insights than is typically assumed. We show you how to interpret pentest results correctly and get the maximum benefit from them.
One of the main reasons is a wrong perspective on the results of a test. Typical assumptions are:
A first important realization is that penetration tests can never detect all vulnerabilities on a target system. This is for the following reasons: Firstly, the test is limited in time, and secondly, not all configuration parameters are known about the system for most tests.
Conclusion: A pentest alone cannot be used to make a target application more secure. A pentest report without critical findings does not mean that the application can contain absolutely no vulnerabilities.
Consequence: Use the full range of testing options for application audits: Code reviews, peer reviews, Secure Software Development training. The earlier vulnerabilities are discovered, the higher the profit. Early code reviews focusing on weaknesses, code complexity and „bad smells“ can uncover errors in the design, data model or programmer understanding. A pentest usually only takes place at a release status of the application where major changes are no longer possible.
If vulnerabilities are identified in a pentest, it should always be evaluated whether these errors may also be present in other application components. Particularly in the case of input validation vulnerabilities, it is often not possible to identify all vulnerable parameters in a test. It should also be analyzed whether the faulty design may have been used in other applications.
A pentest is always just a snapshot of currently known vulnerabilities and the target system in its configuration and version at the time of the test. Just because a current report shows „low“ as the overall risk does not mean that a new vulnerability will not be published in the future that compromises the entire system.
Pentests should therefore not be seen as a one-off measure, but rather as a method for regularly checking an application or IT system for known vulnerabilities.
We often see that pentest results are processed further without a more detailed discussion of the risk. The risk assessment of the pentesters is seen as „set in stone“. Here we would like to point out that a discussion of the identified vulnerabilities with your IT security team can lead to a meaningful weighting or prioritization of the results. Depending on the threat model you have developed (e.g. in a risk/impact analysis as part of ISO 27001 certification), there may be vulnerabilities whose elimination should be prioritized differently than the external assessment of the pentest report.
As Pentest Factory, we are happy to support this discussion (e.g. in a joint meeting) in order to create an overall picture of the target system and risk in its environment.
Another aspect is the risk assessment system itself. When using the standard CVSS system (without environment metrics), the overall risk is calculated from a formula that leaves us as testers little room for context-dependent upgrading or downgrading of risks. For example, you can only choose between „High Attack Complexity“ and „Low Attack Complexity“ for the „Attack Complexity“ metric. Accordingly, attacks of medium complexity cannot be mapped here. This is similar for the other metrics in the CVSS system. This means, for example, that we may classify a finding with medium criticality as „high risk“ because the CVSS formula calculates this.
In general, it makes sense to discuss the individual results and assigned risks in the team.
The result of a pentest is a final report. This lists identified weaknesses and provides specific recommendations for remedying the findings.
At first glance, it appears that the main task after the test is completed is to eliminate these weaknesses.
However, as a pentest service provider, we often see that remedying vulnerabilities is the only activity resulting from a test result. For this reason, it is all the more important to understand that the real value of the pentest lies in the identification of faulty processes. It is worth asking about every weak point „Why did this vulnerability occur? How can we correct the process behind it?„
This is the only way to ensure that, for example, a missing patch management process or inadequate asset management is corrected and that software deployments are not running again with missing updates after a month.
Since we very often see that a root cause analysis is omitted after the pentest has been completed, we would like to show a second example in which an understanding of the process that went wrong can bring significant added value in terms of safety:
–> Monthly session on „Secrets in the source code“
–> Customization of the CI/CD pipeline to automatically stop sensitive commits
–> Pentest result can be transferred to similar systems and processes
–> Analysis of the entire repository for sensitive commits
Just because a „critical“ vulnerability is identified does not mean that the development or the product is „bad“. Products that provide a particularly large number of functions have a particularly large number of potential attack surfaces. The best examples are well-known products such as browsers or operating systems that release monthly security patches.
As experts in the field of cybersecurity for many years, we see that the biggest problems arise from a defensive mindset and an inadequate response to risks. Specifically, the following fatal decisions are made:
–> Maximum transparency is the only correct response, especially after a vulnerability becomes known. What exactly is the weak point? Where does this occur? What is the worst-case scenario? Maximum transparency is the only way to determine the exact cause and ensure that all parties involved understand the risk sufficiently to initiate countermeasures.
The vulnerability should never be seen as the fault of an individual or the company, but as an opportunity to react. The response to a vulnerability (not the vulnerability itself) determines to a large extent what damage can actually be done.
–> These or other restrictions lead to an incorrect risk image of the target system. Instead of recognizing vulnerabilities as early as possible, the complexity and risk potential of the application grows step by step. If a vulnerability is detected late, it becomes more time-consuming and therefore more costly to close it.
As a pentest service provider, it is important to us that our customers get the maximum benefit from a pentest. For this reason, we often hold team discussions to identify trends and make the best possible recommendations. This article is the result of these discussions over the last few years and aims to open up new perspectives on the pentest results.
Do you have any questions or need support with pentesting, secure software development or improving internal processes? Please use the contact form, we will be happy to assist you.
Insbesondere für Unternehmen, die größere Infrastrukturen betreiben, können aus einem Pentest oft mehr Erkenntnisse gewonnen werden, als typischerweise angenommen wird. Wir zeigen Ihnen, wie Sie Pentest Ergebnisse richtig interpretieren und einen maximalen Nutzen daraus ziehen.
Einer der Hauptgründe ist eine falsche Perspektive auf die Ergebnisse eines Tests. Typische Annahmen sind:
Eine erste wichtige Erkenntnis ist, dass Penetrationstests nie alle Schwachstellen auf einem Zielsystem erkennen können. Dies hat folgende Gründe: Zum einen ist der Test zeitlich begrenzt, zum anderen sind bei den meisten Tests nicht alle Konfigurationsparameter über das System bekannt.
Fazit: Ein Pentest kann nicht allein dazu herangezogen werden eine Zielanwendung sicherer zu machen. Ein Pentest Bericht ohne kritische Feststellungen bedeutet nicht, dass die Anwendung absolut keine Schwachstellen enthalten kann.
Konsequenz: Nutzen Sie bei Anwendungs-Audits die volle Bandbreite an Testmöglichkeiten: Code-Reviews, Peer-Reviews, Schulungen zum Secure Software Development. Je früher Schwachstellen entdeckt werden, desto höher ist der Gewinn. So lassen sich durch frühzeitige Code-Reviews mit Fokus auf Schwachstellen, Code-Komplexität und „Bad Smells“ Fehler im Design, im Datenmodell oder im Verständnis der Programmierer aufdecken. Ein Pentest erfolgt meist erst zu einem Release-Status der Anwendung, wo größere Änderungen nicht mehr möglich sind.
Wenn Schwachstellen in einem Pentest identifiziert werden, so sollte immer ausgewertet werden, ob diese Fehler womöglich auch in anderen Applikationskomponenten vorhanden sein können. Gerade bei Schwachstellen bei der Eingabevalidierung lassen sich in einem Test oft nicht alle verwundbaren Parameter identifizieren. Ebenfalls sollte analysiert werden, ob das fehlerhafte Design ggf. in anderen Anwendungen zum Einsatz kam.
Ein Pentest ist immer nur eine Momentaufnahme aktuell bekannter Schwachstellen und des Zielsystems in seiner Konfiguration und Version zur Testzeit. Nur weil ein aktueller Bericht als Gesamtrisiko „niedrig“ ausweist, heißt dies nicht, dass nicht zukünftig eine neue Schwachstelle veröffentlicht wird, die das gesamte System kompromittiert.
Pentests sollten daher nicht als einmalige Maßnahme betrachtet werden, sondern sind vielmehr eine Methode zur regelmäßigen Überprüfung einer Anwendung oder eines IT-Systems auf bekannte Schwachstellen.
Wir sehen oft, dass Pentestergebnisse ohne eine nähere Diskussion des Risikos weiterverarbeitet werden. Die Risikobewertung der Pentester wird als „in Stein gemeißelt“ gesehen. Hier weisen wir drauf hin, dass eine Diskussion der identifizierten Schwachstellen mit Ihrem IT-Sicherheitsteam zu einer sinnvollen Gewichtung oder Priorisierung der Ergebnisse führen kann. Je nachdem, welches Threat Model Sie erarbeitet haben (z.B. in einer Risk/Impact-Analyse als Teil der ISO 27001 Zertifizierung) kann es Schwachstellen geben, deren Behebung anders priorisiert werden sollte, als es der Pentestbericht von außen beurteilt.
Gerne können wir als Pentest Factory diese Diskussion (z.B. in einem gemeinsamen Meeting) unterstützen, um ein Gesamtbild des Zielsystems und Risikos in seiner Umgebung zu kreieren.
Ein weiterer Gesichtspunkt ist das Risikobewertungssystem selbst. Bei der Verwendung des Standard CVSS Systems (ohne Environment-Metriken), wird das Gesamtrisiko aus einer Formel errechnet, die uns als Testern wenig Freiraum zur kontextabhängigen Herauf- oder Herabstufung von Risiken lässt. Beispielsweise lässt sich für die Metrik „Attack Complexity“ ausschließlich zwischen „High Attack Complexity“ und „Low Attack Complexity“ wählen. Dementsprechend lassen sich Angriffe mit einer mittleren Komplexität hier nicht abbilden. Dies ist ähnlich für die weiteren Metriken im CVSS-System. Somit kann es z.B. vorkommen, dass wir eine Feststellung mit mittlerer Kritikalität als „hohes Risiko“ einstufen, weil die CVSS-Formel dies errechnet.
Generell macht eine Besprechung der einzelnen Ergebnisse und zugewiesenen Risiken im Team somit Sinn.
Das Ergebnis eines Pentests ist ein Abschlussbericht. Dieser führt identifizierte Schwachstellen auf und gibt konkrete Empfehlungen zur Behebung der Feststellungen.
Es erscheint auf den ersten Blick, dass die Behebung dieser Schwachstellen die Hauptaufgabe nach Abschluss des Tests ist.
Als Pentest Dienstleister sehen wir jedoch häufig, dass die Behebung von Schwachstellen die einzige resultierende Tätigkeit aus einem Testergebnis ist. Aus diesem Grund ist es umso wichtiger zu verstehen, dass der eigentliche Wert des Pentests in der Identifikation von fehlerhaften Prozessen liegt. Bei jeder Schwachstelle lohnt es sich zu fragen „Warum ist es zu dieser Schwachstelle gekommen? Wie können wir den Prozess dahinter korrigieren?„
Nur auf diese Weise kann gewährleistet werden, dass z.B. ein fehlender Patch-Management-Prozess oder ein mangelhaftes Asset-Management korrigiert werden und Software-Deployments nicht nach einem Monat wieder mit fehlenden Updates laufen.
Da wir sehr häufig sehen, dass eine Ursachenanalyse nach Abschluss des Pentests entfällt, möchten wir ein zweites Beispiel zeigen, bei dem ein Verständnis des fehlerhaft abgelaufenen Prozesses einen deutlichen Mehrwehrt in der Sicherheit bringen kann:
–> Monatliche Session zum Thema „Secrets im Quellcode“
–> Anpassung der CI/CD Pipeline um automatisch sensitive Commits zu Stoppen
–> Pentest Ergebnis lässt sich auf ähnliche Systeme und Prozesse übertragen
–> Analyse des gesamten Repository’s auf sensitive Commits
Nur weil eine „kritische“ Schwachstelle identifiziert wird, heißt dies nicht, dass die Entwicklung oder das Produkt „schlecht“ sind. Gerade Produkte, die besonders viele Funktionen bereitstellen, haben besonders viele mögliche Angriffsflächen. Bestes Beispiel sind bekannte Produkte wie Browser oder Betriebssyteme, die monatliche Sicherheitspatche herausbringen.
Als langjährige Experten im Bereich Cybersecurity sehen wir, dass die größten Probleme durch eine defensive Denkweise und eine unzureichende Beantwortung (=Reaktion) von Risiken auftreten. Konkret kommt es zu den folgenden fatalen Entscheidungen:
–> Gerade nach Bekanntwerden einer Schwachstelle ist maximale Transparenz die einzig richtige Antwort. Was genau ist die Schwachstelle? Wo tritt diese auf? Was ist das worst-case Szenario? Nur durch maximale Transparenz kann eine genaue Ursachenbestimmung erfolgen und sichergestellt werden, dass alle Beteiligten das Risiko ausreichend verstehen, um Gegenmaßnahmen einzuleiten.
Die Schwachstelle sollte nie als Fehler einer einzelnen Person oder des Unternehmens angesehen werden, sondern als eine Möglichkeit zu Reagieren. Die Antwort auf eine Schwachstelle (nicht die Schwachstelle selbst) bestimmt in großem Rahmen, welcher Schaden tatsächlich angerichtet werden kann.
–> Diese oder weitere Beschränkungen führen zu einem falschen Risiko-Abbild des Zielsystems. Anstelle Schwachstellen so früh wie möglich zu erkennen, wächst die Komplexität und das Risikopotential der Anwendung schrittweise. Wenn eine Schwachstelle verspätet erkannt wird, wird es aufwändiger und damit kostenintensiver diese zu schließen.
Als Pentest Dienstleister ist es uns wichtig, dass unsere Kunden den maximalen Nutzen aus einem Pentest ziehen können. Aus diesem Grund führen wir häufig Diskussionen im Team, um Trends zu erkennen und bestmögliche Empfehlungen zu geben. Dieser Artikel ist das Resultat dieser Diskussionen über die letzten Jahre und möchte neue Sichweisen auf die Pentest Ergebnisse eröffnen.
Haben Sie Fragen oder brauchen Sie Unterstützung bei den Themen Pentesting, Secure Software Development oder der Verbesserung von internen Prozessen? Nutzen Sie gerne das Kontaktformular, wir unterstützen Sie gerne.
Häufig können wir in Gesprächen mit Neukunden feststellen, dass der Markt der Penetration Testing Dienstleistungen undurchsichtig erscheint und es schwer ist, sich für einen Dienstleister zu entscheiden. Dabei wird oftmals Fokus auf den Preis eines Pentests gesetzt und andere Entscheidungskriterien entfallen.
Mit diesem Artikel wollen wir Ihnen eine grundlegende Orientierungshilfe geben, um Penetration Testing Dienstleister qualitativ bewerten zu können und Ihre Entscheidungsfindung zu vereinfachen.
Eine Problematik die sich im Bereich Pentesting ergibt ist das Thema Erfahrung. Das Angreifen von Computersystemen erfordert Kreativität, Flexibilität und ein Verständnis von einer Breite an Technologien und Plattformen. Während mehrjährige Erfahrung als Entwickler oder Security Officer den Einstieg erleichtern können, ersetzen diese trotzdem keine praktischen Kenntnisse in der Funktionsweise von Sicherheitsmechanismen und wie diese angegriffen werden können.
Aus diesem Grund empfehlen wir einen Fokus darauf zu legen, wie viele Jahre ein Penetration Tester bereits Tests durchführt und welche praktisch orientierten Qualifikationen dieser besitzt. Im Folgenden haben wir einige häufig zu findende Qualifikationen aufgeführt und welche Kenntnisse hiermit effektiv attestiert werden.
Wie aus den Beschreibungen ersichtlich wird, weist einzig der OSCP von den hier aufgeführten Zertifizierungen tatsächliche praktische Kenntnisse in der Kompromittierung von Computersystemen nach. Wir empfehlen Ihnen Tester zu beauftragen, die eine praktische Qualifizierung ähnlich zu OSCP besitzen. Um die erfolgreiche Qualifizierung und Gültigkeit einsehen zu können, empfehlen wir den Dienstleister nach einem Nachweis zu fragen (z.B. digitaler Link zu Credly, Credential.net oder ein Scan-Abzug des erworbenen Zertifikats eines Testers).
Wie zuvor beschrieben bietet die OSCP Zertifizierung einen guten Anhaltspunkt, um essentielle Kompetenzen eines Penetrationstesters verifizieren zu können. Mit der OSCP Zertifizierung sind Kenntnisse für die Enumerierung und das Testen von einzelnen Hosts und Diensten nachgewiesen.
Da moderne Anwendungen jedoch in ihrer Komplexität extrem gewachsen sind, empfehlen wir den Dienstleister zu fragen, welche Spezialisierungen die einzelnen Tester besitzen und diese Spezialisierungen nachweisen zu lassen (z.B. Zertifizierungen, Kundenreferenzen, CVE-Einträge). Besonders bei komplexen Prüfobjekten sollte der Tester mit den Technologien vertraut sein und sich im entsprechenden Bereich spezialisiert haben. Das gilt insbesondere für Bereiche wie Webanwendungen, API-Schnittstellen, Active Directory, Mobilanwendungstests, SAP Tests und viele mehr.
Wenn Sie ein Angebot anfragen, so sollte das Angebot auf die zu testende Applikation oder Infrastruktur abgestimmt sein. Hierzu sollte der Dienstleister in Erfahrung bringen, welchen Umfang das Testobjekt besitzt und auf dieser Grundlage eine Einschätzung treffen, wie viele Tage getestet werden müssen.
Sollte der Dienstleister keine Details über Ihr Prüfobjekt erfragen und Ihnen „blind“ ein Angebot zusenden, so kann es entweder vorkommen, dass zu wenige Tage einkalkuliert wurden, was dazu führt, dass die Applikation weniger tief getestet werden kann oder sogar bestimmte Komponenten ausgelassen werden. Alternativ kann es ebenso passieren, dass zu viele Tage für das Testobjekt veranschlagt werden und Sie diese einfach bezahlen müssen, obwohl der Test schon im Vorfeld hätte abgeschlossen werden können.
Tipp: Sollten Sie sich an mehrere Dienstleister gleichzeitig wenden (z.B. in einer Ausschreibung), so sollten Sie das Testobjekt so genau wie möglich beschreiben (verwendete Technologien, typische Applikationsfunktionen und Abläufe, Anzahl der Hosts). Diese Angaben erleichtern das Erstellen eines passenden Angebotes und reduzieren die Wahrscheinlichkeit, dass der Testumfang oder die Testmethodik falsch gewählt wird.
Nach der Durchführung eines Penetrationstests ist der Abschlussbericht das zentrale Dokument, was die Ergebnisse des Pentests festhält. Achten Sie daher besonders auf die Qualität des Abschlussberichtes und lassen Sie sich einen Beispielbericht im Vorfeld der Beauftragung zukommen.
Jede Feststellung sollte eine klare Beschreibung mit Screenshots beinhalten, die den Weg zur Identifikation und Ausnutzung der Schwachstelle darstellt, damit Sie oder Ihre Entwickler die Problematik verstehen und gegebenenfalls nachstellen können. Ebenfalls sollte jede Feststellung eine Erläuterung enthalten, welches Risiko der Schwachstelle zugeordnet wurde und worauf diese Zuordnung basiert (z.B. anhand Risikobewertungsmethoden wie CVSS oder OWASP).
Der Bericht sollte alle Rahmenparameter des Tests eindeutig aufführen und typische W-Fragen erläutern, wie zum Beispiel:
– Wann wurde getestet (Zeitraum)?
– Was wurde getestet (Prüfumfang)?
– Was wurde ggf. nicht getestet (Scope)?
– Wie wurde getestet (Methodik)?
– Wer hat den Test durchgeführt (Ansprechpartner)?
– Welche Risikobewertungsmethode kam zum Einsatz?
– Welche Tools, Skripte und Programme kamen zum Einsatz?
Fragen Sie den Dienstleister nach einem Beispielbericht und vergleichen Sie die Berichte miteinander, um das ideale Berichtformat für Sie zu wählen. Achten Sie ebenfalls auf eine Management Summary, welche die Testergebnisse in einer nicht technischen Sprache auf Managementebene zusammenfasst. Dies ist besonders wichtig, da die Details von Feststellungen oftmals sehr technisch bzw. komplex sind und nur von technischem Personal nachvollzogen werden können.
Oftmals vermischen sich die Begriffe Schwachstellenscan und Penetrationstest. Ein Schwachstellenscan ist ein automatisiertes Verfahren, mit dem ein Programm eigenständig oder auf der Basis bestimmter Scanparameter das Testobjekt auf Schwachstellen testet. Hierbei erfolgt kein manuelles Testen durch einen Menschen.
Seien Sie vorsichtig, wenn anstelle eines Penetrationstests ein Schwachstellenscan beworben wird. Viele Schwachstellen sind kontextabhängig und lassen sich nur durch manuelles Testen identifizieren. Zudem können Schwachstellenscanner False-Positive-Ergebnisse liefern, die also keine tatsächlichen Schwachstellen darstellen.
Um effizient zu testen, können ein oder mehrere automatisierte Scans Teil eines Penetrationstests sein. Sie sollten jedoch sicherstellen, dass der Dienstleister einen Fokus auf manuelle Verifikation der Ergebnisse und manuelles Testen des Prüfobjekts legt. Die automatisch generierten Testergebnisse sollten nicht direkt in den Bericht einfließen, lediglich nach einer manuellen Verifizierung. Jede Feststellung sollte eine genaue Darstellung beinhalten, wie die Schwachstelle verifiziert wurde.
Bevor ein Penetrationstest legal durchgeführt werden kann, muss die Erlaubnis des Hosters zwingendermaßen eingeholt werden. Sollten Sie Ihre Anwendung oder Infrastruktur nicht selbst hosten, so müssen Sie unbedingt den Hoster nach einer Erlaubnis zum Testen fragen. Ausgenommen hiervon sind einige Cloud-Hoster, die Penetrationstests explizit erlauben (z.B. Microsoft Azure, Amazon AWS, Google Cloud). Stellen Sie sicher, dass alle Freigaben vor Testbeginn erteilt wurden. Der Penetrationstest Dienstleister sollte diese Problematik von sich aus aufbringen und unbedingt mit Ihnen vor Testbeginn abklären.
Damit eindeutig zugeordnet werden kann, welche Angriffe von Ihrem Dienstleister durchgeführt werden und welche Angriffe eine reale Bedrohung darstellen, sollte der Dienstleister die Tests von einer festen IP-Adresse durchführen. Fragen Sie hierzu Ihren Dienstleister, ob eine solche statische IP-Adresse besteht und bringen Sie diese im Vorfeld der Tests in Erfahrung. Sie können während des Tests ebenso Ihre Logdateien nach der IP-Adresse durchsuchen und Einblicke bekommen, welches Anfragevolumen der Test generiert hat. Seien Sie vorsichtig bei der Wahl des Dienstleisters, sollte dieser keine eindeutige IP-Adresse für seine Tests nutzen. Lassen Sie sich darüber hinaus immer die Kontaktdaten der Person geben, welche die technischen Tests durchführt. So haben Sie die Möglichkeit bei Problemen oder technischen Fragen unmittelbar einen technischen Ansprechpartner zu kontaktieren und umgehend Rückmeldung zu erhalten. Weiterhin können Sie so ausschließen, dass ein Subdienstleister für die Durchführung der Tests intransparent oder ggf. inoffiziell beauftragt wurde.
Ein Penetrationstest einer Webanwendung sollte sich an der öffentlichen Standard-Testmethodologie „OWASP“ orientieren. Das OWASP Konsortium stellt Vorgehensweisen für das Testen von allen aktuellen Schwachstellenkategorien zur Verfügung. Diese sollte unbedingt getestet werden.
Sollten Sie eine Anwendung testen wollen, die eine Nutzeranmeldung und geschützte Nutzerbereiche zur Verfügung stellt, so empfehlen wir die Durchführung eines „grey-box“ Tests. Hierbei werden dem Dienstleister Testkonten bereitgestellt, wodurch interne Bereiche hinter einer Anmeldung effizienter und granularer getestet werden können. Achten Sie darauf, ob der Dienstleister diese Testmethodik vorschlägt oder fragen Sie ggf. aktiv nach der Testmethodik.
Falls eine API-Schnittstelle getestet werden soll, so sollte der Dienstleister eine Schnittstellendokumentation oder eine Sammlung an beispielhafter API-Anfragen anfragen (z.B. Swagger.json, Postman Collections). Ohne eine API-Dokumentation ist das Testen von APIs nicht zielführend, da Endpunkte und Parameternamen erraten werden müssen. Dies kann zur Folge haben, dass wichtige Endpunkte übersehen und Schwachstellen nicht entdeckt werden.
Ein Infrastrukturtest bei dem mehrere Hostsysteme auf ihre verfügbaren Dienste getestet werden, besteht in der Regel aus mehreren automatisierten Scans am Anfang eines Tests kombiniert mit manuellen Testeinheiten und einer anschließenden Verifikation der Scanergebnisse.
Active Directory Umgebungen sind sehr dynamisch und erfordern Spezialwissen, das über eine Grundqualifikation wie OSCP hinausgeht. Vergewissern Sie sich, dass der Tester Ihrer AD Umgebung Fortbildungen und Zertifizierungen im Bereich Windows und Active Directory Sicherheit besitzt. Dazu können zum Beispiel die praktischen Zertifizierung Certified Red Team Professional (CRTP) oder Certified Red Team Expert (CRTE) gehören. Jedoch auch viele andere Weiterbildungen im Bereich Azure AD und Windows Umgebungen.
Die meisten Organisationen und Unternehmen verwenden das Active Directory in ihrer Infrastruktur als zentrale Lösung für die Verwaltung ihrer Ressourcen. Dabei stehen viele vor großen Herausforderungen bei der Absicherung und Stärkung dieser Active Directory-Umgebungen. Fehlendes Fachwissen, begrenzte Budgets, architektonische Herausforderungen aufgrund historisch-gewachsener Systemlandschaften sowie die daraus resultierende Notwendigkeit, Legacy-Systeme zu unterstützen, sind mögliche Ursachen für anfällige IT-Systeme.
Für Bedrohungsakteure stellt das Active Directory eine verlockende Zielscheibe dar, da eine erfolgreiche Kompromittierung in der Regel Zugang zu fast allen Unternehmensressourcen ermöglicht. Dies bietet Angreifern eine ideale Möglichkeit, z. B. Ransomware in das Netzwerk einzuschleusen, um finanzielle Forderungen stellen zu können.
Durch das Bekanntwerden von Schwachstellen im Active Directory besteht jederzeit die Gefahr, dass ganze Active Directory-Umgebungen ohne großen Aufwand kompromittiert werden können. Dabei ist es zunächst einmal unerheblich, über welchen Account oder über welche Schwachstelle der Einbruch gelungen ist. Denn ist den Angreifern der initiale Einbruch in das Firmennetzwerk gelungen, suchen sie nach sogenannten „Low-Hanging-Fruits“ innerhalb der Active Directory Umgebung, um Ihre Rechte auszuweiten.
Gerade für kleinere und mittelständische Unternehmen gestaltet sich das frühzeitige Erkennen von Angriffen auf das Active Directory als schwierig. Aufgrund der Firmengröße verfügen deren IT-Abteilungen in der Regel nicht über ein zureichendes Budget und die notwendigen Ressourcen für den Betrieb von Enterprise Security Lösungen wie SIEM oder EDRs. Doch gerade das rechtzeitige Erkennen von Angriffen ist entscheidend, um schnell zu reagieren und Schäden an der Reputation sowie finanzielle und datenschutzrechtliche Folgen zu vermeiden, bevor sie sich verschlimmern können.
Dennoch können mit Hilfe von „Deception“-Techniken auch Unternehmen, die lediglich über geringe IT-Security-Budgets verfügen, produktunabhängig bestimmte Angriffe wie Kerberoasting auf das Active Directory frühzeitig erkennen und deren Ausführung verzögern. Hierfür müssen gewisse Voraussetzungen erfüllt und präventive Maßnahmen bei der Nutzeranlage von sogenannten „Decoys“ getroffen werden. Diese „Decoys“ werden innerhalb einer Active Directory Umgebung platziert, um die Aufmerksamkeit von Angreifern auf diese zu ziehen, um so einen Alert auszulösen.
Kerberoasting ist eine effiziente Technik für Angreifer, die lediglich über wenig Rechte innerhalb einer Domäne verfügen. Im Jahr 2014 präsentierte Tim Medin den Kerberoasting-Angriff bei seiner Präsentation „Attacking Microsoft Kerberos – Kicking the Guard Dog of Hades“ auf der Derbycon Konferenz. Beim Kerberoasting wird die Eigenheit bei der User-Anlage in Microsoft Kerberos ausgenutzt, dass jeder gültige Domain-User einen Ticket Granting Server (TGS) für einen beliebigen Dienst beantragen und anschließend das Ticket für Offline-Passwort-Cracking-Versuche verwenden kann.
Je nach Stärke der Passwörter können Angreifer in kurzer Zeit und in den meisten Fällen relativ unbemerkt Benutzeraccounts kompromittieren und diese für weitere Angriffe verwenden.
Die einzige Voraussetzung für die Durchführung eines solchen Angriffs ist die Kenntnis über die existierenden Benutzerkonten, die einen sogenannten „Service Principal Name“ (SPN) gesetzt haben. Da alle existierenden SPNs mit einem simplen LDAP Query abgerufen werden können, stellt dies eine vergleichsweise geringe Einstiegsbarriere dar.
Gelingt es also dem Angreifer einzelne oder alle SPNs zu kennen, kann er im System Service Tickets (TGS) für ebenjene anfragen. Die durch die Abfrage erlangten Service-Tickets residieren im Arbeitsspeicher des Angreifers, aus welchem er diese anschließend extrahieren und auf einer Festplatte speichern kann. Nachdem der Eindringling nun über die TGS-Tickets aller Service Accounts verfügt, kann er versuchen, die verschlüsselten Teile der Tickets mit Hilfe eines Brute-Force-Angriffs zu entschlüsseln.
Zur praktischen Ausnutzung der gefundenen Schwachstelle in Microsoft Kerberos stehen mehrere öffentlich verfügbare Tools bereit. Die bekanntesten sind das Python-Skript GetUserSPNs.py und das PowerShell-Script Invoke-Kerberoast. In diesem Beispiel verwendet unser fiktiver Angreifer GetUserSPNs.exe (eine statisch kompilierte Version von GetUserSPNs.py für Windows) für die Durchführung.
Um den Angriff möglichst realistisch zu beschreiben, verfügt der Angreifer in unserem Szenario zunächst lediglich über ein unprivilegiertes Benutzerkonto, um die TGS Tickets anzufordern und deren Hashes für den Cracking-Prozess zu extrahieren. Dieser Account ist jedoch für das Tool GetUserSPNs.exe bereits ausreichend.
Die gewonnene Ausgabedatei kann im Anschluss in jedes beliebige Passwort-Cracking Tool importiert werden, mit deren Hilfe ein Offline-Brute-Force Angriff auf die extrahierten Hashes durchgeführt wird. Der Vorteil von Offline-Cracking Angriffen besteht darin, dass sie selbst keine Spuren im System des angegriffenen Unternehmens hinterlassen und somit nicht entdeckt werden können. Darüber hinaus ermöglichen sie eine deutlich höhere Anzahl von Brute-Force-Versuchen pro Sekunde im Vergleich zu jeglichen Online-Angriffen.
hashcat -a 0 -m 13100 -O kerberoasted_impacket.txt /opt/wordlists/Top2Billion-probable-v2/Top2Billion-probable-v2.txt -r rules/hob064.rule
Wie in der oberigen Abbildung sichtbar, war es dem Passwort-Cracking-Tool möglich, einen der extrahierten Hashes in die Klartextform zurückzurechnen. Dem Angreifer erlaubt die gewonnene Information die Kontrolle über den betroffenen Account und ermöglicht es ihm so, seine Rechte im Netzwerk auszuweiten.
Auch wenn Kerberoasting-Angriffe vergleichsweise unbehelligt erfolgen, gibt es doch einige Hinweise, die ein aufmerksamer Administrator im Domain-Controller selbst erkennen kann. Denn analysiert man die Logging-Aktivitäten auf dem Domain-Controller während eines Angriffs, dann fallen folgende Events auf:
Die oben beschriebene Anfrage eines TGS-Tickets für einen SPN hinterlässt in Form der erzeugten Event-ID 4769 ihre Spuren im angegriffenen System. Sieht man sich das erzeugte Event genauer an, findet man dort weite Angaben zum angefragten „Service Name“, dem „Ticket Encryption Type“ sowie der IP-Adresse des anfragenden Systems. Diese Attribute helfen, einen Angriff frühzeitig zu erkennen.
Auch wenn Kerberoasting-Angriffe die oben beschriebenen Spuren im System hinterlassen, ist es doch relativ unwahrscheinlich, dass ein Administrator diese sofort bemerkt und dementsprechend zeitnah agieren kann. Daher ist es sinnvoll bereits bei der Implementierung der Active Directory die Deception-Techniken mit einzuplanen und umzusetzen.
Hierfür werden sogenannte „Decoys“ – also ungenutzte „Honeypot“-Accounts – erstellt, die als leere Attrappen für potenzielle Angreifer dienen. Hierbei wird die Tatsache ausgenutzt, dass während eines Kerberoasting-Angriffs mehrere Anomalien in den Windows-Logs zu sehen sind. Insbesondere die Tatsache, dass die bekannten Tools standardmäßig SPN-Tickets für alle Accounts, die ein „SPN-Attribut“ gesetzt haben, anfordern (siehe Abbildung 1: LDAP Query zum Extrahieren von allen Domain Accounts die einen SPN gesetzt haben), kann als Frühwarnsystem verwendet werden.
Diese „Honeypot“-Accounts haben nämlich keine eigentliche Funktion im Active Directory und sollten im Regelfall nicht verwendet werden. Im „normalen“ Betrieb werden für diese also keine „TGS“-Tickets für den Service angefragt. Ist dies doch der Fall, handelt es sich mit hoher Wahrscheinlichkeit um den Versuch eines Kerberoasting-Angriffs.
Bei der Anlage des Honeypot-Accounts im Active Directory gelten einige Besonderheiten im Vergleich zu normalen Usern, wie der folgende PowerShell-Befehl zeigt:
New-ADUser -Name "DBAdmin" -DisplayName "DBAdmin" -SamAccountName "dbadm" -description "DatabaseAdministrationAccount" -UserPrincipalName "dbadm" -GivenName "Database" -Surname "Administrator" -AccountPassword ((ConvertTo-SecureString "kd329-/Sl2(2)02(§23kcJk3A$" -AsPlainText -Force)) -Enabled $true -Path "OU=ServiceAccounts, OU=AdministrativeAccounts, DC=WINDOMAIN, DC=LOCAL" -ChangePasswordAtLogon $false -PasswordNeverExpires $trueIm Anschluss kann mithilfe des „setspn“-Befehls eine SPN für den betroffenen Account gesetzt werden.
setspn -s http/wef.windomain.local:1433 windomain.local\dbadmNach Setzen des SPNs sollte folgende Meldung erscheinen:
Wir verwenden in diesem Beispiel den Windows Event Viewer zur Erkennung eines potenziellen Angriffs, um zu demonstrieren, dass dies bereits mittels Standard-Funktionen innerhalb des Active Directorys bzw. Windows realisierbar ist. Selbstverständlich ist es auch möglich dies mittels Monitoring-Lösungen von Drittanbietern umzusetzen.
Der Windows Event Viewer bietet sich für das Tracking von Anomalien bei „Honeypot“-Accounts an, da dort sogenannte „Custom Views“ erstellt werden können, die nach spezifischen Events filterbar sind. Um Ticket-Anfragen des erstellten Honeypot Accounts herauszufiltern, kann folgende XML-Syntax verwendet werden:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[EventData[Data[@Name='ServiceName'] and (Data='dbadm')]]
and
*[System[(EventID='4769')]]
</Select>
</Query>
</QueryList>Eine mögliche „Custom“-View würde bei einer SPN Ticket-Anfrage des Honeypot-Accounts wie folgt aussehen:
Die „Custom View“-Ansicht erlaubt neben der einfachen Anlage von Events auch die Einstellung von „geplanten Aufgaben“, die im Falle eines neuen Events für den im „Custom View“ eingestellten Filter ausgeführt werden.
Windows Event Viewer bietet dafür folgende bereits eingebaute Funktion an:
In diesem Beispiel wird eingestellt, dass bei Auslösen des Events eine E-Mail an den „Administrator“ der AD-Umgebung gesendet wird.
Bei der Ausführung des Kerberoasting-Angriffs auf den Honeypot-Account erhält dieser eine E-Mail zur Alarmierung bei potenziell bösartigen Aktivitäten.
Bereits mit einem geringen IT-Security-Budget ist es möglich, Angriffe wie Kerberoasting frühzeitig zu erkennen. Gelingt es, den Angriff zu verzögern oder im besten Fall sogar zu stoppen, können schlimmere Folgen für das Unternehmen abgewendet werden. Natürlich bilden derartige Alert-Systeme nur einen Baustein bei der Einführung und Umsetzung von Sicherheitssystemen, um die eigene IT-Infrastruktur zu schützen. Dennoch zeigt das Beispiel Kerberoasting, wie einfach und wirksam Deception-Techniken implementiert werden können.
Fast jeder kennt das Thema Spam: Man erhält E-Mails die von unschlagbaren Rabatten, Millionengewinnen für das eigene Portemonnaie oder einem gesperrten Bankaccount erzählen.
Während unseres Arbeitsalltages bei der Pentest Factory konnten wir jedoch eine weitaus effektivere Methode als Smishing aufdecken, die uns gezielt dazu verleiten sollte auf einen bösartigen Link zu klicken.
In diesem Fachartikel stellen wir die Techniken und unsere Analysen vor.
Lies weiterSie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr Informationen