A T M Spells Jackpot

A group of crackers over-seas have managed to break into a number of ATM machines via USB’s and malware.  The crackers break open the ATM machine  just far enough to access the computer which is generally significantly less secured than the actual cash in the machine.  Once they have it open, they take a USB stick with targeted malware, insert it into the machine’s USB printer port and then re-seal the machine.  The attacker then interrupts the network connection on the printer which forces it to reboot from the USB stick. These machines lay dormant until the original crackers accomplice comes by later and enters in a code to bring up an altered menu.  This menu prompts them with a challenge question which the accomplice calls another individual in the ring to get the response code which enables the attacker to have the machine dispense all of its cash. How Did They Do That? This attack makes use of a flaw in the Windows XP operating system on which the ATM runs.  What makes this so easy for them is that Windows XP is approximately 14 years old so most of its vulnerabilities have been discovered. Microsoft listed XP as nearing end of life for many years now. This means that this operating system - the one running all these machines that dispense cash from your bank - will no longer be patched or even supported by Microsoft. Currently, the EOL date for XP is April of 2014 the original EOL was 2012. XP For Life Part of the reason XP has stuck around this long is the disastrous roll out of Windows Vista soured users on the newer operating systems.  The other reason is that once users get used to a system and feel comfortable with it, getting them to change to a neweer more secure system is challenging at best. Not because of a more complex system - in fact much of the user interface in Windows 7 is actually an improvement - but because humans are inherently resistant to change.  This is why XP been used as an embedded operating system for so many devices including ATM machines and to this day remains the core of many such systems. It is also what is making it a ripe target for hackers. Bigger Fish While skimming attacks - where a skimmer is attached to an ATM card reader to gather PIN data - which steal an individuals personal data, this attack enables the attackers to empty the ATM machine itself one fell swoop. So next to identity theft and skimming, where the reward is limited to the contents of a victim’s bank account; this type of attack is just shy of a lottery win for criminals. Another boon to the hackers behind this attack is that it doesn't immediately flag at a bank. There are none of the same safeguards that an individual bank account might have and it does not leave any obvious evidence.  The only clue that this has occurred is that the balance in the machine has suddenly declined. Of course, someone going through the effort of opening the ATM would notice the addition of a USB stick in the back of the computer but these machine are not designed to require daily maintenance. So chances are it could be a few days before the crime is discovered. What Can Be Done? Previous articles have suggested the utilization of password protection on the BIOS (Basic Input Output System). In layman's terms the BIOS is like the spinal cord whereas the Operating system is like the brain.  While a password on the BIOS would stop this attack cold, it would also require the intervention of a human every single time that the machine rebooted.  This would leave the ATM in a non-working state any time it was rebooted which may be for legitimate reasons until someone with the password can drive over to it to unlock it.  This down time would cause a fair amount of damage in the form of lost revenue from transactions and wasted employee time.  This could even turn into a bit of a denial of service harassment against the bank where criminals could force a reboot on a large number of machines at once or ones located in high traffic zones.  Even though it doesn't pad the criminal’s pockets, it would most certainly cost the bank a great deal of money overall. In my opinion, a better way of handling this might be to fingerprint the ATM prior to deployment by inserting a few files that are unique to the machine and bundling them in with the operating system then creating a hash value of the current OS partition.  This value could then be transmitted and checked automatically with the bank before allowing transactions to continue after a reboot.  In the case where malicious code has overwritten the OS on disk or is running in its place, a hash value would still need to be sent and it is highly  unlikely that the malicious code would generate the same number as the original OS.  Then machines which respond back with a false number would be flagged as compromised at which point sending a human to investigate would make sense.