Forgotten Protocols: IPMI

In previous posts we have mentioned the importance of paying special attention to all the services that our IT assets provide to our internal network. A clear example was to mention protocols such as NTP where we found a functionality that, under the current sense of security, seems not to have so much interference within the most critical assets, but precisely as detailed in that post, we found that this forgotten resource is of vital importance for other services that depend on the time variable, as a result, we could show how they can be developed attack vectors applied to this protocol that is usually not observed in the spectrum of those that system administrators take into account when monitoring the health of the same.

As you may well know, it is not the only neglected protocol within the services that we are used to protect, since having such a diversity of technologies within companies we find not only a lack of awareness when it comes to understanding all the protocols, but also the lack of technical capacity to give them the treatment and attention they deserve. Today in this post we will talk about another jewel for attackers that continues to go unnoticed, the IPMI protocol (Intelligent Platform Management Interface), with which the BMC (Baseboard Management Controller) interfaces work.

The IPMI protocol

The Intelligent Platform Management Interface is a set of specifications related to a particular Ethernet interface associated with a subsystem that provides management and monitoring capabilities independent of the main host (like a Mamushka doll of computers). When we talk about the main host, we talk about its hardware (its "CPU"), the firmware and the operating system. IPMI allows defining a set of interfaces for system administrators to perform "out-of-band" management. It provides us with the possibility to manage and monitor the health status of a computer that might be down or might have a problem that prevents the usual response, or to allow the execution of maintenance tasks such as reinstalling the operating system completely remotely, without relying on the main network or the usual mechanisms.

Without this protocol, such tasks would require an administrator to be physically in front of the computer, enter a media with the operating system ISO and complete the installation process using a monitor and keyboard. With IPMI we can mount an image remotely simulating a physical installation.

Using standardized messages, an IPMI-based management system can manage multiple servers dialoguing at this network level. These functions can work in three different scenarios:

 •  Before system startup (Allowing remote monitoring or changing any BIOS settings)
 •  When the system is shutting down (To determine why this is happening, taking into account that sometimes this happens in an unplanned way).
 •  After an operating system failure.

Among the issues to be monitored are technical variables such as temperature, ventilation or power supplies, but also a physical intrusion into the hardware (such as connecting a USB) or a log that can provide help regarding the malfunction that could occur within an installation. This protocol was published by Intel in 1998 and is currently supported by more than 200 manufacturers, including Cisco, Dell, HP, Intel and many others. Systems generally use version 2.0 which can be managed through the serial port over the LAN (note this point for further discussion), in order to function the protocol requires the following components:

 •  Baseboard Management Controller (BMC): A microcontroller housed inside the server motherboard, it is a small computer based on an ARM System on a Chip (SoC), with a graphics controller included. Some manufacturers use non-ARM solutions, but currently, the main SoC dedicated to this is the AST2500. These SoCs are accompanied by flash storage and various input and output controllers.
The image below shows how the BMC controller is connected to an Intel S1200V3motherboard.

In this other image, we can visualize how the BMC (AST2500) is internally composed. We can see in detail all the parts that interact inside the chip.

It has multiple connections to the main system, having the ability to monitor the hardware as previously discussed. The ways to access it can be through a serial port or through a virtual KVM (Keyboard Video & Mouse). To better understand how it works we can make an analogy of this SoC with a RaspberryPi and its component diagram (as shown in the image below).

 •  Intelligent Chassis Management Bus (ICMB): It is used as a control interface between different chassis (defining chassis as the unit inside the Rack that contains a certain number of servers), allowing it to communicate through a wired serial interface.
 •  Intelligent Platform Management Bus: Used to extend the BMC and interconnect different boards.
 •  IPMI Memory: It is the memory used to store the system logs, data stored at rest, among other things.
 •  Communication interfaces: Local interfaces, serial ports, LAN and PCI interfaces.

The administration of these interfaces occurs through the LAN network that we all know, observing the following illustration we can see how an administrator manages to connect to the BMC through port 623/UDP/TCP using IPMI.

It should be clarified that the main system can be turned off, but the IPMI module will "always” be on and a connection to the LAN to be used, because usually all server BMCs are interconnected with each other. To exchange the data necessary for maintenance tasks, an interconnection is generated which can be seen as follows:

So far we do not see anything strange, we have a network parallel to the LAN that interconnects all the BMCs and serves to monitor the health status of the devices. So where is the main problem? Is it in the lack of knowledge of these services or in the way they are implemented? It is very likely that the administrators of the area in charge of the servers are aware of the existence of the BMC controllers, in order to be able to monitor their interfaces, so the problem would not be mostly in the apparent ignorance of this type of protocol. As the BMC is a computer inside another computer and has access to the LAN, the problem is the "same as always" if there is no adequate segmentation to protect these resources, all the flaws that this controller may have will be exposed, expanding the attack surface of this network allowing attackers to access these resources.

Considering the last image, if an attacker has visibility on the Endpoint that manages the BMC network (Point 1 marked in the illustration) or otherwise the same network communicates without any problem with our LAN network leaving the BMC network exposed (Point 2 marked in the illustration):

We are in the presence of a potential security breach that exposes IPMI interfaces, expanding the attack surface, as shown in the following scenario:

So we could say that the attacker not only has access to the monitoring of servers, but could also move from chassis to chassis reaching servers hosted in unauthorized areas of the infrastructure, as we find in the detail of the image above, where we see that in the blue path, from a vulnerability found in a BMC (corresponding to a particular server) the attacker accesses the CMC and then moves from chassis to chassis until accessing the desired server out of its original range of action or otherwise follow the path 1 detailed above where the attacker accesses the uncontrolled Endpoint that has access to the RMC (which can view all the corresponding CMC).

It is important to mention that as cybersecurity professionals we must control these points not only by mitigating potential vulnerabilities, but also by limiting the visibility that attackers can have on these resources that at first glance and without knowing how they work are usually out of the range of interest for protection.

In order to identify if these services have visibility with our internal network, we can perform the following steps. We position ourselves at any point in the network and then we could execute the following commands to perform an enumeration of them, performing an internal pentesting oriented to determine the viability of these potential exposures.

Scanning and Enumeration

At this stage we proceed to run a series of scans that will allow me to identify the respective visibility associated with these interfaces. The attacker at this stage seeks to have eyes on these unattended resources.

 •  Execute the following commands with NMAP from a point of the server network to visualize if these communications are operative (remember that the service can be over both UDP and TCP, so it is advisable to enumerate both segments)
 •  Then we proceed to identify which IPMI version is being used in those services previously found. Using an auxiliary exploit in Metasploit and for UDP a Nmap script::

 •  It is advisable to document all the hosts and then run a segmentation test from all possible points of the network, from which these services should not be seen.


Obtaining access to the BMC:

Recalling the cases seen previously, if the services are accessible and are identified, we must gain access through these ports that are open and visible. To do this we can perform several tests listed below:

 •  IPMI Authentication Bypass via Cipher 0: This vulnerability found by Dan Farmer in the IPMI 2.0 protocol refers to the fact that the cipher 0 cipher type, which indicates that the user uses plain authentication, actually allows access with any password. The problem could probably affect all IPMI 2.0 implementations.

- It can be identified using the following auxiliary exploit with Metasploit: use auxiliary/scanner/ipmi/ipmi_cipher_zero

- After identification, we could exploit the flaw using the ipmitooltool, executing the commands detailed in the following screenshot:

 •  IPMI 2.0 RAKP Authentication Remote Password Hash: We can also ask the server for the MD5 or SHA1 hash of any user and if the user exists these Hashes will be returned respectively (If we repeat the step of the previous attack we can first enumerate the existing users and then request the respective hashes with ipmitool). For this purpose there is a Metasploit module that helps us to collect them.
- use auxiliary/scanner/ipmi/ipmi_dumphashes
 •  IPMI Anonymous Access: If when enumerating the users we find that there are empty fields, they may be null users, if we repeat the previous steps we can configure a password for each one of them.

 •  IPMI SuperMicro - Plain text passwords: In this case, IPMI 2.0 responds to HMAC authentication using SHA1 and MD5. This process has a marked weakness, but access to the plain text password is often required to calculate the respective Hash. As with the passwords of the motherboards of an infrastructure, the users that maintain these installations usually place the same password for all the BMCs, so in many occasions, it is enough to access a particular BMC and extract the passwords from the /nv/PSBlock directory or /nv/PSStore. The next step is to calculate the hash corresponding to the value obtained from those paths and perform the respective authentication.
 •  Brute Force: All installations are vulnerable to brute force attacks and in some cases maintain their original default configurations. Therefore, accessing the necessary information to execute this attack is of vital importance after having carried out the corresponding enumeration. Some example data can be the following:

Obtaining access to the Host

Once we have accessed the virtual KVM interface of the respective BMC, it remains to access the Host in question. Here in this instance, it depends on the type of operating system that has the main server corresponding to the BMC, in this instance, we can obtain access in several ways.

 •  In the case of Linux systems, , simply restarting the server from our KVM we could for example edit the Grub, adding the classic line init=/bin/bash, in the Linux instruction and then start the boot sequence, pressing F10

 •  Then when we get the root prompt we could whiten the root password or otherwise create another user with the respective commands.
 •  In the case of Windows systems; We could use the KVM to load a Hirens Boot CD ISO, and then use the NTPWEdit to whiten the local administrator user key.

Possible solutions

It should be clarified that there are several ways to mitigate these problems. However, if we do not use IPMI, the risks are considerably reduced. We must not neglect to pay attention to the corresponding BMCs. The steps to verify this would be the following:

 •  Make sure that the segmentation tests on these interfaces have been negative. In the case of being positive we have a wide attack surface on which the attacker can work without inconvenience. Remember that in every KillChain, the objective is to stop the attacker as soon as possible to avoid major problems. If we blind the attacker by applying a correct segmentation and security in-depth, we can minimize these risks.
 •  Update vulnerable BMC controllers, Several patches could be applied to this firmware, in case you have a SuperMicro firmware, we leave a link in the references so that you can follow these guides.
 •  To perform a secure patch you must block port 623 momentarily in order to execute the update correctly.
 •  Change the default users and passwords; Set strong passwords to make it more complex to calculate the hash and salt.
 •  Implement a correct NETWORK architecture; In this step make sure that IPMI services are not visible from the Internet, it is very common to find these services enabled in Shodan.
 •  Segment the Management network to prevent access from anywhere on the LAN by implementing an internal DMZ with a dedicated firewall.

Conclusion

We believe it is important to understand the technologies to keep them protected, it is understood that it is difficult to apply solutions once all platforms are in production, so once the risk is identified, or seen in the news. Turning these concepts into routine practices has a direct impact on our architecture, whether they are new vulnerabilities or not, but we will not be safe if we do not verify.