Wiris Desktop 2: Flaws implementing the key validation procedure

The issue

Wiris Desktop 2 is a powerful multiplatform mathematical software written purely in Java. It is widely used in online universities like UOC, UNIR and so on. It is also used on high schools and it has an online version for e-learning platforms such as Moodle and the like. In order to use the software, one needs a valid license. During the program download, you receive a valid 60-days trial license in your email address. This license must be type in the right text-box area inside the application, once it is executed for the first time and then it is validated against the www.wiris.com server. As this post will demonstrate, this whole procedure has flaws.

Toying with the validation procedure

Once a license key is typed in and the OK button pressed, the software tries to validate this license by sending a request to www.wiris.com, processing its response and acting accordingly. This rapidly suggests using an intercepting proxy, like Burp Suite.

First we need to ensure that any call from Wiris to the webserver at www.wiris.com will be redirected through our intercepting proxy. Because Burp is not a socks4 or socks5 proxy, we cannot make use of proxychains. We need to redirect the calls the old way.

First, we have to cheat the name resolution system so that any http request to www.wiris.com goes to our intercepting proxy. Easy as pie: we edit the /etc/hosts file and add this line (supposing that our intercepting proxy will be listening on the loopback interface): www.wiris.com

Once this is done, the next step is to set up our intercepting proxy accordingly. We open the proxy tab options inside Burp and we edit the default proxy listener so that any request will be redirected to the real web server at www.wiris.com. We need to make sure that the option “support invisible proxying” is also enabled. This is shown in the screenshot below (where is the address for www.wiris.com):

Setting up our intercepting proxy to catch the validation license key procedure

Setting up our intercepting proxy to catch the validation license key procedure

Inspecting the key-validation procedure inside Burp

We can type in any invalid license-key we want and then push the OK button. Burp will immediately catch any request and response to and from www.wiris.com. Surprisingly enough, the requests and responses are text-clear: Wiris Desktop does not even uses https (first flaw)! This will facilitate our PoC. The next screenshot shows the two requests sent by Wiris Desktop (a GET and a POST):


The two requests made by Wiris Desktop: a GET followed by a POST during the key-validation procedure against www.wiris.com

Burp can show us the entire contents for the two requests and their respective responses from the server. As shown in the previous screenshot, two obvious things stand out:

  1. Wiris Desktop sends and receives XML data.
  2. The requests are made to www.wiris.com/management-services/DesktopValidateBean?wsdl

Now, the interesting thing here is to observe what sort of response we have from the server whenever the key is not valid at all. We can do this by inspecting the entire XML response from the POST request using Burp:

The response from the server whenever the license key is not valid.

The response from the server whenever the license key is not valid.

The client’s request sending the license-key to be checked is shown below; it is clearly shown the license-key to be tested among other relevant data such as the Wiris Desktop version, the architecture and the operating system where it is running, and so on:

The client’s request sent to the server to validate the license-key.

Therefore, we do know now that whenever the server evaluates the license-key and considers it as not valid, it returns a -1 in the result XML entity to the client. Then, Wiris Desktop shows the “invalid key” error message. Now, on the Internet there is a certain hypothetical non expiring license-key that is not valid anymore. I am not encouraging piracy, so if you are really interested in this license key, surf the web by yourself.

If we try to use this license key, we got a -1 response from the server. Why? It would seem feasible that the staff at www.wiris.com had decided at some point to invalidate this license key in order to prevent new users from using it without paying for a non expiring one. Makes sense, so whenever sending this license-key to www.wiris.com, the server rejects it with a -1. So apparently, we cannot use this license key anymore…right?


The flaw: requesting a new product key

Whenever looking for flaws on a program, we need to test every single functionality and observe its behaviour whenever unexpected parameters are present. Let’s assume we are testing what happens when a valid license key is checked against the web server at www.wiris.com. To do so, we can use a valid 60-days license demo available after downloading the Wiris Desktop 2 product on the website:

The server's response whenever the tested license key is valid.

The server’s response whenever the tested license key is valid.

Okay; it is something quite expected: instead of a -1, we’ve got a 0 this time. Now, we try to change the product key using the “New Product Key” option menu but typing in the same valid license key once again and pressing the “OK” button. This time we are interested both in the request sent by the client with the license-key to test and the server’s response. First, we capture the client’s request and we observe additional parameters passed to the server in the XML data:

Whenever sending the same key to the server, additional parameters are passed.

Whenever sending the same key to the server, additional parameters are passed.

So, the “change” and “revalidate” parameters are now passed to the server. The server returns a valid license-key XML response, even when the original license key has not changed at all. So, the obvious question arises now: what if I send another old valid license key during this revalidation procedure? Instead of asking the server to re-validate a still valid license, we cheat it by sending an old invalidated one. In order for this PoC to work, we need to ensure that the “Intercept ON” is enabled in Burp Proxy. Then, we will have the POST client’s request intercepted and ready to be altered on the fly before sending the data to the web server.

We will type in one of these old invalid license-keys that can be found on the Internet using the “New Product Key” functionality inside Wiris Desktop, and then intercept the POST request to the server within Burp. Once we have the original client’s POST, we are going to edit it in order to add these two additional parameters as shown in the previous screenshot:


Finally, we will forward the client’s request.

This time, the server returns a 0, confirming that this license key is valid, even when the original request was clearly rejected. Now, our Wiris Desktop is ready to use with a non-expiring apparently rejected license, as shown below:

The license-key has been validated by cheating the entire procedure and adding these two additional parameters.

The license-key has been validated by cheating the entire procedure and adding these two additional parameters.

Therefore, it is quite feasible to be still using old license keys even when the license server at www.wiris.com has marked them as non valid ones, according to this PoC.

Another flaw

Of course, all the previous steps were made in order to demonstrate all the flaws the entire key-validation process does have, and to show a real-world example of the Burp Proxy Suite in action. However, there is at least another flaw that can simplify things a lot. The license key, once it has been validated, it is stored text-clear in a file inside the user’s home directory. This file holds the license key as it is, with no encryption or obfuscation at all. The file, in a GNU/Linux operating system, is stored in:


If we edit this file, we can just change the license key directly with any sort of ASCII editor and type in any old license key without even having to go all the way through the key-validation procedure described in this post. And it will work!

The contents of this file is shown below. As you can see, it is extremely easy to write any old unvalidated license-key and then execute Wiris Desktop. The server at www.wiris.com won’t be involved at all. In bold there is the 60-days license-key demo:

<?xml version=”1.0″ encoding=”UTF-8″?><!DOCTYPE map SYSTEM “http://java.sun.com/dtd/pre ferences.dtd”>
<map MAP_XML_VERSION=”1.0″><entry key=”ProductKey” value=”2YVQAVY756ZABYC24C4NTQBUP“/>< entry key=”WebValidation” value=”0″/></map>


Despite being an interesting and powerful tool for learning mathematics, it is shocking how easy is to defeat its key-validation mechanisms. And if we have a look at the prices for a single user valid license, one would suppose only fair that the developers would have taken into account some issues concerning security and software flaws. And yet, this is not so. To conclude, this post has not been publicly available until getting the conformity from the Wiris Desktop staff, after these issues were solved.

The Burp version used during this PoC is the free edition, available on their webpage here.