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.

Attacks/Breaches

12/31/2013
03:53 PM
Gunter Ollmann
Gunter Ollmann
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Sticking It To The ATM

The folly of not preemptively disabling 'boot from USB' on an ATM

Ever since Barnaby Jack leapt on stage at Black Hat USA and had ATMs spew money as if it were going out of style, hackers around the globe have been busy trying to replicate the research before banks and ATM vendors get the vulnerabilities fixed. You'd have thought that after three-and-a-half years both vendors and banks would have fixed the bugs and dealt with the physical attack vectors long ago. Unfortunately, that doesn't seem to be the case.

A pair of security researchers speaking in Hamburg at last week's Chaos Communication Congressprovided new insight and demonstrated some USB-based malware that had been crafted by criminals and used earlier in the year to siphon money from several unpatched ATMs. The original malware authors had taken steps to remove many of the installation traces that forensic investigators would have found useful, so the researchers had to piece together many parts of a complex puzzle.

While it hasn't been disclosed which type of ATM were targeted (or which bank was affected), it seems that the criminals had uncovered physical flaws in the bank's ATM devices that allowed them to cut access holes through which they could slip in their infector USB device. Once the USB device was in place, the ATMs could be rebooted and the malware automatically installed.

I'd have thought that with all the hoopla that followed Black Hat in 2010 and the personal visits that Barnaby Jack (and IOActive -- the consulting company he worked for at the time) made to the ATM manufacturers and high-street banking organizations at the time, that everyone would have at least disabled the "boot from USB" functionality. Apparently, this particular bank hadn't acted on the memo.

The ATM malware appears to have had a number of interesting features designed to protect it from both investigators and fellow criminals or mules. After supplying a 12-digit magic number to bring up a built-in menu, the money mules were provided direct manual access to the machines' money-dispensing functions. However, before money could be extracted, a second code was required, a challenge-response code, most likely added to prevent mules from operating independently of the malware authors.

Given the relative sophistication of the malware and the efforts involved in protecting it from both bank investigators and other criminals, I wouldn't be surprised to learn that the malware is already in use by other organized crime gangs around the world. It would be a rare occurrence for any bank targeted by this malware to openly disclose it was a victim -- doing so is not good for business and customer confidence.

While the attack vector -- booting from an infected USB stick -- will have many security veterans rolling their eyes in disbelief that the targeted bank hadn't already mitigated the threat, I've heard several people argue that writing code (malicious or otherwise) for ATMs is difficult. Unfortunately, it's simpler than most realize. Anyone with an understanding of CEN/XFS, or the time to peruse the online manuals, will quickly master the fundamentals.

This USB infector process is the low-hanging fruit for criminals targeting ATM machines. Banks that haven't already mitigated the attack vector are, for lack of a better word, negligent. There can be no excuses for not disabling the "boot from USB" functionality, especially now with the public disclosure of criminal abuse.

 

Gunter Ollmann serves as CTO for security and helps drive the cross-pillar strategy for the cloud and AI security groups at Microsoft. He has over three decades of information security experience in an array of cyber security consulting and research roles. Before to joining ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
macker490
50%
50%
macker490,
User Rank: Ninja
1/6/2014 | 12:58:01 PM
re: Sticking It To The ATM
ATM should have a sensor in it to protect against physical attack such as cutting a hole in it. tripped sensor should just cut off ac power and signal ADT type alarm. even a pin-ball machine can set the TILT alarm.

we need to start publishing these attack methods all over the net so the fools who are playing free and careless wih our security have to straighten up .
mcabral028
50%
50%
mcabral028,
User Rank: Apprentice
1/3/2014 | 4:11:38 PM
re: Sticking It To The ATM
I certainly no security expert. But wouldn't rebooting an ATM, with an unscheduled reboot no less, have caused the ATM to have to logged and sent that information to someone maybe in real-time? I'm looking at this from a maintenance point of view, I guess, rather than a security one. But it seems it would have been a red flag that something wasn't quite right with that machine.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...