TryHackMe: OWASP Top 10 (Task 17–31) — Walkthrough

September 14, 2023
Posted in TryHackMe, Web
September 14, 2023 Jasper

Hi! This article is the second part of my series which covers the THMs room on the OWASP top 10, a list of the most critical web security risks. Join me!

Join me on learning cyber security. I will try and explain concepts as I go, to differentiate myself from other walkthroughs.

OWASP

Room URL: https://tryhackme.com/room/owasptop10

This is part 2 which covers task 16–31. Part 1 can be found here.


Task 17 (SEV 5 — Broken Access Control)

Websites have pages that are protected from regular visitors, for example only the site’s admin user should be able to access a page to manage other users. If a website visitor is able to access the protected page/pages that they are not authorised to view, the access controls are broken.

A regular visitor being able to access protected pages, can lead to the following:

  • Being able to view sensitive information
  • Accessing unauthorized functionality

OWASP have a listed a few attack scenarios demonstrating access control weaknesses:

Scenario #1: The application uses unverified data in a SQL call that is accessing account information. An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want.

http://example.com/app/accountInfo?acct=notmyacct

Scenario #2: An attacker simply force browses to target URLs. Admin rights are required for access to the admin page.

http://example.com/app/admin_getappInfo

To put simply, broken access control allows attackers to bypass authorization which can allow them to view sensitive data or perform tasks as if they were a privileged user.

Questions

Read and understand how broken access control works.

Answer: No answer needed


Task 18 (SEV 5 — Broken Access Control (IDOR Challenge))

IDOR, or Insecure Direct Object Reference, is the act of exploiting a misconfiguration in the way user input is handled, to access resources you wouldn’t ordinarily be able to access. IDOR is a type of access control vulnerability.

For example, let’s say we’re logging into our bank account, and after correctly authenticating ourselves, we get taken to a URL like this https://example.com/bank?account_number=1234.

There is however a potentially huge problem here, a hacker may be able to change the account_number parameter to something else like 1235, and if the site is incorrectly configured, then he would have access to someone else’s bank information.

Questions

Read and understand how IDOR works.

Answer: No answer needed

Deploy the machine and go to http://MACHINE_IP — Login with the username being noot and the password test1234.

Answer: No answer needed

Look at other users notes. What is the flag?

Log in with the username noot and password test1234.

You will see that there is a GET parameter set in the url called note. Let’s see if we can access other users’ notes by changing this value. When we change it to 0 we get the following answer:

Answer: flag{fivefourthree}


Task 19 (SEV 6— Security Misconfiguration))

Security Misconfigurations are distinct from the other Top 10 vulnerabilities, because they occur when security could have been configured properly but was not.

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

This vulnerability can often lead to more vulnerabilities, such as default credentials giving you access to sensitive data, XXE or command injection on admin pages.

Default Passwords

Specifically, this VM focusses on default passwords. These are a specific example of a security misconfiguration. You could, and should, change any default passwords but people often don’t.

It’s particularly common in embedded and Internet of Things devices, and much of the time the owners don’t change these passwords.

Questions

Deploy the VM

Answer: No answer needed

Hack into the webapp, and find the flag!

Visit the webapp in your browser:

Now we need to try different initials to gain access. I have to admit, this took me some time to figure out. I first started looking into the source code in the browser but I could not find anything there.

But if you google Pensive Notes you get to the following Github repository:

Here they write the following:

Let’s use these default credentials. And YAY, we got access:

Answer: thm{4b9513968fd564a87b28aa1f9d672e17}


Task 20 (SEV 7 — Cross-site scripting)

