BMC BladeLogic: CVE-2016-1542 and CVE-2016-1543

Hi everyone,

Hope those of you who attended Troopers16 enjoyed it as much as we did! In this post I want to summarize my Troopers16 talk and provide you with some details about freshly assigned CVE-2016-1542 and CVE-2016-1543 related to BMC BladeLogic software.

To start with, BMC Software Inc. is an American company specializing in business service management software; they develop software used for multiple functions, including IT service management, data center automation, performance management, virtualization lifecycle management and cloud computing management. Among other products they have developed a BladeLogic suite that includes Database Automation, Middleware Automation, Server Automation, and Network Automation tools. The one under our focus was BladeLogic Server Automation (BSA).

BSA is used to automate administering servers in complex environments containing big amount of different machines. So an administrator would need to interact only with a BSA console, instead of managing directly each of the servers. The architecture of such a solution consists of several components:

• Control Server running BSA Console
• Application Server
• Database Server
• File Server
• Target Servers

These components are communicating using TLS 1.0.

First of all an administrator would need to log into the BSA Console with his credentials. The Control Server after that establishes connection to the Application Server, which now will handle all the communication with the target environment. In order to be able to interact with it, any target server is running a special daemon called RSCD agent. In fact, each BSA component is running the same agent, so one Application Server could be managed by another one.

RSCD keeps listening for incoming connections on the default port 4750 (it can be configured to listen on another port as well). The agent has several configuration files which determine its behavior, define mapping to the system users and state who is allowed to talk to it (IP-based).

As we see, RSCD agent seems to be the one who glues everything in this environment together, and so is definitely worth of some investigation. We had a Linux version of RSCD under our test, and we tried to observe its communication with an Application Server. First we used Wireshark, and what we noticed was an interesting nature of connection establishment: as mentioned before, the components are interacting over an encrypted tunnel, but they do not start from establishing it. Instead first comes a TCP packet with a payload, and this payload is always “TLS” or “TLSRPC”. After this packet the TLS handshake is started.

To find out what actually is happening there, we have attached a debugger to our running RSCD process and identified two functions responsible for agent’s interaction with SSL tunnel – defining what it reads from there, and what it writes in response. Then we have attached a pintool to dump the exact communication of these two functions (the Pin framework allows you to insert your arbitrary code in a running process). An interesting thing has revealed: depending on the payload of the initial packet (“TLS” or “TLSRPC”), an application switches between two protocols, one of which is a proprietary binary one, and the second one is XMLRPC. Using XMLRPC, the agent implements a web server functionality – it handles HTTP POST requests with XML body containing the commands from Application Server. You can see parts of this communication on the following screenshots from the debugger.

Now, after we observed the communication, we know how the Application Server (AS in the following) and RSCD are interacting, and it is happening in the following way:
1. AS sends an initial TLS/TLSRPC packet and switches to SSL
2. AS sends a “Server intro” packet; it contains role:username pair
3. RSCD checks this data (and AS’s IP) against its secure files
4. If authorized, RSCD forks a child process with corresponding privileges (“mapped” to the corresponding system user) which will from now on handle the further communication
5. AS sends the request with concrete actions to be performed on the target server.

Looking at those “Server intro” requests we noticed that the password for corresponding username is not sent and not used in any way by RSCD – and since it’s lost on the way from administrator to the end server, we perhaps could try to bypass the athentication… We know how to talk to RSCD so why not to pretend to be an Application Server itself?

Well, you may say, we still need to have valid IP, role and username. We tried with invalid ones and (as expected!) got back “No authorization”. Normal Application Server stops here, but we just tried to push a little bit further by simply continuing sending the requests. Our “action packet” was the one for changing passwords of system users, and we went for root user in this case. RSCD has sent back “errorCode 0” which prompted us to check the actual root password on our testing server – and voilà! Surprisingly it has changed 😉

So what happened here? It seems that RSCD just doesn not stop even if the “Server intro” data is not meeting the requirements, you just need to keep on knocking in its door 😉
Now we were able to change password of any system user (while staying unauthorized), but the only user that for sure is present is root, which is not always that useful, because root might be not permitted for ssh access. We digged a little further and found out that RSCD has a functionality to retrieve all the users on the system – exactly what we need, and it worked in a similar way. Now with our two scripts on hands we could walk around our BMC environment changing credentials as we like on any Linux machine running RSCD agent.

We have contacted BMC and triggered the responsible disclosure process, which in this case was fast and productive! In quite a short time they have developed the patch (it worked on our environment) and released the Knowledge Article. Ariel Kirson, the Director of Application Security in BMC was so kind to come to Troopers and attend the public disclosure talk.

And lastly, you can find the slides here!

Thanks and see you,
Olga