In dieser Phase sammeln wir Informationen über das Zielsystem, um potenzielle Schwachstellen zu identifizieren. Wir beginnen mit dem ARP-Scan, um die IP-Adresse des Ziels zu finden.
`arp-scan -l` findet den Host mit der IP-Adresse 192.168.2.150 und der MAC-Adresse 08:00:27:67:f8:7f. Der Hersteller der Netzwerkkarte ist PCS Systemtechnik GmbH. Diese Information hilft uns, das Gerät im Netzwerk zu identifizieren und mögliche Betriebssysteme einzugrenzen.
Als nächstes führen wir einen umfassenden Nmap-Scan durch, um offene Ports, laufende Dienste und Betriebssysteminformationen zu ermitteln.
Der Nmap-Scan liefert wichtige Informationen: * **Offene Ports:** 22 (SSH), 80 (HTTP), 443 (HTTPS) * **Dienste:** SSH (OpenSSH 8.0), HTTP (Apache 2.4.37), HTTPS (Mongoose httpd) * **Betriebssystem:** Linux (vermutlich CentOS) * **Hostname:** creditcard.vln
Analyse der Ergebnisse: Der SSH-Dienst könnte für Brute-Force-Angriffe oder die Ausnutzung von Schwachstellen in OpenSSH verwendet werden. Der Apache-Webserver auf Port 80 und der Mongoose-Webserver auf Port 443 sind potenzielle Angriffsziele. Da der Nmap-Scan ein CentOS-System vermutet, können wir nach CentOS-spezifischen Exploits suchen.
Als Nächstes verwenden wir Nikto, um den Webserver auf Port 80 auf bekannte Schwachstellen zu überprüfen.
Nikto findet mehrere potenzielle Schwachstellen: * **Fehlende Header:** X-Frame-Options und X-Content-Type-Options * **PHP-Version:** PHP/7.2.11 wird verwendet * **Veraltete Apache-Version:** Apache 2.4.37 * **HTTP TRACE aktiviert:** Anfälligkeit für Cross-Site Tracing (XST) * **Directory Indexing:** In /css/, /img/ und /icons/ aktiviert * **Sensitive Dateien:** /package.json und /README.md gefunden
Analyse der Ergebnisse: Die fehlenden Header sind ein häufiges Problem und können leicht behoben werden. Die Aktivierung von HTTP TRACE ist ein größeres Problem, da es Angreifern ermöglichen kann, Cookies zu stehlen. Directory Indexing ermöglicht es Angreifern, den Inhalt von Verzeichnissen aufzulisten, was ebenfalls ein Sicherheitsrisiko darstellt. Die Dateien `/package.json` und `/README.md` könnten sensible Informationen wie Softwareversionen oder Konfigurationsdetails enthalten.
Wir verwenden Gobuster, um weitere Verzeichnisse und Dateien auf dem Webserver zu entdecken.
Gobuster findet die folgenden Ressourcen: * `index.html` * `img`, `css`, `vendor`, `settings`, `class` (Verzeichnisse) * `buynow.php` * `package.json` * `LICENSE`
Analyse der Ergebnisse: Die gefundenen Verzeichnisse und Dateien geben uns einen Einblick in die Struktur der Webanwendung. `buynow.php` deutet auf eine E-Commerce-Funktionalität hin, was bedeutet, dass es möglicherweise Formulare gibt, die Kreditkarteninformationen verarbeiten. `/settings` könnte Konfigurationsdateien enthalten.
In dieser Phase versuchen wir, uns Zugriff auf das System zu verschaffen, indem wir die identifizierten Schwachstellen ausnutzen.
Wir versuchen, eine Cross-Site Scripting (XSS)-Schwachstelle auszunutzen, um Cookies zu stehlen.
Dieser Code ist ein einfacher XSS-Payload, der die Cookies und die aktuelle URL an einen Server unter 192.168.2.199 sendet. Der Code erstellt ein neues Bild und setzt die Quelle des Bildes auf eine URL, die die Cookie-Daten und die aktuelle URL enthält. Wenn dieser Code in einer anfälligen Anwendung ausgeführt wird, sendet er die sensiblen Daten an unseren Server.
Wir starten einen einfachen HTTP-Server mit Python, um die gestohlenen Cookies zu empfangen. Der Server protokolliert die eingehenden Anfragen, einschließlich der Cookie-Daten.
Bei der weiteren Untersuchung finden wir ein Admin-Panel.
Der Zugriff auf `http://creditcard.vln/_admin/dist/` leitet uns zu einer Login-Seite weiter.
Indem wir im Cookie-Editor `PHPSESSID=hvi32n927m1292mnj9ajbt6v27` hinzufügen, wird unsere XSS-Attacke mit "Hello World" ausgelöst. Dies bestätigt, dass eine XSS-Schwachstelle vorhanden ist.
Bestätigung einer XSS Schwachstelle: Die erfolgreiche Ausführung von JavaScript-Code durch die XSS-Schwachstelle beweist, dass Angreifer beliebigen Code im Kontext des Benutzers ausführen können. Dies kann für verschiedene Angriffe genutzt werden, z. B. zum Stehlen von Cookies, zum Umleiten von Benutzern auf bösartige Websites oder zum Ausführen von Aktionen im Namen des Benutzers.
Um das System weiter zu kompromittieren, nutzen wir eine SQL-Injection, um eine Hintertür zu erstellen.
Dieser SQL-Befehl injiziert PHP-Code in die Datei `/var/www/html/ben.php`. Der injizierte Code ermöglicht die Ausführung beliebiger Systembefehle über den GET-Parameter `cmd`.
Wir testen die Command Injection, indem wir den `id`-Befehl ausführen. Wir erhalten die Ausgabe `uid=48(apache) gid=48(apache) groups=48(apache)`, was bestätigt, dass die Command Injection funktioniert.
Wichtiger Erfolg! Die Command Injection ermöglicht es uns, beliebige Befehle auf dem System auszuführen, was ein großes Sicherheitsrisiko darstellt.
Nachdem wir die Command Injection erfolgreich getestet haben, nutzen wir diese, um eine Reverse Shell zu erhalten.
Wir starten einen Netcat-Listener auf Port 9001, um die Reverse Shell zu empfangen.
Wir senden einen HTTP-Request an `ben.php` mit einem Command-Injection-Payload, der eine Reverse Shell zu unserem Netcat-Listener initiiert.
Nachdem wir uns erfolgreich mit dem Tomcat-Server verbunden haben, verwenden wir noch einmal Curl, um die ID des aktiven Benutzers zu identifizieren.
Nach der Identifizierung der Benutzer möchten wir als nächstes prüfen, wo sich unsere Anmeldeinformationen in einem dieser Ordner befinden könnten.
In dieser Phase versuchen wir, unsere Privilegien auf Root zu erhöhen.
Wir verwenden das Programm Curl, um die Informationen für die Benutzer, Admin und Moneygrabber, in den Verzeichnissen aufzulisten.
Wir verwenden das Programm Curl, um die Informationen für die Benutzer, Admin und Moneygrabber, in den Verzeichnissen aufzulisten.
Wir verwenden das Programm Curl, um die Informationen für die Benutzer, Admin und Moneygrabber, in den Verzeichnissen aufzulisten.
Wir verwenden das Programm Curl, um die Informationen für die Ordner im Ordner "var/www/html" aufzulisten.
Wir versuchen mit der PHP Filter Methode in den code einzusteigen.
Da der Filter funktioniert versuchten wir eine Reverse Shell zu erstellen
Nun laden wir ein WebShell von unserem Server mit dem cmd=wget Befehl auf das system um eine einfachere verbindung zur Web-Applikation zu erhalten.
Nun versuchen wir von aussen auf die shell2.php zuzugreiffen.
Nun versuchen wir über NC eine verbindung zu erstellen.
Nun erstellen wir mit VI einen neuen index.html zum testen.
wir laden von unserem Rechner einen Ordner über curl
Da die Standard Reverse Shell nicht funktioniert suchen wir weiter und versuchen den befehl mit nc zu senden.
Endlich wir haben eine Reverse Shell !!!
find / -type f -perm -4000 -ls 2>/dev/nullAls nächstes suchen wir nach SUID-Binärdateien mit dem Befehl find.
bash-4.4$ pwdPwnKit - wir sind sehr nah dran :)
bash-4.4$ cd /var/www/html/Wir untersuchen die Daten auf der Website.
bash-4.4$ cat buynow.phpWir versuchen in den Konfigurationsdatenbanken zu schauen um die passwörter raus zu finden.
bash-4.4$ cat settings/config.phpMit den gewonnen Daten versuchen wir uns als admin anzumelden.
Wir schauen nach ob es andere User gibt
bash-4.4$ su adminDanach versuchen wir ein Zugriff über MYSQL
bash-4.4$ mysql -u orders -pDa die dechiffrierung sehr lange gedauert hat gaben wir ab und versuchten es so zu versuchen über den moneygrabber zu bekommen.
[moneygrabber@ppeshop html]$ cd ~