Warcodes II - The Desko Case

工控安全 1周前 admin

51 0 0

Six months ago we published a blog post describing ‘Warcodes’ a novel attack vector against industrial barcode readers. It included the following warning in the conclusion:
六个月前，我们发表了一篇博客文章，描述了“Warcode”是一种针对工业条形码阅读器的新型攻击媒介。它在结论中包括以下警告：

“Also, according to IOActive’s experience, it is likely that similar issues affect other barcode manufacturers.”
“此外，根据IOActive的经验，类似的问题可能会影响其他条形码制造商。

The same warning still applies at the time of writing this post, so I am afraid that we will have a 'Warcodes III' sooner rather than later.
在撰写本文时，同样的警告仍然适用，因此恐怕我们迟早会有一个“战争代码III”。

Also, I would like to clarify that, as opposed to previously published research on barcode readers, we are directly attacking the barcode reader device. This basically means that for our attacks to work we do not take the user terminal (a PC or any other device) connected to the target barcode reader into account.
另外，我想澄清一下，与以前发表的关于条形码阅读器的研究相反，我们正在直接攻击条形码阅读器设备。这基本上意味着，为了使我们的攻击起作用，我们不考虑连接到目标条形码阅读器的用户终端（PC或任何其他设备）。

In the previous blog post, we focused on industrial barcode readers used in the baggage handling systems deployed at a significant number of international airports. The context in this case does not change very much from the previous one, we are still analyzing threats to smart airports by looking for potential security risks in the devices that comprise the most critical systems within modern airport facilities. To identify those systems, we again used the ranking that appeared in this ENISA paper on securing smart airports.
在之前的博客文章中，我们重点介绍了大量国际机场部署的行李处理系统中使用的工业条形码阅读器。在这种情况下，上下文与上一个没有太大变化，我们仍在分析对智能机场的威胁，方法是在构成现代机场设施中最关键系统的设备中寻找潜在的安全风险。为了识别这些系统，我们再次使用了ENISA关于保护智能机场的论文中出现的排名。

This time we targeted boarding gate readers used as part of the passenger boarding and flow control.
这次我们针对的是用作乘客登机和流量控制一部分的登机口读卡器。

DESKO 德斯科

Please note that after 3 months DESKO stopped responding to our requests so unfortunately we are not aware of any workaround.
请注意，3 个月后，DESKO 停止响应我们的请求，因此很遗憾，我们不知道有任何解决方法。

DESKO products are found in most international airports around the world. For instance, while going through a security checkpoint you may have noticed that the TSA uses DESKO’s PENTA Scanner®.
DESKO 产品遍布全球大多数国际机场。例如，在通过安检时，您可能已经注意到 TSA 使用 DESKO 的 PENTA 扫描仪®。

Unfortunately, I couldn’t find one of those devices publicly available so if anyone out there is willing to help me access a PENTA Scanner, just ping me.
不幸的是，我找不到公开可用的设备之一，所以如果有人愿意帮助我访问 PENTA 扫描仪，只需 ping 我。

However, I managed to buy a couple of BCR/BGR 504 pro devices, which are pretty common at boarding gates and security checkpoints at international airports such as Munich (Germany), San Francisco (US), Heathrow (UK) or Mumbai (IN).
但是，我设法购买了几台BCR / BGR 504 pro设备，这些设备在慕尼黑（德国），旧金山（美国），希思罗机场（英国）或孟买（IN）等国际机场的登机口和安全检查站很常见。

BGR 504 at Mumbai Airport (India) -
孟买机场 BGR 504 （印度） -Image from https:// 图片来自 https://livefromalounge.com livefromalounge.com

BGR 504 at Munich Airport (Germany)
慕尼黑机场的BGR 504（德国）

Hardware Analysis 硬件分析

At first glance, it is obvious that the BGR 504 pro is a much more complex device than the BCR 504 pro; however, they both use the same imaging engine, an OEM barcode reading engine manufactured by Honeywell: the N56xx family.
乍一看，很明显 BGR 504 pro 是一款比 BCR 504 Pro 复杂得多的设备;但是，它们都使用相同的成像引擎，即霍尼韦尔制造的OEM条形码读取引擎：N56xx系列。

According to the FCCID documents, the Desko Penta Scanner Cube seems to be using the same n56XX module.
根据FCCID文件，Desko Penta扫描仪立方体似乎使用相同的n56XX模块。

So let’s see what we can learn from the manual.
因此，让我们看看我们可以从手册中学到什么。

According to the document we can “create and print programming bar codes” pretty much the same way as in the SICK scenario, so the EZConfig-Scanning software is certainly an interesting target to dig deeper into and explore all those functionalities.
根据该文档，我们可以像在 SICK 场景中一样“创建和打印编程条形码”，因此 EZConfig-Scan 软件无疑是深入研究和探索所有这些功能的有趣目标。

Ok, there we go. This basically confirms that we can control the N5600 via custom programming barcodes, but there are some security settings that may prevent this from working. Unfortunately, those security settings are not publicly available, so it seems like reverse engineering is, once again, the only path we can take to satisfy our curiosity.
好的，我们开始了。这基本上证实了我们可以通过自定义编程条形码控制 N5600，但有一些安全设置可能会阻止它工作。不幸的是，这些安全设置不是公开可用的，所以逆向工程似乎是我们再次可以采取的唯一途径来满足我们的好奇心。

The N56xx module is basically comprised of a camera module and logic board.
N56xx模块基本上由摄像头模块和逻辑板组成。

The MCU of the logic board is an i.MX257
逻辑板的MCU是i.MX257

We have already seen that it is possible to configure the module with custom settings, but it is also possible to develop custom plugins for this module using the TotalFreedom SDK. There is even a marketplace for commercial plugins. Taking this into account, the Winbond SPI flash memory may hold interesting data; hopefully, the firmware as well.
我们已经看到可以使用自定义设置配置模块，但也可以使用 TotalFreedom SDK 为该模块开发自定义插件。甚至还有一个商业插件市场。考虑到这一点，华邦SPI闪存可能会保存有趣的数据;希望固件也是如此。

So instead of dumping the memory, I just sniffed the SPI bus during a regular boot using a SALEAE logic analyzer.
因此，我没有转储内存，而是在常规启动期间使用 SALEAE 逻辑分析仪嗅探 SPI 总线。

It was possible to grab the firmware from the captured data. I directly exported the CSV data from the SALEAE session and wrote the following program to extract the contents.
可以从捕获的数据中获取固件。我直接从 SALEAE 会话导出 CSV 数据，并编写了以下程序来提取内容。

Firmware analysis 固件分析

Right after the highlighted header, we find the code for a loader that decompresses the main application.
在突出显示的标题之后，我们找到解压缩主应用程序的加载器的代码。

After the loader comes the application header, and then finally, the compressed application.
加载程序之后是应用程序标头，最后是压缩的应用程序。

Honestly, I didn’t spend too much time trying to understand the decompression algorithm; it looks like some kind of RLE, but I moved directly to emulating it using the Unicorn engine. There are just few requirements we need to comply with in order to emulate this function:
老实说，我没有花太多时间试图理解解压缩算法;它看起来像某种RLE，但我直接使用独角兽引擎模拟它。为了模拟这个函数，我们只需要遵守几个要求：

We need to understand the context where the decompression function is executed and replicate it within our Unicorn-based emulator program. We need to set the context of the function as if we were the loader. The function is expecting four parameters:
我们需要了解执行解压缩函数的上下文，并在基于 Unicorn 的仿真器程序中复制它。我们需要设置函数的上下文，就好像我们是加载器一样。该函数需要四个参数：
- R0 - Source (compressed data)
  R0 - 源（压缩数据）
- R1 - Length (compressed length)
  R1 - 长度（压缩长度）
- R2 - Destination R2 - 目的地
- R3 - Flag
  R3 - 标志

We need to save the code for the ‘decompress’ function (732 bytes)
我们需要保存“解压缩”功能的代码（732 字节）
In the Unicorn engine program, we have to create the memory mappings, load the code to be emulated (decompress.bin), and set the registers accordingly, before invoking the function to be emulated. C source code available here.
在 Unicorn 引擎程序中，我们必须创建内存映射，加载要模拟的代码（解压缩.bin），并相应地设置寄存器，然后再调用要模拟的函数。此处提供 C 源代码。

Back to those ‘confidential’ security settings, firmware analysis revealed the logic behind them.
回到那些“机密”安全设置，固件分析揭示了它们背后的逻辑。

The ‘MNUENA’ command is used to decide whether or not the N56xx module will accept programming barcodes. Basically, executing MNUENA0 disables menu commands through programming barcodes and executing MNUENA1 forces the device to start accepting them again.
“MNUENA”命令用于确定 N56xx 模块是否接受编程条形码。基本上，执行MNUENA0通过编程条形码来禁用菜单命令，并执行MNUENA1强制设备再次开始接受它们。

However, it appears that someone considered that once you deploy one of these modules, it is not a good idea to let just anyone send menu commands through programming barcodes. By reverse engineering the firmware, I noticed that Honeywell implemented a single security boundary: a ‘PASSWORD’ field in the working config. It can be configured through 'PASWRD' command in order to require a password when attempting to enable menu commands with 'MNUENA1'.
但是，似乎有人认为，一旦您部署了这些模块之一，让任何人通过编程条形码发送菜单命令并不是一个好主意。通过对固件进行逆向工程，我注意到霍尼韦尔实现了单一的安全边界：工作配置中的“密码”字段。它可以通过“PASWRD”命令进行配置，以便在尝试启用带有“MNUENA1”的菜单命令时需要密码。

‘validatePassword’ checks whether the password entered via the programming barcode is the same as the one that was configured, and ‘check_password’ checks whether the format of the password is acceptable when it is set.
“validatePassword”检查通过编程条形码输入的密码是否与配置的密码相同，“check_password”检查设置密码时密码格式是否可接受。

Obviously, this approach may have a significant caveat: when configured, the value of that 'PASWRD' will probably be the same for all N56xx modules. Therefore, if you have physical access to one, for instance, by buying a decommissioned device (like I did), it is possible to access the password.
显然，这种方法可能有一个重要的警告：配置时，所有N56xx模块的“PASWRD”值可能相同。因此，如果您可以物理访问一个，例如，通过购买退役的设备（就像我一样），则可以访问密码。

A further analysis revealed that you do not even need physical access to dump flash memory, as I also found undocumented commands that can be sent through specially crafted USB (or Serial when Desko VCOM is installed) requests. Their names are pretty self-explanatory but are summed up as follows:
进一步的分析表明，您甚至不需要物理访问转储闪存，因为我还发现了可以通过特制 USB（或安装 Desko VCOM 时的串行）请求发送的未记录命令。他们的名字不言自明，但总结如下：

• DUMPMEMORY: Allows dumping arbitrary chunks of memory
•转储内存：允许转储任意内存块

• PEEK: Allows reading memory contents from arbitrary addresses
•PEEK：允许从任意地址读取内存内容

• POKE: Allows writing attacker-controlled values to arbitrary addresses
•POKE：允许将攻击者控制的值写入任意地址

You can use the following PoC to communicate with a N56xx module and send the aforementioned commands via USB.
您可以使用以下 PoC 与 N56xx 模块通信，并通过 USB 发送上述命令。

In the DESKO case, the 'PASWRD' field has not been configured, so anyone presenting the following barcode to the device will enable menu commands through programming barcodes, allowing them to disrupt the normal functioning of the device.
在 DESKO 案例中，“PASWRD”字段尚未配置，因此任何向设备出示以下条形码的人都将通过编程条形码启用菜单命令，从而破坏设备的正常运行。

Conclusion 结论

The attack vector described in this blog post can be exploited in various ways across multiple industries, as the Honeywell N56xx family is an OEM device that is actively deployed in different sectors. These issues can be leveraged to backdoor and take control of these devices.
这篇博文中描述的攻击媒介可以在多个行业中以各种方式被利用，因为霍尼韦尔 N56xx 系列是在不同领域积极部署的 OEM 设备。可以利用这些问题来后门并控制这些设备。

We recommend all barcode reader manufacturers take a proactive approach and assess the security posture of their products against this type of attack, as the trend we are observing is worrisome.
我们建议所有条形码阅读器制造商采取积极主动的方法，并评估其产品针对此类攻击的安全状况，因为我们观察到的趋势令人担忧。

Disclosure Timeline 披露时间表

Following a responsible disclosure policy, IOActive notified DESKO about these issues. After approximately three months of telling us they were actively working to resolve the issues, DESKO stopped responding to our requests.
根据负责任的披露政策，IOActive 将这些问题通知了 DESKO。在告诉我们他们正在积极努力解决问题大约三个月后，DESKO 停止响应我们的请求。

2020-08-12 - Initial contact through DESKO’s web support form.
2020-08-12 - 通过 DESKO 的网络支持表进行初步联系。
2020-08-12 - Automatic reply from DESKO.
2020-08-12 - 来自 DESKO 的自动回复。
2020-08-17 - DESKO support staff asks for additional information about the issue.
2020-08-17 - DESKO 支持人员要求提供有关该问题的更多信息。
2020-08-19 - IOActive shares the initial advisory describing the issue with DESKO.
2020-08-19 - IOActive 与 DESKO 分享了描述该问题的初步公告。
2020-08-20 - DESKO support staff acknowledge the report and mention they will share it with their Research & Development team.
2020-08-20 - DESKO 支持人员确认该报告，并提到他们将与研发团队分享该报告。
2020-09-23 - DESKO states they are in contact with the N5600 manufacturer in order to address the issue.
2020-09-23 - DESKO 表示，他们正在与 N5600 制造商联系以解决此问题。
2020-10-26 - IOActive asks for a status update; no response
2020-10-26 - IOActive要求更新状态;无响应
2020-11-23 - IOActive asks whether DESKO has any plans to share a statement about this security issue; no response.
2020-11-23 - IOActive 询问 DESKO 是否有计划分享有关此安全问题的声明;没有回应。