Owasp Top 10 | TryHackMe Writeup

In this blog, we’ll be exploring the solutions to the questions in this room as well as learning how we can utilize the Owasp top 10 web vulnerabilities to perform our “malicious” actions. This one’s gonna be quite long so lets get on with it my fellow hackers.

1. Command Injection

The first room we explore is command injection. Here we only have an input field with very little information whenever anything is typed into the field. It is however enough for us to discover a lot of valuable information.

We start off by running ls to list everything in our current directory which brings up a few files (drpepper.txt being the strange file we want).

By running cat /etc/passwd, we read the plaintext database of users on the system. After some careful examination, we can see that there are no users apart from deamons and root.

Running a simple whoami reveals to us that this app is running as the www-data user.

We yet again run cat /etc/passwd to view user information in hopes of finding the shell that’s being used. We can see that this is the /usr/sbin/nologin shell which is a shell that prevents the user from being able to make SSH connections.

After this, we need to look for some system information. By running cat /etc/os-release we get a lot of info about what this machine is running. We can obviously tell that this is a Linux machine after running our previous commands however this here tells us which distribution we are on.

Finally to finish this task off, we read out the MOTD (message of the day). This can be found in that very same strange file we discovered at the start and by running cat drpepper.txt we can see it says “I love Dr Pepper” (don’t we all).

This concludes the first Owasp vulnerability which allows us to inject commands onto our targets to get them to give us the outputs we desire.

2. Broken Authentication

Broken authentication allows us to break the security of accounts and gain access to them, allowing us to fully compromise them if the logic for handling logins is implemenetd incorrectly.

The way we take advantage of this vulnerability in this task is by registering a user with a slightly modified username. Since the name “darren” is already taken , we register “ darren” with a space at the start which allows us to create the new user. Now when we login with this username and our new password, it assumes we are trying to login into the original account whilst also handling our own credentials.

Upon logging in, we are greeted with the flag. We can save ourselves the hassle of typing this out by right clicking in our browser, inspecting element and extracting the piece of text.

We do the same trick with arthur. Start by registering an account with the username “ arthur” and set a password. Next, login by using “arthur” and your new password and voila we get the second flag.

This vulnerability basically relies on incorrect handling of logic which allows us to break boundaries and get to places we shouldn’t be in. What we did should have registered a brand new user but instead it modiifed the original user.

3. Sensitive Data Exposure

Next up on the list is a vulnerability which can be created simply by human error. Incorrectly securing information can lead to malicious parties exploiting this knowledge for their own gains. We’ll try this out on this website.

By viewing the source for this page, we can see the /login directory which if followed leads us to the source for that page. In here the developers have left a very visible comment which reveals the /assets page for everything on this website.

And just like that, what seemed like a simple comment has led us to a database file which is where the fun begins.

By following through with the example on accessing database files, we discover the password hashes for all users on the site including admin which are very conveniently in the MD5 format. We can then take this hash onto crackstation.net and crack it which gives us “qwertyuiop”.

Perfect now that we have the admin credentials, we can login and we arrive at the admin portal where we find the flag.

This task has shown us that data needs to be stored securely and away from the eyes of users or else someone malicious could discover it and learn information that should have been private.

4. XML External Entity

The fourth entry in the Owasp Top 10 is XML External Entity. By leveraging this markup language we can reveal some things that should otherwise be kept hidden.

The first task has us display our name which can be done by taking the first payload example and replacing the firstName value with anything we want. Sending this payload off results with our name popping up on the screen.

Afterwards we’re tasked with reading the /etc/passwd file. This can be achieved with the second payload example which results in a large display of text. Here we can spot the user is named “falcon”.

Now that we’ve got the user name, we can use this to look for the SSH keys. I didn’t know where these could be found so I did a quick online search and found they’re stored in /.ssh/id_rsa.

Placing that file path into the payload we just used will result in us seeing the RSA private key. Now we just simply have to take the first 18 characters of this private key and the task is solved.

The XXE vulnerability shows us how incorrectly processed XML can be used to reach places that shouldn’t be accessible and how that can lead to pretty serious damage (such as seeing a private key which has now been compromised).

5. Broken Access Control (IDOR)

One of the more easier to pull off vulnerabilities on this list is the Broken Access Control or IDOR (insecure direct object reference). This is when the logic for accessing objects is implemented wrong and allows us to then access any object we desire.

To test for this vulnerability on this task, we go to the site and login with the credentials we have been given. This then gives us insight into how objects for users is handled as can be seen in the URL with the “note=1” at the end.

Replacing that 1 with 0 (which is usually the first number when computers count eg an array) leads us to accessing anothers user’s site object. The flag can be seen instantly after loading into the webpage.

As we’ve seen from this task, IDOR vulnerabilities can be very easy to pull off but they can still have very damaging effects if for instance we gained access to peoples’ financial information or an admin account.

6. Security Misconfiguration

Security misconfiguration occurs when a web app has had its security done wrong. This can come in a variety of ways such as default credentials, not implementing two factor authentication, overly detailed error messages and so forth.

