This will never happen to us!
I have taken to mountaineering a couple of years ago. I am currently mastering the five-thousanders of the Caucasus; the plan is to climb the seven-thousanders of the Pamirs. Each time before the trip, the members of the crew are debating. Should we take helmets? Or is it just added weight? Should we take ice drills for the safety stations, in case someone falls in a crevasse? But this adds 300g per person. Or we’ll better to stick to the rope team. Appeals to security reasons and references to statistics of accidents are not always convincing. We are sure bad things will never happen to us!
The reason of all this is that the attitude towards the risks that the person hasn’t experienced is not rational. The desire to remain in the comfort zone wins.
Because the market for the tools to protect network endpoints is saturated, the vendors are forced to develop new niches. The POS terminals attracted their attention. The arguments here are usually the security standards and requirements, mainly PCI DSS. There are a lot of articles about how new viruses with catchy names try to get the contents of the clipboard of the payment applications with the purpose to get access to the payment card data.
I often can hear an opinion that in the USA they have cards without microchips, while other countries have all the data encrypted. Who needs protection tools?!
In 2015 Karsten Nohl, a security researcher at Security Research Labs, showed how to exploit a flaw in the data transfer protocol that POS terminals use to transfer payment card data. RT’s video demonstrates how the researchers have gained access to the card data including PIN code, and have even cloned the card. In was an EMV card.
As the researcher claims, exploiting the flaw allows changing the type of the transaction, the size of the payment, as well as faking the transaction by substituting the reply that the transaction has been successfully authorized.
‘Some time ago, the fraudsters used flaws in software. To fix the problems, it was sufficient to download the update. We hack the protocol itself, which means the terminal works in a normal mode but remains vulnerable. As a result, one cannot solve the problem with the help of a patch. One has to reset the whole system,’ Karsten Nohl told Motherboard.
‘Those who are responsible for the security flaws, including banks, admit that the problem exists, but are reluctant to take care of it. They say that no such cases of fraud have been detected as yet. But it is only a matter of time! By doing nothing they only make it worse,’ emphasized Nohl.For details see here.
In-house security engineers have to overcome the doubts of the managers when they try to explain why it is necessary to protect from threats that, so far, have only been described in the articles by the popular industry publications. Being insistent is not encouraged.
The arguments of business executives and more influential IT departments sound more convincing:
- The whole system is barely functional. We could not possibly add antiviruses to cash registers!
- Where have you seen such a thing? Our system is not like this, is it?
- We pay incredible amounts of money for consulting on how to arrange the cash register services and gain some seconds per receipt. Do you want to ruin it all with antiviruses?
The arguments are well-grounded. In the permanent protection mode, modern antiviruses affect the performance of the computer significantly. An antivirus’s task is to intercept the start of each process, check a process according to the signatures, and compare the process activity with the control policy rules. If the antivirus scans the traffic as well, delays are inevitable.
The processes on the cash register computers that are connected to special peripherals are often susceptible to delays in processing the commands from the connected devices. A large number of functional drivers of the COM services makes a device very sensitive to delays as well.
Is it worth installing software protection tools on such a sensitive system?
A system that is properly set up is already protected from possible destructive attacks. It is important to preserve such a configuration during the operation. What is the problem, then?
The problem is that one needs to install new business features and, therefore, new software and updates for the payment applications. On the test bench under laboratory conditions, the engineer does everything properly, according to the instructions created by the same engineer. Out in the field, however, installing the software can be different:
- The engineers deployed the wrong image on some of the devices in the network.
- When trying to fix the conflict, they re-installed the drivers but did not change the UpperFilters value for the COM services. As a consequence, some of the peripherals started working differently.
- The engineers configured the computers as they used to configure them, not as specified in the instructions.
- They tried to fix it according to common sense and to the tips on an ATM forum. The result turned out to be even better than they expected.
It’s working! Everything else is beyond the responsibility of the maintenance engineer. During further maintenance, it is impossible to trace the consequences of such a common practice.
What happens if one installs the protection software with sample settings, from a test bench to a system such as this, is hard to tell.
The manufacturers of the protection tools are going to comment on the article before they even finish reading it. ‘Why do you write about antiviruses for the cash registers? Malware for targeted attacks is custom-built. Analysts would not know about it, and there would be nothing about it in the signature bases. Protection according to black lists does not work here! We need white lists and process integrity control.’
Indeed, the white list technology proved to be efficient, for example, on the ATMs. This isn’t a new technology; years of application have allowed the developers to learn through mistakes and to adapt the technology so that it can be used in a complicated framework of very sophisticated devices.
Different vendors have some failed projects with the white lists as well. I think the reason here is the fallacy that one can achieve the protected state of a network of devices by installing a new sample image each time.
However, the inevitable result of optimization in the operational practices is that software modifications and protection settings will be managed remotely and centrally. And here lies the pitfall. Most of the existing software protection tools that are based on the white lists work according to checksums and certificates of the executable files that are added to the application control rules. If a process parameter matches the rules, the process runs; otherwise, it is blocked.
What happens if we try to replace executable files with the help of an installer or by self-updating while the protection is enabled? The protection tool blocks the attempts to modify the processes under control. The update or new software cannot be installed. What if one disables the protection tool while installing new software? After the protection tool is enabled again, the driver does not allow the processes to run, because their new parameters are not in the rules. The device hangs, and the reboots do not help.
Our experience says that the network of devices has its protection turned off after one or two quarters of use, because the availability of the network has priority over protection.
For such cases of maintaining a network of devices, the good practice is to implement secure software operation. Only trusted installers, for example, those with the digital signature from a trusted publisher, can modify the processes. All modifications that trusted installers make in the processes are automatically added to the process control rules. This means the modification of entries about the checksums and the certificates that correspond to the processes. Because the results of the operation of such installers and modifications in the rules can be monitored centrally, the operation of the software on a network of devices becomes easy to manage, predictable and secure.
A weak point in this technique is the guidance for the engineers performing maintenance out in the field. For example, to change a peripheral device, the engineer needs to install a new driver. If the engineer arrives at the destination with the set of installation packages that differ from those approved by the security service, or with a USB drive that is not in the white list of the approved connected devices, two options are possible. The engineer will go back to the headquarters to get the right software, or he will call a system administrator he is acquainted with and talk him into temporarily switching off the protection on the device remotely. As soon as the engineer leaves, and the administrator turns the protection on, the cash register hangs. It will be very hard to get these two to acknowledge what they did. The hanging of the cash register will be considered the malfunction of the protection. SLA’s provision for mean time to recovery is quite strict; and it takes too much time to analyze the incident with the help of logs of the administrator’s and the engineer’s activities.
Cleverly written articles by expensive PR specialists about new threats to POS terminals; lively publications in the business media that tell about the consequences of a ransomware attack on the neighbors’ network of cash registers; all this will eventually affect people’s opinion about the protection of cash register networks in large retail chains.
Some time ago, protection tools on the ATMs were a rare sight. ‘The network is isolated, and the channels are encoded. This will never happen to us!’ Protection on the ATMs is now a mandatory thing, which encourages the vendors of software protection tools to develop a new market niche. 50% of the projects start only after the incidents…
