Mastering OWASP Top 10 by Solving TryHackMe Labs Part 1 of 2
Link : https://tryhackme.com/room/owasptop10
Task1 : Introduction
This room breaks each OWASP topic down and includes details on what the vulnerability is, how it occurs and how you can exploit it. You will put the theory into practise by completing supporting challenges.
· Injection
· Broken Authentication
· Sensitive Data Exposure
· XML External Entity
· Broken Access Control
· Security Misconfiguration
· Cross-site Scripting
· Insecure Deserialization
· Components with Known Vulnerabilities
· Insufficent Logging & Monitoring
The room has been designed for beginners and assume no previous knowledge of security.
Answer the questions : No answer needed
Task 2 : Accessing machines
Some tasks will have you learning by doing, often through hacking a virtual machine.
However, to access these machines you need to either:
· Connect using OpenVPN (connect using OpenVPN by SSH in terminal)
· Use an in-browser Linux Machine (deploy the in-browser AttackBox!)
Connect to our network or deploy the AttackBox.
Answer the questions : No answer needed
Task 3 : [Severity 1] Injection
Injection flaws are very common in applications today. These flaws occur because user controlled input is interpreted as actual commands or parameters by the application. Injection attacks depend on what technologies are being used and how exactly the input is interpreted by these technologies. Some common examples include:
SQL Injection: This occurs when user controlled input is passed to SQL queries. As a result, an attacker can pass in SQL queries to manipulate the outcome of such queries.
Command Injection: This occurs when user input is passed to system commands. As a result, an attacker is able to execute arbitrary system commands on application servers.
If an attacker is able to successfully pass input that is interpreted correctly, they would be able to do the following:
Access, Modify and Delete information in a database when this input is passed into database queries. This would mean that an attacker can steal sensitive information such as personal details and credentials.
Execute Arbitrary system commands on a server that would allow an attacker to gain access to users’ systems. This would enable them to steal sensitive data and carry out more attacks against infrastructure linked to the server on which the command is executed.
The main defence for preventing injection attacks is ensuring that user controlled input is not interpreted as queries or commands. There are different ways of doing this:
Using an allow list: when input is sent to the server, this input is compared to a list of safe input or characters. If the input is marked as safe, then it is processed. Otherwise, it is rejected and the application throws an error.
Stripping input: If the input contains dangerous characters, these characters are removed before they are processed.
Dangerous characters or input is classified as any input that can change how the underlying data is processed. Instead of manually constructing allow lists or even just stripping input, there are various libraries that perform these actions for you.
I’ve understood Injection attacks.
Answer the questions : No answer needed
Task 4 [Severity 1] OS Command Injection
Command Injection occurs when server-side code (like PHP) in a web application makes a system call on the hosting machine. It is a web vulnerability that allows an attacker to take advantage of that made system call to execute operating system commands on the server. Sometimes this won’t always end in something malicious, like a whoami or just reading of files. That isn’t too bad. But the thing about command injection is it opens up many options for the attacker. The worst thing they could do would be to spawn a reverse shell to become the user that the web server is running as. A simple ;nc -e /bin/bash is all that’s needed and they own your server; some variants of netcat don’t support the -e option. You can use a list of these reverse shells as an alternative.
Once the attacker has a foothold on the web server, they can start the usual enumeration of your systems and start looking for ways to pivot around. Now that we know what command injection is, we’ll start going into the different types and how to test for them.
I’ve understood command injection.
Answer the questions : No answer needed
Task 5 [Severity 1] Command Injection Practical
What is Active Command Injection?
Blind command injection occurs when the system command made to the server does not return the response to the user in the HTML document. Active command injection will return the response to the user. It can be made visible through several HTML elements.
Let’s consider a scenario: EvilCorp has started development on a web based shell but has accidentally left it exposed to the Internet. It’s nowhere near finished but contains the same command injection vulnerability as before! But this time, the response from the system call can be seen on the page! They’ll never learn!
Just like before, let’s look at the sample code from evilshell.php and go over what it’s doing and why it makes it active command injection. See if you can figure it out. I’ll go over it below just as before.
EvilShell (evilshell.php) Code Example
In pseudocode, the above snippet is doing the following:
1. Checking if the parameter “commandString” is set
2. If it is, then the variable $command_string gets what was passed into the input field
3. The program then goes into a try block to execute the function passthru($command_string). You can read the docs on passthru() on PHP’s website, but in general, it is executing what gets entered into the input then passing the output directly back to the browser.
4. If the try does not succeed, output the error to page. Generally this won’t output anything because you can’t output stderr but PHP doesn’t let you have a try without a catch.
Ways to Detect Active Command Injection
We know that active command injection occurs when you can see the response from the system call. In the above code, the function passthru() is actually what’s doing all of the work here. It’s passing the response directly to the document so you can see the fruits of your labor right there. Since we know that, we can go over some useful commands to try to enumerate the machine a bit further. The function call here to passthru() may not always be what’s happening behind the scenes, but I felt it was the easiest and least complicated way to demonstrate the vulnerability.
Commands to try
Linux
- whoami
- id
- ifconfig/ip addr
- uname -a
- ps -ef
Windows
- whoami
- ver
- ipconfig
- tasklist
- netstat -an
To complete the questions below, navigate to http://MACHINE_IP/evilshell.php.
Answer the questions below :
What strange text file is in the website root directory?
Answer : drpepper.txt
Explanation
Type the command ls in the console of the reverse shell and press submit
How many non-root/non-service/non-daemon users are there?
Answer : 0
Explanation
Type the command cat /etc/passwd in the console of the reverse shell and press submit
What user is this app running as?
Answer : www-data
Explanation
Type the command whoami in the console of the reverse shell and press submit
What is the user’s shell set as?
Answer : /usr/sbin/nologin
Explanation
Type the command getent passwd www-data in the console of the reverse shell and press submit
What version of Ubuntu is running?
Answer : 18.04.4
Explanation
Type the command lsb_release -a in the console of the reverse shell and press submit
Print out the MOTD. What favorite beverage is shown?
Answer : Dr Pepper
Explanation
Type the command cat /etc/update-motd.d/00-header in the console of the reverse shell and press submit
Task 6 [Severity 2] Broken Authentication
Authentication and session management constitute core components of modern web applications. Authentication allows users to gain access to web applications by verifying their identities. The most common form of authentication is using a username and password mechanism. A user would enter these credentials, the server would verify them. If they are correct, the server would then provide the users’ browser with a session cookie. A session cookie is needed because web servers use HTTP(S) to communicate which is stateless. Attaching session cookies means that the server will know who is sending what data. The server can then keep track of users’ actions.
If an attacker is able to find flaws in an authentication mechanism, they would then successfully gain access to other users’ accounts. This would allow the attacker to access sensitive data (depending on the purpose of the application). Some common flaws in authentication mechanisms include:
Brute force attacks: If a web application uses usernames and passwords, an attacker is able to launch brute force attacks that allow them to guess the username and passwords using multiple authentication attempts.
- Use of weak credentials: web applications should set strong password policies. If applications allow users to set passwords such as ‘password1’ or common passwords, then an attacker is able to easily guess them and access user accounts. They can do this without brute forcing and without multiple attempts.
- Weak Session Cookies: Session cookies are how the server keeps track of users. If session cookies contain predictable values, an attacker can set their own session cookies and access users’ accounts.
There can be various mitigation for broken authentication mechanisms depending on the exact flaw:
- To avoid password guessing attacks, ensure the application enforces a strong password policy.
- To avoid brute force attacks, ensure that the application enforces an automatic lockout after a certain number of attempts. This would prevent an attacker from launching more brute force attacks.
- Implement Multi Factor Authentication — If a user has multiple methods of authentication, for example, using username and passwords and receiving a code on their mobile device, then it would be difficult for an attacker to get access to both credentials to get access to their account.
I’ve understood broken authentication mechanisms.
Answer the questions : No answer needed
Task 7 [Severity 2] Broken Authentication Practical
For this example, we’ll be looking at a logic flaw within the authentication mechanism.
A lot of times what happens is that developers forgets to sanitize the input(username & password) given by the user in the code of their application, which can make them vulnerable to attacks like SQL injection. However, we are going to focus on a vulnerability that happens because of a developer’s mistake but is very easy to exploit i.e re-registration of an existing user.
Let’s understand this with the help of an example, say there is an existing user with the name admin and now we want to get access to their account so what we can do is try to re-register that username but with slight modification. We are going to enter “ admin”(notice the space in the starting). Now when you enter that in the username field and enter other required information like email id or password and submit that data. It will actually register a new user but that user will have the same right as normal admin. That new user will also be able to see all the content presented under the user admin.
To see this in action go to http://MACHINE_IP:8888 and try to register a user name darren, you’ll see that user already exists so then try to register a user “ darren” and you’ll see that you are now logged in and will be able to see the content present only in Darren’s account which in our case is the flag that you need to retrieve.
Answer the questions below :
What is the flag that you found in darren’s account?
Answer : fe86079416a21a3c99937fea8874b667
Now try to do the same trick and see if you can login as arthur.
Answer : No answer needed
What is the flag that you found in arthur’s account?
Answer : d9ac0f7db4fda460ac3edeb75d75e16e
Task 8 [Severity 3] Sensitive Data Exposure (Introduction)
When a webapp accidentally divulges sensitive data, we refer to it as “Sensitive Data Exposure”. This is often data directly linked to customers (e.g. names, dates-of-birth, financial information, etc), but could also be more technical information, such as usernames and passwords. At more complex levels this often involves techniques such as a “Man in The Middle Attack”, whereby the attacker would force user connections through a device which they control, then take advantage of weak encryption on any transmitted data to gain access to the intercepted information (if the data is even encrypted in the first place…). Of course, many examples are much simpler, and vulnerabilities can be found in web apps which can be exploited without any advanced networking knowledge. Indeed, in some cases, the sensitive data can be found directly on the webserver itself…
The web application in this box contains one such vulnerability. Deploy the machine, then read through the supporting material in the following tasks as the box boots up.
Read the introduction to Sensitive Data Exposure and deploy the machine.
Answer the questions : No answer needed
Task 9 [Severity 3] Sensitive Data Exposure (Supporting Material 1)
The most common way to store a large amount of data in a format that is easily accessible from many locations at once is in a database. This is obviously perfect for something like a web application, as there may be many users interacting with the website at any one time. Database engines usually follow the Structured Query Language (SQL) syntax; however, alternative formats (such as NoSQL) are rising in popularity.
In a production environment it is common to see databases set up on dedicated servers, running a database service such as MySQL or MariaDB; however, databases can also be stored as files. These databases are referred to as “flat-file” databases, as they are stored as a single file on the computer. This is much easier than setting up a full database server, and so could potentially be seen in smaller web applications. Accessing a database server is outwith the scope of today’s task, so let’s focus instead on flat-file databases.
As mentioned previously, flat-file databases are stored as a file on the disk of a computer. Usually this would not be a problem for a webapp, but what happens if the database is stored underneath the root directory of the website (i.e. one of the files that a user connecting to the website is able to access)? Well, we can download it and query it on our own machine, with full access to everything in the database. Sensitive Data Exposure indeed!
That is a big hint for the challenge, so let’s briefly cover some of the syntax we would use to query a flat-file database.
The most common (and simplest) format of flat-file database is an sqlite database. These can be interacted with in most programming languages, and have a dedicated client for querying them on the command line. This client is called “sqlite3”, and is installed by default on Kali.
Let’s suppose we have successfully managed to download a database:
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 can see from the table information that there are four columns: custID, custName, creditCard and password. You may notice that this matches up with the results. Take the first row:
0|Joy Paulson|4916 9012 2231 7905|5f4dcc3b5aa765d61d8327deb882cf99
We have the custID (0), the custName (Joy Paulson), the creditCard (4916 9012 2231 7905) and a password hash (5f4dcc3b5aa765d61d8327deb882cf99).
In the next task we’ll look at cracking this hash.
Read and understand the supporting material on SQLite Databases.
Answer the questions : No answer needed
Task 10 [Severity 3] Sensitive Data Exposure (Supporting Material 2)
In the previous task we saw how to query an SQLite database for sensitive data. We found a collection of password hashes, one for each user. In this task we will briefly cover how to crack these.
When it comes to hash cracking, Kali comes pre-installed with various tools — if you know how to use these then feel free to do so; however, they are outwith the scope of this material.
Instead we will be using the online tool: Crackstation. This website is extremely good at cracking weak password hashes. For more complicated hashes we would need more sophisticated tools; however, all of the crackable password hashes used in today’s challenge are weak MD5 hashes, which Crackstation should handle very nicely indeed.
When we navigate to the website we are met with the following interface:
Let’s try pasting in the password hash for Joy Paulson which we found in the previous task (5f4dcc3b5aa765d61d8327deb882cf99). We solve the Captcha, then click the “Crack Hashes” button:
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.
Read the supporting material about cracking hashes.
Answer the questions : No answer needed
Task 11 [Severity 3] Sensitive Data Exposure (Challenge)
It’s now time to put what you’ve learnt into practice!
Answer the questions below :
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?
Answer : /assets
Navigate to the directory you found in question one. What file stands out as being likely to contain sensitive data?
Answer : webapp.db
Use the supporting material to access the sensitive data. What is the password hash of the admin user?
Answer : 6eea9b7ef19179a06954edd0f6c05ceb
Explanation
In kali terminal run sqlite3 webapp.db
Crack the hash. What is the admin’s plaintext password?
Answer : qwertyuiop
Explanation
Using crackstation https://crackstation.net/
Login as the admin. What is the flag?
Answer : THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}
Task 12 [Severity 4] XML External Entity
An XML External Entity (XXE) attack is a vulnerability that abuses features of XML parsers/data. It often allows an attacker to interact with any backend or external systems that the application itself can access and can allow the attacker to read the file on that system. They can also cause Denial of Service (DoS) attack or could use XXE to perform Server-Side Request Forgery (SSRF) inducing the web application to make requests to other applications. XXE may even enable port scanning and lead to remote code execution.
There are two types of XXE attacks: in-band and out-of-band (OOB-XXE).
1) An in-band XXE attack is the one in which the attacker can receive an immediate response to the XXE payload.
2) out-of-band XXE attacks (also called blind XXE), there is no immediate response from the web application and attacker has to reflect the output of their XXE payload to some other file or their own server.
This challenge is from our subscriber only material - happy hacking!
Deploy the machine attached to the task.
Answer the questions : No answer needed
Task 13 [Severity 4 XML External Entity — eXtensible Markup Language
Before we move on to learn about XXE exploitation we’ll have to understand XML properly.
What is XML?
XML (eXtensible Markup Language) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. It is a markup language used for storing and transporting data.
Why we use XML?
1. XML is platform-independent and programming language independent, thus it can be used on any system and supports the technology change when that happens.
2. The data stored and transported using XML can be changed at any point in time without affecting the data presentation.
3. XML allows validation using DTD and Schema. This validation ensures that the XML document is free from any syntax error.
4. XML simplifies data sharing between various systems because of its platform-independent nature. XML data doesn’t require any conversion when transferred between different systems.
Syntax
Every XML document mostly starts with what is known as XML Prolog.
<?xml version="1.0" encoding="UTF-8"?>
Above the line is called XML prolog and it specifies the XML version and the encoding used in the XML document. This line is not compulsory to use but it is considered a `good practice` to put that line in all your XML documents.
Every XML document must contain a `ROOT` element. For example:
<?xml version="1.0" encoding="UTF-8"?>
<mail> <to>falcon</to> <from>feast</from> <subject>About XXE</subject> <text>Teach about XXE</text>
</mail>
In the above example the <mail> is the ROOT element of that document and <to>, <from>, <subject>, <text> are the children elements. If the XML document doesn't have any root element then it would be consideredwrong or invalid XML doc.
Another thing to remember is that XML is a case sensitive language. If a tag starts like <to> then it has to end by </to> and not by something like </To>(notice the capitalization of T)
Like HTML we can use attributes in XML too. The syntax for having attributes is also very similar to HTML. For example:
<text category = "message">You need to learn about XXE</text>
In the above example category is the attribute name and message is the attribute value.
Answer the questions below
Full form of XML ?
Answer : Extensible Markup Language
Is it compulsory to have XML prolog in XML documents?
Answer : no
Can we validate XML documents against a schema?
Answer : yes
How can we specify XML version and encoding in XML document?
Answer : 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.
DTD stands for Document Type Definition. A DTD defines the structure and the legal elements and attributes of an XML document.
Let us try to understand this with the help of an example. Say we have a file named note.dtd with the following content:
<!DOCTYPE note [ <!ELEMENT note (to,from,heading,body)> <!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> <!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)> ]>
Now we can use this DTD to validate the information of some XML document and make sure that the XML file conforms to the rules of that DTD.
Ex: Below is given an XML document that uses note.dtd
<?xml version=”1.0" encoding=”UTF-8"?>
<!DOCTYPE note SYSTEM “note.dtd”>
<note>
<to>falcon</to>
<from>feast</from>
<heading>hacking</heading>
<body>XXE attack</body>
</note>
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.
Answer the questions below
How do you define a new ELEMENT?
Answer : !ELEMENT
How do you define a ROOT element?
Answer : !DOCTYPE
How do you define a new ENTITY?
Answer : !ENTITY
