About the recent vulnerability in Diebold Nixdorf ATMs

[Tomcat]

Disclaimer: This article is published for informational purposes only and in no way constitutes a guide to action. The vulnerabilities described in the material were discovered by the author of the article as part of a project agreed upon with the ATM manufacturer. They have now been corrected by Diebold Nixdorf , which has been notified by Positive Technologies in accordance with the principles of responsible disclosure. As an additional security factor, the vendor was recommended to enable physical authentication for the operator during firmware installation. This allows you to make sure that changes to the ATM are made by an employee and not by attackers.

Greetings! The other day, Positive Technologies published news that ATMs from the manufacturer Diebold Nixdorf (formerly Wincor), or rather the dispenser models RM3and CMDv5, contain a vulnerability that allows you to issue cash and upload modified (vulnerable) firmware. And since my former colleague Alexey Stennikov and I are directly involved in finding this vulnerability, I would like to share some of its details.

On October 29, I will speak at the Hardwear.io conference dedicated to the security of hardware solutions, where I will talk about the vulnerability found in detail.

Introduction​

Firstly, it’s worth briefly talking about what an ATM is, how it works and who dispensers are . In general, an ATM is a rather complex structure, which consists of two main parts: upper and lower.

The photo shows NCR, but this does not change the essence

The top part is a regular PC, which most often lies flat in this part. A huge number of USB devices are stuck into it: cameras, printers, card readers and... that same dispenser that is located at the bottom. It is this PC from the upper part (which, by the way, is considered unsafe) that is the main target for malware developers. But we are not like that, HPE is bad! Therefore, we go down the USB cable to the lower part of the ATM, where...

Safe zone (aka safe, dispenser) is a safe and obviously secure part of the ATM. It is locked with a key, which only collectors have, is not made of plastic (unlike the upper part) and is often reinforced with concrete or mounted into the wall. It is in the safe that there is something for which ATMs are broken into - banknotes. They are arranged in cassettes with the required denominations, each of which is also locked. Money is taken out of the cassettes by a belt system (and in NCR, for example, by suction cups), travels along a conveyor to the “shutter” ( shutter ), and is then removed by the user.

So, this whole complex structure of sensors (you need to determine the thickness, quantity, wrinkling of banknotes), conveyors, “curtains” and cassettes is controlled by the dispenser control board (hereinafter referred to as simply the dispenser). The board contains a processor, memory and other attributes of an independent device, as well as the code that controls everything. And this is where we just went down the USB cord.

Why do they hack a dispenser instead of a PC and what does blackbox have to do with it?​

Actually, that's a good question. If you look at it from the attacker’s perspective (but it’s better not to look at it), then disconnecting one USB device (dispenser) from the ATM computer will appear only as a line in the latter’s logs, and the logs of the dispenser itself will not contain any meaningful information (if compared with the attacker’s commands launched from the console ).

In addition, at one time dispensers were often subject to blackbox -type attacks , in which, having once captured USB/ COM-cash dispensing traffic on one device, an unknown person could approach another with it, repeat it and receive money. Now, it’s unlikely that anyone will be able to pull this off, because anti-blackbox techniques are widely used: for example, session rolling keys for encrypting USB traffic and the use of cryptography at almost every stage. Now only the ATM computer can work with this encryption, so an attacker most often cannot interfere with traffic.

But then this article, as well as the mentioned news, would not exist. There was one small gap in our project (fortunately, it is no longer there). And more about her below.

What's the vulnerability, brother?​

Before we begin, I'll briefly outline what exactly the vulnerability is and then get into the details.

First of all, it is worth saying that the firmware is encrypted with keys that are known only to the developer. The vulnerabilities described by Positive Technologies (one per device) are that an attacker can download firmware to the dispenser without knowing these same encryption keys (they will appear later in the article in the form KEY0and KEY1). That is, having a clean code, he can modify it as he wants, encrypt it back and load it into the ATM, and then issue it, bypassing the existing encryption algorithms for USB traffic. Well, now to the details...

End of 2017, start of the project​

As part of a project in one bank, Alexey and I received two files: one had an extension BTR( bootloader ), the second - FRM( firmware ). The files had clear titles, but completely incomprehensible content. We tried this way and that to decipher the contents (it became obvious that it was encrypted), but to no avail. The project could have ended there, and the files actually sat on the hard drive for several months, until the wise Alexey decided to look for the dispenser board on eBay . The payment, as you might have guessed, was found there, and after some time it ended up on Alexey’s desk.

Without a controller it’s bad, with a controller it’s good​

After some manipulations with the dialing, the connector was successfully found JTAG, which was located right next to the main processor. In addition to the main one, there were two more processors on the board, the purpose of which was not very clear to us: CollectorBooterand DispenseBooter. However, the memory of all three processors was dumped for further analysis.

Well, they dumped and dumped, so much for muttering, but what next? We decided that it was worth approaching from the side of the firmware being uploaded, the encrypted files of which, I remind you, we had. And although there were dumps, it was still more pleasant to work with the firmware in its pure form.

Software from the vendor​

Often, either for diagnostic purposes or for working with an ATM, manufacturers write specialized programs that can be used to perform both common tasks for an ATM, as well as some undocumented ones that are rarely used. For example, updating the dispenser firmware. Such software was also available in our case. And it was written not in some BASIC or plus, but in a normal language (respected by any reverse engineer) Java. If you want, decompile, if you want, rebuild.

After a short time of digging through the JAR-files, a function was discovered that downloads firmware files to the controller. Unfortunately, it did not decrypt the files, but it gave us a convenient opportunity to debug this process. Having connected to the software debugger JTAGand started uploading the firmware, we were somehow able to find the place responsible for decryption. Let's talk about her.

