CVE-2014-8272: A Case of Weak Session-ID in Dell iDRAC

Following Dan Farmer’s IPMI research in August 2013, one of our researchers dug further and discovered another vulnerability in the Dell Baseband Management Controller (also known as iDRAC) implementation of the Intelligent Platform Management Interface (IPMI) v1.5 protocol. This vulnerability, CVE-2014-8272, allows an unauthenticated or lower-privileged attacker to inject arbitrary commands into the context of another privileged session. This was first reported in late 2013 during his previous employment with X-Force, but wasn’t officially addressed until Dec 2014. This blog post details the vulnerability, how it could be exploited and our comments about the fix. Finally, MWR has decided to release a tool to check for machines vulnerable to CVE-2014-8272.

Background: Session-ID in IPMI v1.5 LAN Activation

Before diving into more details, we will first look at the purpose of a Session-ID in an IPMI v1.5 communication channel.

The communication channel between a user (remote console) and Baseband Management Controller (BMC – managed system) communicates in a channel that is set up in 3 stages, as stated in the specifications:

In the “Discovery” stage, the BMC replies with the authentication algorithms that could be used for the console-specified IPMI v1.5 channel/account type (eg: ADMINISTRATOR, USER, OPERATOR, etc). In the “Activation” stage, the account credentials are presented and verified with one of the supported authentication algorithms. Upon success, a Session-ID is issued. All communication after this point must include this Session-ID because it identifies an authenticated, active and valid channel. This enables the BMC to support multiple simultaneous sessions. Besides tying the corresponding channel to a session, the Session-ID also identifies the channel’s privilege level to an account type. For example, the remote console is unable to complete a “Set User Password” command in a session activated with a USER privilege account.

Vulnerability: Session-ID in iDRAC

The Session-ID, being represented as an unsigned integer, should exhibit two properties:

1. The values should be randomized across different channels
2. It should have a space of (2^32) possible values

Unfortunately, this is not the case with iDRAC. The Session-ID that iDRAC issues takes a 0x0200XXYY format. Byte-3 and byte-2 are set as the constant 0x0200. It is unclear what this means, but it may represent the IPMI version number that iDRAC supports. Byte-0 (YY) seems to show the number of sessions being activated within a ~3 sec period. It ranges from 0x00 to 0x03, indicating that iDRAC supports only 4 simultaneous channels (at least on the version that is tested). On subsequent channel requests, iDRAC will return a “Node Busy” error, as shown below:

Byte-1 (XX) is a value that increments by one after issuing a Temporary-Session-ID and Session-ID in the “Activation” stage. Apparently, iDRAC regards 0x00 as a special value and skips it as Byte-1 is wrapped around 0xFF. This results in a space of (2^8)-1 possible values for the Session-ID:

Exploitation: Arbitrary Command Injection

As a result of the predictability, an attacker is able to inject arbitrary commands in the context of any established session. In the scenario where an attacker has a USER account, he could predict the next Temporary-Session-ID and Session-ID with the current set of values. Here are the sequence of steps:

1. With any account credentials, an attacker sends a “Get Session Challenge” request to obtain the current Temporary-Session-ID.
2. Craft an IPMIv1.5 command with the next Session-ID, which would be the value of current Temporary-Session-ID + 3.
3. Repeatedly send the crafted request so that it will be injected into the next session, whenever it is established.

The following two screenshots demonstrate the attack:

In the above example, the first “User List” command shows that of the 6 accounts in iDRAC, only the “root” account has ADMINISTRATOR privilege. Next, the “Chassis Status” command is a general query by a legitimate ADMINISTRATOR user. It is during this command that the attacker sends a crafted “Set User Access” command with his predicted Session-ID. The last “User List” command shows that the injected “Set User Access” command is successful, and the “user” account is now elevated from USER to ADMINISTRATOR privilege.

The image above shows the network packet capture of the “Chassis Status” command. Frame 12 stands out because it is the response from the injected “Set User Access” command even though the injected command is sent from another IP (not shown). This shows that even though iDRAC keeps a mapping of Session-ID to IP, it uses this mapping to direct responses but not to filter out the source of requests.

In this capture, the window of opportunity to inject arbitrary command occurs after frame 10 and before frame 14. If iDRAC had received the crafted command at frame 9, an “Insufficient Privilege Level” error would have been returned instead.

A downside to this attack is the amount of “noise” generated, because there is no way of knowing when the next session will be established.

Vendor Response

There are two possible fixes for this vulnerability. The first would be to use the full (2^32) values for Session-ID, and randomize them appropriately. The second would be to check the mapping for command requests. However, Dell chose to fix this in iDRAC v1.98 by disabling IPMI v1.5 completely despite the specifications recommending backward-compatibility, reasoning that:

“…Use of IPMI 1.5 is clearly not recommended, and none of Dell customers have asked that we enable this…”

Comments

According to this follow-up article by Dan Farmer on June 2014, a mass scan shows that 109,726 (46.8%) of machines with UDP port 623 open (default IPMI port), are still using IPMI v1.5. With Dell having an estimated 15% server market share in May 2014], this worked out to an estimated 17,500 iDRAC machines using IPMI v1.5. As Dell has indicated that no customers have requested backwards compatibility, this either means that all of the 17,500 machines have now switched to IPMI v2.0 (which is a fantastic situation), or these machines are still vulnerable unknowingly. As a result, MWR has released a tool to check if a server machine is vulnerable to CVE-2014-8272. You can download this tool at the link below: