TryHackMe - OWASP Top 10 Event

Introduction

Hello there! In this writeup, we are going to take a look at the TryHackMe OWASP Top 10 Event which combines a total of 10 topics, covered every day. This event is a great opportunity for beginners to learn and practice the most common web vulnerabilities. The theory was compiled to be as easy as possible, making it understandable to anyone.

Event link: tryhackme.com/room/owasptop10

Table of contents:

  • Day 1 Injection

  • Day 2 Broken Authentication

  • Day 3 Sensitive Data Exposure

  • Day 4 XML External Entity

  • Day 5 Broken Access Control

  • Day 6 Security Misconfiguration

  • Day 7 Cross-site Scripting

  • Day 8 Insecure Deserialization

  • Day 9 Components with Known Vulnerabilities

  • Day 10 Insufficient Logging & Monitoring

[Day 1] - OS Command Injection

Command Injection - a vulnerability that occurs when a server-side code (like PHP) in a web application makes a system call on the hosting machine.� Given misconfiguration may allow an attacker to take advantage of those system calls and execute operating system commands on the server.

Most commonly, an attacker is aiming at retrieving some sensitive information, for example, users, passwords and backup files.

Let's take a look at one of those vulnerable machines. In the task 6, we can deploy a highly misconfigured web application which, as stated in the task, allows us to execute system commands on /evilshell.php

Browse to the given directory and you should see a prompt like so:

Question 1

The first question is asking us to find a "strange text file is in the website root directory". This can be easily done by running a Linux listing command - ls. Run it and you should see the answer.

Question 2

The second question wants us to find all "non-root/non-service/non-daemon users". The best way to do so is to read the /etc/passwd file, which contains information about all users on the system.

Generally speaking, the task is asking us to find any user with a home directory, excluding root, services and daemon. Simply use Ctrl+F to search for /home and see if you get anything. !Note: Service users do not count.

Question 3

The third question is asking us to find a current user's name. This can be easily done with the most basic Linux command - whoami.

Question 4

Question 4 is asking us to retrieve a "user shell's" name. To do so, we need to use another Unix command - getent. Getent stands for "get entries from administrative database". For this question, we need to get information about the passwd entry, which should contain information about every single user.

Now, use Ctrl+F to search for our current user (Check Question 3 for the name).

Question 5

The fifth question is asking us to pull the machine's Ubuntu version. A small google search told me that the lsb_release utility can display LSB (Linux Standard Base) information about the Linux distribution. A flag -d, alongside with the command should display us the desired information.

Question 6

Finally, the last question wants us to print out the MOTD. MOTD - message of the day is a message displayed every time anyone new accesses the server via ssh. This message can be read or edited in the /etc/update-motd.d directory. Simply cat the 00-header file and get the answer!

That's all for Day 1! OS injection is now done

[Day 2] - Broken Authentication

Authentication is the most basic method of interacting with the web application which allows users to gain access to additional web application services by verifying their identities.

A missconfiguration in the following process can lead to a lot of horrible consequences, such as account takeover or access to admin panel by an unprivileged user.

Let's take a look at one really vulnerableapplication that allows an attacker to double sign-up an account and get access to anyone's profile.

Browse to :8888 and you'll land on a simple web application page with only two action possibilities: Sign-in and Register.

Questions 1-3

As stated in the theoretical part, a given web application allows us to gain access to any account by adding a space to the desired nickname when registering a new account. Say, if we wanted to gain access to Swafox's account, we would put " Swafox" in the user registration prompt (Notice the space before the nickname!).

So, in order to complete these questions, you need to register 2 accounts: darren and arthur and add a space to each one while registering.

Should look like so:

After doing so, you should be able to log in to arthur's account and get the flag!

Do the same with darren and get your flags! That's all for Day 2, moving on to the third one.

[Day 3] - Sensitive Data Exposure

Sensitive data exposure is a very common vulnerability which is represented in a form of developer misconfiguration and naive mistakes. These include: badly configured web directory permissions, comments with sensitive information, open subdomains, etc.

A provided machine has a combination of those, allowing an attacker to gain access to admin's account by following small developer mistakes.

Browse to the provided IP and you should see a website:

Question 1

The first question is asking us to find some 'mentioned' directory. Let's browse to the login page (top-right corner) and look at the source code! (Press Ctrl+U to view it)

A following comment reveals that there's a database located in the /****** directory! That also appears to be an answer to the first question!

Question 2

The second question is asking us about a file, which can probably contain sensitive information. A comment is the previous question revealed, that there's a database laying in the directory. Browse there and see if there's one.

Bingo! Here's our database! Now you can answer the second question.

Question 3

Click on the database to download it on your machine. The question is asking us for admin hash. Task 10 suggest us to enumerate the database using a database manager called sqlite3. Open up the database using sqlite3 DatabaseName.db;

As you can see on the screenshot above, we first need to use command .tables to list all tables on the database. Next, by running PRAGMA table_info() we retrieve the available data. And then finally, we can easily get all the data using a basic SQL SELECT command.

Question 4

Now, let's crack the hash and get the admin password! Browse over to crackstation.net and paste a hash from question 3.

After a quick reCAPTCHA we get our admin password!

Question 5

We can now finally login to the admin account using the password.

Here's the flag! You should immediately see it after the log-in. That's all for Day 3!

[Day 4] - XML External Entity

An XML External Entity (XXE) attack is a vulnerability that abuses features of XML parsers/data. XML - a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. It often allows an attacker to interact with any back end or external systems that the application itself can access and can allow the attacker to read the file on that system.

XML had a wast amount of Document Type Definition (DTD) which can be used to define a document structure with a list of validated elements and attributes.

On of those DTD values can be abused to read system files. Here's a simple structure for the XXE payload:

<?xml version="1.0"?>
<!DOCTYPE root [<!ENTITY read SYSTEM 'file:///etc/passwd'>]>
<root>&read;</root>

Question 1 - 3

The first three questions are asking us to read the /etc/passwd file and enumerate existing users. Use the above payload to retrieve this information.

You can see the source code (Ctrl+U) for more beautiful output.

Question 4

SSH keys are usually located in the user's home folder. Use the retrieved user to answer the question. Link: askubuntu.com/questions/512935/where-are-ssh-client-private-keys-stored

Question 5

Now, as we know the SSH key file location, we can use that to connect via ssh. Edit the previous payload to read the file:

<?xml version="1.0"?>
<!DOCTYPE root [<!ENTITY read SYSTEM 'file:///home/falcon/.ssh/id_rsa'>]>
<root>&read;</root>

Now you can answer the question by viewing the source code Ctrl+U.

Question Extra You can use the file to connect to the machine via SSH by changing the file permissions to 600 and using it in the ssh command. After that you'll be able to see a user flag.

[Day 5] - Broken Access Control

Websites usually have pages that are protected from regular visitors, for example, only authorized users should be able to access the admin panel. If a website visitor is able to access the protected page/pages that they are not authorized to view, the access controls are broken.

Questions 1-3

This time we need to exploit a broken access vulnerability. We are given some credentials -- noot:test1234 and should read a flag from another user's note.

Browse to the machine ip and let's take a look.

We can see a login page. Log in to the application and enumerate the app. We don't see anything valuable right away, but there's something strange in the link.

http://10.10.106.130/note.php?note=1

You can see that the application is providing a note number in the link itself, which can be used to read other notes. Simply switch to note 0 and read the flag!

Day 5 done!

[Day 6] - Security Misconfiguration

Security misconfiguration is a serious vulnerability that can lead to various amounts of horrible consequences.

Security misconfigurations include:

  • Poorly configured permissions on cloud services, like S3 buckets

  • Having unnecessary features enabled, like services, pages, accounts or privileges

  • Default accounts with unchanged passwords

  • Error messages that are overly detailed and allow an attacker to find out more about the system

  • Not using�HTTP security headers, or revealing too much detail in the Server: HTTP header

Questions 1-2

A given practical example is focused on default credentials misconfiguration. Browse to the provided machine IP and let's take a look.

We can see a simple note taking application. A hint suggest to take a look at the application source code which could possibly contain some sensitive information. What's the most popular service for open source code? GitHub!

A simple title lookup immediately led us to the project page and revealed default credentials. Use them to login to the application and retrieve the flag!

That's all for Day 6!

[Day 7] - Cross-site scripting

Cross-site scripting, (XSS) is a serious security vulnerability typically found in web applications. It's a type of injection which can allow an attacker to execute malicious scripts and have it execute on a victim's machine.

Questions 1-3 (Reflected XSS)

Deploy the provided machine and sign up on the main page (IP:80).

All we have here is a simple search prompt, vulnerable to reflected XSS. This can identified by simply inputting alert(1).

Now, use the following payload to display 'Hello' message and get the flag. Note: In JS, text should be surrounded by single quotes ('').

<script>alert('Hello')</script>

Question 3 can be answered by changing the 'Hello' to window.location.hostname in the above payload.

Questions 4-6

Now let's take a look at stored XSS. IP/stored.

Stored XSS vulnerability can be easily identified by inputting some custom html syntax (like or

). Try doing so and see if your comment will be different from others.

Now, to create a cookie alert message, we need to use document.cookie JS function in the payload.

<script>alert(document.cookie)</script>

An answer to question 6 is located in the hint.

<script>document.querySelector('#thm-title').textContent = 'I am a hacker'</script>

A script here simply replaces the title with a new text, changing 'XSS Playground' to 'I am a hacker'.

Check out my other XSS walkthrough here -> link. That's all for day 7 :)

[Day 8] - Insecure Deserialization

Insecure deserialization occurs when data from an untrusted party (I.e. a hacker) gets executed because there is no filtering or input validation; the system assumes that the data is trustworthy and will execute it no holds barred.

Day 8 Challenge has enough guidance to be easily completed. There aren't any uncovered questions, so I'll have to skip this day here. (No-answer policy)

[Day 9] - Known Vulnerabilities

Known vulnerabilities exploitation is one of the easiest OWASP vulnerabilities, which is aimed at your understanding of the web application's structure and relies mostly on your research.

Let's take a look at one of those vulnerable apps using the practical part of the day. Question 1: How many characters are in /etc/passwd (use wc -c /etc/passwd to get the answer).

It looks like we need to get an RCE (remote code execution) in the web application and get the /etc/passwd file. Remember, all we got to do is pure research!

It looks like a simple web app from the first glance. Now enumerate the web app and start collecting valuable information like so:

  • Made with: PHP and MYSQL

  • Title: Bookstore

  • Made by: projectworlds

Now let's google what we got so far.

Our desired exploit appears to be the first link! That was easy :)

Now download the exploit and run it like so:

python3 47887.py http://<IP>

After that, run the wc -c /etc/passwd as was suggested in the task and get the answer!

[Day 10] - Insufficient Logging and Monitoring

Sometimes logs can reveal a lot of sensitive information if configured properly. This can be extremely useful to identify any kind of performed attacks. A provided practice example contains an example of those kinds of logs.

As you can see here, logs have detected multiple login fails from the same IP (attacker's ip), indicating login brute forcing attack.

Afterword

This room was a great piece of practical knowledge that can significantly boost beginner's skills. Thanks for reading this writeup :) See you on the platform.

PreviousServer-side request forgery (SSRF)NextTryHackMe - Anthem

Last updated