Cross-site scripting, also known as XSS is a 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. A web application is vulnerable to XSS if it uses unsanitized user input. XSS is possible in Javascript, VBScript, Flash and CSS. There are three main types of cross-site scripting:

  1. Stored XSS — the most dangerous type of XSS. This is where a malicious string originates from the website’s database. This often happens when a website allows user input that is not sanitised (remove the “bad parts” of a users input) when inserted into the database.
  2. Reflected XSS — the malicious payload is part of the victims request to the website. The website includes this payload in response back to the user. To summarise, an attacker needs to trick a victim into clicking a URL to execute their malicious payload.
  3. DOM-Based XSS — DOM stands for Document Object Model and is a programming interface for HTML and XML documents. It represents the page so that programs can change the document structure, style and content.

XSS Payloads

Remember, cross-site scripting is a vulnerability that can be exploited to execute malicious Javascript on a victim’s machine. Check out some common payloads types used:

  • Popup’s (<script>alert(“Hello World”)</script>) — Creates a Hello World message popup on a users browser.
  • Writing HTML (document.write) — Override the website’s HTML to add your own (essentially defacing the entire page).
  • XSS Keylogger — You can log all keystrokes of a user, capturing sensitive information they type into the webpage.
  • Port scanning — A mini local port scanner (more information on this is covered in the TryHackMe XSS room).

XSS-Payloads.com (http://www.xss-payloads.com/) is a website that has XSS related Payloads, Tools, Documentation and more.

Questions

Deploy the VM

Answer: No answer needed

Navigate to http://MACHINE_IP/ in your browser and click on the “Reflected XSS” tab on the navbar; craft a reflected XSS payload that will cause a popup saying “Hello”.

Click on the “Reflected XXS” tab:

Let’s enter a XSS payload in the search field like so:

All we are doing is entered some simple Javascript into the field and this gets output. This works because you can see in the source code that your payload is executed directly on the webpage.
<h6>You searched for: [Your input will be input directly in here]</h6>

The alert box pops up:

Followed by the flag:

Answer: ThereIsMoreToXSSThanYouThink

On the same reflective page, craft a reflected XSS payload that will cause a popup with your machines IP address.

They payload you should insert is the following:

<script>alert(window.location.hostname)</script>

This gives the following popups:

Answer: ReflectiveXss4TheWin

Now navigate to http://MACHINE_IP/ in your browser and click on the “Stored XSS” tab on the navbar; make an account. Then add a comment and see if you can insert some of your own HTML.

Move to the “stored XXS tab”. Register a new user with initials you decide yourself and login to get to the following screen:

I opted to add the following HTML:

This works, so we can add HTML to the page!

Answer: HTML_T4gs

On the same page, create an alert popup box appear on the page with your document cookies.

You can access your cookie through javascript like follows:

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

This makes the following info pop up:

Followed by:

Answer: W3LL_D0N3_LVL2

Change “XSS Playground” to “I am a hacker” by adding a comment and using Javascript.

If you look at the source code, the “XSS Playground” text has an id set to ‘thm-title’.

In Javascript we can change the text contents of a tag with a id like this:

document.getElementById(id).innerHTML = “I am a hacker”

Enter this into the input field and you get the result:

Answer: websites_can_be_easily_defaced_with_xss


Task 21 (SEV 8 — Insecure Deserialisation)

Insecure deserialisation is replacing data processed by an application with malicious code; allowing anything from DoS (Denial of Service) to RCE (Remote Code Execution) that the attacker can use to gain a foothold in a pentesting scenario. Specifically, this malicious code leverages the legitimate serialisation and deserialisation process used by web applications. We’ll be explaining this process and why it is so commonplace in modern web applications.

What’s Vulnerable?

At summary, ultimately, any application that stores or fetches data where there are no validations or integrity checks in place for the data queried or retained. A few examples of applications of this nature are:

– E-Commerce Sites
– Forums
– API’s
– Application Runtimes (Tomcat, Jenkins, Jboss, etc)

Questions

Who developed the Tomcat application?

Answer: The Apache Software Foundation

What type of attack that crashes services can be performed with insecure deserialisation?

Answer: Denial Of Service


Task 22 (SEV 8— Insecure Deserialization — Objects)

A prominent element of object-oriented programming (OOP), objects are made up of two things:

  • State
  • Behaviour

Simply, objects allow you to create similar lines of code without having to do the leg-work of writing the same lines of code again.

For example, a lamp would be a good object. Lamps can have different types of bulbs, this would be their state, as well as being either turned on/off — their behaviour!

Questions

Select the correct term of the following statement: if a dog was sleeping, would this be:

A) A State
B) A Behaviour

