CVE-2019-16384, 85: Cyblesoft Thinfinity VirtualUI – Path Traversal, HTTP Header Injection

Nettitude discovered two vulnerabilities within Cyblesoft’s Thinfinity VirtualUI web application. The findings include path traversal and HTTP header injection, which could be leveraged to execute an XSS payload.

Thinfinity VirtualUI enables Windows-based desktop applications to function as cross-browser, cross-device web applications, which can be run on a Windows environment or be accessed remotely from a web-browser.

Path Traversal Proof of Concept – CVE-2019-16384

The path traversal vulnerability can be leveraged to perform remote data exfiltration on the Windows host.  This enables files outside of the intended web directory to be retrieved if the location is known and the application has sufficient permissions. Consequently, this compromises the confidentiality of application data.

The following proof of concept shows how common Windows configuration files were retrieved on the test host, traversing the file directories using the ../ notation. This was captured on the Cyblesoft demo site.

Vulnerable Request Including Path Traversal Payload

Vulnerable Request Including Path Traversal Payload

Local File ‘win.ini’ Displayed within Server Response

Local File ‘win.ini’ Displayed within Server Response

HTTP Header Injection Proof of Concept – CVE-2019-16385

The identified HTTP header injection vulnerability enables control over the application response and can be leveraged to perform a reflected Cross-Site Scripting attack.

The vulnerable mimetype URL parameter can be injected with an arbitrary payload, which is reflected within the Content-type header of the server response, in its entirety.

Injecting HTML encoded carriage return line feed characters %0d%0a within that vulnerable parameter results in the response being split, as a new line is inserted within the header section of the server response, whilst still returning a 200 OK response.

The ability to insert newlines and arbitrary payloads gives full control over the contents of the response and as shown below can be leveraged to perform reflected cross-site scripting. The created new lines result in the proceeding response headers being interpreted as the response body, and within this new response body, the malicious JavaScript payload is injected.

An example payload consisting of encoded CRLF characters, HTML, and JavaScript is injected to reflect a basic alert box within the client.

Vulnerable Request Including HTML Encoded CRLF Characters and XSS Payload

Vulnerable Request Including HTML Encoded CRLF Characters and XSS Payload

Server Response Showing Injected JS Payload

Server Response Showing Injected JS Payload

Versions Affected

All versions up to and including Thinfinity VirtualUI are affected by both of the vulnerabilities disclosed.


These vulnerability types are common in modern web applications.  The ones presented here could have a moderate impact, and it is recommended that users of the software fix the vulnerability by applying the available patch,

Cyblesoft were quick to respond, and regular communication with the vendor enabled a patch to be released to address both of these issues before public disclosure.

Thinfinity UI Vulnerability Disclosure Timeline

  • Date of discovery: 20 August 2019
  • Vendor informed: 22 August 2019
  • Vendor patch received: 14 October 2019
  • Patch confirmed effective: 14 October 2019
  • Vendor informed about planned disclosure: 14 October 2019
  • Public Disclosure: 4 June 2020

Cross Site Scripting (XSS) Payload Generator

This post will help you to evade some of those tricky cross site scripting restrictions with the help of a new tool I’ve pushed to our XSS Payloads repository.

There are times during a web application penetration test when Cross Site Scripting (XSS) has been identified with a trivial payload such as <script>alert(1)</script> or via a Burp Suite scan result and you want to take it further, but for various reasons it’s not as easy as you would like to inject a useful JavaScript payload. This could be due to output encoding or character blacklisting, which might turn all your single and double quotes into their HTML entity equivalent, or it could be that simply by a quirk of where the injection occurs only non-letter characters can be used. In these cases we usually turn to encoding to build up an obfuscated string which will hopefully bypass these restrictions and that the application can interpret and execute.

For example, an application might block certain keywords in a string, so you encode your payload as base64 and then execute it by decoding with atob() and passing that into eval(), assigned to the “onerror” event of an image, to bypass restrictions on scripts:

<img src=x onerror=eval(atob('YWxlcnQoJ0kgb25seSB3cml0ZSBsYW1lIFBvQ3MnKQ==')) />

Burp Suite includes a few options for this, such as the “Decoder” tool, which can convert strings to and from base64, URL encoding, ASCII hex etc, and the often overlooked “Construct string” function which includes “Construct string in JavaScript” to create a string purely by using the String.fromCharCode() method.

C:\Users\coakley\Desktop\download (1).png

Constructing a string using String.fromCharCode

This is fine for doing a quick fire and forget payload, but what happens when it doesn’t work and you want to make some changes? You slowly find yourself getting caught in your browser’s Developer Tools and making tweaks, then laboriously having to re-encode them to make your chosen bypass method work, then re-encapsulating them into whatever delivery method you were able to use to execute the XSS payload. It’s time consuming, boring and ends up leading to difficult to spot errors because you’re no longer looking at readable source code.

When the injection method becomes more complex, such as when testing blind XSS with something like 0xsobky’s XSS polyglot, having to encode a simple payload into a string begins to quickly become non-trivial.

There were no time-saving options for solving this problem so I decided to make one, and added it to our XSS Payloads repository. It works by setting three basic options for the payload you want to generate which combine to create an encoded string. They should be fairly logical once you get started, but in brief, they are as follows.

XSS Payload

This is what you want the actual action to be when the XSS is executed and includes two methods for inserting an external script (JQuery and document.createElement), two methods for invoking a URL request ( XMLHttpRequest and Image), which are good for establishing execution has occurred when testing for blind XSS, and finally the option to simply write your own JavaScript snippet for when you just gotta have alert(1).

Selecting one of the two load script payloads automatically gives you the option of choosing from the scripts in the XSS payloads repository.


Loading a remote script using JQuery


The next option contains a series of basic obfuscation methods. These are designed to simply bypass filters. By default “None” is selected which simply puts the XSS payload verbatim into the resulting injection string. We also have the option of:

  • String eval() – passes the payload into the eval function.
  • Base64 – uses atob() to pass the base64 payload into eval.
  • Reverse – hides the payload by reversing it before passing to eval.
  • String.fromCharCode() – builds the string by ordinal values.
  • Hex codes – uses hex notation to create a string.
C:\Users\coakley\Desktop\download (2).png

Using the string reverse obfuscation technique

Injection type

This is how the XSS payload actually ends up being interpreted by a browser and is where an app pentester should be spending their time. A basic polyglot that we all know and love is to assume the string is being output unescaped within an element attribute or textarea, and simply attempts to break out of those:


We’ve included other examples for different situations as well, such as within an svg element onload event or, my personal favourite – 0xsobky’s XSS polyglot, which is included in Daniel Miessler’s excellent SecLists repository. If the application can take the input that lengthy and it’s at all vulnerable to XSS, then there’s a good chance this payload will find it.


Add these all together and we end up with something pretty complex looking, which might have taken a bit of time to create manually:

C:\Users\coakley\Desktop\download (3).png

The final payload

If that didn’t work then you can simply tweak some of the options and the XSS payload will be regenerated automatically for you.

If you’ve used one of these payloads in a new and interesting way or you’ve thought of a new payload, obfuscation or injection option to add to the configuration, let me know – I’m @strawp on Twitter. Enjoy!

Introducing ‘XSS Payloads’ repository: Cross Site Scripting doesn’t have to be boring

Sometimes, particularly when dealing with a system perimeter, there’s very little attack surface to deal with.  You may find yourself with not much more than boring old XSS to poke at.  We feel your pain.  The good news is that it isn’t all doom and gloom. Read more