Bright Stove

Reflecting information risk journey

A Black Swan on the ATM system

leave a comment »

This past week’s news headlines have once again been filled with a number significant cyber security incidents. Data breaches in JP Morgan, Bash shell vulnerability in a number of Unix/Linux operating systems (Apple OS X included), and many others. One that was of particular interest, not because it happened just around our neighborhood location, but one that’s concerned with a risk-based approach to information security management. That’s the Automated Teller Machine (ATM) attacks incident in Malaysia, which was reported in major newspapers online and offline on/around September 30th, 2014.

I was first curious about the ATM attacks as Malaysia had not had an ATM related fraud for quite some time then, at least a few years since all the banks there had upgraded their ATM to a chip card (smartcard) based system. Prior to the upgrade, a number of banks were seriously impacted by major organized crime attacks on their magnetic card system, which involved installation of fraudulent reader to copy the card holders’ account data on the magnetic stripe, and tiny camera overseeing the PIN pad to capture the user PIN as the cardholders enter it while using the machine. With the smartcard based system, data on chip cannot be copied easily, which makes cloning the ATM card a major challenge. Capturing the PIN via an external camera itself doesn’t serve any good when the card cannot be cloned. The smartcard based ATM card system basically “won” the war against the criminals. I was therefore interested to find out how the perpetrator did what they’ve done and got away this time. A good thing is that the news report did provide some useful information to understand the gist of the attack.

As reported in various news sources, the attack essentially involves a combination of physical and logical techniques, and of course a certain amount of courage, confidence, and luck on the part of the perpetrator. The attack begins with the perpetrator forcing open the ATM physical enclosure to reach the computer so as to insert a CD into the CDROM player to launch the logical attack. It appears that the targeted ATM systems were all using a form of weak physical protection that did not even have one of those temper resistant setup that would shutdown the machine, or intrusion detection mechanism that would trigger an alarm when it is forced open. This looks like a fundamental design failure. Otherwise, it would have to be a weak lock, or someone compromising the key.

Once the perpetrator overcomes the physical “protection”, a malware (a file named ULSSM.EXE) that resides in a CD takes over the rest of the work. At this stage, the activation of the malware requires that the machine to be using an operating systems that is compatible with it (which in this case, Windows XP), and more importantly, configured (or rather, mis-configured) in such a way that will “auto-run” the malware program in the CDROM. If it runs successfully, the perpetrator will eventually receive a code on his/her mobile phone that allows him/her to gain administrative access to the ATM to pour out whatever cash that is still in the ATM system at that point.

The perpetrator was either lucky, or had prior knowledge that the malware will work as planned, and there were sufficient cash in each machine to worth the efforts, or a combination of all this. The ATM systems were apparently running Windows XP, have a CDROM installed, and had “auto-run” enabled (a default setting in Windows XP anyway). The total loss reported ranges from 450,000 to as high as 3.1 millions Malaysian ringgits, over several (some say 17, others say 18) ATM systems across the Malaysia peninsula, including Selangor, Melaka, and Johor.

To gain more insights on the attack, I did a quick search of the malware, ULSSM.EXE, and apparently, it had been reported by quite a number of anti-virus software vendors as early as May 2014 (i.e., about four months ago). The first thing that comes to mind was, even if it was reported four months ago, how will the bank know of such a unique malware that was specifically targeted on ATM systems among the millions of malware that have emerged in the period? A subsequent report in the news confirmed our expectation — that the vendor of the ATM system should be monitoring for such vulnerability (and exploit) and inform their customers (the banks) accordingly. Whether the vendor actually contact all their customers directly, or simply post the vulnerability information on their web site is not known.

In Symantec report, the malware is diagnosed as a Trojan, and named as “Backdoor.Padpin”. Incidentally, the Trojan malware is rated as a “Very Low” risk, as shown in the screen shot captured from the Symantec web site on September 30th, 2014. The layout of the site seems to have been updated now, but the contents have remained unchanged.

14 - 1

The “Very Low” risk rating is based on three threat assessment factors: Wild level, Potential Damage, and Distribution. At the time of their assessment (first on May 9, 2014, and subsequently updated on May 20, 2014), the Wild Level is rated “Low” since the number of infections reported is between 0 and 49, number of sites infected is 2, and threat containment and removal are both assessed as “easy”. The Damage assessment is rated “Medium” as the Payload involves “opening a backdoor”, “displaying sensitive information to the attacker”, and “disables the local network to avoid triggering alarms”. Finally, the Distribution is “low” since only two sites have been reported infected at that time. If you are a security manager of a bank that uses the ATM system, how would you respond to such an advisory? My guess is that most security managers are not going to even see a report highlighting such a risk issue, given its “Very Low” risk rating, not to mention taking any precautionary step in view of the advisory that the vendor has published. There are many more “High Risk” items to pay attention to. In the online report, Symantec has also provided detailed recommendations for preventing and mitigating against the malware. They may not have been read by anyone if not for the attacks that have happened.

The risk rating (“Very Low”) appears to be largely influenced by the distribution, even though the potential impact is quite significant. What does “Medium” damage rating mean is not clear, but the capabilities of the malware appears to be sophisticated, designed for very specific purpose — being able to disable the local network and display sensitive information to the attacker at the same time. My retrospective assessment of the impact is perhaps influenced by the occurrence of the ATM attacks incident itself. As such, the incident looks very much like a Black Swan — a “low” risk, but high impact incident, which we only find it to be significant retrospective to its occurrence.

NZ-20051204 146

The Black Swan highlights one of the issues of a risk-based approach. That is, we can’t predict what will go wrong or how bad events will play out in the future. Incidents of the past are history, which tell us something about what can go wrong, but do not tell us whether they will happen again. Even if the attack is similar, their future frequency, and distribution of occurrence are basically unknown. Our risk assessments therefore can be wrong, and the worst case is when a low risk issue materializes, since we tend to ignore or give very low priority to low risk issues. Ironically, a risk-based approach relies on risk assessment to make decisions.

A continuous risk assessment approach, which builds on the risk-based approach, doesn’t fare much better either. How often do organizations re-assess their risks of an existing system? If they adopt the ISO/IEC 27001 certification standard, the normal cycle is once a year. If an organization relies on the internal control and audit function, which banks tend to be, it depends on the their schedule and priorities. In all cases, each cycle will normally look at a different scope (due to limited resources, and many new systems to review). The ATM systems security is thus unlikely to get a reassessment of its risk for a long time if the bank has not made any significant changes to it. The previous major change is likely to be the upgrade to the smartcard card system.

Getting back to the ATM incident in Malaysia, the vendor has responded as reported in the news that the banks were warned four months ago. It’s almost a week’s past since the publicity of the ATM attacks incident involving the Trojan malware, the risk information at the Symantec site has remained as “Updated: May 20th, 2014 9:44:15 PM” (as seen at the time of this writing), October 5, 2014 11:50 PM. Apparently, there’s no continuous risk assessment for such threat at its information source either.

Given our knowledge of the Black Swan, Nassim Taleb, the author of the book, “The Black Swan“, has asserted the importance of designing and building robust systems that is “anti-fragile“. Any attack on a system will occur as a change event, or a series of change events, from the perspective of the victimized systems, regardless of the outcome of the attack. A prerequisite for robustness, or antifragility is therefore responsiveness, i.e., having the ability to “see” the effects of the changes, and trigger appropriate actions for criticality alignment. We shall discuss more about Responsive Security in future blogs as the main idea of this blog is to highlight the Black Swan that was observed on the ATM system. Meanwhile, if you wish to learn more, check out the book itself from the links in the earlier blog.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: