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?

Hacking the Oce Colorwave printer: when a quick security assessment determines the success of a Red Team exercise.

Back in September 2019, as Red Timmy Security group, we have been involved in a Red Team exercise. We had to simulate the scenario of a malicious insider plugging a Raspberry Pi device in to the network to potentially use as a C&C, and to check how much time the guys monitoring the environment would have spent to detect it. Furthermore, the place where to hide our device had to be tricky enough to spot, with the aim to pour a pinch of extra pepper on the challenge against the blue team.

Consequently, we did not want simply to drop the device at the first location available, raising suspicions on other employees who were unaware of our real role and increasing the risk to be caught. Therefore the initial couple of days following the job engagement we behaved normally: we have been assigned a company laptop, a badge and completed all the on-boarding tasks, which are typical of when somebody is hired for real. Oh well, almost. The second day, after opening the browser of our new shining company laptop, we mistakenly typed in the number “1” in the URL bar, and discovered that some IP addresses were already visited in the chronology.

We selected the first URL in the list (a local IP address) and visited that. It was the web interface of the Océ Colorwave 500 printer, a big boy weighting more than 250 kilograms (see picture below).

Why should not we give a quick look at it? I guess you know how it went. We did a mini assessment of the printer that lasted a couple of hours. That was enough to discover five different flaws. However, for the matter of this story, only one was relevant. We provide the details of the rest at the end of this post.

Basically we discovered that the Oce Colorwave 500 printer was vulnerable to an authentication bypass bug on the page “http://<printer-IP>/home.jsp”. When that page is browsed by an anonymous (unauthenticated) user clicking on the “View All” button with the intention to visualize the current job queue, the application returns a login panel asking for administrative credentials.

However it was sufficient to append the parameter “openSI=[SI]” to the “home.jsp” page (with “[SI]” being the name of a network user) to view the printer inbox of that user and all the relative print jobs, so completely skipping the authentication process.

Currently the name of the network user we wanted to spy the inbox of was nothing more than its Windows active directory username. The convention used internally by the target company was easy enough to understand (a combination of the user first name and surname, and of course AD was “publicly queryable”), that was really a joke to script an automated process collecting all the printed documents from the device’s queue for subsequent manual analysis.

We did not need to poll the device frequently, just once per user, as the queue of the printed jobs was configured (a default setting of the printer we guess) so to be shred only every 2 weeks. This would have given us enough time to download everything submitted to the printer by anyone in the company that had used it in the last 14 days. After finishing the task, we started to manually analyze all the documents collected. A tedious but rewarding task at the end!

We were indeed lucky enough to find the blueprints/security plants of the customer building, including the space hosting us. At the beginning everything was quite tough to read as the blueprints were full of meaningless labels and symbols. But in the middle of the set of documents exfiltrated from the printer spool was also found a legend with the description of each symbol. Something similar to this:

After taking confidence with it, we knew the exact dislocation of desks, security cameras, conference rooms, security equipment including card readers, local alarms / sounders, electromagnetic locks, intercoms, patch panels, network cables, etc… in the building!

It was the turning point of our exercise. The place we found for our Raspberry Pi device and what happened later is another story.

Most importantly, soon after the closure of the red team operation, the e-shredding functionality has been activated and applied for all print-jobs and the device immediately isolated from the network, put behind a firewall in a separate VLAN.

We have contacted the vendor of course and communicated our findings. After few days the vendor has replied informing us of the existence of a newer firmware version compared to the one running on the printer tested by us (that was As no CVEs have been registered for these bugs in the past, we have decided to do that.

In total we have registered five CVE(s). All these bugs (two Reflected XSS, one Stored XSS and a systemic CSRF), including the authentication bypass already described (CVE-2020-10669), have been discovered by Giuseppe Calì with the contribute of Marco Ortisi. Below you can find the additional details for each of them.


The web application exposed by the Canon Oce Colorwave 500 printer (firmware version and possibly below) is vulnerable to Stored XSS in “/TemplateManager/indexExternalLocation.jsp”. The vulnerable parameter is “map(template_name)”.

An external location is first created by browsing the URL “http://<printer-IP>/TemplateManager/editTemplate.jsp?type=ExternalLocation”. Here the “Name” parameter (actually the “map(template_name)” parameter in the POST request generated after clicking the “Ok” button) is injected with the following sample JavaScript payload:


After creating the external location template, any attempts to edit it will trigger the sample payload.


The web application exposed by the Canon Oce Colorwave 500 printer (firmware version and possibly below) is vulnerable to Reflected XSS in “/home.jsp”. The vulnerable parameter is “openSI”. Browsing the URL:


an alert box will pop-up in the page, showing that the attacker’s payload has been executed in the context of the user’s browser session.


The web application exposed by the Oce Colorwave 500 printer (firmware version and possibly below) is vulnerable to Reflected Cross-Site Scripting in “/SettingsEditor/settingDialogContent.jsp. The vulnerable parameter is “settingId”. Browsing the URL:

http://<printer-IP>/SettingsEditor/settingDialogContent.jsp?settingId=<img src=x onerror=”alert(document.domain);”/>

An alert box will pop-up in the page, showing that the attacker’s payload has been executed in the context of the user’s browser session.


The web application of the Canon Oce Colorwave 500 printer (firmware version and possibly below) is missing any form of CSRF protections. This is a system-wide issue. An attacker could perform administrative actions by targeting a logged-in administrative user.

That’all for today. As usual we remind you that we will be at Blackhat Las Vegas with our Practical Web Application Hacking Advanced Course on 1-2 August and 3-4 August 2020.