It’s number of legs would be a state, in other words a property. Sleeping is a “function” and therefore a behaviour.

Answer: a behaviour


Task 23 (SEV 8 – Insecure Deserialization — Deserialization)

Serialisation is the process of converting objects used in programming into simpler, compatible formatting for transmitting between systems or networks for further processing or storage. Alternatively, deserialisation is the reverse of this; converting serialised information into their complex form — an object that the application will understand.

What does this mean?

Say you have a password of “password123” from a program that needs to be stored in a database on another system. To travel across a network this string/output needs to be converted to binary. Of course, the password needs to be stored as “password123” and not its binary notation. Once this reaches the database, it is converted or deserialised back into “password123” so it can be stored.

How can we leverage this?

Simply, insecure deserialization occurs when data from an untrusted party 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.

Questions

What is the name of the base-2 formatting that data is sent across a network as?

Easy. Base-2 means ones and zeroes. Binary!

Answer: binary


Task 24 (SEV 8) – Insecure Deserialization — Cookies

Cookies are an essential tool for modern websites to function. Tiny pieces of data, these are created by a website and stored on the user’s computer. Websites use these cookies to store user-specific behaviours like items in their shopping cart or session IDs. In the web application, we’re going to exploit, you’ll notice cookies store login information like the below!

Whilst plaintext credentials is a vulnerability in itself, it is not insecure deserialisation as we have not sent any serialised data to be executed!

Cookies are not permanent storage solutions like databases. Some cookies such as session ID’s will clear when the browser is closed, others, however, last considerably longer. This is determined by the “Expiry” timer that is set when the cookie is created.

Questions

If a cookie had the path of webapp.com/login , what would the URL that the user has to visit be?

Answer: webapp.com/login

What is the acronym for the web technology that Secure cookies work over?

Answer: HTTPS


Task 25 (SEV 8 — Insecure Deserialization — Cookies Practical)

In the browser of the device that you are connected to the VPN with, navigate to the ip of the target machine.

Let’s create an account. No need to enter your TryHackMe details, you can enter what you like. Afterwards login and you will be directed to your profile page. Right-Click the Page and press “Inspect Element”. Navigate to the “Storage” tab.

Inspecting Encoded Data

You will see here that there are cookies are both plaintext encoded and base64 encoded. The first flag will be found in one of these cookies. Notice here that you have a cookie named “userType”. You are currently a user, as confirmed by your information on the “myprofile” page. This application determines what you can and cannot see by your userType. What if you wanted to be come an admin?

Double left-click the “Value” column of “userType” to modify the contents. Let’s change our userType to “admin” and navigate to http://10.10.211.171/admin to answer the second flag.

Questions

1st flag (cookie value)

There is a value for sessionId, but it is base64 encoded.

gAN9cQAoWAkAAABzZXNzaW9uSWRxAVggAAAAMDhkN2NhZDgyZmQ2NDg5MDg2OTNjN2QwYTU3ZWFiMmNxAlgLAAAAZW5jb2RlZGZsYWdxA1gYAAAAVEhNe2dvb2Rfb2xkX2Jhc2U2NF9odWh9cQR1Lg==

