XSS and RCE

RCE (Remote Code Execution) is a critical vulnerability which usually is the final goal of an attack. With code execution, it’s possible to compromise servers, clients and entire networks. XSS, like many other vulnerabilities, is a step towards it, even if people usually don’t think about XSS in this way.

But far from being roughly coverage on this subject, this post would not be complete without taking into consideration the 2 possible scenarios regarding these: XSS to RCE and XSS from RCE. Although we may see an escalation from an XSS to an RCE as a logical step, it’s also possible to consider an RCE being used to XSS. It would be pointless to use the same domain for such a thing, so we will see a different procedure.

XSS to RCE

Leveraging an XSS to RCE usually is done with the compromise of an admin account of the target website, using CSRF to make requests on his behalf. Admins use to have upload capabilities via HTTP in their administration dashboard so it’s pretty straightforward to make him upload a web shell and achieve our RCE goal. After an admin session is stolen (or a new admin is created), an attacker can also perform manually the steps needed if he/she wants.

There are some other types of compromise using XSS, abusing server-side javascript and embedded browser engines in mobile apps as we can see in the links below:

XSS to RCE in …

XSS to RCE in Atlassian Hipchat

ColdFusion Bomb: A Chain Reaction From XSS to RCE

XSS from RCE

Third-party includes just enlarge the attack surface of a given website. So, from a security perspective, the security of a system equals the security of the weaker link on its trust chain. In a case of a website, including scripts from external sources give an attacker a way to achieve a stealthy stored XSS if he/she is able to take over one of the domains being called in the background by the target.

Usually, these scripts are hosted in a CDN (Content Delivery Network), which has a dedicated server to provide static content to thousands of websites. But a good assessment has to take all loaded scripts in consideration, in the hope of finding a potential third-party compromise. The level of difficulty may vary from medium to very hard, but the reward will be complete indirect control of the target website.

Let’s see a live example. The domain globo.com is one of the most visited in Brazil and worldwide:

After loading the website and checking its js calls with browser console (F12), we are able to see the following:

After checking the subdomain ivccftag.ivcbrasil.org.br, which is being called from globo.com, we have nothing obvious to work with (it’s static). But after playing a little with the main domain ivcbrasil.org.br:

A SQL injection, a critical vulnerability that can lead to a full server compromise is present. For legal reasons, we can’t go further without explicit authorization. Although not the domain included on globo.com, it’s not that difficult to imagine how far we can go to increase the chances to compromise the desired subdomain and include our code in the middle of the served javascript file (ivc.js) to globo.com.

To see it working without actually having to compromise anything, just append the respective line to your host's file

And create a file named ivc.js in your webroot folder with alert(document.domain) as content. A popup will appear: