This blogpost is the second part of the series about our journey to the pwn2own Toronto 2022 contest.
这篇博文是关于我们参加 2022 年 pwn2own 多伦多比赛的系列文章的第二部分。

In Our Pwn2Own journey against time and randomness, part 1 we explained how we attacked the router from the WAN side and lost our battle against randomness and time just by a few seconds. Here we will describe two vulnerabilities that we found on the LAN side of the Netgear RAX30 router.
在我们的 Pwn2Own 与时间和随机性的斗争中，第 1 部分，我们解释了我们如何从 WAN 端攻击路由器，并在几秒钟内输掉了与随机性和时间的战斗。在这里，我们将描述我们在 Netgear RAX30 路由器的 LAN 端发现的两个漏洞。

Pwn2own Toronto 2022 occurred on December 6-9, 2022, so why publish this now ?
Pwn2own Toronto 2022 于 2022 年 12 月 6 日至 9 日举行，那么为什么现在发布这个呢？

Well, we reported the discovered vulnerabilities to the vendor and followed a coordinated vulnerability disclosure process that took a lot of time, and we decided not to rage-quit and just publish them, so after a lengthy coordination process we reached the agreed date for publication and here’s the blog post.
好吧，我们向供应商报告了发现的漏洞，并遵循了花费大量时间的协调漏洞披露流程，我们决定不愤怒地退出，只是发布它们，所以经过漫长的协调过程，我们达到了商定的发布日期，这是博客文章。

LAN vulnerabilities LAN 漏洞

Buffer Overflow inside soap server (CVE-2023-27368)
SOAP 服务器内部缓冲区溢出 （CVE-2023-27368）

This vulnerability was not attributed to us, it seems that another competitor also found it. However, since we found this vulnerability during the competition, we will describe it nonetheless.
这个漏洞不是归咎于我们，似乎另一个竞争对手也发现了它。但是，由于我们在比赛中发现了这个漏洞，因此我们仍将对其进行描述。

On the LAN side, a server brought to our notice this program called soap_serverd, it is a server that is exposed on all LAN interfaces but does not seem to be designed for human interaction, which is of great interest to us.
在LAN方面，一台服务器引起了我们的注意，这个程序称为 soap_serverd ，它是一台暴露在所有LAN接口上的服务器，但似乎不是为人机交互而设计的，这引起了我们的极大兴趣。

In fact, this service is used by the Netgear application to communicate with the router.
实际上，Netgear 应用程序使用此服务与路由器进行通信。

During our analysis, we realized from the first line of parsing the HTTP entry that some things could go wrong. Indeed, as you can see in the decompiled code below, the parsing of the HTTP header is using sscanf with a string format without size control.
在我们的分析过程中，我们从解析 HTTP 条目的第一行就意识到有些事情可能会出错。事实上，正如您在下面的反编译代码中看到的那样，HTTP 标头的解析是使用 sscanf 没有大小控制的字符串格式。

  memset(auStack_1820,0,2044);
  local_1e24 = 0;
  memset(auStack_1e20,0,508);
  local_1c24 = 0;
  memset(auStack_1c20,0,508);
  local_1a24 = 0;
  memset(auStack_1a20,0,508);
  local_1024 = 0;
  memset(auStack_1020,0,2044);
  local_824 = 0;
  memset(auStack_820,0,2044);
  iVar1 = FUN_00019050(&local_1824,0x800);
  if (iVar1 == 0) {
    log_log(7,"handle_soapRequest",0x182,"line:[%s]",&local_1824);
    pcVar6 = "No request found.";
  }
  else {
    iVar1 = __isoc99_sscanf(&local_1824,"%[^ ] %[^ ] %[^ ]",&local_1e24,&local_1c24,
                            &local_1a24);
    if (iVar1 == 3) {
      iVar7 = strcasecmp((char *)&local_1e24,"post");
      if (iVar7 == 0) {
        FUN_00015060(param_1);

soap_serverd reads the HTTP headers calling sscanf to extract the HTTP method, path, and protocol version.
soap_serverd 读取调用 sscanf 以提取 HTTP 方法、路径和协议版本的 HTTP 标头。

Because we didn’t want to waste any time unnecessarily, our strategy was to focus on vulnerabilities that were easier to exploit, and we kept this vulnerability for the time we had left. The Netgear hotfix released right before the contest forced us to change our plans and we never went any further than a simple DOS with this vulnerability.
因为我们不想不必要地浪费任何时间，所以我们的策略是专注于更容易利用的漏洞，并在剩下的时间里保留这个漏洞。在比赛前发布的 Netgear 修补程序迫使我们改变计划，我们除了一个简单的 DOS 之外，再也没有进一步利用这个漏洞。

However, we were happy to see that, in their last release Netgear corrected this vulnerability by controlling the size of the parsed elements.
但是，我们很高兴地看到，在他们的上一个版本中，Netgear 通过控制解析元素的大小来纠正此漏洞。

    iVar1 = __isoc99_sscanf(&local_1824,"%511[^ ] %511[^ ] %511[^ ]",&local_1e24,&local_1c24,
                            &local_1a24);

If you are interested in a blogpost that converts this vulnerability into a remote code execution one, we strongly encourage you to read this blogpost.
如果您对将此漏洞转换为远程代码执行漏洞的博文感兴趣，我们强烈建议您阅读此博文。

A Denial of service vulnerability
拒绝服务漏洞

The Netgear RAX30 router integrates several paths to access a set of services, some with authentication and some without. Among the unauthenticated calls, there is the possibility to push files to the router via the rex_cgi binary. Below, an extract of rex_cgi which handles the file uploads.
Netgear RAX30 路由器集成了多条路径来访问一组服务，其中一些具有身份验证功能，而另一些则没有身份验证。在未经身份验证的调用中，有可能通过 rex_cgi 二进制文件将文件推送到路由器。下面， rex_cgi 其中的摘录处理文件上传。

if (http_docroot != '\0') {
        if (http_boundary == (void *)0x0) {
                    pcVar1 = "/tmp/uploadFile";
        } else {
                    pcVar1 = "/tmp/multipartFile";
        }
        strcpy(psz_dest_file,pcVar1);
        pfile_dest = fopen(psz_dest_file,"w+");
        if (pfile_dest != (FILE *)0x0) {
                for (i = http_content_length; i != 0; i = i - 0x400) {
                            if (i < 0x401) {
                                            fread(buffer,i,1,stdin);
                                            fwrite(buffer,i,1,pfile_dest); 
                                            break;
                            }        
                            fread(buffer,0x400,1,stdin);
                            fwrite(buffer,0x400,1,pfile_dest);
                    }
                fclose(pfile_dest);
        strcpy(&DAT_00027427,psz_dest_file); 
    }

As you can see, the file is directly written inside the /tmp directory, and no size verification is done. Thus, if you submit a file of a size greater than router’s available RAM, the router will freeze.
如您所见，文件直接写入 /tmp 目录内，没有进行大小验证。因此，如果您提交的文件大小大于路由器的可用 RAM，路由器将冻结。

To try this you can use this script:
要尝试此操作，您可以使用以下脚本：

import requests
url = 'http://192.168.1.1/tm_block/tm_block.cgi'
files={'testfile':open('test.cfg','rb')}
resp = requests.put(url, files=files)
print(resp.status_code)

To have a POC that works properly, you should have a test.cfg file of size over 1G, the RAM size of this router.
要使POC正常工作，您应该有一个 test.cfg 大小超过1G的文件，即此路由器的RAM大小。

This vulnerability is not critical, but it could be really inconvenient for anyone wanting to use this router.
这个漏洞并不重要，但对于任何想要使用此路由器的人来说，它可能真的很不方便。

Signature bypass of the whole firmware
整个固件的签名旁路

We reverse engineered the firmware format of the Netgear RAX. The figure below details it precisely:
我们对 Netgear RAX 的固件格式进行了逆向工程。下图精确地详细说明了它：

This analysis was based on the original image found on the manufacturer’s website, the bcm_flasher binary and its library libbcm_flashutil.so allowing to flash the image on the NAND memory and the library libpu_util.so containing two interesting functions for the understanding of the firmware format:
该分析基于在制造商网站上找到的原始映像， bcm_flasher 二进制文件及其库允许在NAND存储器上刷新映像，并且该库 libbcm_flashutil.so libpu_util.so 包含两个有趣的功能，用于理解固件格式：

• puUtl_signCfg is used to check the signature embedded in the firmware format, and
  puUtl_signCfg 用于检查固件格式中嵌入的签名，以及
• puUtl_getSignHeader is used to retrieve the important information contained in the proprietary header.
  puUtl_getSignHeader 用于检索专有标头中包含的重要信息。

The router uses a wrapping header for the ITB format used on Broadcom chipset and some other chipset, the ITB format is a firmware format based on FDT (Flattened Device Tree) for SoC (System-on-a-Chip) of the ARM processor family. The ITB format is designed to store a firmware image that includes both the firmware binary code and a Flattened Device Tree representation of the devices embedded in the SoC. This representation allows the firmware to recognize the hardware devices and configure them correctly. The ITB format also allows for the storage of important metadata such as firmware version, security information and firmware integrity checks. It is possible for instance to create a signed image commonly called a FIT image, but for our case it is not used. They have their own method for signing the firmware.
路由器使用 Broadcom 芯片组和其他一些芯片组上使用的 ITB 格式的包装标头，ITB 格式是基于 ARM 处理器系列的 SoC（片上系统）的 FDT（扁平化设备树）的固件格式。ITB 格式旨在存储固件映像，其中包括固件二进制代码和嵌入 SoC 中的设备的扁平化设备树表示。这种表示形式允许固件识别硬件设备并正确配置它们。ITB 格式还允许存储重要的元数据，例如固件版本、安全信息和固件完整性检查。例如，可以创建一个通常称为 FIT 映像的签名映像，但在我们的例子中，它没有被使用。他们有自己的固件签名方法。

In fact, one field is called signature, and this signature is based on sha256 and 2 salted parts (K and K2). This verification is found inside the puUtl_signCfg function.
实际上，一个字段称为 signature ，此签名基于 sha256 和 2 个盐渍部分（K 和 K2）。此验证位于 puUtl_signCfg 函数内部。

    SHA256_Init(sha_context);
    SHA256_Update(sha_context,"hr89sdfgjkehx",0xd);
    SHA256_Update(sha_context,&Header,iVar4 + 4U);
    SHA256_Update(sha_context,ITB,size_ITB);
    SHA256_Update(sha_context,"nohsli9fjh3f",0xc);
    SHA256_Final((uchar *)&uStack_548,sha_context);

A sha256 hash is computed with hr89sdfgjkehx + PADDING + TYPE_VER + SIZE + VERSION + TYPE_VER + SIZE + DB_VERSION + ITB_HEADER + ITB + nohsli9fjh3f.
sha256 哈希的计算方式为 hr89sdfgjkehx + PADDING + TYPE_VER + SIZE + VERSION + TYPE_VER + SIZE + DB_VERSION + ITB_HEADER + ITB + nohsli9fjh3f .

Thus, because the “signature” of a firmware image is just the SHA256 digest of image data concatenated with a secret string embedded in the firmware it is possible to create firmware images with valid signatures that will pass the signature validation check.
因此，由于固件映像的“签名”只是映像数据的 SHA256 摘要，与固件中嵌入的秘密字符串连接起来，因此可以创建具有有效签名的固件映像，这些签名将通过签名验证检查。

Conclusion 结论

During our participation in the Pwn2Own Toronto 2022 contest, we discovered a couple of vulnerabilities that were exploitable on the LAN side of the router. One of them was also discovered by another participating team and it is fixed in the latest firmware version. We reverse engineered the firmware’s format and also discovered that it is possible to create custom firmware with a valid signature and flash it on the router for persistence. We reported the vulnerabilities to Netgear and followed a 173-day coordinated disclosure process for publication.
在我们参加 Pwn2Own Toronto 2022 比赛期间，我们发现了几个可在路由器的 LAN 端利用的漏洞。其中一个也被另一个参赛团队发现，并在最新的固件版本中修复。我们对固件的格式进行了逆向工程，还发现可以创建具有有效签名的自定义固件，并将其闪存到路由器上以实现持久性。我们向 Netgear 报告了这些漏洞，并遵循了 173 天的协调披露流程进行发布。

Disclosure timeline 披露时间表

• 2023-05-18 Quarkslab sent email to Netgear Technical Support asking for product security contact information explaining that Clause 3 of their Bug Bounty’s terms on Bugcrowd makes it unacceptable to report vulnerabilities using it.
  2023-05-18 Quarkslab 向 Netgear 技术支持发送电子邮件，要求提供产品安全联系信息，并解释说其 Bug 赏金条款第 3 条对 Bugcrowd 的条款不允许使用它报告漏洞。
• 2023-05-18 Netgear opened case #47304021 in their technical support portal.
  2023-05-18 Netgear 在其技术支持门户中开放 case #47304021 。
• 2023-05-19 Netgear technical support asked for purchase invoice and picture of the router.
  2023-05-19 Netgear 技术支持要求提供路由器的购买发票和图片。
• 2023-06-23 Netgear technical support closed the support case due to lack of response.
  2023-06-23 Netgear 技术支持因缺乏响应而关闭了支持案例。
• 2023-07-14 Quarkslab sent the technical report describing the vulns, proof-of-concept program, a picture of the router and a copy of the purchase invoice.
  2023-07-14 夸克斯实验室发送了描述漏洞的技术报告、概念验证程序、路由器图片和购买发票副本。
• 2023-04-14 Netgear opened case #47468661 in their technical support portal.
  2023-04-14 Netgear 在其技术支持门户中开放 case #47468661 。
• 2023-07-17 Netgear informed that it escalated the case to Level 2 Tech support and asked for a phone number and time for a callback within 48 hours.
  2023-07-17 Netgear 通知称，已将案件上报至 2 级技术支持，并要求在 48 小时内提供电话号码和回电时间。
• 2023-07-20 Netgear sent email to Quarkslab’s generic contact email requesting contact information for Quarkslab Vulnerability Reports team.
  2023-07-20 Netgear 向 Quarkslab 的通用联系邮箱发送了一封电子邮件，要求提供 Quarkslab 漏洞报告团队的联系信息。
• 2023-07-20 Quarkslab Vulnerability Reports team sent contact information and said it preferred to communicate over email so a record of the discussion could be kept and all parties (vendor, coordinator, researchers) could remain synchronized and informed. Nonetheless offered to discuss in a conference call if required.
  2023-07-20 夸克斯实验室漏洞报告团队发送了联系信息，并表示更愿意通过电子邮件进行沟通，以便保留讨论记录，所有各方（供应商、协调员、研究人员）可以保持同步和知情。尽管如此，如果需要，还是愿意在电话会议上讨论。
• 2023-07-26 Netgear sent email to Quarkslab’s generic contact email and to a sales representative acknowledging the findings and requesting to work directly with the vulnerability reports team. Asked for an email or phone number to contact it.
  2023-07-26 Netgear 向 Quarkslab 的通用联系邮箱和销售代表发送了电子邮件，确认调查结果并请求直接与漏洞报告团队合作。要求提供电子邮件或电话号码以与之联系。
• 2023-07-26 Quarkslab Vulnerability Reports sent contact information ([email protected]) and asked Netgear to continue further communications using only that email address.
  2023-07-26 Quarkslab 漏洞报告发送了联系信息 （[email protected]），并要求 Netgear 仅使用该电子邮件地址继续进一步沟通。
• 2023-08-01 Quarkslab reminded Netgear that the contact information was provided 5 days ago.
  2023-08-01 夸克斯实验室提醒网件，联系方式是5天前提供的。
• 2023-08-01 Netgear said their engineering team would like direct contact with Quarkslab and asked for a phone number.
  2023-08-01 Netgear 表示，他们的工程团队希望与 Quarkslab 直接联系，并要求提供电话号码。
• 2023-08-02 Quarkslab replied that it did not have a phone number but offered to do a videoconference if necessary.
  2023-08-02 夸克斯实验室回复说，它没有电话号码，但提出在必要时进行视频会议。
• 2023-08-03 Netgear PSIRT confirmed receiving the report and passing it to the engineering team for validation and analysis. Requested a 120-day embargo period.
  2023-08-03 Netgear PSIRT 确认收到报告并将其传递给工程团队进行验证和分析。要求120天的禁运期。
• 2023-08-08 Netgear PSIRT requested an update from Quarkslab.
  2023-08-08 Netgear PSIRT 请求 Quarkslab 更新。
• 2023-08-13 Netgear L2 technical support asked if Quarkslab had received their PSIRT’s email.
  2023-08-13 Netgear L2 技术支持询问 Quarkslab 是否收到了 PSIRT 的电子邮件。
• 2023-08-14 Quarkslab replied to Netgear PSIRT agreeing to a 120-day embargo, counting from the first report date. Publication date was set to November 6, 2023. Noted that its likely other researchers will find the same bugs.
  2023-08-14 Quarkslab 回复 Netgear PSIRT 同意 120 天禁运，从第一次报告日期开始计算。发布日期定为 2023 年 11 月 6 日。注意到其他研究人员可能会发现相同的错误。
• 2023-08-14 Quarkslab notified Netgear L2 tech support that it already replied to the PSIRT team and asked them to stop using Quarkslab’s commercial contact email address for vuln report coordination.
  2023-08-14 Quarkslab 通知 Netgear L2 技术支持，它已经回复了 PSIRT 团队，并要求他们停止使用 Quarkslab 的商业联系电子邮件地址进行漏洞报告协调。
• 2023-08-21 Netgear PSIRT said that since the initial date of the report was July 31st, the disclosure date should be November 28th. Asked Quarkslab to confirm the date.
  2023-08-21 Netgear PSIRT表示，由于报告的初始日期为7月31日，因此披露日期应为11月28日。要求夸克斯实验室确认日期。
• 2023-08-22 Quarkslab replied that the report was sent on July 14, 2023 and the tech support case was opened on the same date, therefore that should be considered the initial date of the report. Also mentioned that a prior support case was opened on May 18th and closed on June 6th because Quarkslab did not provide a picture of the router and copy of the purchase invoice. We reaffirmed November 6, 2023 as final day for coordinating disclosure.
  2023-08-22 夸克实验室回复称，该报告于2023年7月14日发送，技术支持案例于同日开庭，因此应视为报告的初始日期。还提到，由于夸克斯实验室没有提供路由器的图片和购买发票的副本，因此之前的支持案例于 5 月 18 日打开，并于 6 月 6 日关闭。我们重申 2023 年 11 月 6 日是协调披露的最后一天。
• 2023-08-22 Netgear L2 tech support asked if it could close the support case.
  2023-08-22 Netgear L2 技术支持询问是否可以关闭支持案例。
• 2023-08-23 Netgear PSIRT agreed to the proposed disclosure date of November 6, 2023.
  2023-08-23 Netgear PSIRT 同意将拟议的披露日期定为 2023 年 11 月 6 日。
• 2023-08-24 Quarkslab told Netgear L2 tech support that it would prefer to keep the case opened until the bugs are fixed. Asked again to remove Quarkslab’s generic contact email address from the case.
  2023-08-24 Quarkslab 告诉 Netgear L2 技术支持，它更愿意保持案件开放，直到错误得到修复。再次要求从案例中删除 Quarkslab 的通用联系电子邮件地址。
• 2023-09-27 Netgear L2 tech support closed the case.
  2023-09-27 Netgear L2 技术支持结案。
• 2023-11-07 This blog post is published.
  2023-11-07 这篇博文发表。

原文始发于Eloïse BrocasDamien CauquilRobin DavidBenoît Forgette：Our Pwn2Own journey against time and randomness (part 2)