A deeper dive into THM pickle rick

I would like to start with a little disclaimer; I am a junior in this field so there might be things I know incorrectly however, it is important that beginners also see how others do at the beginning of their professional careers.

With that out of the way, let’s get started 🙂 .

So what are web shells? Web shells are basically a backdoor on a server that is accessible through a web interface. You might ask how is this relevant at the THM pickle rick challenge? The answer is simple, we used one to solve it 😀 .

If it still doesn’t ring a bell that is fine, we are all beginners here and if you read this you probably would like to learn it so that is good 🙂 . So the web shell was the following:

As we can see it is a .php file (that is a common language to write web shells in) and what it does is that it reads input from the user, then executes that on the server and returns the standard output stream. This last bit of information is very important but to understand it I have to explain a bit about Linux standard I/O.

So what is the Linux standard I/O? Without going into too much detail, these are the input and output streams of a Linux operating system. These streams are separated into 3 main categories: input (STDIN), output (STDOUT) and error (STDERR). They also have corresponding numbers as their file descriptors: STDIN -> 0, STDOUT -> 1, STDERR -> 2. This is important because a web shell (usually) doesn’t return the STDERR stream, meaning that the attacker would have no idea what went wrong. In case of ls it could be confusing if the directory is empty or we just run into an error. A solution to this problem is to redirect the STDERR into the STDOUT or into a file. If you would like to know more about Linux streams and I/O I suggest reading this blog post by Steve Vona.

So to get back on track, we have a web shell that we can interact with. Now this is the time one might start asking questions like but how did it get there? In this case, it was there becase it was a beginner-level lab but in real life, you as the penetration tester would have to utilize another kind of misconfiguration or vulnerability on the web app to upload a file containing the web shell.

Why is it good? The simple answer is that it usually lets us enumerate the server that hosts the web application. Why just enumerate? If the server is configured correctly (besides the fact that we uploaded a web shell 😀 ) the user that we can run commands as should be the user running the app and it should have no privilege to do damage on the server. This type of access is also can be referred to as a foothold.

Why is it needed to escalate our privileges after gaining foothold access? As I said we should have no permission to run commands that can damage the server and this type of shell is also not interactive. This means that if the OS prompts us with something we are unable to interact with it. A good example is why we had passwordless sudo privileges on the server. By default sudo would prompt us to enter a password but since the web shell is not interactive, we cannot do that so sudo becomes useless for us unless it doesn’t ask for the password.

In the case of this challenge we could access all the files needed to solve it but in reality, it is rarely the case. In a real-world scenario, our goal is not to reach a certain file or to gain root access (that is certainly not bad tho) however, penetration testing is about showing clients how their valuable information could be stolen. This information could be anything and as beginners, we should not fall into the CTF mistake where the only goal we see is to be root.

I hope you found this post informative! If there are any questions do not hesitate to ask them in the comment section!

Thank you for reading!
Sincerely,
B4D4M.