It is possible for an unauthenticated user with network access to a ClearPass server to expose database credentials.
This vulnerability leads to complete system compromise.
CVSSv3 Overall Score: 9.8
CVSS Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Discovery: This vulnerability was discovered by [email protected] and reported through the BugCrowd managed bug bounty
FIX: Fixed in 6.5.7 and 6.6.2
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.
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
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
Based on the applications function, we can guess that the application is using similar backend code to calculate the result:
<?php eval(\"$num1\" \"$operand\" \"$num2\"); ?>
STEP 2: Editing the operand field
Since there appears to be server side validation preventing non-integer values for $num1 and $num2, we can try to edit the operand field to get our injected PHP code to run. This can be done using a web browser and right-clicking the element and selecting “Inspect Element”.
STEP 3: Edit the operand field to inject our PHP code
To inject our PHP code, we will edit the operand field as shown below to control the execution of the original function without producing an error:
After clicking Submit, you will notice that our injected PHP function is executed and displayed. To prevent these types of attacks, all use of eval() should be avoided at all costs and all user input should be sanitized and validated before being executed.