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, as many other vulnerabilities, is a step towards to it, even if people usually don’t think about XSS in this way.
But far from being a roughly coverage on this subject, this post would not be complete without taking in consideration the 2 possible scenarios regarding these: XSS to RCE and XSS from RCE. Although we may see an escalation from a XSS to a RCE as a logical step, it’s also possible to consider a RCE being used to XSS. It would be pointless to use the same domain for such thing, so we will see a different procedure.
XSS to RCE
Leveraging a XSS to RCE usually is done with the compromise of an admin account of the target website, using CSRF to make requests in his behalf. Admins use to have upload capabilities via HTTP in their administration dashboard so it’s pretty straightforward to make him upload a webshell 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 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, included scripts from external sources give an attacker a way to achieve a stealthy stored XSS if he/she is able to takeover one of the domains being called in 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 a 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:
Its request map is here.
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 difficulty 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 hosts file
And create a file named ivc.js in your web root folder with alert(document.domain) as content. A popup will appear:
#hack2learn
Brute XSS Cheat Sheet
Hey,
Good Writeup, but one doubt, in this case you are redirecting 127.0.0.1 to the Domain name ivccftag.ivcbrasil.org.br . Now, when you are making a File called svc.js with the content alert(1) than it will obviously prompt as it will try to go check your host and give preference to local hosted file > original domain. Hence, this is obviously a Self-XSS in that case. If you had exploited SQLi on that domain and than changed the Content of .js file than it would be true Exploit which could further lead to RCE.
Is that the case, right
Regards
Thanks. The hosts editing was just to show what would happened in the main domain if the domain used as source of a script was compromised. The ivc.js file would be updated to host the attacker’s malicious content. This would not lead to RCE, we are using RCE to achieve a stored XSS on main domain.