What is ethical hacking?

... und etwas deutscher ...

Vulnerability Assessment vs Pentest

• Ersteres ist eher ein Scan (und oft auch Teil eines Pentest)
• und kann sehr gut automatisiert und daher regelmäßiger durchgeführt werden
• Pentests erfordern Expertise und manuellen Einsatz (unter Zuhilfenahme von automatisierten Tools)
• Je nach Scope dauern
  Vuln. scans einige Minuten bis Stunden
  Pentests einige Tage bis Wochen
• Empfohlen (aber auch von Größe und Art des Unternehmes und der IT abhängig):
  • Vuln. scans: wöchentlich bis vierteljährlich
  • Pentest: viereljährlich bis jährlich
  • beides auf jeden Fall aber nach signifikanten Systemänderungen

Standards?

There is no standard!

• Aber einige gute Frameworks
• OWASP Web Security Testing Guide (OWASP, Open Web Application Security Project)
• Open Source Security Testing Methodology Manual (ISECOM, Institute for Security and Open Methodologies)
• Technical Guide to Information Security Testing and Assessment (NIST, National Insitute of Standards and Technology)
• Penetration Testing Guidance (PCI SSC, Payment Card Industry Security Standards Council)
• and many more, like PTES (a very practical wiki guide, no HTTPS though!)

Pentest Lifecycle

1. Pre-engagement phase define the scope!
2. Intelligence gathering
3. Vulnerability analysis
4. Exploitation
5. Post-exploitation phase
6. Reporting

1. Pre-engagement phase

Der Auftrag

• Rechtliche und technische Rahmenbedingungen müssen zwischen Kundin und Pentester:in ausgehandelt werden
• Rules of engagement schriftlich definiert und von beiden Seite unterschieben:
  • Goal & scope
  • Timeline & milestones
  • Haftung und Verantwortlichkeiten
  • Erlaubte Methoden
  • Zu erwartende Ergebnisse
• It is dangeours to go alone!
• It is much more dangerous to go without rules of engagement!

Goal

• Der Grund für den Auftrag: warum will der Kunde einen Pentest
• Wie in der Softwareentwicklung auch: Kund:innen wissen oft nicht was sie wollen bzw. wirklich brauchen!
• Nachfragen! Was ist der Grund und die Motivation?

Scope of engagement

• Grenzt den Auftrag konkret ein
• Was genau ist zu testen?
• Diese Grenzen sind unbedingt zu beachten, da im Zweifelsfall strafrechtlich relevant
• Logical Scope: z.B. nur einzelne Systeme, Abteilung, Standort, oder ganzes Unternehmen?
• Physical Scope: z.B. nur bestimmte Services, IP-ranges oder Domains?

Timeline

• Als Tabelle, oder bei größeren Engagements mit GANTT-Chart
• Wichtige Infos für einzelne Phasen:
  • Start & Ende
  • Sources (von wo wird getestet?)
  • Targets (was wird getestet? IPs, domains, etc)
  • Risiken (wie hoch ist z.B. die Ausfallgefahr)

Haftung & Verantwortlichkeiten

• Permission to Test: Auftraggeber:in gibt explizite Erlaubnis ^schriftlich!, die System im Scope zu testen
• Es können immer Dinge schief gehen
• Abklärung vorhersehbarer Probleme, und Incident handling (wie wird damit umgegangen, wenn etwas schief geht)
• U.a. können explizite Verantwortlichkeiten definiert und an Personen festgemacht werden
• NDA (Non-Disclosure Agreement)

Haftung & Verantwortlichkeiten (ctd.)

• Probleme die z.B. auftreten können:
  • Auf sensitive Daten (out-of-scope) wird zugegriffen
  • Versehentliche Datenlöschung oder -manipulation
  • Versehentliche Systemabstürze
• Konkrete Verantwortlichkeiten:
  • Kund:in wird während des Tests laufend informiert
  • Datenschutz & Sichere Verwahrung gesammelter Daten und Reports
  • Code of Conduct (z.B. EC-Council Code Of Ethics)

Erlaubte Methoden

• Vor allem auf Live- und Produktiv-Systemen: wie intrusiv darf/soll der Test sein?
• Bei intrusiven Methoden erhöht sich die Wahrscheinlichkeit einer negativen Beeinflussing des Zielsystems
• Beispiele intrusiver Methoden:
  • Brute-force attacks (e.g. password guessing)
  • DoS attacks (denial-of-service)
  • (binary) exploits auf sensitive Prozesse, die womöglich zum Absturz führen (e.g. segfault anstatt buffer overflow)
  • ...

Ergebnisse & Erwartungen

• Deliverables welche die Pentester:innen liefern, müssen definiert werden
• Eventuell Festlegung auf bestimmten Report-Standard
• Welche Reports sollen überhaupt angefertigt werden?

2. Intelligence gathering

Intelligence gathering

• Wichtigste Aktivität des Pentests
• Grundsätzlich gilt: je mehr und detaillierter die Infos, desto mehr Angriffsvektoren stehen später zur Verfügung
• Aber: Rules of Engagement grenzen Art der Infos ein, die gesammelt werden
• OSINT (Open Source Intelligence) geht immer ^{(aber nur sinnvoll wo wirklich notwendig)}
• Bei Black Box Tests ^(meistens!) bleibt nur OSINT

passive vs active recon ^{(reconnoissance but cooler)}

• passive:
  • wir verwenden nur frei zugängliche Informationen, ohne direkt technische Systeme der Kundin zu nutzen
  • also über den Kunden, aber nicht beim Kunden
  • keine Datentransfers zu Kundensystemen (auch nicht zur Website)
• semi-passive:
  • Alles was nach normaler Systemnutzung ausschaut
  • Z.B. auf der Website herumbrowsen
• active:
  • wir untersuchen auch (technische) Quellen im Scope, die aber öffentlich zugänglich sind
  • z.B. port scanning, fingerprinting, Aufrufen öffentlich zugänglicher Testsysteme
  • kann potentiell als ungewöhnliche Nutzung und daher Angriff detektiert werden

3. Vulnerability analysis

Abgrenzung zum Information Gathering

• Vuln. analysis setzt auf recon/info gathering auf
• Es werden aber nicht mehr Infos über das Zielunternehmen gesammelt
• Sondern es wird aktiv nach Lücken gesucht
  • z.B. mit automatisierten Scans (nicht nur Port-Scan sondern auch Überprüfung ob das Service dahinter verwundbar ist)
  • z.B. bei den Web-Applikationen die wir in der recon gefunden haben untersuchen wir nun, ob es hier Lücken gibt
  • wir versuchen aktiv versteckte Artefakte zu finden, z.B. mit directory enumeration
• Es gibt auch passive vuln. analysis, z.B. auf Basis von Metadatenanalyse oder traffic monitoring

Threat modeling

• Kann in/vor der vuln. analysis sinnvoll sein
• eigentlich ein defensiver Ansatz, kann aber auch für die offense genutzt werden
• zeigt Bedrohungsvektoren auf die eigenen Systeme und Assets auf
• Threats identifizieren,z.B. mit STRIDE, Risikoanalyse z.B. mit DREAD
  • Ablauf: Sammeln, identifizieren, kategoriesieren, Angriff planen
  • Eher nur im APT^{(Advanced Persistent Threats)} Bereich

Mehr zu vulnerability analysis in Block 3 (Port Scanning & Enumeration)

4. Exploitation

Exploitation

• Gefundene vulnerabilities werden nun angewandt
• Mit Gegenmaßnahmen muss gerechnet werden
• Nicht alle Lücken bringen uns im Test weiter, aber alle müssen überprüft und dokumentiert werden
• Auch die gefundenen Gegenmaßnahmen müssen analysiert und dokumentiert werden
• Am Ende geht es immer darum Verbesserungsvorschläge und Empfehlungen zu machen, wie die Lücken beseitigt werden können
• Kann vor allem auch in CTFs (Capture The Flag tournamets) oder speziellen Trainingsszenarios geübt werden
• Werden wir im Laufe der nächsten Blöcke praktisch durchgehen ^{(... zumindest ein paar Web Apps Varianten)}

5. Post-exploitation phase

Post-exploitation

• Hängt stark davon ab, was in den Rules of Engagement (RoE) definiert ist
• Sollen auch die internen Netze weiter getestet werden, oder nur externe "Eintritts"lücken?
• Falls es die RoE zulassen:
  • local information gathering (am angegriffenen System)
  • privilege escalation (mehr Kontrolle im angegriffenen System erlangen)
  • evasive techniques (unerkannt bleiben)
  • backdooring (einfacheren Zugriff auch für später ermöglichen)
  • lateral movement (das Zielsystem nutzen um andere System auszuforschen und anzugreifen -> Pentest in das interne Netz)

6. Reporting

Das bestenervigste kommt zum Schluss?

Berichten an wen?

• Immer mehrere Adressat:innenkreise für einen einzelnen Report
  • Manager:innen
  • CISO
  • Sys & net admins
  • Entwickler:innen

Für Entscheidungsträgner:innen

• Überblick über Gefährdungslage
• Veränderungen zu vorigen Tests
• Visuelle Aufbereitung, Statistiken
• Relevante Metriken: Geld, Zeit, Personenstunden

Für IT Personal

• Detaillierter Bericht (aber in unterschiedlichen Detailgraden)
• Übersicht:
  • Fehlende Updates/Patches
  • Falsch (oder schwach) konfigurierte System
  • Bekannte exploits bei verwendeter Software
• + detaillierte Beschreibung zu den einzelnen Items mit konkreten Verbesserungsvorschlägen

Speziell für Entwickler:innen

... falls im Unternehmen, und Eigenentwicklungen im Betrieb

• Detaillierte Beschreibung der gefundenen Lücken
• Proof of Concept (wie genau wird die Lücke ausgenützt)
• Konkrete Verbesserungsvorschläge ^{(mit Code Review, falls Code zugänglich)}

Report-Struktur

1. Executive Summary
2. Vulnerability Report
3. Action Points

... typische schematisch Vorlage, bei Bedarf an Auftraggeber:in anzupassen

Executive Summary

• eine high-level view des reports, für technisch (potentiell) nicht versierte Entscheidungsträger:innen
• mit einem Abstract zu Beginn mit den wesentlichsten Kernpunkten
• Keine Details, vor allem Grafiken, Statistiken, Tabellen und andere schnell zu erfassende Darstellungen
• Zu Beginn vor allem auch den Fokus (bzw. die Aufgabe/den Auftrag) des spezifischen Pentests hervorheben
• Klare Metriken verwenden und immer auch die Dringlichkeit der Verbesserungsvorschläge (bzw. Risiko)
• Sofern möglich Aufwand für Verbsserung schätzen ^{(kann schwierig sein ohne innere Abläufe zu kennen)}

Vulnerability Report

• Detaillierte Beschreibungen der gefundenen Vulnerabilities für Techniker:innen
• Allgemeine IT-Fachbegriffe können vorausgesetzt werden
• Für IT-Security spezifische Begriffe eventuell ein Glossar mitliefern
• Zusätzliche Statistiken und Visualisierungen sind auch hier hilfreich
• Struktur an Art des Pentests und der IT-Landschaft anpassen

Beschreibung einzelner Vulnerabilities

• Name der Vuln.
• Vulnerability ID (CVE number, z.B mit Link zum Eintrag in der NVD)
• Kurze Beschreibung der möglichen Auswirkungen
• Einordnung in Klassifikation, z.B. nach CWE
• Proof of Concept (PoC), mit Screenshots und Exploit Code
• Liste der betroffene Ziele
• Exposure (remote, lokal, nur authentifiziert, nur Admins, etc.), und Schwierigkeit der Exploit-Durchführung

Action Points

• konkrete Verbesserungsvorschläge
• was ist zu tun, um die Lücken zu schließen?
  • Update einspielen
  • Konfig anpassen um outdated cypher suites zu deaktiviere
  • Parametrisierte SQL queries verwenden
  • CSRF tokens verwende
  • ...
• Priorisierung und Einteilung in quick-wins und aufwändigere Anpassungen

Damit das Reporting nicht so nervig wird

• Der finale Report wird zwar am Schluss geschrieben
• Die relevanten Infos fallen aber schon im info gathering an
• und ziehen sich durch das ganze Pentesting
• Daher: Notizen, Notizen, Notizen!