This vulnerability was discovered in version 3.1.04 of Control-D, but it is present in all versions up to 9.0.18. Having done so, I quickly obtained access to the reports available to my victim, and called it a day!Īmusingly, 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! 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! offĪ quick change to the local socat listener to forward connections to the real server on port 7777, and I was in business!
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.Īfter 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!īack to my trove of downloads to find one that did!Įventually finding a file with the right name that contained the string ‘REMOTE_USER’, I was back in the game, trying to decipher the protocol. By default, it wants to speak to its server on localhost:7777. 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.
Note: It appears that BMC have removed all the files from this FTP server since the discovery of this vulnerability. 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. Pillaging the FTP server for all it had, resulted in a number of packages for Windows, HP/UX, Solaris, etc. However, more poking around the BMC website revealed the existence of an FTP site ( ) that contained patches for various versions of the Control-D reporting software. 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?įortunately, 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! ? 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! The response is eventually translated by the CGI into an HTML page that is returned to the user.The service relays the request on to the mainframe, which responds accordingly.
This post documents a vulnerability discovered in the way that integrated authentication is managed by Control-D. 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. 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. This blog post describes an authentication bypass vulnerability that was found, allowing access to restricted reports. Control-D is a “Report Distribution system for distributed and mainframe platforms”.
BMC makes a number of mainframe-focused applications, one of which is Control-D.