In 4-Schritten: Den richtigen Pentest für Ihr Unternehmen auswählen

Erfahren Sie, welcher Pentest für Ihr Unternehmen sinnvoll ist: ISO 27001, TISAX, Webanwendungen, APIs, AI-Services oder Assume-Breach-Szenarien. Verständliche Erklärung zu Black Box, Grey Box und White Box Pentests sowie Tipps zur Auswahl eines professionellen Pentest-Anbieters mit transparenten Preisen.

Lies weiter

COM-Hijacking

a computer screen with colorful text

COM-Hijacking wird häufig nach einer erfolgreichen Systemkompromittierung eingesetzt und bietet Angreifern eine effektive Möglichkeit, dauerhaft Zugriff zu behalten. Diese Technik kann unbemerkt Schadcode ausführen und stellt somit ein erhebliches Risiko für die Systemsicherheit dar. In unserem Beitrag zeigen wir, wie COM-Hijacking funktioniert, welche Gefahren es birgt und welche Maßnahmen helfen, solche Angriffe zu erkennen und zu verhindern.

Lies weiter

ClickFix & FileFix: Die unterschätzte Gefahr im Social Engineering

OSINT, Passive Reconnaissance

Technische Schwachstellen stehen oft im Fokus der IT-Security – doch die größte Angriffsfläche bleibt der Mensch. Zwei aktuelle Methoden zeigen, wie einfach sich Schutzmechanismen umgehen lassen:

✅ ClickFix: Täuschend echte CAPTCHA-Seiten verleiten Nutzer dazu, harmlose Tastenkombinationen auszuführen. In Wirklichkeit starten sie PowerShell-Befehle – ohne Warnung, ohne Admin-Prompt.
✅ FileFix: Noch perfider – über die Adresszeile des Windows Explorers wird ein vermeintlicher Dateipfad eingefügt, der in Wahrheit ein Systembefehl ist.

Beide Techniken nutzen Vertrauen, Routine und UI-Tricks, nicht technische Exploits. Klassische AV-Lösungen erkennen das kaum.
Schutz? Kombination aus Monitoring, restriktiven Policies und vor allem: Awareness. Nutzer müssen diese Täuschungen kennen, bevor sie klicken.

Lies weiter

Das Ende von HTTP/1.1: Request Smuggling unter der Lupe

black laptop computer turned on on table

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

Wie aus einer initialen SQL-Injection eine Recherche zum Thema URL-Normalisierung und mod_rewrite wurde

a computer screen with colorful text

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

Die Wichtigkeit von OSINT

OSINT, Passive Reconnaissance

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 weiter

Pentestszenarien der realen Welt – 0x01: SQLMap und seine Eigenheiten

In 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

Pentesting the Rainbow – Was sind Purple, Red und Blue Teams

Try the Rainbow - Test the Rainbow
ana cruz QuoNoM9nyz0 unsplash scaled 1

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. 

Hierbei handelt es sich um die visuelle Darstellung verschiedener Testkonzepte im Bereich IT-Security. Neben zahlreichen Begriffen wie Black-Box, Grey-Box und White-Box werden häufig auch Farben zur Veranschaulichung eingesetzt. 

Um diesen Regenbogen einmal in das Farbspektrum aufzubrechen und die Unterschiede zu verstehen, sehen wir uns die Begriffe Red Teaming, Purple Teaming und Blue Teaming genauer an.

Begrifflichkeiten

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.

Was sind die Aufgaben der Teams?

Blue Teaming:

  • Blue Teaming konzentriert sich auf die Verteidigungsseite der Sicherheit. Es beinhaltet die interne Sicherheitsabteilung oder Sicherheitsteams, die sich darauf konzentrieren, Sicherheitsmaßnahmen zu entwickeln, zu implementieren und zu verbessern, um Angriffe zu verhindern oder zu erkennen.
  • Diese Teams führen interne Penetrationstests selbstständig durch, analysieren Sicherheitsprotokolle und -richtlinien, überwachen Netzwerke auf verdächtige Aktivitäten und reagieren auf Sicherheitsvorfälle.

Red Teaming:

  • Red Teaming ist im Wesentlichen das Gegenteil von Blue Teaming. Diese Teams fungieren als Angreifer und versuchen, Schwachstellen in den Sicherheitssystemen eines Unternehmens aufzudecken, indem sie realistische Angriffsszenarien simulieren. Schwachstellen werden aktiv ausgenutzt.
  • Das Ziel von Red Teaming ist es, die Effektivität der Sicherheitsmaßnahmen zu testen, indem sie die Perspektive eines tatsächlichen Angreifers einnehmen. Dadurch können Sicherheitslücken und Schwachstellen aufgedeckt werden, die möglicherweise von den Blue Teams übersehen wurden.

Purple Teaming:

  • Purple Teaming ist eine Kombination aus Red und Blue Teaming. Hierbei arbeiten beide Teams Hand in Hand zusammen, um die Sicherheitslage zu verbessern.
  • Während ein Red-Team Angriffe simuliert, um Schwachstellen aufzudecken, arbeitet das Blue-Team daran, diese Schwachstellen zu identifizieren, zu beheben und präventive Maßnahmen zu entwickeln, um ähnliche Angriffe in Zukunft zu verhindern.
  • Durch diese Zusammenarbeit erhalten beide Teams ein besseres Verständnis für die Stärken und Schwächen der Sicherheitssysteme und können effektivere Verteidigungsstrategien entwickeln.

Green-Teaming:

  • Das Green Team hilft dabei, Best Practices zu identifizieren und sicherzustellen, dass die durchgeführten Übungen die Sicherheitsfähigkeiten des Unternehmens stärken und weiterentwickeln.
  • Das Green Team überwacht den Purple Teaming-Prozess neutral und unterstützt die Zusammenarbeit zwischen Red und Blue Teams.
  • Ziel des Green Teams ist es, die Effektivität der Purple Teaming-Übungen zu maximieren, indem es Feedback gibt und sicherstellt, dass die Ergebnisse den Sicherheitszielen des Unternehmens entsprechen.

Teamaufgaben im Überblick

Red Team

  • Offensive Security / Ethical Hacking
  • Aktive Ausnutzung von Schwachstellen
  • Black Box Pentesting
  • Angriffe auf Webseiten
  • Zielorientierung
  • Social Engineering Angriffe

Purple Team

  • Ausarbeiten von Verbesserungen in Verteidigung und Angriffstests
  • Schulungsaufgabe gegenüber Red und Blue Team
  • Zuständig für Stichprobenkontrolle in größeren Organisationen
  • Informationsaustausch und Aufbereitung

Blue Team

  • Defensive Security
  • Infrastruktur Härtung
  • Schadesnkontrolle
  • Incident Response (IR)
  • Operationssicherheit
  • Proaktive Suche nach Konfigurationsfehlern
  • Digitale Forensik

Unterschied zwischen einem Pentest und Red-Team-Assessment

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:

  1. Red-Teaming:

    • Red-Teaming ist ein umfassenderer Ansatz, der darauf abzielt, realistische Angriffsszenarien zu simulieren, indem er die Taktiken, Techniken und Verfahren (TTPs) von potenziellen Angreifern (Advanced Persistent Threat; APT) nachahmt. Das Red Team handelt wie ein echter Angreifer, indem es verschiedene Angriffspfade und -techniken ausnutzt, um Schwachstellen in den Sicherheitssystemen eines Unternehmens aufzudecken.
    • Das Ziel des Red-Teams ist es, die Effektivität der Sicherheitsmaßnahmen ganzheitlich zu testen, einschließlich der Erkennung, Reaktion und Wiederherstellung nach einem Angriff. Dabei werden nicht nur technische Schwachstellen, sondern auch Schwachstellen in Prozessen, Richtlinien und menschlichem Verhalten berücksichtigt.
    • Sobald ein zuvor definiertes Ziel bei einem Red-Team-Assessment erreicht wurde, gilt das Projekt als abgeschlossen. Anderweitige Angriffswege, welche ggf. ebenfalls zur Erreichung des Ziel führen könnten, werden vernachlässigt.

  2. Penetrationstest (Pen-Test):

    • Ein klassischer Penetrationstest konzentriert sich hauptsächlich darauf, Schwachstellen in einem bestimmten System, einer Anwendung oder einem Netzwerk zu identifizieren. Ein Pentest wird in der Regel von Sicherheitsexperten durchgeführt, die gezielt nach Sicherheitslücken suchen, um sie zu dokumentieren und zu beheben.
    • Im Gegensatz zum Red-Teaming zielt ein Pentest in der Regel nicht darauf ab, realistische Angriffsszenarien zu simulieren oder den gesamten Angriffspfad eines Angreifers über mehrere Infrastrukturkomponenten zu replizieren. Stattdessen konzentriert er sich darauf, Schwachstellen zu identifizieren und den Kunden Berichte darüber zu liefern, wie diese behoben werden können.

Penetrationstest

Standardisierte IT-Sicherheitsüberprüfung
ab 2 PT Projektzeit
  • Fokus auf Vollständigkeit und allen Schwachstellenklassen
  • Standardisierte Vorgehensweise (OWASP, OSSTMM, NIST, BSI)
  • Limitierter Prüfumfang - Enge Abstimmung
  • Keine Verschleierung der Tests - Erkennung irrelevant
  • Keine Notwendigkeit für SIEM, SOC oder Blue-Team
  • Fokus auf eine Testklasse (Web, Mobile, API, Phishing)
  • Zertifizierte Pentester (OSCP, BSCP, CRTP)
Zum Konfigurator
Beginner

Red Teaming

APT Angreifer-Simulation
ab 10 PT Projektzeit
  • Fokus auf realisitische Angriffe und Zielerreichung
  • Individuelle Angriffe, wenig standardisiert (0-Days)
  • Kaum Limitierung im Prüfumfang
  • Verschleierte Tests - Vermeidung der Erkennung
  • Notwendigkeit für SIEM, SOC oder Blue-Team
  • Verkettung mehrerer Testklassen (Infra, AD, Phishing/SE)
  • Zertifizierte Red-Teamer (OSEP, OSEE, CRTO)
Beauftragen
Advanced

5 Irrtümer bei Pentest Ergebnissen

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:

Irrtum 1: Ein Pentest findet sämtliche Schwachstellen die auf dem Target vorhanden 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.

Irrtum 2: Ein Pentest trifft eine Aussage darüber, wie sicher das System gegenüber (zukünftigen) Angriffen ist

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.

Irrtum 3: Risikobewertung ist gleich Priorität

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.

Irrtum 4: DIe Behebung von Schwachstellen löst das Problem

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:

  • In einem Pentest-Bericht wird festgestellt, dass im Web-Verzeichnis des Anwendungsservers eine Datei mit sensitiven Umgebungsvariablen gespeichert wurde. Die Datei mit dem Namen „.env“ wurde bereits während des Pentests an den Kunden kommuniziert und dieser hat die Datei unmittelbar entfernt. Belässt der Kunde seine Behebungsmaßnahmen bei diesem Schritt, so ignoriert er eine komplette Ursachenanalyse und womöglich weitere Schwachstellen, die bestehen.
  • Stellen wir uns die Frage: Warum hat es die .env Datei in das Webverzeichnis geschafft? Nach einer Analyse des Entwicklungs-Repository’s (z.B. GIT) stellen wir fest, dass ein Entwickler die Datei 2 Monate vor Release angelegt hat und in ihr sensitive Umgebungsvariablen speichert. Dies beinhaltet den AWS Secret Key, sowie die Kennwörter des Administrator-Accounts. Dabei hat der Entwickler vergessen, die Datei von der Repository-Indizierung zu exkludieren. Dies wird erreicht, indem die Datei in die „.gitignore“ Liste aufgenommen wird.
    • Wie können wir diesen Fehler in Zukunft beheben?
      • Erkenntnis 1: Mögliche Ursache im Missverständnis der Entwickler: „Entwickler verstehen nicht, welches Risiko fest eingespeicherte („hardcoded“) Passwörter und Schlüssel haben“.
        –> Awareness Seminar mit Entwicklern zum Thema Secure Software Development

        –> Monatliche Session zum Thema „Secrets im Quellcode“

      • Erkenntnis 2: Der Fehler wurde 2 Monate lang nicht bemerkt und erst im Pentest festgestellt.
        –> Möglichkeiten der automatischen Erkennung von Secrets: „Statische Quellcode Analyse“, „Automatisierte Analyse von Commits“, „Automatisierte Scans des Quellcode-Repositories“

        –> Anpassung der CI/CD Pipeline um automatisch sensitive Commits zu Stoppen

      • Erkenntnis 3: Schlechtes Management von sensitiven Schlüsseln
        –> Neues zentrales Tool zum Secrets-Management einführen – Dies verbessert ebenfalls die Durchsetzung von Password-Policies, Passwort-Rotation
    • Haben wir diesen Fehler in der Vergangenheit mehrmals begangen?
      • Erkenntnis 1: Entwickler haben nicht nur eine Anwendung programmiert. Wir stellen fest, dass derselbe Fehler auch in einer benachbarten Anwendung begangen wurde.

        –> Pentest Ergebnis lässt sich auf ähnliche Systeme und Prozesse übertragen

      • Erkenntnis 2: Das Versionsmanagement Tool enthält einen Verlauf aller jemals eingefügten Änderungen

        –> Analyse des gesamten Repository’s auf sensitive Commits

Irrtum 5: Hohe Risiken im Abschlussbericht = "Das Produkt ist schlecht"

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:

  • Fehlentscheidung 1: „Je weniger wir über die Schwachstelle bekannt geben, desto weniger negative Aufmerksamkeit erzeugen wir.“

    –> 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.

  • Fehlentscheidung 2: Es werden verantwortliche Personen für die Schwachstelle gesucht.
    –> Es kommt zu einer fatalen Fehlerkultur im Unternehmen, bei der Fehler nicht mehr offen kommuniziert und korrigiert werden.
    –> Fehler werden als Versagen interpretiert. Lerneffekte und gemeinsames Wachstum bleiben aus.
  • Fehlentscheidung 3: Um im Vorhinein die Identifikation einer kritischen Schwachstelle unwahrscheinlicher zu machen, wird bewusst ein stark eingeschränkter Scope für den Pentest gewählt. Hier ein paar Beispiele:
    • Es wird nur ein bestimmtes Nutzer-Frontend als „in-scope“ betrachtet. Administrative Komponenten dürfen nicht getestet werden.
    • Für den Pentest wird eine Nutzerumgebung bereitgestellt, die keine oder unzureichend viele Testdaten enthält, wodurch essentielle Anwendungsfunktionen nicht getestet werden können.
    • In der produktiven Umgebung „dürfen keine Daten abgesendet werden“. Der Pentest kann somit effektive keine Eingabeverarbeitung testen.
    • Der Einsatz von Intrusion Prevention Systemen oder Web Application Firewalls wird nicht angegeben. Der Pentest wird durch diese Systeme behindert. Ein Ergebnis bildet nicht mehr adäquat das Risiko der Anwendung selbst ab.

    –> 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.

Fazit

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.