There are systems that ordinary mortals do not have access to by default. And the developers of such systems naively believe that they are protected from penetration and the watchful eyes of researchers.
Take ATMs, for example. It is not uncommon for unknown persons to approach the ATM, connect a laptop, take the money and leave without leaving any logs in the system. And recent stories with "cutlets" (malware called Cutlet Maker) even more confirm that there are no invulnerable systems - there are under-explored ones.
The beginning of the study
There is an opinion that the only way to steal money from an ATM is to come by a dump truck, hook up to the ATM and rip it out with giblets, and then use a grinder, crowbar and gas welding machine. But there is also another method.
After a short search on Ebay, I found an NCR USB S1 Dispenser with firmware on my desk. The goals were:
find a bypass of the encryption of commands that the computer sends via USB to the dispenser itself, in particular, to dispense banknotes;
learn how to bypass the need for physical access to the safe for authentication (tampering with the cassette) to generate encryption keys for the commands from the previous paragraph.
Firmware
Firmware is an ELF file for an NXP ColdFire processor (Motorola 68040, my favorite processor) running VxWorks v5.5.1.
There are two main sections of interest in an ELF file - .text and .data:
One of them contains a code that runs all the time (let's call it the main firmware) when the dispenser is connected to the system unit at the top of the ATM.
The second contains the bootloader code packed with zlib (its local name is USB Secure Bootloader), which is responsible for uploading the firmware and running the main code.
And the best part is that there are uncut characters in the file - take it and look for something interesting.
The internal structure of the main firmware
If you divide the code into main components, you get the following scheme (in order of subordination):
1. A thread that receives USB packets and distributes them among services.
2. Services are the main executing units, each of them has its own role and each has its own tasks (classes).
3. Classes - here these are tasks that can be performed by a particular service using controllers.
4. Controllers - actually "workers" (workers) who are engaged in the validation of the tasks sent to them, their implementation, as well as the formation of response packets.
Since there is a lot of code in the firmware, it was decided to start by searching for all possible services, and then look at where tasks are transferred.
As a result, the following services were found that just should do what I'm looking for:
1) DispTranService (Dispenser Transaction Service) : working with encrypted commands, generating banknotes, authentication. We can say that the most interesting thing is here.
2) securityService : after authentication on the side of the dispenser, a session key is generated, which is sent to it in encrypted form at the request of the computer. This key will encrypt all important commands - issuing, forming a bundle of banknotes
Subsequently, another service caught my eye: UsbDownloadService. Its task is when the dispenser is connected to the computer and the version of the dispenser firmware does not match the one stored on the ATM computer, go to the bootloader in order to upload the firmware with which the OS should work (located in the folder with the vendor's software on the computer). This service also knows how to give information about the firmware version.
Physical authentication
Physical authentication is implemented at the highest level and protects ATM from simply sending USB commands to issue without authorization. In this case, it consists in the fact that only when the safe with money is open, one of the following actions must be performed:
remove and insert the lower cassette,
toggle the toggle switch on the back of the dispenser stand.
But all this is required only if the access level is set to the maximum, that is, physical. There are three of them: USB (0), logical (1) and physical (2). The other two are used by service providers and developers to debug and test the firmware. Well, the physical one is highly recommended by the vendor to be used by default.
Vulnerability The
following is a critical vulnerability (already fixed by the vendor at the time of publication of the article), which allowed, if there was access to the service area, but without access to the safe (for example, through a hole made in the ATM front panel), to execute any dispenser commands, including cash dispensing.
As it turned out, UsbDownloadService accepts commands that do not require encryption. Sounds tempting. But suddenly everything is further protected, and the nameWill Secure Bootloader Pay Off? Will not justify!
We need to go deeper
As already mentioned, the .data section contains the packed bootloader code, which for a long time did not arouse my interest, and my colleagues, when examining the firmware, did not pay attention to it.
While the presence of the bootloader was a mystery, the question remained open: how does the software on the computer fill the firmware? After all, nothing of the kind was found in the main firmware.
So, bootloader is unpacked, loaded into IDA at offset 0x100000 - now you can investigate ... Only no symbols!
It doesn't matter: comparing the main firmware with the bootloader code, reading the datasheetcontroller - and a certain picture begins to emerge.
It turned out that the firmware upload, although it looks secure, is not really such. All you need to know is how to fill it correctly.
Quite a lot of effort and time has been spent to fully understand this process (you can learn more about this in the talk "Blackbox is dead — Long live Blackbox!" At the Black Hat 2018 conference in Las Vegas). What is the cost of soldering the NVRAM memory, pouring a backup into it in order to "sprinkle" the entire controller ... Thanks to colleague Alexei for his patience!
As a result, we got the following algorithm for pouring the firmware into the dispenser:
1) Generate a pair of RSA keys and pour the public key into the controller.
2) Write sequentially the sections .data and .text from ELF at their physical addresses from the section headers.
3) Calculate SHA-1 from the recorded data, encrypt the hash with a private key, send to the controller
4) Calculate and send the sum of all written firmware words.
After that, if everything is calculated and written successfully, the main firmware will be loaded.
It turned out that when writing the firmware, there is only one limitation: the firmware version must be at least the current one. But no one is stopping us from changing the firmware version in its data itself.
As a result, my special firmware with antisecurity fixes was uploaded and successfully launched!
By this time, the code of the main firmware was well studied, commands for issuing banknotes were found. They can now be sent unencrypted and the dispenser will happily fulfill them.
Issuance
After everything experienced during the research (for example, a "bricked-up" real ATM), the result was so pleasant and compensating for the efforts that the algorithm wanted to be repeated with another large vendor.
The most real ATM started to hum and willingly shared fresh crisp banknotes with us (in this case, vendor wrappers). No magic was used: just a laptop, a brain, and a USB cable.
conclusions
Once again, we have made sure that it is impossible to ensure adequate protection based on the principle of security through obscurity. The fact that the code or firmware is proprietary does not mean at all that an attacker will not gain access to it and will not take advantage of the vulnerabilities found. Everything necessary for the realization of selfish goals can be acquired with a certain amount of money.
Developers have to deal with code, and security guards have to protect it. That is why the most productive approach seems to be cooperation with information security companies with sufficient experience in ensuring the security of various systems that will help build adequate protection in each case.
PS The vendor confirmed the vulnerability (the flaw was also found in another model - S2), which was announced as fixed in the February 2018 fix.
CVE list:
CVE-2017-17668 (NCR S1 Dispenser) https://cve.mitre.org/cgi-bin/cvenam...CVE-2017-17668
CVE-2018-5717 (NCR S2 Dispenser) https: // cve.mitre.org/cgi-bin/cvenam...=CVE-2018-5717
Take ATMs, for example. It is not uncommon for unknown persons to approach the ATM, connect a laptop, take the money and leave without leaving any logs in the system. And recent stories with "cutlets" (malware called Cutlet Maker) even more confirm that there are no invulnerable systems - there are under-explored ones.
The beginning of the study
There is an opinion that the only way to steal money from an ATM is to come by a dump truck, hook up to the ATM and rip it out with giblets, and then use a grinder, crowbar and gas welding machine. But there is also another method.
After a short search on Ebay, I found an NCR USB S1 Dispenser with firmware on my desk. The goals were:
find a bypass of the encryption of commands that the computer sends via USB to the dispenser itself, in particular, to dispense banknotes;
learn how to bypass the need for physical access to the safe for authentication (tampering with the cassette) to generate encryption keys for the commands from the previous paragraph.
Firmware
Firmware is an ELF file for an NXP ColdFire processor (Motorola 68040, my favorite processor) running VxWorks v5.5.1.
There are two main sections of interest in an ELF file - .text and .data:
One of them contains a code that runs all the time (let's call it the main firmware) when the dispenser is connected to the system unit at the top of the ATM.
The second contains the bootloader code packed with zlib (its local name is USB Secure Bootloader), which is responsible for uploading the firmware and running the main code.
And the best part is that there are uncut characters in the file - take it and look for something interesting.
The internal structure of the main firmware
If you divide the code into main components, you get the following scheme (in order of subordination):
1. A thread that receives USB packets and distributes them among services.
2. Services are the main executing units, each of them has its own role and each has its own tasks (classes).
3. Classes - here these are tasks that can be performed by a particular service using controllers.
4. Controllers - actually "workers" (workers) who are engaged in the validation of the tasks sent to them, their implementation, as well as the formation of response packets.
Since there is a lot of code in the firmware, it was decided to start by searching for all possible services, and then look at where tasks are transferred.
As a result, the following services were found that just should do what I'm looking for:
1) DispTranService (Dispenser Transaction Service) : working with encrypted commands, generating banknotes, authentication. We can say that the most interesting thing is here.
2) securityService : after authentication on the side of the dispenser, a session key is generated, which is sent to it in encrypted form at the request of the computer. This key will encrypt all important commands - issuing, forming a bundle of banknotes
Subsequently, another service caught my eye: UsbDownloadService. Its task is when the dispenser is connected to the computer and the version of the dispenser firmware does not match the one stored on the ATM computer, go to the bootloader in order to upload the firmware with which the OS should work (located in the folder with the vendor's software on the computer). This service also knows how to give information about the firmware version.
Physical authentication
Physical authentication is implemented at the highest level and protects ATM from simply sending USB commands to issue without authorization. In this case, it consists in the fact that only when the safe with money is open, one of the following actions must be performed:
remove and insert the lower cassette,
toggle the toggle switch on the back of the dispenser stand.
But all this is required only if the access level is set to the maximum, that is, physical. There are three of them: USB (0), logical (1) and physical (2). The other two are used by service providers and developers to debug and test the firmware. Well, the physical one is highly recommended by the vendor to be used by default.
Vulnerability The
following is a critical vulnerability (already fixed by the vendor at the time of publication of the article), which allowed, if there was access to the service area, but without access to the safe (for example, through a hole made in the ATM front panel), to execute any dispenser commands, including cash dispensing.
As it turned out, UsbDownloadService accepts commands that do not require encryption. Sounds tempting. But suddenly everything is further protected, and the nameWill Secure Bootloader Pay Off? Will not justify!
We need to go deeper
As already mentioned, the .data section contains the packed bootloader code, which for a long time did not arouse my interest, and my colleagues, when examining the firmware, did not pay attention to it.
While the presence of the bootloader was a mystery, the question remained open: how does the software on the computer fill the firmware? After all, nothing of the kind was found in the main firmware.
So, bootloader is unpacked, loaded into IDA at offset 0x100000 - now you can investigate ... Only no symbols!
It doesn't matter: comparing the main firmware with the bootloader code, reading the datasheetcontroller - and a certain picture begins to emerge.
It turned out that the firmware upload, although it looks secure, is not really such. All you need to know is how to fill it correctly.
Quite a lot of effort and time has been spent to fully understand this process (you can learn more about this in the talk "Blackbox is dead — Long live Blackbox!" At the Black Hat 2018 conference in Las Vegas). What is the cost of soldering the NVRAM memory, pouring a backup into it in order to "sprinkle" the entire controller ... Thanks to colleague Alexei for his patience!
As a result, we got the following algorithm for pouring the firmware into the dispenser:
1) Generate a pair of RSA keys and pour the public key into the controller.
2) Write sequentially the sections .data and .text from ELF at their physical addresses from the section headers.
3) Calculate SHA-1 from the recorded data, encrypt the hash with a private key, send to the controller
4) Calculate and send the sum of all written firmware words.
After that, if everything is calculated and written successfully, the main firmware will be loaded.
It turned out that when writing the firmware, there is only one limitation: the firmware version must be at least the current one. But no one is stopping us from changing the firmware version in its data itself.
As a result, my special firmware with antisecurity fixes was uploaded and successfully launched!
By this time, the code of the main firmware was well studied, commands for issuing banknotes were found. They can now be sent unencrypted and the dispenser will happily fulfill them.
Issuance
After everything experienced during the research (for example, a "bricked-up" real ATM), the result was so pleasant and compensating for the efforts that the algorithm wanted to be repeated with another large vendor.
The most real ATM started to hum and willingly shared fresh crisp banknotes with us (in this case, vendor wrappers). No magic was used: just a laptop, a brain, and a USB cable.
conclusions
Once again, we have made sure that it is impossible to ensure adequate protection based on the principle of security through obscurity. The fact that the code or firmware is proprietary does not mean at all that an attacker will not gain access to it and will not take advantage of the vulnerabilities found. Everything necessary for the realization of selfish goals can be acquired with a certain amount of money.
Developers have to deal with code, and security guards have to protect it. That is why the most productive approach seems to be cooperation with information security companies with sufficient experience in ensuring the security of various systems that will help build adequate protection in each case.
PS The vendor confirmed the vulnerability (the flaw was also found in another model - S2), which was announced as fixed in the February 2018 fix.
CVE list:
CVE-2017-17668 (NCR S1 Dispenser) https://cve.mitre.org/cgi-bin/cvenam...CVE-2017-17668
CVE-2018-5717 (NCR S2 Dispenser) https: // cve.mitre.org/cgi-bin/cvenam...=CVE-2018-5717
