For the astute among you, you’ll notice that the chaining of these types of exploits has been seen/used often enough, but the implications thereof are often overlooked. In this write-up we delve a little deeper into a real life example of how we uncovered three zero-days in a vendor system.

A big thank you to VTENEXT for their quick and diligent response to the disclosure, they serve as a great example of how to handle disclosures.

Typically during security assessments of more mature clients, we’re rarely faced with what many would describe as “low hanging fruit”. These organizations have worked hard to cover their technical bases, and implemented procedures and protocols to ensure that this keeps running smoothly. This is where we as security analysts need to up our game, and set our sights on more complex approaches, namely the zero-day approach.

Our client had the VTENEXT crm system on a server exposed to the internet. After some investigation into the server, we were able to ascertain the version of software being run, the server OS information, and the email address of the administrator of this system. We spun up a test environment, downloaded a copy of the software (which at the time of the assessment was 19.07).

Analyzing the code, we realized that the best way “in” would be to target the internal emailing component within this CRM. We noticed that there was no filtering on the “From” field in the messages module, and we were greeted with a friendly alert. 

The developers had implemented the HTTPOnly flag on the cookies, thus preventing any cookie theft.

Clicking through the system and investigating the functionality, we decided to focus our attention on the file upload portion. Uploading files didn’t require much more than the contents of the file, and an authenticated session. 

As can be seen above, no csrf mitigations in place. However, any file with a dangerous extension that we tried uploading automatically had a .txt appended to the end of it. Digging deeper into the code, we see the developers had made use of extension blacklisting.

An often overlooked extension within these systems is .pht (which in a stock installation of php/ubuntu, is processed by default).

Great, so now we have a trigger (XSS), an action to perform (CSRF), and a vulnerability to leverage (File upload vuln).

Piecing this all together, we had a way into the network, which we successfully exploited as the entry point for this particular external test. 

Below are the CVE’s assigned to these vulnerabilities:




Exploit database: https://www.exploit-db.com/exploits/48804

Watch the video to see the penetration test in action

Exposing a Cross-Site Scripting Attack 

Click here to find out more about Mobius Consulting