Encryption of firmware files​

The encryption algorithm was a regular one XTEA, but with an unusual delta: 0xF27716BA. How it was generated, whether it is safe, we don’t know. But one thing is for sure: she doesn’t Google.

The following input data was used as the encryption key XTEA:

• the first five dvords immediately after the firmware name indicated in the header. We named themHeader-Dwords
• KEY0a byte -long foreign key 8, which is still unknown where it came from
• KEY1a byte -long foreign key 16, which we also didn’t know where to get

After a while, we finally found a section of code that reads and KEY0, and KEY1. It turned out that they were located in a special area at offset 0x64000000, the offset in which was hard-set by default. Next, we dumped this area and extracted both foreign keys from there. Having used these keys in a decryptor written in advance on our knees, we received... No, not firmware.

AP32-archives​

Yes exactly APLib. Those who reverse malware at work will probably recognize this name, since this compression algorithm is (was) very often used by malware developers.

There were a lot of archives, and they all followed each other. If you combine the data unpacked from them, you will get full-fledged firmware. It seems like you can be happy. But hey, it's too early. When we tried to change anything in the firmware (for example, a line), subsequent packaging and encryption, the device refused to accept our firmware. This means there was an integrity check somewhere.

Self-signing​

The title of this section speaks for itself. Yes, we found code that verified the signature of the firmware, and what’s funny is that the firmware itself had everything that was required to verify its integrity, namely the public key and the signed data itself.

As a signature verification algorithm, it is used RSAwith an exponent equal to 7, and the bit depth of the key is determined by the size of the public part N. It turns out that if you fit into the offsets at which the signature and public key are recorded, you can set almost any length.

That's what we did. Instead of the original ones 2048( it seems ) the key was successfully inserted onto 512the bit.

Uploading the modified firmware​

Yes, now you can. Here it is worth talking in more detail about what the firmware download process is like. First, let's open the device manager and see what is displayed there during normal operation of the controller:

And this is what the list looks like when the device is updated:

This last device accepts files. And it works according to the protocol DFU( Device Firmware Update ), which one could guess without even having the board itself in hand. The fact is that at the end of each firmware file there is a certain structure that contains the “ UFD ” tag.

First, a DFU_DETACHprotocol command is sent to the device, after which the USB - command is executed UsbCyclePort, which makes available the interface that accepts the firmware. Those who have worked with this protocol will say that it also contains a command DFU_UPLOAD(in this case, unloading), but in our case it was not implemented.

Launching the firmware​

After loading the firmware into the dispenser, it is decrypted, unpacked, the signature in it is checked, after which the firmware is written to flash memory.

Issue?​

Not yet. Before dispensing, it was necessary to figure out how to send commands to the dispenser. After digging through Javathe -code, we managed to find special JAR-files responsible for self-test, that is, for testing the dispenser components. From this code we found out the following:

1. A smart card is involved in the interaction between the ATM computer and the dispenser (it has long been visible on the board)
2. Used TPM( Trusted Platform Module )
3. Used to Keystoragestore session counters (more on this below), certificates and the base key ( Basekey)
4. There are four directions, each of which uses its own session key and counter: PC → Firmware IN/OUT , Firmware → PC IN/OUT

Smart card​

The smart card turned out to be an interesting object for research. I had never dealt with APDU(the protocol used when communicating with smart cards), so I had to study it. After that, Javaa class was found in the software that was responsible for working with a smart card, where I was able to isolate most of APDUthe commands. In addition, they could be found in the firmware code, and then some other commands could be found using references.

Armed with a smart card reader, I selected various commands and their parameters. Unfortunately, I was unable to discover anything particularly secret. Nevertheless, commands were found that allowed you to set your own session counter values (although they could not be set to the values that were used previously).

Session keys (no thanks)​

In fact, this whole scheme with session keys, four directions of communication, TPMand a key store evoked nothing but respect. The scheme is made very competently. An attacker cannot simply inject himself into traffic, repeat a hijacked session, or do anything similar. Therefore, as a reverse engineer, I didn’t really want to delve into this jungle.

As part of the project, we changed the firmware so that it would no longer contact the smart card for session keys, using an array of zeros instead.

All that remains is to do the same in Java-software, so as not to bother writing code from scratch. By the way, here it became clear from the code that an encryption algorithm was used Aes-EAX.

Issue!​

Here I would like to make an important note: all tests were still carried out on the same dispenser controller board that was lying on my desk. And this meant that there was no periphery and, accordingly, there was nowhere to issue banknotes. Therefore, when Alexey and I had complete confidence that the issue would be possible, we went to the vendor’s laboratory, where we carried out the final tests.

During these tests, it turned out that in order to carry out the issuance, we also had to indicate how much cash we had and in which cassettes (make a configuration), and skip setting up devices that were not connected to the laptop (well, the computer has a lot of USB ports , but there are only two in the laptop).

Only after this did a team go to the dispenser with the cassette numbers and the number of banknotes to be removed. The ATM began to hum happily, anticipating sharing cash with fellow researchers, but we never saw any money. We just didn’t know , we forgot that we still needed to open the curtain. Take two - and fresh “ candy wrappers ” (special vendor bills) were in our hands. Hooray!

Conclusions​

The project was damn interesting! During it, we managed to work with new technologies, successfully beep with a speaker installed on the board, and, of course, issue cash. At the time of writing, the vulnerabilities (one per device) have already been fixed by the ATM manufacturer, Diebold Nixdorf. Their identifiers are as follows (identifiers in Miter are on the way ):

• BDU:2021-04967
• BDU:2021-04968

That's probably all. Separately, I would like to note Alexey’s work on the “ hardware ” part of the project and the dispenser board he purchased, which is still on my desk.