TryHackMe Write-up: Python Playground

Introduction

This is my write up for TryHackMe's Python Playground Room.

Enumeration

Nmap scan shows that both HTTP and SSH are running. 

Let's take a look at the website.

Let's see if we can login.

So that didn't work.

Let's try to register.

So both login and signup pages aren't working.  Let's try something else.

Running nikto, we see that there's another html page.

Going to the admin page, we see a working login page.

Let's look at the page source.

We see that there's another page super-secret-admin-testing-panel.html and also code for getting a password.  

Let's look at the super secret page first.

Exploitation

From the title, let's assume it accepts Python code.

And it does accept Python code.  We see that it writes the code to a the scripts directory and then running it.  Let's try some directory traversal.

So we get the first flag!

Let's try decoding the source from admin.html earlier.  Reversing the javascript I came up with the following Python decoder.

Using the password from the above script, we are able to login as connor.

However, we can't use sudo.  There is also no files whose SUID bits are set that we can use for privilege escalation.

Privilege Escalation

Checking the running processes, we find that this machine is running a docker container.

And that it is running as root.  However, connor is not part of the docker groups, nor are there any working docker exploits for connor to run.  Let's go back to python playground page and see if we can do something from inside the container.

First, let's see if we can import properly.

Since we were able to print earlier, importing modules is going to be a problem.  Let's try something else.

Now the error is because of invalid syntax.  It seems that the problem is when we call "import " (with a space).  We may be able to circumvent it by using the built-in "__import__" function.

This gives us a shell as shown.

Checking for the IP, open ports and running processes, we find that maybe we are not root after all, but running from within the container.  Now let's try to break out.

Checking the mount from inside the container, we see something different:

Going to the host, we find that /dev/xvda2 actually exists!

Further research shows that files marked with a "b" show that it's a device file.  So it's possible that a device on the host may be reading from this file and writing to a different location.  Let's test this by creating a file in the container with a unique filename and then search for it in the host.

Let's first create a unique file in the container:

And then search for it in the host:

We find that the container's /mnt/log/ is the host's /var/log/.

So any file we make from within the container' /mnt/log/ directory will be  owned by root in the host's /var/log/ directory.  We can then write an executable and set the SUID so that we can have connor run it to elevate privileges.

In the container, we create the executable as follows:

And from the host, we execute it to become root!