Hi! In this article I will cover THMs room on the OWASP top 10, a list of the most critical web security risks. Join me!
I am making these walkthroughs to keep myself motivated to learn cyber security, and ensure that I remember the knowledge gained by THMs rooms. Join me on learning cyber security. I will try and explain concepts as I go, to differentiate myself from other walkthroughs.
Room URL: https://tryhackme.com/room/owasptop10
Part 2 can be found here:
https://medium.com/@JAlblas/tryhackme-owasp-top-10-task-17-31-walkthrough-73d5248fc8e4
Task 1 (Introduction)
The Open Web Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. The OWASP Top 10 is a book/referential document outlining the 10 most critical security concerns for web application security. These include:
- 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
Questions
Read the above.
Answer: No answer needed
Task 2 (Accessing machines)
Nothing to do here but accessing TryHackMe’s VPN or starting up the AttackBox.
Questions
Connect to our network or deploy the AttackBox.
Answer: No answer needed
Task 3 (SEV 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.
Questions
I’ve understood Injection attacks.
Answer: No answer needed
Task 4 (SEV 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. 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.
Questions
I’ve understood command injection.
Answer: No answer needed
Task 5 (SEV 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. We know that active command injection occurs when you can see the response from the system call.
We can use these commands to answer the following questions:
Linux
- whoami
- id
- ifconfig/ip addr
- uname -a
- ps -ef
Windows
- whoami
- ver
- ipconfig
- tasklist
- netstat -an
Questions
What strange text file is in the website root directory?
Let’s start looking in the root directory by entering ls in the EvilShell input text field. We get the following result:
drpepper.txt looks interesting! Note: we can actually read it by writing cat drpepper.txt.
Answer: drpepper.txt
How many non-root/non-service/non-daemon users are there?
You can find a list of all users by looking at the following command:
Human users have a UUID of greater than 1000, which is the third column when the command. You can see that no users have a UUID of over 1000, so they are all root/service/daemon users.
Answer: 0
What user is this app running as?
This one is easy. Insert whoami in the input field.
Answer: www-data
What is the user’s shell set as?
If you look at the passwd file again, you can find the following info on the current user:
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
Answer: /usr/sbin/nologin
What version of Ubuntu is running?
Run the command lsb_release -a.
Answer: 18.04.4
Print out the MOTD. What favourite beverage is shown?
MOTD stands for Message Of The Day. A little bit of help from Google tells us that the MOTD is usually in /etc/update-motd.d
. In this file there are different headers, and the answer is hidden in the 00-header. Write cat /etc/update-motd.d/00-header in the input field and you will find the answer.
PS: Technically you could have gotten this answer by remembering the text file we found during the first question.
Answer: dr pepper
Task 6 (SEV 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.
Questions
I’ve understood broken authentication mechanisms.
Answer: No answer needed
Task 7 (SEV 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.
Questions
What is the flag that you found in darren’s account?
When you try to create a new user with the name darren then you get the following message:
Let’s try again with an extra whitespace before “darren”. We get registrered and if we afterwards try to login we can see we got access to darren’s profile:
What likely happened on the backend is that the developer has not checked for whitespace, and thus when loading data for “ darren”, you get to see data for “darren”.
Answer: fe86079416a21a3c99937fea8874b667
Now try to do the same trick and see if you can login as arthur.
Same as before. Create a new user with “ arthur”, and try logging in to it.
Answer: No answer needed
What is the flag that you found in arthur’s account?
We get access and see the flag.
Answer: d9acc0f7db4fda460ac3edeb75d75e16e
Task 8 (SEV 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…).
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.
Questions
Read the introduction to Sensitive Data Exposure and deploy the machine.
Answer: No answer needed.
Task 9 (SEV 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. 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!
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. 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:
Questions
Read and understand the supporting material on SQLite Databases.
Answer: No answer needed.
Task 10 (SEV 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.
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.
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.
Questions
Read the supporting material about cracking hashes.
Answer: No answer needed.
Task 11 (SEV 3 — Sensitive Data Exposure (Challenge))
It’s now time to put what you’ve learnt into practice!
Questions
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?
If you look in the source code for the webapp you can find the following message:
Answer: /assets
Navigate to the directory you found in question one. What file stands out as being likely to contain sensitive data?
Navigate to the directory by adding /assets after the machines ip address.
webapp.db sure looks interesting!
Answer: webapp.db
Use the supporting material to access the sensitive data. What is the password hash of the admin user?
Download the database file, open your terminal, and access the database by writing sqlite3 webapp.db. Proceed by entering .tables to list all tables in the database. Then write PRAGMA table_info(users) to see the columns of the users table.
Finally write the following SQL query to select all rows from the user table:
SELECT * FROM users;
We have gotten access to usernames and hashed passwords.
Answer: 6eea9b7ef19179a06954edd0f6c05ceb
Crack the hash. What is the admin’s plaintext password?
To get the answer to this question we can use https://crackstation.net/.
Enter the hashed password and let the website run. You should get the answer quickly! Spoiler: it’s very insecure!
Answer: qwertyuiop
Login as the admin. What is the flag?
Go back to the webapp and enter the initials.
And we got access once more!
Answer: THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}
Task 12 (SEV 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.
Questions
Deploy the machine attached to the task.
Answer: No answer needed.
Task 13 (SEV 4 — XML External Entity — eXtensible Markup Language)
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.
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.
Questions
Full form of XML
Answer: extensible markup language
Is it compulsory to have XML prolog in XML documents?
This is not required, but strongly encouraged!
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 (SEV 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.
Questions
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
Task 15 (SEV 4 — XML External Entity — XXE Payload)
Now we’ll see some XXE payload and see how they are working.
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.
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.
Questions
Try the payload mentioned in description on the website.
Answer: No answer needed.
Task 16 (SEV 4 — XML External Entity — Exploiting)
Now let us see some payloads in action. The payload that I’ll be using are the ones we saw in the previous task.
Questions
Try to display your own name using any payload.
I slightly adjusted the payload from the previous task:
<!DOCTYPE replace [<!ENTITY name “Jasper Alblas”> ]>
<userInfo>
<name>&name;</name>
</userInfo>
It basicly declares a a new entity called name and sets it to my name. Then we use it inside the userInfo and name XML tags.
Answer: No answer needed.
See if you can read the etc/passwd.
Yes we can:
I just used the previous example. We set a new entity, and set it equals to the output from reading the passwd file. Afterwards we display this inside a root XML tag.
Answer: No answer needed.
What is the name of the user in etc/passwd.
If you know a little about the passwd file, it gives the following information about each user:
- User name.
- Encrypted password.
- User ID number (UID)
- User’s group ID number (GID)
- Full name of the user (GECOS)
- User home directory.
- Login shell.
The important thing about the UID is that real users have a UID that is higher than 1000. In the bottom of the output we have the following line:
falcon:x:1000:1000:falcon,,,:/home/falcon:/bin/bash
Answer: falcon
Where is falcon’s SSH key located?
We know falcon’s home directory is located at /home/falcon. SSH keys are found within the .ssh directory within the home directory, and the private key is called id_rsa.
Answer: /home/falcon/.ssh/id_rsa
What are the first 18 characters for falcon’s private key?
We can use a similar XXE payload as when we read the passwd file:
Answer: MIIEogIBAAKCAQEA7b
We are done with task 16. We will continue with task 17 in another post as this one is getting very long! It can be found here: https://medium.com/@JAlblas/tryhackme-owasp-top-10-task-17-31-walkthrough-73d5248fc8e4
Like my articles?
You are welcome to support me by buying me a cup of coffee:
Finally, 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: