Cybersecurity of ATMs: how to prevent direct dispense?
On the assumption of our practice more than 40 percent of the implemented by our company projects on the software security of automatic teller machines (ATMs) and self-service terminals is post incident. In years 2014–2016 within the Russian Federation’s territory more than 30 incidents occurred, generally the “direct dispense” attacks to ATMs in two scores of banks. A range of banks suffered from repeated series of attacks, the resources for implementing on-line counter measures on the territory-distributed area network were not enough.
Often the fact of incident was revealed a week or more afterwards the attack itself by the economic security service as the lack of denominations in cassettes in the result of regular cash collection. Within such period it is of low success probability to carry out the hot pursuit actions. Predominantly the complainants do not disclose information about incidents, as everybody knows that the reputation risk comes not after the incident but after its disclosure.
Shown degree of readiness of the banks to react on the incidents has influenced the sense of impunity by attack initiators. Gained by the attack initiators funds are being effectively invested in preparation of new actions with relevant methodical and resources support.
Following situation became possible in result of:
- Indifference of services in charge for technical security measures and reaction for incidents at issues of ATMs and self-service terminals network maintenance. Probably it is happening due to fact that in major, more often in large banks, the remote service lines infrastructure is beyond the control area of information security services. This was determined by history in period of rapid remote service lines expansion.
- Usage on devices of not supported and not updated operation system versions and application software, that makes fragile the ATM’s software environment.
Herewith the majority of, more often, large banks had the opportunity to pay enough attention to ATMs software security issues. There are examples of some banks that can be considered as the “best practice” by world standards.
However, among banks that in different time have begun the implementation of special tools of software security there are examples of uncompleted projects. Despite of sufficient project financing and resources availability for deployment and administration, banks were unable to overcome rather widespread stop-factors. “ The devil is in the details”.
The special tools of software security for ATMs were implemented based on the white list technology. Malwares for ATM attacks are custom written and they do not get to the anti-virus analysts, security tools based on black lists for ATM software protection are inefficient.
In device’s software environment launching is allowed for only those processes, that correspond to specific strict rules:
- Correspondence of process checksum to the value set in rules. Process launch with checksum different from the value set in rules is locked up.
- The launch is allowed only for those processes that are placed in relevant directories.
- The launch is allowed only for those processes which digital certificates are set in rules.
At developing of special tools of ATMs security (as for any security means from targeted attacks) following framework is underlain: prohibition of unauthorized changes to the software environment. Thus, some static state of protection and saving of system in last known good state can be ensured in case of any attempts of ravage.
However let’s imagine the real situation of software maintenance of ATM.
Engineer of external software maintenance service in the territories has arrived on task for ATM to install the updates of payment application, or to install new software adding features of new banking product, or to carry out control procedure of ATM maker on compliance with licence policy of payment applications versions usage. The engineer has brought a USB flash drive with installation package, utility software with features allowing to make required alterations to ATM software configuration along.
If the engineer tries to run new software on ATM with operating protection based on white lists, than the results will be predictable as follows:
- Either installer launch will be disabled, as the checksum of this installer is absent in rules;
- Or upon making of changes all subsequent launch attempts of altered executive files will be disabled.
Both of these scenarios are unwanted for maintenance service.
And then the engineer disables the device protection. Makes the alterations to software. And... leaves the ATM. For alteration of control rules (process white lists) it is required certain knowledge of both security tools maintenance and detailed understanding of exactly what alterations were made.
He has made his work, ATM software security issues are beyond his area of responsibility.
It is expected that the bank maintenance service engineer responsible for ATM software maintenance should make changes to the control rules and enable the protection in this case. However, such practice of situational alterations to the settings of security tools requires the high degree of readiness and control for the actions of engineer “in fields”, that is rather resource intensive and difficult implementable.
Already after quarter the significant part of ATMs of the network remains with either disabled protection or disabled after protection been enabled - to take into account the alterations been made turns to be impossible after such a long term. Disaster recovery of ATM operability is rather demanding procedure. And after the situation has repeated once or twice, the decision is made to stop completely the maintenance of security tools. Network access from the business point of view is of higher-priority.
Officially the security tools are deployed. In fact there is no protection. Since the assistance of security tools for maintenance service of remote service line means is not determinant KPI, then the current situation remains so during long period of time. Until the practice of security tools appliance is lost completely.
The practice of banks implemented the mode of ATM network software safe maintenance is notable for availability of coordinating function allowing to ensure action coordination among external maintenance service engineers and own managing services. It can be reached either with availability of implemented practices of work tasks management with through informational support (such banks do not exist in Russia; the practice of the kind was observed only in two banks of Eastern Europe), or appliance of control features for trusted installers usage in the ATM network. Our recommendations:
- The installation package prior to be transferred to external maintenance service is to pass the internal check for compatibility with software environment of device network.
- Check of correct operation of new required and the old current features is to be carried out.
- Check of installation package is to be carried out for existing viruses, critical vulnerabilities of software elements, concordance of assumed deployment process to security policies.
- Upon carrying out of all checks, the installation package is signed with bank’s certificate or, if available, trusted publisher certificate of the installation package is entered to the white list, the rule is distributed by group policies for customer security tool units of the devices.
- Checked installation package is transferred to maintenance service for deployment on devices.
Now while running of such installer the alterations been made will be automatically added to control rules. That ensures the possibility to make only authorized changes into self-service terminals software without necessity to protection disable.
Here I shall elaborate with examples
While developing of “golden image” bank’s engineers have included into the software the installation package of media player for advertisement content on devices. The installation package was downloaded from untrusted source and contained file infector set and backdoors. The infection was found out in several months after “golden image” deployment within the territory-distributed area network.
According to our statistics about 80% of banks use software on the RAdmin devices as the remote administration tool. The features themselves and available privileges of the given administration tool are security breach without implementing of additional control tools (limitations of system privileges for supporting processes, limitations of start-up scripts, limitation of process network activity etc.) Herewith the customer’s part of given administration tool is distributed with scripts usage containing unenciphered password and ports, and it is impossible to delete this part from file system after deployment.
This became possible owing to absence of internal control after software maintenance of self-service terminals.
In our experience the implementation of such control practice after alterations into the software can be easily carried out. Already in several weeks the quantity of situations when external maintenance service engineer is unable to carry out work task due to absence of confirmed by bank installation package version will be equal to zero. It is important timely to emphasize that it is bank who settles the ATM software maintenance issues.
As the example of consequences in case of such position lack by bank I shall share following observation.
In four operator banks of NCR automatic teller machines the utilities NIRCMD.exe and PSKILL.exe are included into the ATM software. Herewith these files are determined by virus scanners as virus samples. The file analysis has shown:
- NIRCMD.exe 1.85 version is dated 2006. The NIRSOFT company has not confirmed the authority of this file version. All current versions of NIRCMD.exe on the maker’s web-site (current version is dated 2017) are not determined by virus scanners as threats
- Version of PSKILL.exe is dated end of 2006 and has not got the publisher’s certificate. All versions of PSKILL.exe beginning with mid of 2006 have got the Microsoft Root Certificate and are not determined by virus scanners as threats.
With account of possibilities of these utilities and available system privileges, presence of above stated files in ATMs constitutes a security threat. However, according to reports of the operator banks’ responsible representatives of given ATMs they are connected with warranty maintenance conditions of devices software and have no right for alteration of software, including deleting from devices these utilities.
Till now the origin of these files on devices remains unknown.
The most advanced practice of implementation the mode of self-service terminals software safe maintenance we can observe at separate operators of large network of devices in countries of Southeast Asia. High rate of both traditional and new banking service entry in region, high degree of service determination for different customer categories requires to make updates and new software ensuring the features of new banking products rather fast and regular. Implementation of traditional approach with add-on tools of program security does not ensure required rates of updates distribution in protected mode. Technical security measures are implemented on stage of developing of payment applications themselves:
- Self-protection of payment application own elements from unauthorized modification attempts
- Safe software alteration procedures
- Process activity monitoring tools
This allows to introduce new banking products with dispatch, to implement powerful extrusive bidding model not limited to excessive control procedures.
