[VulnHub] - billu: b0x 2 Walkthrough

Below is my walkthrough for the vulnhub machine billu: b0x 2 by Manish Kishan Tanwar bhaiji. I already did this box a week ago but for the sake of this blog, I did it again so forgive my mistakes if you spot any.

So, let's get started with our traditional boot2root box solving strategy by kicking off nmap to scan for open ports and services.

Scanning the machine's IP, we can notice few ports are open like 22 (SSH), 80 (HTTP), 111(RPCBIND) and so on. As author already said we can get low priv shell with two methods, I decided to go with port 80. If we simply visit the machine's address, we can see a drupal instance running.

Drupal 8? Few months ago, remote code exec vulnerability was discovered on Drupal CMS including version 8.x so without thinking twice, I tried the same RCE exploit and it worked!

While obtaining reverse shell, nc from the netcat openbsd-package failed (old version of nc?) but ncat did the job and we got a working netcat reverse shell on our local machine. As soon as I get reverse shell, I upgrade it to fully interactive TTY shell because it makes the job more easy. You can check this blog for more info.

Before running enumeration scripts for escalating priveleges on the box, I manually check for passwd/shadow files, home dirs and common dirs, hidden files, cronjobs, running processes and apps, SUID/GUID bits and so on. While checking the /etc/passwd file, I noticed there is one user indishell with a hash.

Modern linux machines generally have password hash stored in /etc/shadow file but we can still store hash (password) on the passwd file and the system will also allow us to login or switch users accordingly. Like, if we replace "x" with a hash for user A in passwd file itself, we can login/switch user as user A by simply providing plaintext password we replaced before. So, let's crack the hash of user indishell with famous password cracker john.

The cracked password is "paagal" and salt is "sss" but when I tried to login with the same password, I got authentication failure :/ Maybe /etc/passwd couldn't recognize the hashing algorithm? .. or maybe it was author's intention to make the attacker paagal ¯\_(ツ)_/¯ Password hash in passwd file and "paagal" as password can't just be a coincidence. After hitting my head for few times in desk, I thought to look at this passwd file once again and noticed its permission.

Apart from owner and the group members, every other can also read, write and execute the file. Sounds interesting :D I quickly generated a password hash with openssl, replaced newly generated hash with the old one and tried logging in again as indishell and this time I got logged in.

While checking for sudo privs for this user, we can notice (ALL : ALL) ALL which means user indishell can run any command as sudo without having to enter password so why not just sudo su and get root? :D

uid=0(root) gid=0(root) groups=0(root) Mission accomplished.

Note: There are 2 ways to get root; most probably one is described as above and the other one is by exploiting SETUID binary available at /opt/s of the box. Since I couldn't exploit the box with that binary, I went for plan B. Other method is well explained by Gerren here.



Popular posts from this blog

DC-2 Walkthrough

Adventures Into The MeowCorp Bug Bounty Program

Expanding the attack surface with Shodan's lesser known filter