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.
Everything You Need to Know About DNS AttacksIt's important to understand DNS, potential attacks against it, and the tools and techniques required to defend DNS infrastructure. This report answers all the questions you were afraid to ask.
Domain Name Service (DNS) is a critical part of any organization's digital infrastructure, but it's also one of the least understood. DNS is designed to be invisible to business professionals, IT stakeholders, and many security professionals, but DNS's threat surface is large and widely targeted.
Attackers are causing a great deal of damage with an array of attacks such as denial of service, DNS cache poisoning, DNS hijackin, DNS tunneling, and DNS dangling. They are using DNS infrastructure to take control of inbound and outbound communications and preventing users from accessing the applications they are looking for. To stop attacks on DNS, security teams need to shore up the organization's security hygiene around DNS infrastructure, implement controls such as DNSSEC, and monitor DNS traffic
Incident Readiness and Building Response Playbook
In this special report, learn the Xs and Os of any good security incident readiness and response playbook.
Tweet This
1 Comments
User Rank: Ninja
12/22/2016 | 3:23:53 AM
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.