Inadequate Patch in Hewlett Packard Enterprise iMC 7.3 E0703

Published in

Tenable TechBlog

5 min readOct 1, 2019

Background

On March 20, 2019, we released a research advisory detailing two vulnerabilities in HPE iMC 7.3 E0605P06 that could reward a remote, unauthenticated attacker with admin access. We first reported the bugs to HPE on December 14, 2018. In response, HPE posted a security bulletin on May 9, 2019 to address these (and more) vulnerabilities, and the E0703 release notes claim to have fixed them.

However, we have found that the patch in E0703 does not address the root cause of the vulnerabilities. We reported this to HPE as well, and 90 days have passed since then (see TRA-2019-42). HPE has not issued a patch in response. This means there are (at least) two unpatched, known vulnerabilities in iMC with a CVSSv2 base score of 10.0. Basically, these bugs have been lurking around without proper patches since December 2018.

The Vulns

We initially reported a command injection and a stack-based buffer overflow. Both are triggered by first sending a HostRoleSwitch request (command code 10018) to write configuration values into dbman.conf, and then a subsequent request is sent to cause dbman.exe to reload the configuration file. As I mentioned in a previous blog post, ASN.1 is used for the custom dbman protocol.

If you decompile the Deployment Monitoring Agent (deploy.jar), you can see the makeup of a HostRoleSwitch request. In fact, the related class is called “AsnDbmanHostRoleSwitchReq”:

public class AsnDbmanHostRoleSwitchReq implements ASN1Type {
    [...snip…]
    public BigInteger iSwitch;
    public BigInteger iBackUpTime;
    public byte[] ipAddr;
    [...snip…]
}

After a valid request is received, the dbman.conf file will contain values similar to these (note that the names differ from the above):

BackHoseIp = 127.0.0.1
PrimaryHost = 1
BackupTime = 17
BackupTimeMinute = 30

BackHoseIp is filled with the value of ipAddr. This value is a string, and we all know string processing can be dangerous.

Stack Buffer Overflow

When the config file is read, if an exceptionally large line exists, it can trigger a stack buffer overflow due to an unsafe strcpy inside CCfgFile::GetValue(). Specifically the value is copied to a 0x12c byte string buffer. The line length must also be less than 0x400 (including the null byte) or else the line won’t be processed.

Command Injection

Alternatively, by inserting newline characters after the BackHoseIp value, an attacker can inject arbitrary configuration line items. In our PoC, we specify a BackHoseIp value of:

127.0.0.1\nPrimaryDbSaUserName1 = foo" -F & notepad.exe & "

Assuming the new config has been loaded, when a backup occurs, notepad.exe is launched due to the lack of input validation. The CDbBase::ExecSql() function concatenates the value of PrimaryDbSaUserName1 into an osql command. This command is passed to the runCommand() function, which in turn calls system().

Triggering the Vulnerabilities

I mentioned that after the malicious BackHoseIp is injected, the configuration file must be reloaded. Upon reload, the stack overflow would be triggered. However, the command injection isn’t triggered until a backup is launched. Let’s see a diagram of each flow.

The “Patch”

Version 7.3 E0703 claims to patch these issues. However, the changes simply don’t address the root cause. Instead of validating that BackHoseIp is an actual IP address, the developers decided to require encryption for commands 10000 and 10002. Without the encryption key, you cannot tell the server to reload dbman.conf or perform a manual backup using these command codes. On the other hand, command code 10018 does not require the encryption key and can still be used to inject configuration variables. All this means is that an attacker needs to find a new way to reload the configuration (and trigger a backup if you’re going after the command injection).

Bypassing the “Patch”

We discovered ways to trigger both vulnerabilities despite the changes made. First, a DoS vulnerability was found in dbman which reboots the process and causes it to reload dbman.conf. If this interests you, more details can be found in our research advisory.

Secondly, an automated backup can be scheduled by setting the BackupTime and BackupTimeMinute configuration variables accordingly. These represent the scheduled hour and minute (24-hour format), respectively. The easiest way to do this is by injecting the variables into the BackHoseIp variable value. However, if you wanted to do it “correctly,” iBackUpTime is actually a representation of these two values, so you could pre-calculate the time.

The time variables would look like this if you wanted to schedule a backup at 3:00 PM:

BackupTime = 15
BackupTimeMinute = 00

Triggering the Vulnerabilities

The updated flow diagrams look like such.

Let’s see the command injection in action! Wait for notepad.exe to pop up on Process Monitor.

Conclusion

Let’s recap. We first reported these vulnerabilities in December 2018. An inadequate patch was released to address these bugs. We reported the faulty patch to HPE in June 2019, and we still don’t have an updated patch (as of Oct 1, 2019). Unfortunately we aren’t sure when this will be addressed. We advise you to keep an eye on the HPE Security Bulletins page.

For more information, please take a look at our latest research advisory and our GitHub PoC repo.

Update Feb 21, 2020: According to HPE, iMC PLAT 7.3 (E0705P02) has fixed these vulnerabilities. Security bulletin HPESBHF03930 rev.4 has been updated to reflect this.