QCT & Pantsdown: An Executive Summary

Recent research has identified that a number of Quanta Cloud Technology (QCT) servers are vulnerable to the well-known ‘Pantsdown’ vulnerability. (For details on this vulnerability, on the proof-of-concept exploit model, and on mitigation steps, please read Quanta Servers (Still) Vulnerable to Pantsdown.) This post, however, explores the business ramifications of this issue.  

Business and Market Impact

QCT and other providers have prospered as their customers have pursued their digital transformation efforts. Research by Gartner, in their “Market Guide for Compute Platforms” in 2018, that Quanta “acts as an ODM [Original Design Manufacturer] (by selling server parts and full servers through server OEM partners) and a server provider to some larger end users”, and that Quanta’s primary customer penetration “has been in the hyperscale data centers of large consumer service providers.” It is unknown if these customers are still heavily reliant on QTC equipment, but it’s easy to see that an unpatched vulnerability in this firmware represents a vast, new, and undefended attack surface. 

While these “large consumer service providers” are abstracting their services away from the underlying hardware and trading the hardware’s associated costs for benefits in the speed and ROI, the effort comes with some often-overlooked facts:

  • These services still run on hardware: “somebody else’s” hardware, but hardware just the same 
  • Hardware cannot run without firmware: complex custom code provided by the manufacturer and a multitude of suppliers 
  • Firmware contains the same misconfiguration, vulnerabilities, and weaknesses that application and operating system code does: it’s just more complex, less accessible, and less understood by practitioners in the field who often have a hands-off approach to firmware  

Priorities for CISOs and Security Teams

The QCT vulnerabilities described in our research report are three or more years old. They still exist. At the same time, remote management interfaces like lights-out server management systems known as Baseboard Management Controllers (BMC) have been the target of increased cyber attacks including ransomware, stealthy implants, and disruptive operations. One recent example is the iLOBleed malware infecting iLO BMC firmware in HPE servers. Common BMC vulnerabilities like Pantsdown, USBAnywhere, and Cloudborne combined with infrequent firmware updates to leave many server systems vulnerable. Security guidance encourages separation of management networks, but many BMCs remain internet accessible. In addition to BMCs, most systems have management capabilities built into the chipset like the Intel Management Engine (ME). 

Guidance: Three Things TO STOP, Three Things TO START 

In light of the breadth and reach of these vulnerabilities, cybersecurity teams are advised to change their view on firmware-level code. It may be that firmware issues are a priority for your teams already, but it may be they need an urging to STOP doing these things (if they’re still doing them):

  1. Stop accepting, unchallenged, the security posture of embedded firmware
  2. Stop assuming that previously detected vulnerabilities have been patched or mitigated by manufacturers 
  3. Stop treating firmware as an untouchable “black box,” unexposed to the discipline and rigor that applications and operating systems receive 

At the same time, cybersecurity teams responsible for endpoint security, vulnerability and risk, and supply chain security need to take ownership of firmware security and START

  1. Identifying all firmware in their devices – whether that’s on-prem servers, firmware in network devices, or firmware in “borrowed” cloud servers – and create workable, updated inventories. This also includes detecting backdoors, implants and counterfeits introduced by supply chain threats and bad actors.
  2. Verifying these firmware images against known-good hashes, while also checking their configurations against published guidance and protections
  3. Fortifying firmware by updating where needed, configuring securely, and patching with verified code     

Vulnerabilities in remote management firmware will continue to appear and continue to be exploited. But we can get ahead of these exploits by regularly identifying firmware vulnerabilities, applying firmware updates and scanning firmware in all systems for indicators of compromise.