BMC makes a number of mainframe-focused applications, one of which is Control-D. Control-D is a “Report Distribution system for distributed and mainframe platforms”. This blog post describes an authentication bypass vulnerability that was found, allowing access to restricted reports.

To make mainframe-based reports accessible outside the mainframe, and to avoid having to create mainframe accounts for every report consumer, BMC provides a web application, making the reports available via a browser.

There are two ways of authenticating the users who are interacting with the web application, either IIS-based integrated authentication, or by presenting an HTML form, and passing the credentials through to the mainframe. This post documents a vulnerability discovered in the way that integrated authentication is managed by Control-D. I strongly suspect that using this same technique, it would be possible to provide the username, and bypass the forms-based authentication mechanism as well. 

Once the Control-D web application is installed, the setup is as follows:

• IIS is configured to authenticate the user before access to the application is permitted, using either Basic or Integrated (NTLM/Kerberos) Authentication.
• The authenticated user name is passed to a CGI application (bmc-ctd-wa-cgi.exe) by means of environment variables. This is standard CGI protocol.
• The CGI application establishes a TCP connection to a service running on the same server on port 7777, and makes requests for various reports that are available to the user.
• The service relays the request on to the mainframe, which responds accordingly.
• The response is eventually translated by the CGI into an HTML page that is returned to the user.

Some of you will already have spotted the vulnerability: What happens if I can connect directly to the service listening on port 7777? Naturally, I portscanned the server, and was delighted to find port 7777 accessible! Now all I need to do is speak the protocol that the CGI uses, and provide the desired userid, to obtain their reports!

While simple in concept, in practice it was not so easy! Socat to TCP/7777 revealed a binary protocol, that is, when I could even get it to respond to me at all! How to figure out what this protocol actually looked like?

Fortunately, I had the name of the CGI that I was interacting with (bmc-ctd-wa-cgi.exe), so, Google to the rescue! Well, 3 hits in total later, and I had no more information about what was really going on! :-(

However, more poking around the BMC website revealed the existence of an FTP site (ftp://ftp.bmc.com/) that contained patches for various versions of the Control-D reporting software. Pillaging the FTP server for all it had, resulted in a number of packages for Windows, HP/UX, Solaris, etc. But not every package had the CGI that I was looking for! One bash snippet later, and I had extracted every package into its own directory, and could run find on the results. Note: It appears that BMC have removed all the files from this FTP server since the discovery of this vulnerability.

The fun part about CGI-based web applications is that you can actually just run them from the command line, if you set your environment variables appropriately. By default, it wants to speak to its server on localhost:7777. So I ran a socat server, piping the output to hexdump, so I could see what the protocol looked like, and so I could try to figure out how to tweak it, and particularly, how to provide my chosen username.

After much gnashing of teeth, and frustration as all the environment variables I attempted resulted in no changes to the data sent to port 7777, I finally realised by running ‘strings’ on the CGI binary that the version of the CGI I had chosen had no support for IIS authentication at all!

Back to my trove of downloads to find one that did!

Eventually finding a file with the right name that contained the string ‘REMOTE_USER’, I was back in the game, trying to decipher the protocol. I wasted way too much time on this, until I realised I could simply wrap the CGI in a batch file that would set the desired environment variable, then invoke the original CGI, and access the whole thing through my own web server!

@echo off
SET REMOTE_USER=<insert user here>
bmc-ctd-wa-cgi.exe

A quick change to the local socat listener to forward connections to the real server on port 7777, and I was in business!

Having done so, I quickly obtained access to the reports available to my victim, and called it a day!

Amusingly, Google actually shows that there are a couple of Control-D report servers accessible from the Internet! None of them expose port 7777, though! Internal networks may be a different story, of course!

https://www.google.com/search?q=inurl%3Abmc-ctd-wa

This vulnerability was discovered in version 3.1.04 of Control-D, but it is present in all versions up to 9.0.18.

Vendor response:

This vulnerability was fixed in Control-D/WebAccess Server release 9.0.19 and patches for supported releases:
9.0.00 - DRNBO.9.0.00.021
9.0.18 - DRNBO.9.0.18.008

All supported platforms were fixed (Windows, Linux X64, AIX, Oracle Solaris).

CTM-1436 (https://docs.bmc.com/docs/cdwas9/corrected-problems-in-control-d-webaccess-server-847215379.html) captures the fix.

Timeline:
Reported to BMC: 22 October 2018.
Acknowledgement of receipt from BMC: 22 October 2018.
Confirmation of vulnerability from BMC: 26 December 2018.
Fix implemented by BMC: 21 Jan 2019.
Information that patches are available from BMC: 24 June 2019.