ATM In-Security in 2013 | ATM Security Flaws & Vulnerabilities
With the recent SecTor security conference in Toronto Canada, once again ATM security flaws have risen to the top of the agenda. ATM flaws have become wide-stream knowledge since Barnaby Jack showed off his ‘Jackpotting‘ attack. ATM flaws have once again become a hot-topic since the late Barnaby’s demise two weeks prior to this years Blackhat conference (USA 2013) where he was going to present about Pacemaker flaws. Barnaby was famous for demonstrating how he could potentially bypass the authentication mechanisms on smaller ATMs (typically found in bars and casinos); and subsequently how he could add his own code to the ATM, and make it spit out all its cash.
The conference mainly talked about in-security within ATMs typically used by banks and supermarkets (The BIG HEAVY ones). These mainly run an embedded version of Windows XP or even the IBMs OS/2. The talk mentioned security vulnerabilities like MS08-067, weak locks that could be picked, weak encryption (eg SSL,IPSEC VPN, unencrypted private keys), and weak passwords. Some of these are fairly common and others are not. At Pentura we have assessed a multitude of European ATM Manufactures and have some similar yet different results.
This week there is an international security conference about ATMs and Banking in London (Park Plaza Victoria Hotel 22-23rd October 2013) http://www.rbrlondon.com/events/security
Yes, some of the locks on the smaller ATMs or Statement Machines are generally weak, and can easily be picked (by an experience locksmith or locksport enthusiast) in under 30 seconds. However, there is generally one key by the manufacturer that will open all locks of a particular brand; saving fiddling around with picks. Yet, the security is said to be mitigated by the fact that the part with the lock is inside a bank and on the even larger machines typically has extra security like a manifold lock (spin wheel) or a Mauer Lock & Key (difficult to pick, as the keys are usually 90mm in length – conventional picks do not stretch that far, and at that distance are almost impossible to use), and the bank has CCTV monitoring the ATM 24-7.
If an ATM can become physically compromised the next level of security is usually a hard metal box. This prevents you from accessing the core components of the ATM ; The Motherboard. However, this is where the security ends….
You can usually find unprotected USB ports, a CD-ROM drive, Floppy Drive PS/2 ports (keyboard & mouse if their not already connected) and an unlocked BIOS! and typically a BIOS configuration with an insecure boot-order:
- Floppy Drive (Windows Rescue Floppy)
- Internal HDD
Depending on the Bank, passwords are managed differently; Some are weak and static and are identical on all machines, others are static to a specific model. Some passwords contain non-printable characters, and are different on every single ATM? But then passwords aren’t really used otherwise your ATM would be stuck at a Windows Login prompt everytime it rebooted! ATMs use an autologin system (similar to SCADA systems) where the password is stored in plain text within the Windows registry. If your lucky enough to catch an ATM rebooting, you’ll typically see a Windows Logo, a Desktop, then the ATM application will take over the screen (sometimes web-based, some times its a binary application).
I’ve generally found that patches are applied to ATMs so its not a simple case of own all the ATMs with a common public exploit such as MS08-067. However, the Service Pack version can make a difference. Sometimes you may find no service pack is installed with one particular bank, but at a different bank you’ll find the latest service pack applied. This generally affects the security mechanisms that may be applied to the Operating Systems Memory or TCP/IP stack. DEP and ALSR sometimes are found to not be in effect. Whereas, other Banks may have them fully enabled. This typically effects the type of shellcode you may use when you indeed find a vulnerability.
Unpatched 3rd Party Software
Now from personal experience this is where I have personally pwned ATMs since 2009; and strangely the issue remains unpatched, even though the Vendor has a fix/patch. I do not know if it is the SCADA mindset that typically prevents these patches from being applied unless they are fully tested to ensure the patch does not introduce any new bugs. But I find it hard to fathom that this vulnerability can still be actively exploiting after 4years! This vulenrability has always been exploitable, but because of the above issue (Service Pack, ALSR, DEP, Stack Canaries), or due to the custom version of Windows Embedded XP, typically publicly available shellcode does not always work. If your lucky enough to installed a debugger on the ATM you can generally create a working exploit quite quickly as these mechanisms can be bypassed.
Encryption is typically initially set-up within a test environment, and then when the ATMs are rolled out into production sometimes the keys are forgotten to be changed. Even more helpful, is that the keys are stored in a clear-text file on the root of the C: or within a folder called VPN or IPSEC, and typically the file is readable by Everyone. Again similar issues exist for PGP keys and SSL certificates.
ATM’s sit on a leased line and are firewalled off from the public internet. But depending on the configuration, set-up and firewall administration – depends on a number of ways of how access can be achieved. They are typically accessible from inside the Bank’s main corporate network or from the 3rd-Party provider VLAN. What’s this 3rd-Party VLAN, well you know all those pretty adverts you see on the ATM before you insert your card – those are the images/video-clips provided by the 3rd-Party Link!