HackTheBox - Ellingson

Nmap scan (Basic and all port)

Let's start off with a simple nmap scan followed by a all port scan.

nmap -sC -sV -oA nmap-ellingson 10.10.10.139

Gobuster scan (Directory busting)

gobuster dir -w /opt/SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://ellingson.htb/ 

Looking out for interesting stuff on the home page of the website. Just found these three directories and nothing else. Even used wfuzz to scan for subdomains but no luck.

Looks like the server running at the back-end is Werkzeug

Werkzeug is a comprehensive WSGI web application library. It began as a simple collection of various utilities for WSGI applications and has become one of the most advanced WSGI utility libraries. Werkzeug is Unicode aware and doesn't enforce any dependencies.

Werkzeug Console RCE found

we try to access http://ellingson.htb/articles/4 ,we get the following error.

And we can even run some python code by clicking on the shell icon on each line.

So maybe we can try to get RCE using python's modules like os or subprocess

Firewall rules blocking outgoing connections

Due to iptables rules, we can get a reverse shell on the target computer but we can write to certain files using python's in-build file read and write commands.

So we can read /etc/passwd file using the following code.

file = open('/etc/passwd','r')
file.read()

To list the files in any directory, we can use os.listdir() command.

So after poking and enumerating for a while, I found a private SSH key belonging to hal user.

Generating Custom SSH key for user hal

The hal's private SSH key is encrypted and we need a password to decrypt it.

That didn't work. So one thing that we can do is create our own private-public key pair and as we have write privileges, we can replace our public key in the authorized_keys file.

You can create a public-private key pair using the following command.

ssh-keygen -f hal_custom_key

We just copied the public key to authorized_keys file and gave 600 (Only root can read and write) permission to it.

And we are in :))

Enumerating System Information

The hal user belongs to adm (admin) group: uid=1001(hal) gid=1001(hal) groups=1001(hal),4(adm)

So the backup shadow file was last accessed at 09-03-2019 20:42:17

And we can see that margo is only user whose password didn't at all, so maybe we can try to crack the hash for margo present in that backup shadow file.

Password cracking for margo user

hashcat.exe -m 1800 hash.txt rockyou.txt

Password cracked for margo user: iamgod$08

This /usr/bin/garbage file looks suspicious and it has given a SETUID file permission.

Running strings on garbage binary,

Analyzing Binary in Ghidra (Great tool for Binary exploitation)

Looks like the binary is vulnerable to buffer overflow attack. Let's open the binary in gdb and use checksec property to see if any kind of protection is enabled or not.

NX is enabled that means, when this option is enabled, it works with the processor to help prevent buffer overflow attacks by blocking code execution from memory that is marked as non-executable.

So we have to perform a ROP (Return Oriented Programming) Attack.

ROP Attack on garbage binary

ROP is the process of stitching together existing executable fragments of code ending in a return instruction. By creating chains of addresses of these 'gadgets' one can write new programs without introducing any new code. Keep in mind that you will need to be flexible in identifying methods to exploit programs.

First to start off with the buffer overflow attack, we need to find the offset of the program. We can open the binary in gdb-peda (Python Exploit Development Assistance).

Finding the offset

We can create a pattern using pattern_create command in gdb-peda.

Then after the program crashes, we need to find the value in RSP.

We need this value to calculate the offset using pattern_offset command.

Offset found for the binary : 136

Using ropper tool to get pop rdi gadget

ROP gadgets are small sets of instructions which usually end with a ret instruction. These gadgets are put together to form ROP chains. After execution, the gadget returns to the next gadget in the chain. The reason this technique is called return-oriented programming should be apparent now!

Making of the exploit (Getting addresses)

References: 
https://pop.rdi.sh/rop-exploits/
https://ctf101.org/binary-exploitation/return-oriented-programming/
https://systemoverlord.com/2017/03/19/got-and-plt-for-pwning.html

The main intention over here is that we need to calculate the address of libc and it keeps get changing everytime we run the binary. (ASLR Protection) So what we can do is get the address for puts in the binary and then subtract it with the real puts present in the libc. And then after we can perform the old school exploitation.

plt contain stubs to jump to the target, those starting with . got are tables of the target addresses. Let's walk through the way a relocation is used in a typical binary. We'll include two libc functions: puts and exit and show the state of the various sections as we go along.

We can use objdump to get the plt and got address for puts.

objdump -D garbage | grep puts

plt puts address - 0x401050
got puts address - 0x404028
plt main address - 0x401619

PLT stands for Procedure Linkage Table which is, put simply, used to call external procedures/functions whose address isn't known in the time of linking, and is left to be resolved by the dynamic linker at run time. GOT stands for Global Offsets Table and is similarly used to resolve addresses.

Leaking the puts address

This code will leak the put address by sending a bunch of junk characters followed by the gadget leak.

We can modify the code a little bit to display it more properly (User friendly)

ljust in the program will just fill out the padding with a null byte character (\x00).

Getting system, puts and /bin/sh addresses from libc.so.6

We can identify the location of libc using the following command.

ldd garbage | grep libc

Getting the libc address

We can get the libc address by subtracting the leaked puts address with the puts address from libc.so.6

Now to get the system, setuid and /bin/sh offset, add the libc_address to it and we are good to go.

Chaining the exploit to get shell access

First the program will set the setuid bit to 0 i.e root and then run system('/bin/sh')

It worked on our local machine. Now all we have to do is change the libc addresses of system, setuid and /bin/sh. (Addresses from the target machine)

And also changing the script a bit, we will be using ssh from pwntools.

So now we are good to go. Let's run the script and get that shell :))