Get in touch

Intel Data Center Manager <= 5.1 Local Privileges Escalation

Dec 7, 2022 · By Julien Ahrens

ADVISORY INFORMATION

CREDITS

This vulnerability was discovered and researched by Julien Ahrens from RCE Security.

VERSIONS AFFECTED

Intel Data Center Manager 5.1 (latest) and below

INTRODUCTION

Energy costs are the fastest rising expense for today’s data centers. Intel® Data Center Manager (Intel® DCM) provides real-time power and thermal consumption data, giving you the clarity you need to lower power usage, increase rack density, and prolong operation during outages.

(from the vendor’s homepage)

VULNERABILITY DETAILS

The latest version (5.1) and all prior versions of Intel’s DCM are vulnerable to a local privileges escalation vulnerability using the application user “dcm” used to run the web application and the rest interface. An attacker who gained RCE using this dcm user (i.e., through Log4j) is then able to escalate their privileges to root by abusing a weak Sudo configuration for the “dcm” user:

dcm ALL=(ALL) NOPASSWD:/usr/local/bin/SDPTool
dcm ALL=(ALL) NOPASSWD:/usr/bin/cp
dcm ALL=(ALL) NOPASSWD:/usr/bin/chmod

The Intel Server Debug and Provisioning Tool (SDP Tool) must be installed for the Data Center Manager to be vulnerable. Successful exploits can allow an authenticated attacker to execute commands as root. In this way, the attacker can compromise the victim system’s entire confidentiality, integrity, and availability, thereby allowing to persist within the attached network.

PROOF OF CONCEPT

Just one way of exploitation is by replacing the current sudoers configuration:

1.Create a new sudoers configuration file using the compromised “dcm” user in i.e. /tmp/ 2.sudo chmod 440 /tmp/sudoers 3.sudo cp sudoers /etc/sudoers 4.sudo /bin/bash

SOLUTION

None. Intel thinks that this is not a vulnerability and therefore does also not assign a CVE for it.

REPORT TIMELINE

  • 2022-07-16: Discovery of the vulnerability
  • 2022-07-16: Reported to vendor via their bug bounty program
  • 2022-07-18: Vendor response: Sent to “appropriate reviewers”
  • 2022-07-26: Vendor states that the vulnerability “depends on something that does not exist (eg; RCE).”
  • 2022-07-26: Sent a clarification that a compromise of the “dcm” account is indeed necessary, but there have been RCEs in the past (i.e. through Log4j)
  • 2022-09-22: Vendor has troubles to reproduce the bug and asks for another PoC
  • 2022-09-22: Sent a clarification about the PoC
  • 2022-09-22: Vendor states that the report “does not clearly demonstrate a vulnerability in DCM” and the report will be closed.
  • 2022-09-23: Provided the vendor with a PoC utilizing Log4shell (CVE-2021-44228) in a former version of DCM
  • 2022-10-10: Vendor asks whether the Log4shell bug is still reproducible in the latest version of DCM
  • 2022-10-10: Made clear that Log4shell is not the point about the report
  • 2022-10-11: Vendor states “We do not clearly see a a vulnerability demonstrated in DCM”
  • 2022-10-12: [Back and forth about the provided PoCs]
  • 2022-10-12: I’m giving up.
  • 2022-12-07: Public disclosure

REFERENCES

None