Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

'Alice' Malware Loots ATMs
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
12/22/2016 | 3:23:53 AM
A Redesign is in Order
It's a beautiful piece of work, Alice.  However the beauty isn't solely in the simplicity of the malware, but also in it revealing the shortsightedness of the ATM design, from the outer ATM casing down to the computing.  Seriously, I don't know if anyone reading this article has read the Payment Card Industry Data Security Standards for ATM security (a favorite of mine is PCI PIN Transaction Security Point of Interaction Security Requirements (PCI PTS POI)).  I can tell you, though, that some ATM manufacturers and implementation teams are not reading them closely enough.  There is clearly a disconnect between the masters of the ATM hardware and the keepers of ATM software, because someone thinks designing an ATM that can be opened with a key from the front to give access to computing hardware (that these standards clearly illuminate as vulnerable if not well protected) is OK.  Yeah, sure.  And lets also start designing safes that may hold several million dollars in cash and gold with wall protrusions accessible to the public, opened with just a single key, and code-protected via software on hardware exposed once that panel door is opened, whether legally or otherwise.  Sure, ATMs don't hold millions of dollars, but because of the sad stae of their design model, much much more money that that is vanishing from ATMs.  (Not all bank ATMs have the same flawed access design.)

A redesign is seriously in order.  Check out the International Journal of Software Science and Computational Intelligence, 2(1), 102-131, January-March 2010, "The Formal Design Model of an Automatic Teller Machine (ATM)". This paper demonstrates that "the ATM system, including its architecture, static behaviors, and  dynamic  behaviors,  can  be  essentially  and  sufficiently  described  by  RTPA. The  experimental  case  study  has  shown  that  the  formal  specification  and  modeling  of  the ATM  system are helpful for improving safety operations and quality services of the system."  Moving in this direction on the software side, then partnering more rigidly designed secure software with a better ATM hardware model will benefit everyone in the long run, rendering Alice and her cousins inoperable.  Here's a couple ideas:

1) For stand-alone ATMs, design the lower cabinet where the safe is located to house the CPU.  If someone actually does get the front of the lower cabinet opened, they're met with a steel cube that would cost more to get opened than is actually inside, protecting the money and the CPU.  And don't make the frickin casing key-based. For wall-embedded ATMs, again, bury the CPU in a steel safe where the money is held.  Ditto on the key thing.

2) Use some formal modeling methods like RTPA outlined in the ATM paper noted above to write better ATM software that will not be compatible with most malware attempts if somehow a person got past all the nifty newly redesigned ATM hardware (in other words, friendly fire - inside jobs).  Make ATM logic less predictable, separate each state with more secure transitions, etc.  

Just don't make it so easy.  Insecure design is a calling card - an invitation - to reveal it.

What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Post a Comment
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-06-14
DoS attack can be performed when an email contains specially designed URL in the body. It can lead to the high CPU usage and cause low quality of service, or in extreme case bring the system to a halt. This issue affects: OTRS AG ((OTRS)) Community Edition 6.0.x version 6.0.1 and later versions. OTR...
PUBLISHED: 2021-06-13
The package studio-42/elfinder before 2.1.58 are vulnerable to Remote Code Execution (RCE) via execution of PHP code in a .phar file. NOTE: This only applies if the server parses .phar files as PHP.
PUBLISHED: 2021-06-12
Receita Federal IRPF 2021 1.7 allows a man-in-the-middle attack against the update feature.
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an infinite loop while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.