Another SSRF, Another RCE – The Microstrategy case

If you are passionate about music and especially historical rock bands, the post’s title could have rung a bell on you. It is indeed the parody of the famous song “Another Girl, Another Planet“. It may be that you know it because of the Blink 182 cover song more than for the original piece sung by “The Only Ones” band. Anyway, the focal point of the title is that, regardless the pun, there are so many documented cases out there where a SSRF bug has led straight to execution of remote code that should not come as a surprise if today we are going to add another one over the table.


What reported here is the output of a web application penetration test we quickly conducted early last autumn on Microstrategy Intelligence Server & Web, that brought us to discover six different vulnerabilities and recently to register a total of five CVE(s). Until now these vulnerabilities have been unknown to the public.

Microstrategy Intelligence Server & Web

MicroStrategy Intelligence Server (also dubbed iserver) is an analytical server optimized for enterprise querying, reporting, and OLAP analysis. A front-end component, called MicroStrategy Web, connects to iserver and provides users with an interface for reporting and analysis.

The application includes a functionality allowing users to import files or data from external resources such as URLs or databases. Of particular interest is the “File From URL” option. This sounds like a feature that would be typically vulnerable to SSRF (Server Side Request Forgery). Let’s check it.

We first create the file “pwned.txt” with random content and host it somewhere over the internet:

$ cat pwned.txt
You are Pwn3d!

Now, what if an external URL under the attacker’s control referencing that file (for example “http://attacker_ip:8080/pwned.txt”) is typed into the “Upload your files” textbox as shown below?

What happens with Microstrategy 10.4 (and potentially above) is that the application downloads the file’s content from the attacker-controlled machine…

…then parses and prints it into the dashboard area.

Ehi, but wait! If we carefully take a look at the first screenshot coming with this blog post, a label over the “File From URL” option is explicitly stating that the usage of “file://” scheme is allowed too. How would the application react if we provided the string “file:///etc/passwd” instead of a URL? The picture below clearly answers this question.

Well we have officially a SSRF (registered as CVE-2020-11452) that an attacker can take profit of to retrieve arbitrary files from the local system where the Microstrategy solution is installed. This is great: we can get the content of files whose path is well-known (for example OS configuration files) or proceeding by trial and error approach if unknown. However, it would be even better if we could at least identity the full path of the application server (or servlet container) where the application is hosted and continue the analysis from that angle.

Here is where a second vulnerability comes in. Browsing to the URL “/MicroStrategyWS/happyaxis.jsp”, as an unauthenticated user, we can obtain some basic information such as the JVM version in use, the CPU architecture and the installation folder of the application server or servlet container (tomcat in our case).

With RedTimmy Security we have registered this information disclosure bug as well and MITRE assigned to it the CVE-2020-11450.

Needless to say, once the base configuration folder of Tomcat is known, more paths and information about the deployed applications can be obtained from “server.xml”, “web.xml”, tomcat log files, etc… So it should not come as a surprise if after obtaining these resources through the SSRF and carefully analyzed them, we ended up to exfiltrate private keys and passwords, sometimes obfuscated, sometimes in clear-text (by the way, how to de-obfuscate passwords in Tomcat is a good story for another blog post).

By analyzing the tomcat configuration files, we also learnt that Microstrategy comes with an administration console reachable from “https://hostname/MicroStrategy/servlet/admin”. Eventually one of the passwords previously retrieved has worked against the admin panel, which has open us the door to the exploitation of the most boring RCE vulnerability ever.


Once logged into the Microstrategy admin panel, the “Upload Visualization”plugin accessible from the “Custom Visualizations” link (see image above), allows a global administrator to upload a zip archive containing files with arbitrary extensions and data.

Why don’t we upload a zip archive containing a malicious JSP web shell? We have used for the purpose something similar to this and renamed it as “admin.jsp”. The bottom line is that regardless what is put inside the zip archive, these file(s) are then extracted to the publicly accessible URL “/MicroStrategy/plugins/<FILENAME>”.

All we need to do now is just pointing the browser to the resource “https://hostname/MicroStrategy/plugins/admin.jsp” to invoke the web shell and execute arbitrary OS commands with the privileges of the Tomcat user.

Other CVE(s).

During our assessment we have discovered more bugs.

CVE-2020-11453 is another Server-Side Request Forgery in the “Test Web Service” functionality exposed through the path “/MicroStrategyWS/”. The functionality requires no authentication and, while it is not possible to pass arbitrary schemes in the SSRF request, it could still be possible to exploit it in order to conduct port scanning.

Specifically the attacker browses the URL “https://hostname/MicroStrategyWS/” and passes an arbitrary IP address/hostname and port number into the “Intelligence Server” and “Port Number” textboxes.

CVE-2020-11454 is instead a Stored Cross-Site Scripting vulnerability affecting the “HTML Container” and “Insert Text” functionalities in the window allowing for the creation of a new dashboard. The application allows to insert new text lines inside a created dashboard or opening a ready one. Basically it is possible to change its type from “iframe” to “HTML Text” right-clicking on it and selecting “Properties and Formatting”.

The HTML code injected will be evaluated every time the dashboard is loaded.

That’s all for today. If you want to learn more in-depth webapp hacking techniques, remember to join us at Blackhat Las Vegas this year with our Practical Web Application Hacking Advanced Course on 1-2 August and 3-4 August! We look forward to see you there!

Also, why don’t you follow us on twitter?

JMX RMI – Multiple Applications (RCE)

After achieving a foothold inside the targeted organization, an attacker surely will search for vulnerabilities giving him/her the ability to compromise other machines and move laterally into the network. Especially for companies adopting Java-based software solutions, one of the most abused services to achieve Remote Command Execution is JMX/RMI. It has revealed to be very pervasive in the business LAN/DMZ contexts. Indeed around one year ago we performed a random analysis of both open source and business tools, checking for the presence of JMX/RMI ports. We ended up discovering (and sometimes directly reporting) some new vulnerabilities. Few CVE(s) were registered as well. This whitepaper includes main highlights of our findings.


JMX (Java Management Extension) is a documental specification for remote management and monitoring of Java applications. Its main unit is the MBean (management bean), a java object exposing some attributes that can be read/written through the network, and most importantly a series of functions or operations invokable from remote. A so-called “MBeanServer” (or more simply JMX Server) keeps track of all registered MBeans inside a kind of searchable register/archive. It is the component puts in charge of managing the communication between clients that want access to one or more exposed functions/attributes of an MBean and the MBean itself.

JMX was not built with the security principle in mind. Therefore, whoever is able to reach the network port it is listening to can also invoke the exposed methods anonymously, without going through a formal authentication process.


The RMI (Remote Method Invocation) protocol is the most common mechanism (as well as the only one that the JMX standard expressly requires to be supported by default) through which the methods and functions the MBeans remotely expose (made available by means of JMX server) are invoked by clients.


By default no authentication is enabled for JMX/RMI. Furthermore the authentication, when rarely adopted, is only restricted to a couple of options:

  • File-based: insecure as passwords are left in clear-text in the filesystem (also transmitted in clear-text over the network);
  • TLS mutual authentication: difficult to set up and maintain with the growth of the numbers of clients and nodes, as it requires the generation of digital keys and certificates for each of them.

The Oracle Java documentation is self-explanatory when it comes to determine where the problem stems from: (

Caution – […] any remote user who knows (or guesses) your port number and host name will be able to monitor and control your Java applications and platform. Furthermore, possible harm is not limited to the operations you define in your MBeans. A remote client could create a “” MBean and use it to create new MBeans from arbitrary URLs, at least if there is no security manager. In other words, a rogue remote client could make your Java application execute arbitrary code”.


Below follows the list of components and software solutions that we found affected by this specific issue during an analysis conducted in the period February-March 2018.


Cisco Unified CVP is an intelligent IVR (Interactive Voice Response) and call control solution. In its default configuration, until version <= 11.x and potentially above, an unauthenticated JMX/RMI interface is bound to a wildcard address on TCP ports 2098 and 2099. An attacker establishing a network connection to one of these affected ports and sending the malicious payload could easily trigger the RCE.

The vulnerability was first discovered on February 2018. The vendor was made aware almost immediately. After multiple meetings and discussions occurred between April and July 2018, Cisco agreed to document two new security procedures in to its CVP configuration guide:

  • Secure JMX Communication between CVP Components
  • Secure JMX Communication between OAMP and Call Server using Mutual Authentication.

We reopen the dialogue with Cisco on February 2019 when a CVE has been asked but not assigned, as the vendor considers the flaw as a configuration issue.

Anyway Cisco has published a security bulletin for the flaw we reported at the URL


This is a commercial GRC (Governance, Risk and Compliance Management) solution for risk handling and management. Branch 5.x of Nasdaq BWise is vulnerable because by default the SAP BO Component enables JMX/RMI on TCP port 81 without authentication.

We discovered the vulnerability and contacted the vendor on March 2018. After discussing with them, the release of Service Pack (SP02) has been announced to solve the problem.

A CVE number has not been requested until February 2019, when we realized that in the meantime another security researcher had registered CVE-2018-11247 for the same issue. As indicated in their published security bulletin, the researcher had discovered the vulnerability 2 months after us (May 2018).

However as a CVE already existed, we did not requested a new one.


NICE Engage is an interaction recording platform. Versions <= 6.5 (and potentially above) open up the TCP port 6338 where a JMX/RMI service listens to without authentication. Of course this may be abused to launch remote commands by deploying a malicious MBean.

On March 4th 2018 we contacted the vendor and on 7th same month they have recognized the vulnerability. They also declared that no specific fix would have been released because enabling the JMX file-based authentication was considered enough to mitigate the finding. Anyway, this change is not reflected in the default configuration and must be applied manually, leaving at risk the companies using the product and are not aware of the problem. Only very recently, February 2019, we have registered CVE-2019-7727 for this vulnerability


On February 2018 we discovered that the Apache Software Foundation project dubbed Cassandra (release between 3.8 and 3.11) exposed the TCP port 7199 on which JMX/RMI was running. We did not report the finding immediately. Soon after someone else did it and registered CVE-2018-8016. All details are perfectly explain here:

During a contextual security investigation on March 2018 we also managed to spot multiple instances of Cloudera Zookeeper/CDH (versions 5.x and 6.x) affected. In this case the TCP port 9010 was exposing a JMX/RMI service. The vendor is aware of the problem at least since June 2018. In one of their release notes they wrote:

A successful attack may leak data, cause denial of service, or even allow arbitrary code execution on the Java process that exposes a JMX port. Beginning in Cloudera Manager 6.1.0, it is possible to configure mutual TLS authentication on ZooKeeper’s JMX port”.

The possibility to configure mutual TLS authentication for previous product versions is unknown instead. We did not register a CVE for this vulnerability.


Working tools to exploit JMX/RMI vulnerabilities exist out there. Some good examples are sjet and mjet. When we have started our first investigations in this field did not manage to find one fitting all requirements (we have had problems to target specific contexts and configurations) and have decided to develop our own. This tool is not going to be publicly shared for now. It probably will in future, so visit our blog (

Moreover, if you want to know more about JMX/RMI exploitation and mitigation, check out our Blackhat Las Vegas courses on 3-4 and 5-6 August 2019, because this will be one of the topics covered there.

Stay tuned!

FlexPaper <= 2.3.6 RCE

Around one year ago we discovered a Remote Command Execution vulnerability on FlexPaper ( The vendor was immediately contacted and a CVE registered (2018-11686). However the vulnerability itself has remained undisclosed until now, regardless the fact that a patch has been issued with the release 2.3.7 of the project.

What is Flexpaper

FlexPaper is an open source project, released under GPL license, quite widespread over the internet.  It provides document viewing functionalities to web clients, mobile and tablet devices. At least until 2014 the component has been actively used by WikiLeaks, when it was discovered to be affected by a XSS vulnerability subsequently patched. The remote command execution vulnerability hereby descripted has remained 0day until being reported to vendor in April 2018.


The “php/setup.php” script is used to initialize the Flexpaper configuration file in the “config/” folder. The function “pdf2swfEnabled()” passes the user input unsafely to “exec()” that leads straight to arbitrary command execution.

However, this entry point can be only reached in case Flexpaper has not been initialized (i.e. there is no configuration file in the “config/” folder) which is the main reason to have the software downloaded and installed.

Therefore, after the configuration process is completed, the “exec()” function cannot be hit with arbitrary user input.

File removal via change_config.php

FlexPaper <= 2.3.6 also suffers from an unrestricted file overwrite vulnerability in “php/change_config.php“. The component exposes a functionality to update the configuration file. However, access to this file is improperly guarded, as can be seen in the code snippet below

The “SAVE_CONFIG” is done before the “FLEXPAPER_AUTH” authorization check is performed. Therefore, a not authenticated user can send a POST request and have the configuration file updated. Even more interesting is the fact that after the configuration file is updated, the script will remove all files in the directory that is configured under “path.swf”. As this path was just updated by the attacker, he is in full control of the directory in which he wants to delete files. 

An example of a HTTP request, which results in deletion of the configuration file, is depicted below.

Back to Setup.php

Once the Flexpaper configuration file is deleted, the vulnerable entry point at “setup.php” becomes reachable again. Now the attacker is one GET request far from triggering RCE. The malicious payload is provided to the “PDF2SWF_PATH” parameter. The command is injected just prepending a semicolon “;” character as shown below

In the example above the server was forced to base64 decode a PHP web shell (see following image) and write that in to a file named “tiger_shell.php” in the webserver’s document root.

The web shell

The web shell adopted in this case takes as an input a key and an arbitrary base64 encoded command submitted via GET request. It base64 decode and execute the command only if the key matches with the hardcoded one. From now on, the attacker can launch any arbitrary command like this:

The command injected through “cmd” parameter, for this specific example, is the base64 encoded representation of “id;uname -a;pwd”. Needless to say it can be whatever command the attacker wants to run.

Red Timmy Sec will be at Blackhat Las Vegas this year! Check out our trainings

Some additional notes

During last year we have reported this vulnerability to several broadcasting and media companies that were using the affected component. Some government websites as well.

Exploit code

The exploit has been published here.