This task wants us to hack into the webapp. This one was quite tough for me to figure out so I checked the hint which suggested checking the source code. As Github is where most source code can be found, I went there to test my luck.

The documentation revealed default credentials which we can then use to log into the web app. Here we have now hijacked an account and found the flag.

This is yet another somewhat simple vulnerability category as it relies on there not being appropriate security in place. These security holes then allow us to break into the web app with minimal effort.

7. Cross-site Scripting

Cross site scripting or XSS happens when developers don’t sanitize user input. This can then allow attackers to send off JavaScript code which is then executed on the web app.

To display Hello, we can use the first payload and modify it <script>alert(“Hello”)</script>. We place the script tags around our code as this means we are adding JavaScript to the HTML of the site. The alert method allows us to create these dialogue boxes as seen above. Upon successful execution, we can press Ok and we get the flag.

Next, we need to display the IP of our local machine. After having some problems with other payloads, I checked the hint which shows us which method reveals the hostname. By placing this inside the alert method (without the speech marks) we get the payload we need <script>alert(window.location.hostname)</script>. We press the Ok button on the dialogue as before and the flag awaits us.

Moving onto the stored XSS section, we will be adding some of our own HTML. After logging into our made up account, we add a comment with some very simple HTML <p>Hi</p>. All this does is add a paragraph with the word “Hi” which then brings up our next flag.

Our next task for stored XSS is to read out our cookies. We find our cookies by viewing the source for the page. The JavaScript code shows that cookies are stored in document.cookies. We can now craft a payload to read them out <script>alert(document.cookies)</script>. This shows us our session cookie and pressing the Ok button reveals the flag.

Finally, we’re gonna deface the site with HTML Here I tried to insert some HTML which I hoped would override the XSS Playground text but this didn’t work. I checked the hint which gave me the payload. Once we execute this code, we gain the flag.

XSS can be quite a serious vulnerability as there is so much that can be done via the use of JavaScript. Any user input should never be trusted as this gives attackers so many possible attack vectors.

8. Insecure Deserialization

Insecure Deserialization is when the process of serializing data is done wrong. Serialization allows for data to be sent in computer formats but for this to be done properly, there need to be checks in place so only valid safe data is received and used.

For the first question we check our cookies and copy the value found inside the sessionId. This data is base64 encoded which we can decode very easily online to find the flag hidden within the gibberish.

As the task stated, this isn’t specifically an insecure deserialization however it primes us for what’s ahead. After creating an account, we can see that we get some cookies downloaded onto our machine. By changing the userType from user to admin and refreshing the site, we can escalate ourselves to a higher ranked user which gives us the flag.

The next task is where this vulnerability really shows its true power now that we can use it to perform remote code execution. Here we prepare a reverse shell which we’ll upload by placing it in the encodedPayload cookie as the website will be deserializing our code. We run ifconfig to find our machine IP listed under tun0. Once that’s done, we paste this address into the payload script and run it afterwards to get the encoded result.

This encoded payload can be pasted into the specific cookie and after we send feedback to the server, the code is deserialized and executed which gives us a reverse shell. After some digging we find the flag.txt with the flag inside.

Insecure deserialization can be tougher to pull off than the others but enough knowledge about the system and the goal can lead to a lot of damage if serialized data is not checked thoroughly.

9. Components With Known Vulnerabilities

This vulnerability happens when the web app features or uses vulnerable components in some form. If for example the developers use an outdated piece of software with a serious bug, we can then find an exploit online and use this for our own gains.

Since the information is already out there on the internet, all we need to do is find it. The front page of the web app shows some info on what its made from. By searching for bookstore exploits, we can find some exploits that have been made for that specific application. The first one is a remote code execution vulnerability which is perfect as we need a way to read out system files.

To ensure this script works, we need to enter http:// in front of the IP address of the website. The address also needs to be placed inside of quote marks “. Once we get the reverse shell going, we run the command that’s shown and we get the character sequence.

The Components with Known Vulnerabilities relies on being able to do some reconnisance and then use that information to find exploits which in many cases need to be modified to work properly. Other than that, the hard work has been already done for us.

10. Insufficient Logging and Monitoring

Last up on the list is the lack of logging and monitoring. If this is not implemented, attackers can sneakily perform their actions while the developers remain oblivious to anything happening.

From the data we’re given, we can see that an attack was happening from the 49.99.13.16 IP address as there were a sequence of very rapid login requests sent which kept iterating through usernames (some being out of the ordinary such as root).

So that’s all there is to the Owasp Top 10. As you can see, some of these are fairly easy to test for and exploit and for the most part they can all be done within your browser, no need for terminals or anything of that sort.

This room has taught me quite a bit of things as it was jam packed with vulnerabilities. I learned how to test and perform each vulnerability, I played around with some scripting, got reverse shells with Netcat (yes it was my first time) and I leveraged the exploit database to find exploits that would help me with my mission.

Sorry if this writeup isn’t the best quality; this was quite a long room where originally each vulnerability would be done on a seperate day. I was also quite busy in the midst of writing this up which may make me sound repetitive at times.