‘Cloudborne’ IaaS Attack Allows Persistent Backdoors in the Cloud

A known vulnerability combined with a weakness in bare-metal server reclamation opens the door to powerful, high-impact attacks.

An attack scenario affecting various cloud providers could allow an attacker to implant persistent backdoors for data theft into bare-metal cloud servers, which would be able to remain intact as the cloud infrastructure moves from customer to customer. This opens the door to a wide array of attacks on businesses that use infrastructure-as-a-service (IaaS) offerings.

Appropriately dubbed “Cloudborne” by Eclypsium, the attack vector (which the firm characterizes as a critical weakness) consists of the use of a known vulnerability in bare-metal hardware along with a weakness in the “reclamation process.”

Reclamation is part of the way bare-metal cloud infrastructure is managed; it’s a shared pool of resources that get re-assigned to different users over time.

“While physical servers are dedicated to one customer at a time, they don’t stay that way forever,” researchers explained in a Tuesday posting. “Servers are provisioned and reclaimed over time and naturally move from customer to customer.

The issue is that all too often, the servers’ firmware is not re-flashed (overwritten to factory settings, essentially) when a server is reclaimed by the cloud provider to be moved on to a new user. This allows the firmware to persist from customer to customer, including any changes a malicious user might make to it.

In the Cloudborne scenario, an attacker can first use a known vulnerability in Supermicro hardware (present in many cloud providers’ infrastructure, the firm said), to overwrite the firmware of a Baseboard Management Controller (BMC). BMCs are a third-party component designed to enable remote management of a server for initial provisioning, operating system reinstall and troubleshooting.

This allows the adversary to implant a backdoor that gives them direct access to the hardware itself. The system could then be returned to the hardware pool, and because of the lack of re-flashing, the compromised BMC firmware would remain and could be used to attack the next user of the system.

“An attacker could spend a nominal sum of money for access to a server, implant malicious firmware at the UEFI, BMC or even component level, such as in drives or network adapters,” Eclypsium explained.

With a backdoor available on the firmware, an attacker would be able to subvert the controls and security measures of the host operating system and the virtualization layers of a server, according to Eclypsium.

“Given a BMC’s ability to control the server, any compromises to the BMC firmware can be particularly powerful for an attacker,” researchers said. “Given the nature of the applications and data hosted on bare-metal offerings, this opens up the possibility for high-impact attack scenarios.”

These include application disruption, where a malicious implant at the BMC level could permanently disable a server; data theft since attackers would gain access to the data stored on the physical host; and attacks against the firmware on drives and network adapters which would give attackers a simplistic way of stealing or intercepting data.

Ransomware attacks are possible too. “With the ability to disable applications and damage data, attackers would naturally have the ability to perform high-value ransomware attacks,” the team said.

[Don’t miss our free Threatpost webinar this Wednesday, Feb. 27 at 2 p.m. ET, featuring Patrick Hevesi of Gartner; Mike Burr of Google Android; and David Richardson from Lookout.] 

Also, the implant could be used to compromise other parts of the infrastructure. That’s because the BMC is a highly privileged component that uses the Intelligent Platform Management Interface (IPMI) to communicate with software running on the host processor. These communications are session-less and as such, don’t have a method for authentication.

“Malware can potentially send malicious IPMI commands over system interfaces from the host without the commands being authenticated,” researchers noted in the post. “Since there is no authentication performed when using system interfaces, the only barrier to running arbitrary code within the BMC is whether the BMC itself performs cryptographically secure signature verification of the firmware update image before applying the update. Unfortunately, not all BMCs perform this check, and even when they do, malware can exploit vulnerabilities in the BMC firmware to bypass it.”

The team tested IBM’s SoftLayer IaaS services to see if they could implant a persistent backdoor that would survive customer migration – though researchers stressed that “what we tested for in the experiment is common to many cloud providers and should not be considered limited to IBM SoftLayer.”

The team acquired access to a bare-metal server through the IaaS service, with the goal being to make a small change to the BMC firmware (a placeholder for dropping a real implant), release it back to IBM, and then reacquire the same device from a different user account to see if the change survived the migration process.

“It took about 45 minutes to provision the server, almost evenly split between OS provisioning (DEPLOY) and configuration (DEPLOY2) stages. Once the instance was provisioned, we verified that it had the latest BMC firmware available, according to the Supermicro site.”

After recording the chassis and product serial numbers of the server so they could re-identify it later, the team made a benign change to firmware. They then updated the BMC firmware, and created an additional IPMI user with administrative access to the BMC channels. The system was then released back to IBM.

After making multiple bare-metal provisioning requests from another account, the Eclypsium team was able to reacquire the same piece of hardware, validating it with the chassis and product serial numbers recorded earlier. It turns out that while the additional IPMI user was removed during the reclamation process, the firmware change was still there, indicating that the firmware hadn’t been re-flashed.

There were other issues as well: “We also noticed that BMC logs were retained across provisioning, and that the BMC root password remained the same across provisioning,” according to Eclypsium. “By not deleting the logs, a new customer could gain insight into the actions and behaviors of the previous owner of the device. Meanwhile, knowledge of the BMC root password would enable an attacker to more easily gain control over the machine in the future.”

For its part, IBM acknowledged the issue, and in an advisory said that it had addressed the Cloudborne weaknesses.

“IBM has responded to this vulnerability by forcing all BMCs, including those that are already reporting up-to-date firmware, to be re-flashed with factory firmware before they are re-provisioned to other customers,” it said. “All logs in the BMC firmware are erased and all passwords to the BMC firmware are regenerated.”

However, Big Blue disagreed with the critical 9.3 CVSS score that Eclypsium gave the issue, instead characterizing it as “low-severity.”

“The BMC has limited processing power and memory, which makes these types of attacks difficult,” IBM noted. “IBM has found no indication that this vulnerability has been exploited for malicious purposes. In addition, all clients of IBM Cloud receive a private network for their BMCs, separate from the private networks containing other clients’ BMCs and unprovisioned BMCs.”

Interested in learning about mobile enterprise security threats and best practices? Don’t miss our free Threatpost webinar Wednesday, Feb. 27 at 2 p.m. ET.

Patrick Hevesi of Gartner; Mike Burr of Google Android; and David Richardson from Lookout will join Threatpost senior editor Tara Seals.

They’ll discuss the top evolving threats and risks that are unique to this work-from-anywhere environment; best practices for addressing them; and new challenges on the horizon, such as 5G services.

Suggested articles