You can enter it on the following website to decode it (make sure to select decode:

https://www.base64encode.org/

Answer: THM{good_old_base64_huh}

2nd flag (admin dashboard)

Make sure you edited the value of the userType cookie to admin:

Visit the admin page. Here you will find the answer.

Answer: THM{heres_the_admin_flag}


Task 26 (SEV 8) — Insecure Deserialization — Code Execution

1. First, change the value of the userType cookie from “admin” to “user” and return to http://<ip>/myprofile

2. Then, left-click on the URL in “Exhange your vim” found in the screenshot below.

3. Once you have done this, left-click on the URL in “Provide your feedback!” where you will be direct to a page with a form.

What makes this form vulnerable?

If a user was to enter their feedback, the data will get encoded and sent to the Flask application (presumably for storage within a database for example). However, the application assumes that any data encoded is trustworthy.

The Exploit

First, we need to set up a netcat listener on our Kali.

Because the code being deserialised is from a base64 format, we cannot just simply spawn a reverse shell. We must encode our own commands in base64 so that the malicious code will be executed. I will be detailing the steps below with provided material to do so.

Once this is complete, copy-and-paste the source code from this python file (pickelme.py) to your kali and modify the source code to replace your “YOUR_TRYHACKME_VPN_IP” with your TryHackMe VPN IP.

1. Create a python file to paste into, I have used “rce.py” for these examples:

2. Paste the code from the GitHub site, replacing YOUR_TRYHACKME_VPN_IP with your TryHackMe VPN IP from the access page.

3. Execute “rce.py” via python3 rce.py

4. Note the output of the command, it will look something similar to this:

5. Copy and paste everything in-between the two speech marks (‘DATA’).

6. Paste this into the “encodedPayload” cookie in your browser:

7. Ensure our netcat listener is still running.

8. Refresh the page. It will hang, refer back to your netcat listener:

If you have performed the steps correctly, you will now have a remote shell to your instance. No privilege escalation involved, look for the flag.txt flag!

Questions

flag.txt

Follow all the steps. Setup the netcat listener, create a python file, insert the code from Github, paste in your attacking machine ip, run the script, and insert the output in the “encodedPayload” cookie. This will give you a remote shell to the instance. Go up a level, and you will find the flag.txt file.

Answer: 4a69a7ff9fd68


Task 27 (SEV 9 – Components With Known Vulnerabilities — Intro)

Occasionally, you may find that the company/entity that you’re pen-testing is using a program that already has a well documented vulnerability.

For example, let’s say that a company hasn’t updated their version of WordPress for a few years, and using a tool such as wpscan, you find that it’s version 4.6. Some quick research will reveal that WordPress 4.6 is vulnerable to an unauthenticated remote code execution(RCE) exploit, and even better you can find an exploit already made on exploit-db.

As you can see this would be quite devastating, because it requires very little work on the part of the attacker as often times since the vulnerability is already well known, someone else has made an exploit for the vulnerability. The situation becomes even worse when you realize, that it’s really quite easy for this to happen, if a company misses a single update for a program they use, they could be vulnerable to any number of attacks.

Questions

Read above.

Answer: No answer needed.


Task 28 (SEV 9 — Components With Known Vulnerabilities — Exploit)

Recall that since this is about known vulnerabilities, most of the work has already been done for us. Our main job is to find out the information of the software, and research it until we can find an exploit. Let’s go through that with an example web application.

The server is using the default page for the nostromo web server. Now that we have a version number and a software name, we can use exploit-db to try and find an exploit for this particular version.

(Note: exploit-db is incredibly useful, and for all you beginners you’re gonna be using this a lot so it’s best to get comfortable with it)

Lucky us, the top result happens to be an exploit script. Let’s download it and try and to get code execution. Fortunately for us, the error was caused by an line that should have been commented, so it’s an easy fix. Fixing that, let’s try and run the program again.

Boom! We have RCE. Now it’s important to note here that most scripts will just tell you what arguments you need to provide, exploit developers will rarely make you read potentially hundreds of lines of codes just to figure out how to use the script.

Questions

Read the above!

Answer: No answer needed.


Task 29 (SEV 9 — Components With Known Vulnerabilities — Lab)

The following is a vulnerable application, all information you need to exploit it can be found online.

Note: When you find the exploit script, put all of your input in quotes, for example “id”

Questions

How many characters are in / etc/passwd?

Visit the web app in the browser.

So it is a CSE bookstore app. Go to exploit-db, search for bookstore and you will find the following exploit:

It mentions a admin.php page on which you can login with:
Payload:
Name: admin
Pass: %' or '1'='1

You now have admin access!

BUT…

We need to get access to the passwd file. There is another exploit:

This requires us to add some books to our shopping cart (click on a book on the front page), and visit cart.php afterwards. Here we can insert payloads in the quantity field: "><svg/onload=alert(5)>

But again, not the right exploit. A final one is found here:

Let’s download the script and run it in the terminal.

wget https://www.exploit-db.com/exploits/47887

Try running the script: python3 47887.py

If you run it as it, we are missing a url parameter. Let’s add it and see if it runs.

Heck yes!

Now all we need it to run the command mentioned in the question. This uses the word count function, but with the -c flag it counts characters instead.

Answer: 1611


Task 30 (SEV 10— Insufficient Logging and Monitoring)

When web applications are set up, every action performed by the user should be logged. Logging is important because in the event of an incident, the attackers actions can be traced. Once their actions are traced, their risk and impact can be determined. Without logging, there would be no way to tell what actions an attacker performed if they gain access to particular web applications. The bigger impacts of these include:

  • regulatory damage: if an attacker has gained access to personally identifiable user information and there is no record of this, not only are users of the application affected, but the application owners may be subject to fines or more severe actions depending on regulations.
  • risk of further attacks: without logging, the presence of an attacker may be undetected. This could allow an attacker to launch further attacks against web application owners by stealing credentials, attacking infrastructure and more.

The information stored in logs should include:

  • HTTP status codes
  • Time Stamps
  • Usernames
  • API endpoints/page locations
  • IP addresses

These logs do have some sensitive information on them so its important to ensure that logs are stored securely and multiple copies of these logs are stored at different locations.

As you may have noticed, logging is more important after a breach or incident has occurred. The ideal case is having monitoring in place to detect any suspicious activity. The aim of detecting this suspicious activity is to either stop the attacker completely or reduce the impact they’ve made if their presence has been detected much later than anticipated. Common examples of suspicious activity includes:

  • multiple unauthorised attempts for a particular action (usually authentication attempts or access to unauthorised resources e.g. admin pages)
  • requests from anomalous IP addresses or locations: while this can indicate that someone else is trying to access a particular user’s account, it can also have a false positive rate.
  • use of automated tools: particular automated tooling can be easily identifiable e.g. using the value of User-Agent headers or the speed of requests. This can indicate an attacker is using automated tooling.
  • common payloads: in web applications, it’s common for attackers to use Cross Site Scripting (XSS) payloads. Detecting the use of these payloads can indicate the presence of someone conducting unauthorised/malicious testing on applications.

Just detecting suspicious activity isn’t helpful. This suspicious activity needs to be rated according to the impact level. For example, certain actions will higher impact than others. These higher impact actions need to be responded to sooner thus they should raise an alarm which raises the attention of the relevant party.

Questions

What IP address is the attacker using?

This one is easy. If you look in the login-logs.txt file you can see 4 entries with the same ip address, returning a 401 (unauthorized). This must be someone trying different usernames to get into the system!

Answer: 49.99.13.16

What kind of attack is being carried out?

It seems like a brute force attacks, where different combinations of usernames/passwords are being run.

Answer: brute force


Task 31 (What’s next?)

Nothing to do but celebrate our progress! Great job on getting through 31 tasks. Thanks for reading!


Like my articles?

You are welcome to give my article a clap or two 🙂
I would be so grateful if you support me by buying me a cup of coffee:

I learned a lot through HackTheBox’s Academy. If you want to sign up, you can get extra cubes, and support me in the process, if you use the following link: