In this post, we covered OWASP Top 10 using the material in TryHackMe OWASP Top 10 Room. You can find answers to the room’s questions below along with a video playlist of walk-throughs for thorough explanations.
We also covered the solutions for TryHackMe OWASP Top 10 – 2021 room.
HackTheBox Certified Penetration Testing Specialist (CPTS) Study Notes
According to OWASP, the top 10 web application vulnerabilities are
- A01:2021-Broken Access Control
- A02:2021-Cryptographic Failures
- A03:2021-Injection
- A04:2021-Insecure Design
- A05:2021-Security Misconfiguration
- A06:2021-Vulnerable and Outdated Components
- A07:2021-Identification and Authentication Failures
- A08:2021-Software and Data Integrity Failures
- A09:2021-Security Logging and Monitoring Failures
- A10:2021-Server-Side Request Forgery
Injection Vulnerabilities
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.
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.
Task 5 Answers
What strange text file is in the website root directory?
drpepper.txt
How many non-root/non-service/non-daemon users are there?
0
What user is this app running as?
www-data
What is the user’s shell set as?
/usr/sbin/nologin
What version of Ubuntu is running?
18.04.4
Print out the MOTD. What favorite beverage is shown?
Dr Pepper
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.
Task 7 Answers
What is the flag that you found in darren’s account?
fe86079416a21a3c99937fea8874b667
Now try to do the same trick and see if you can login as arthur.
No answer needed
What is the flag that you found in arthur’s account?
d9ac0f7db4fda460ac3edeb75d75e16e
Sensitive Data Exposure
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…
Task 11 Answers
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?
/assets
Navigate to the directory you found in question one. What file stands out as being likely to contain sensitive data?
webapp.db
Use the supporting material to access the sensitive data. What is the password hash of the admin user?
6eea9b7ef19179a06954edd0f6c05ceb
Crack the hash.
What is the admin’s plaintext password?
qwertyuiop
Login as the admin. What is the flag?
THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}
XML External Entity Injection
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.
Task 13 Answers
Full form of XML
Extensible Markup Language
Is it compulsory to have XML prolog in XML documents?
no
Can we validate XML documents against a schema?
yes
How can we specify XML version and encoding in XML document?
XML prolog
Task 14 Answers
How do you define a new ELEMENT?
!ELEMENT
How do you define a ROOT element?
!DOCTYPE
How do you define a new ENTITY?
!ENTITY
Example XXE Payloads
<!DOCTYPE replace [<!ENTITY name “feast”> ]>
<userInfo>
<firstName>falcon</firstName>
<lastName>&name;</lastName>
</userInfo>
<?xml version=”1.0″?>
<!DOCTYPE root [<!ENTITY read SYSTEM ‘file:///etc/passwd’>]>
<root>&read;</root>
Task 16 Answers
Try to display your own name using any payload.
No answer needed
See if you can read the /etc/passwd
No answer needed
What is the name of the user in /etc/passwd
falcon
Where is falcon’s SSH key located?
/home/falcon/.ssh/id_rsa
What are the first 18 characters for falcon’s private key
MIIEogIBAAKCAQEA7
Broken Access Control Vulnerability
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:
pstmt.setString(1, request.getParameter(“acct”));
ResultSet results = pstmt.executeQuery( );
An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.
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/getappInfo
http://example.com/app/admin_getappInfo
If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw (reference to scenarios).
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.
IDOR Vulnerability
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:
pstmt.setString(1, request.getParameter(“acct”));
ResultSet results = pstmt.executeQuery( );
An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.
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/getappInfo
http://example.com/app/admin_getappInfo
If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw (reference to scenarios).
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.
Look at other users notes. What is the flag?
flag{fivefourthree}
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.
Hack into the webapp, and find the flag!
thm{4b9513968fd564a87b28aa1f9d672e17}
Cross Site Scripting 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 () – 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.
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”.
ThereIsMoreToXSSThanYouThink
On the same reflective page, craft a reflected XSS payload that will cause a popup with your machines IP address.
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.
HTML_T4gs
On the same page, create an alert popup box appear on the page with your document cookies.
W3LL_D0N3_LVL2
Change “XSS Playground” to “I am a hacker” by adding a comment and using Javascript.
websites_can_be_easily_defaced_with_xss
Insecure Deserialization Vulnerability
“Insecure Deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application” (Acunetix., 2017)
This definition is still quite broad to say the least. Simply, insecure deserialization 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 serialization and deserialization process used by web applications. We’ll be explaining this process and why it is so commonplace in modern web applications.
OWASP rank this vulnerability as 8 out of 10 because of the following reasons:
- Low exploitability. This vulnerability is often a case-by-case basis – there is no reliable tool/framework for it. Because of its nature, attackers need to have a good understanding of the inner-workings of the ToE.
- The exploit is only as dangerous as the attacker’s skill permits, more so, the value of the data that is exposed. For example, someone who can only cause a DoS will make the application unavailable. The business impact of this will vary on the infrastructure – some organisations will recover just fine, others, however, will not.
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)
If a cookie had the path of webapp.com/login , what would the URL that the user has to visit be?
webapp.com/login
What is the acronym for the web technology that Secure cookies work over?
HTTPS
Task 25 Flags
1st flag (cookie value)
THM{good_old_base64_huh}
2nd flag (admin dashboard)
THM{heres_the_admin_flag}
Task 26 Flag
flag.txt
4a69a7ff9fd68
Components with known vulnerabilities
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.
Hence, why OWASP has rated this a 3(meaning high) on the prevalence scale, it is incredibly easy for a company to miss an update for an application.
Task 29 Answers
How many characters are in /etc/passwd (use wc -c /etc/passwd to get the answer)
1611
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.
Put this knowledge to practise by analysing this sample log file.
What IP address is the attacker using?
49.99.13.16
What kind of attack is being carried out?
Brute Force
TryHackMe OWASP TOP 10 2021 | Room Answers
Look at other users’ notes. What is the flag?
flag{fivefourthree}
Have a look around the web app. 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?
/assets
Navigate to the directory you found in question one. What file stands out as being likely to contain sensitive data?
webapp.db
Use the supporting material to access the sensitive data. What is the password hash of the admin user?
6eea9b7ef19179a06954edd0f6c05ceb
Crack the hash.
What is the admin’s plaintext password?
qwertyuiop
Log in as the admin. What is the flag?
THM{Yzc2YjdkMjE5N2VjMzNhOTE3NjdiMjdl}
What strange text file is in the website’s root directory?
drpepper.txt
How many non-root/non-service/non-daemon users are there?
0
What is the user’s shell set as?
apache
What is the user’s shell set as?
/sbin/nologin
What version of Alpine Linux is running?
3.16.0
What is the value of the flag in joseph’s account?
THM{Not_3ven_c4tz_c0uld_sav3_U!}
What is the database file name (the one with the .db extension) in the current directory?
todo.db
Modify the code to read the contents of the app.py
file, which contains the application’s source code. What is the value of the secret_flag
variable in the source code?
THM{Just_a_tiny_misconfiguration}
What is the content of the /opt/flag.txt file?
THM{But_1ts_n0t_myf4ult!}
What is the flag that you found in darren’s account?
fe86079416a21a3c99937fea8874b667
What is the flag that you found in arthur’s account?
d9ac0f7db4fda460ac3edeb75d75e16e
What is the SHA-256 hash of https://code.jquery.com/jquery-1.12.4.min.js
?
sha256-ZosEbRLbNQzLpnKIkEdrPv7lOy9C27hHQ+Xp8a4MxAQ=
Try logging into the application as guest. What is guest’s account password?
guest
What is the name of the website’s cookie containing a JWT token?
jwt-session
What is the flag presented to the admin user?
THM{Dont_take_cookies_from_strangers}
What IP address is the attacker using?
What kind of attack is being carried out?
Brute Force
Explore the website. What is the only host allowed to access the admin area?
localhost
Check the “Download Resume” button. Where does the server parameter point to?
secure-file-storage.com
Using SSRF, make the application send the request to your AttackBox instead of the secure file storage. Are there any API keys in the intercepted request?
THM{Hello_Im_just_an_API_key}
Video Playlist Walk-Throughs