Warcodes II - The Desko Case

by Ruben Santamarta

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:

“Also, according to IOActive’s experience, it is likely that similar issues affect other barcode manufacturers.”

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. 

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.

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.  

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.

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®. 

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.

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).

                                            BGR 504 at Mumbai Airport  (India) - Image from https://livefromalounge.com 

                                                    BGR 504 at Munich Airport (Germany)

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.  

                      

According to the FCCID documents, the Desko Penta Scanner Cube  seems to be using the same n56XX module.

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.

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.

The N56xx module is basically comprised of a camera module and logic board.

The MCU of the logic board is an 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. 

So instead of dumping the memory, I just sniffed the SPI bus during a regular boot using a SALEAE logic analyzer.

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.

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:

• 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: 
• R0 - Source (compressed data)
• R1 - Length (compressed length)
• R2 - Destination 
• R3 - Flag 

• We need to save the code for the ‘decompress’ function (732 bytes)
• 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.

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.

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'.

‘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.

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.

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:

• DUMPMEMORY: Allows dumping arbitrary chunks of memory

• PEEK: Allows reading memory contents from arbitrary addresses

• POKE: Allows writing attacker-controlled values to arbitrary addresses

You can use the following PoC to communicate with a N56xx module and send the aforementioned commands via 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.

 

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.

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.

• 2020-08-12 - Initial contact through DESKO’s web support form.
• 2020-08-12 - Automatic reply from DESKO.
• 2020-08-17 - DESKO support staff asks for additional information about the issue.
• 2020-08-19 - IOActive shares the initial advisory describing the issue with DESKO.
• 2020-08-20 - DESKO support staff acknowledge the report and mention they will share it with their Research & Development team.
• 2020-09-23 - DESKO states they are in contact with the N5600 manufacturer in order to address the issue.
• 2020-10-26 - IOActive asks for a status update; no response
• 2020-11-23 - IOActive asks whether DESKO has any plans to share a statement about this security issue; no response.

Please note that after 3 months DESKO stopped responding to our requests so unfortunately we are not aware of any  workaround.