# Nachprüfung Yannis

## Theoretischer Teil

- Leo: Production hell
- Realität, wenn man in Unternehmen kommt, wo alles kaputt ist
- explizit: nicht funktionierende Services
- Yannis:
- Status Quo aufnehmen: was ist da
- Monitoring: was will man erreichen
- Services durchgehen, Ziele überprüfen, gucken was man dafür tun musst
- Leo: nicht funktionale Störung, sondern malicious actor
- eine Person hat etwas gemacht, was sie nicht durfte
- Yannis:
- mögliche Angreifer: im Unternehmen, Angreifer von außen
- zuerst Schadensbegrenzung
- Stecker ziehen bei Produktivsystem keine gute Idee
- Angreifer im System stoppen
- gucken, was ist passiert? worauf konnte der Angreifer zugreifen?
- Leo: Tools?
- Yannis:
- Monitoring System
- Leo: Unterschiede?
- Logging: was passiert auf der Maschine
- Monitoring: von außen draufgucken
- Leo: Monitoring = Metriken
- Yannis: Logging = Events
- Yannis:
- mit Monitoring Timeline erstellen
- wie kann man so ein Szenario verhindern
- Leo: Gefahr beim Neuaufsetzen?
- Yannis:
- man macht nicht alles neu
- Angreifer erlangt wieder Kontrolle über eine noch vorhandene Backdoor
- Leo: wie erklärt man CEO, was zu tun ist nach Angriff?
- Yannis:
- high-level (wenig technisch), mit Vergleich erklären
- Risikoabschätzung machen:
- pleite gehen / Klage wegen Datenschutz
- was kann das Unternehmen verkraften
- was ist technisch möglich
- **zusammen** mit CEO
- Leo: Angreifer auf Unternehmen, Maschine zum Hill machen
- Yannis:
- wie bleiben wir auf der Maschine?
- gleichzeitig versteckt bleiben
- rootkit:
- in system calls reinhooken
- e.g. diamorphine + die eigentliche Funktionalität ausführen
- Prozess / Dateien von rootkit verstecken
- Zugriff auf System (e.g. ICMP), die weniger offensichtlich ist als SSH login
- wie machen wir es anderen schwer uns zu entfernen?
- nicht so wichtig, führt wahrscheinlich zu reset der Maschine
- Leo: wie kann man auf Maschine mit rootkit zugreifen?
- Yannis:
- Port an der Maschine offen
- ICMP oft verfügbar -> Kontrolle des rootkits
- auf Nachfrage: ICMP hat keine Ports
- Leo: Admin hat geile Firewall (e.g. ICMP, Ports geblockt)
- Yannis:
- über Kernel Firewall öffnen
- tcpdump kriegt Pakete vor Firewall
- im Kernel vor der Firewall die Pakete lesen
- Leo: Netzwerkbasierte Firewall davor
- Yannis:
- verstecken, wenn Maschine ins Web geht
- einmal pro Stunde reverse Shell aufmachen
- Leo: auch reverse shell geht nicht
- Yannis:
- Pi in Lobby in Honolulu platzieren und über VPN erreichen
- andere Maschinen im Netzwerk als Proxy nutzen
- Leo: VM auf gleichem Hostsystem wie Zielsystem
- Yannis:
- Sidechannel Angriffe über RAM
- darüber herausfinden, was auf dem anderen System passiert
- Leo: Cache
- Leo: andere Sidechannel Optionen
- Yannis:
- Lautstärke messen
- _war bereit für mehr, aber Leo hat genug_
- Leo: Pi wird gefunden und Netzwerkverbindung wurde erkannt
- Yannis:
- Pi aus dem Netzwerk ziehen
- SD-Karte analysieren: Skripts
- Logs auf dem Server
- Pi als Initial Foothold, vielleicht aber auch rootkit auf Ziel platziert
- beispielsweise auch mit Elk
- Leo: wie fixt man das?
- Yannis:
- Backups: man weiß, dass gestern noch nichts war (e.g. Putzfachkräfte), dann Backup von gestern einspielen
- sonst: Daten retten und neuaufsetzen
- Leo: muss live sein
- Yannis:
- Backup booten und daran parallel arbeiten oder so
- Leo: das geht nicht
- Yannis:
- Logs
- Netzwerkverkehr
- rootkitsearcher
- dp-- --verify (_er meint dpkg_)
- Leo: wie kann man das wirklich sicherstellen?
- Yannis:
- braucht die Maschine Netzwerk? Leo: ja
- auf Firewall achten
- Leo: Maschine darf nicht aus gehen, aber Sicherheit muss garantiert sein
- Yannis: mit 100%iger Sicherheit nicht möglich
- Leo: Lieblingsthema
- Yannis: Leaking VPN aus Challenge 1 war nett, hat ihn überrascht wie schnell das passiert
- Leo: wie sicherstellen, dass es keine Leaking VPNs gibt?
- Yannis:
- DNS over HTTPS (mit der Downside, dass der Browserhersteller mehr Macht hat)
- Client weiß fest, wo VPN Server ist und leitet jeden DNS Verkehr dadurch
- Leo: sicherstellen, dass Mitarbeiter das alle richtig machen
- Yannis:
- sollten das nicht selbst konfigurieren müssen
- direkt Wireguard Config aushändigen
- Router sagt direkt, dass DNS im VPN ist
- merkt selbst, dass das nicht ideal ist: führt zu Problemen, e.g. wenn man von Zuhause aus zugreift
- organisatorisch: Mitarbeiter sind geschult und aware
- technisch: in Wireguard Config DNS Server festlegen
- Leo: sicherstellen für Server, der nur im VPN ist
- Yannis:
- Killswitch via Firewall (VPN Port)
- Daniel: wie stellt man sicher, dass Anweisungen richtig umgesetzt werden?
- Yannis:
- Definition of Done definieren
- Sicherheits Best Practices einarbeiten
- prüfen lassen (möglicherweise auch extern)
- Daniel: synchronere Maßnahmen?
- Yannis:
- Pair-Aufsetzen (wie auch am Anfang von Team B praktiziert)
- Collective-System-Ownership
- Driver wechseln!
- Ende: 14:06

## Praktischer Teil

- eingestöpselt um 14:06
- Setup nicht im Griff: Extension Pack fehlt
- Yannis wechselt auf Windows mit dortiger Kali VM
- 14:13 connected und IP bekommen
- Leo: 10.61.133.115 anschauen
- Yannis:
- pingt die Maschine
- ist leise sein wichtig? (_er tippt gerade nmap -A_)
- fährt vollen nmap
- guckt zuerst auf Port 80
- erkennt default Apache index page
- wirft gobuster dagegen
- kennt die Dirbuster flags nicht, aber mit kleiner Hilfe wie die Hilfe zu lesen ist, schafft er es
- parallel versucht er sich per SSH einzuloggen
- Permission denied (PublicKey)
- Leo:
- fixt das Problem durch reboot (hoffentlich)
- muss doch noch die SSH daemon config bearbeiten
- Yannis:
- startet gobuster neu
- connected sich per SSH
- versucht `sudo` zu nutzen
- sieht Hostname docker
- probiert docker command
- Leo: bist Du in Docker container?
- Yannis:
- vermutlich nicht (weil `docker` command available)
- _überprüft es nicht richtig_
- guckt direkt welche home Verzeichnisse es gibt
- Leo lenkt ihn erstmal auf das eigene home Verzeichnis
- Yannis:
- guckt sich bash history an
- ein kleines bisschen planlos, wo man noch so hingucken kann
- findet flag in `/PDF`
- gobuster war erfolglos
- nutzt scp, um sich `/PDF` herunterzuladen
- findet flag in einer PDF
- Leo: fragt nochmal nach Docker container
- Yannis:
- will Skript draufwerfen
- `netstat -tulpen`
- will nach Partitionen suchen
- Leo: wie viele Services pro Docker Container?
- Yannis:
- einer
- DNS-Server auf Nachfrage auch eher unüblich für Container
- vermutet aufgrund des Namens, dass Docker Container laufen
- guckt nochmal in den Nmap scan
- noch ein SSH auf Port 1
- erkennt auf Nachfrage, dass es ein anderes SSH ist wegen Hostkey
- vermutet, dass das ein SSH in einem Container sein könnte
- Leo: Yannis kann butcher private key aus Doku holen
- HPI Wifi geht mal wieder nicht
- Yannis macht sich Hotspot
- Leo packt Key auf VM
- Yannis:
- lädt Key mit SCP runter
- ändert Berechtigungen
- nutzt den Key, um sich zu verbinden (_kennt -i flag_)
- sieht, dass er im Container ist
- guckt sich Prozesse an
- guckt sich home directory an
- sucht nach anderen Nutzern (nur in `/home`)
- Leo: was hast Du noch auf dem Host getan?
- Yannis:
- probiert docker command aus
- sieht mit sudo, dass er alle Rechte hat
- will aus Container ausbrechen
- Optionen:
- Hostsystem mounten
- ist verwirrt, wieso er einen Container sieht
- merkt auf Nachfrage, dass er das selbst ist
- Leo: magst Du den Container stoppen?
- Yannis:
- ne, damit wirft man sich selbst raus
- weitere Option: andere Container starten
- will nach verfügbaren images suchen
- will SSH image als priviliged starten und dann dort das Host Filesystem mounten
- _kann docker flags nicht aus dem Kopf, aber versteht sie_
- startet Container, meint aber, dass er dadurch keine weiteren Privilegien hat
- probiert auf Nachfrage aus, ob Docker im neuen Container funktioniert
- tut es nicht -> weniger Rechte als vorher
- guckt in seine Aufzeichnung nach dem Command, um Container mit gemountetem Hostsystem zu starten
- führt den Command aus
- erkennt am PDF Ordner, dass er das Host Filesystem hat
- findet `docker-escape-proof.txt`
- will SSH Key für root drauflegen
- auf Nachfrage von Leo kommt er auch auf sudoers
- cattet aus Versehen seinen private Key
- 14:44 ist per SSH root auf dem System
- Leo: 10.61.133.21
- Yannis:
- neue Maschine:
- pingt erstmal
- dann ssh (_glaube aus Versehen_)
- großer nmap scan (abbruch und dann als root)
- geht wieder auf die docker Maschine
- findet Hint für Netzwerk mit einzelnem UDP Host
- findet binary
- strugglet kurz, ob er sie ausführen möchte
- führt sie aus
- zieht sie per SCP runter
- Leo: läd neue Challenge hoch und lässt sie Yannis nochmal runterladen
- Yannis:
- versucht sein Ghidra zu fixen
- bricht nmap ab, weil er stuck ist
- findet mit neuem Scan seeeehr viele Ports (Leo: _das ist schon wieder nicht so ganz erwartet_)
- öffnet ghidra mit anderem User erfolgreich
- schaut zuerst in die entry function
- wirft nochmal file und strings drauf
- sieht, dass binary mit upx gepackt wurde
- will es unpacken
- googelt englische Übersetzung von `entpacken` ^^
- googelt wie upx funktioniert
- Leo: nutz mal `upx`
- Yannis:
- entpackt binary
- überfliegt ganz kurz den `strings` output
- findet mit Ghidra main function
- sieht setuid
- Leo: führ doch mal aus
- Yannis:
- will es erst auf dem Server machen, macht es aber dann doch lokal
- schließt aus der Ausgabe nicht, dass die ptrace Bedingung anders evaluiert als erwartet, sondern dass nicht in der main gestartet wird
- braucht etwas Anlaufhilfe wie man gdb startet
- merkt beim Durchsteppen, dass das Programm erkennt, wenn gdb läuft
- Leo: wenn es getracet wird
- Leo: was kann man da machen?
- Yannis:
- in gdb das Result von `ptrace` ändern
- guckt sich dann die `utility` function an
- glaubt nicht mehr, dass es eine Standardfunktion ist
- struggelt etwas mit scanf Syntax, braucht etwas Hilfe von Leo
- weiß nicht, dass türkise Identifier in Ghidra global sind
- findet heraus, dass die decryptete Flag nach `/tmp/flag.jpg` geschrieben wird
- bei falschem Passwort steht dort nur data
- erkennt mit Hilfe, dass es einen Stack Canary gibt
- weiß, was es ist
- der Name ist ihm aber nicht eingefallen
- 9 Zeichen sind viel zum Bruteforcen
- mit Hilfe: wenn sie ihre eigene Verschlüsselung bauen, dann ist vielleicht auch der String hardcodiert
- mit StackOverflow und Hilfe findet er ein Regex, um alle Strings in der binary herauszufinden, die 9 Zeichen lang sind
- probiert ein Passwort aus, dass komisch aussieht
- `file` erkennt, dass es ein JPEG ist, aber es ist noch kaputt
- Leo: guck doch mal in encrypt_decrypt
- Yannis:
- mit Hilfe versteht Yannis die decrypt Funktion
- erkennt, dass nur ein erster Teil seines Passwortes richtig ist
- mit Hilfe kriegt er das Passwort raus und sieht das richtige Bild
- Leo (16:02): noch Chance den anderen Host anzugucken
- Yannis:
- macht zuerst Website (Derrick's Blog auf)
- findet Wordpress login
- Leo: was sagt der Browser
- Yannis:
- nur HTTP
- würde mein Login nicht so machen
- Leo: was birgt das für Probleme?
- Yannis:
- Passwort wird im Klartext verschickt
- will direkt mit arp spoof loslegen
- Leo: was braucht man dafür?
- Yannis: muss auf demselben Link sein
- Leo: welche Maschinen kennst Du noch?
- Yannis:
- connectet sich per SSH
- sieht, dass er im selben Link ist
- installiert nach Nachfrage dsniff (arpspoof)
- setzt iptables Regel
- enabled forwarding
- will zwischen Blog und Router spoofen
- Leo: läuft das denn zwingend über den Router?
- Yannis:
- tut es nicht, wenn der Client im selben Netz ist
- fängt alle Nachrichten an Derrick's Blog ab und leitet sie weiter
- bestätigt auf Nachfrage, dass die Antwort ihn nicht interessiert
- listened erst auf seinem Hostsystem und auf Nachfrage dann auf dem Docker host
- probiert ob er seine eigenen Anfragen loggt -> nein
- Leo:
- allgemeiner spoof scheint nicht zu funktionieren
- Tipp: targeter arpspoof auf 10.61.133.75
- Yannis:
- merkt, dass er die ganze Zeit 10.133.61.21 gearpspooft hat
- probiert nochmal den allgemeineren spoof
- kriegt Nutzernamen und Passwort
- logt sich erfolgreich ein
- Leo: was ist machbar mit Admin Zugriff auf Wordpress (theoretisch)?
- Yannis:
- will Zugriff / Shell auf System mit wp user
- dann Privilege Escalation (oder auch lateral movement)
- Felix: wie RCE auf Wordpress?
- Yannis:
- will PHP execution aktivieren auf Wordpress Seite

## Notenbesprechung

### Theoretisch

- sehr gute Antworten
- nicht so selbstbewusst: "Im Idealfall..."
- organisatorische Antworten waren super
- etwas über die Fangfrage mit dem Sicherheit garantieren gestolpert

### Praktisch

- Setup nicht im Griff
- Docker escape:
- lief nicht reibungslos (obwohl es so basic war)
- Reversing:
- relativ schnell auf UPX gekommen
- unstrukturiertes Vorgehen: hat sich keinen Überblick verschafft, sondern ist direkt in Details gegangen
- Blog:
- relativ schnell vorgegangen
- wusste genau was man alles für arpspoof machen mussof

### Ergebnis

- 18/20 Punkten (90%)
- Teamleistung von Team B aus der C3 bestätigt