Malware Steals ATM Data

One of the risks of using a commercial OS for embedded systems like ATMs: it’s easier to write malware against it:

The report does not detail how the ATMs are infected, but it seems likely that the malware is encoded on a card that can be inserted in an ATM card reader to mount a buffer overflow attack. The machine is compromised by replacing the isadmin.exe file to infect the system.

The malicious isadmin.exe program then uses the Windows API to install the functional attack code by replacing a system file called lsass.exe in the C:WINDOWS directory.

Once the malicious lsass.exe program is installed, it collects users account numbers and PIN codes and waits for a human controller to insert a specially crafted control card to take over the ATM.

After the ATM is put under control of a human attacker, they can perform various functions, including harvesting the purloined data or even ejecting the cash box.

EDITED TO ADD (6/14): Seems like the story I quoted was jumping to conclusions. The actual report says “the malware is installed and activated through a dropper file (a file that an attacker can use to deploy tools onto a compromised system) by the name of isadmin.exe,” which doesn’t really sound like it’s referring to a buffer overflow attack carried out through a card emulator. Also, The Register says “[the] malicious programs can be installed only by people with physical access to the machines, making some level of insider cooperation necessary.”

Tags: , , , , , , , ,

Posted on June 10, 2009 at 1:51 PM • 49 Comments

Comments

Aaron • June 10, 2009 2:24 PM

Seems like they should have included something to disable the last five minutes of camera footage if the control card was inserted. Easy to walk away with the cash box, hard to keep it if they have footage of you doing it.

Bob • June 10, 2009 2:28 PM

It never ceases to amaze me that companies and organizations whose entire business model rests on security choose the OS/CPU combination that has the most known exploits and the largest community of skilled black hats.

I’m not advocating security through obscurity, but thieves – whether thugs on the street or Eastern European hackers – usually prefer the easy targets.

In a more rational world, companies that make ATMs, voting machines, and so on would reject Windows, especially on x86, out of hand. Instead, we’d see a varied ecosystem including Linux on ARM, QNX on MIPS, VxWorks on PowerPC, and so on. You certainly don’t need the latest-and-greatest from Intel and Microsoft – it’s not like these applications are exactly processor-intensive or require much of a GUI.

HJohn • June 10, 2009 2:30 PM

Perhaps their is something about ATM technology I don’t understand, but even when using Windows for their system (a questionable decision), what kind of brainiac decided to allow this to be initiated from the ATM card slot? Seems little need for anything but a read of numbers to be performed.

Karl • June 10, 2009 2:31 PM

I am highly skeptical of a buffer overflow attack being mounted through the magstripe reader. Not only do cards only contain a limited amount of data (but could be theoretically infinite if a card emulator was used), but the character set is EXTREMELY limited, especially on track 2. I would be VERY impressed if someone managed to write a successful buffer overflow that only used this limited character set.

Bob • June 10, 2009 2:34 PM

@Aaron: The footage would only be useful if they could identify you from it. I immediately thought of a half dozen ways to fox that – for details, read Harry Harrison’s Stainless Steel Rat short stories.

Dan • June 10, 2009 2:37 PM

You know, just seeing “C:\WINDOWS” associated with an ATM makes me shake my head in amazement…

Jeremy • June 10, 2009 2:51 PM

I somehow would’ve thought that all the data on an ATM card would be in a fixed-length format, and read accordingly, which should make buffer overflows impossible. But I suppose what seems the obvious way to do something in the abstract isn’t necessarily the easiest or best in practice…

Karl • June 10, 2009 3:09 PM

Jeremy: The ISO 7811 standard for magstripe cards has a fixed upper length of data, but that doesn’t mean that cards not conforming to the standard (or card emulators) can’t exceed that length. Still very skeptical, though.

Anonymous • June 10, 2009 3:26 PM

There exists those blackhats who can dream assembly and machine code exploits for SYSTEMS.

Those who can write top code can break top code in different archs, it just takes teams, time, and $.

Check out how many banks still use lower grade ssl/tls. RC4-MD5, grr. Some use SHA, and AES. Some also have extra urls to stuff that can compromise analysis. Oh well. Why bother.

Check out how many browsers even, grr, have any reason to trust anything.

Logs and meaning even are problematic with Lynx. Oh well. Computer Security, what a lousy field, better to be an actor.

Michael Lambrellis • June 10, 2009 3:28 PM

To those skeptical of the likelihood of a successful buffer overflow:
It seems to me highly likely (using a card emulator), given the developer’s probable assumption that the fields are fixed length (since that’s all the card can store), and that the character set is limited. Developer assumptions about input data is probably the single biggest vector for attacks on Windows (and any other system). Long live the buffer overflow!

bob • June 10, 2009 3:31 PM

I dont understand why people sell “limited use” computers, like ATMs, Voting Machines, GPSs, automobiles that use an OS for “general purpose” systems like Win, Mac, Linux etc.

They should write a dedicated OS which only does the few functions needed for the mission. Display to the screen. Read from the card. Activate a couple of motors and servos (to dispense cash, accept deposit, etc). Store data. Communicate with outside world. Print something.

Yes, the initial development time will be more, but in the long run it will come out miles ahead due to radically simplified testing, debugging and “oh shit we forgot it could do THAT” fixes.

Nevermind the incredible value of never seeing your company in the headlines followed by the words “…loses 450,000 customer records”.

-ac- • June 10, 2009 4:00 PM

@Anonymous: “Oh well. Computer Security, what a lousy field, better to be an actor.”
Well you could play a security expert 😉

I think the POC exploit to should be to eject the cash drawer as soon as it is inserted. But then, maybe I just want to see what the people loading the ATM do next.

Mel • June 10, 2009 5:06 PM

what kind of brainiac decided to allow this to be initiated from the ATM card slot?

From my short stint in the industry: the kind of brainiac who’s obsessed with lowering maintenance costs. If we opened up an ATM machine we had to send an armoured truck with a couple of guards, etc. A guy with a magic card is much cheaper.

IMHO the way to do it right is through the network with signed messages, but …

David • June 10, 2009 5:22 PM

I have had money stolen from my checking account using a cloned ATM card. During the investigation into exactly what happened, I learned that most ATM cameras no longer work, or are no longer maintained. So it seems these days it is only a small risk that your picture will be taken at an ATM machine. This is probably because defeating a camera on the machine is brainlessly simple (duct tape, anyone?). A remote camera would be moderately more risky for a would-be thief.

ge • June 10, 2009 6:38 PM

I have to agree with previous posters, it is highly doubtful that the contents of a magnetic strip can contain information that causes a buffer overflow attack. You’d have to get the card reader firmware (which is stored in a ROM) to send an oversized message first, and then the application has to be written in an unusually stupid way.

Not all that likely. It seems more likely that the creator of the original article has something to sell to the ATM industry.

Todd • June 10, 2009 7:18 PM

“…they can perform various functions, including harvesting the purloined data or even ejecting the cash box.” Should that read “ejecting the CONTENTS of the cash box.”? Given the cash container is physically secured, I don’t see how this is possible.

Ninja • June 10, 2009 7:25 PM

Another commenter mentioned the cameras watching the ATMs. But who’s watching the cameras? If a masked offender walks up to an ATM at 4am and hacks it with an overflow card, how many real transactions will go through before it’s discovered?

G • June 10, 2009 8:28 PM

IMHO it is highly unlikely that the code was injected via a card – this is just a blatant unverified assumption in the linked article. The report does not state the source of the initial compromise, which is probably someone with access to the OS store on the machine. Once the code is there, like any hacked system, any trigger (aka card in this case) can be used. Don’t see anything new here except a compromised network via the usual routes.

Rophuine • June 10, 2009 9:22 PM

re: Cameras
Having worked in IT for a TPP, I got to assist with plenty of ATM theft cases. It’s amazing how often the thief: a) lives in the local area, and b) smiles for the camera. The unmaintained, non-functional camera myth works wonders, even today. The smart ones just cover their faces up; many ATMs are accessible late at night when few people are around to be suspicious.

re: Initial Exploit
I read the report, and couldn’t see anything specific about the initial compromise vector. Buffer overflow via the mag-stripe seems unlikely to yield the amount of exploit code involved, or even to provide a vector to cause download and execution from elsewhere. I would suspect the usual vector is via tech staff.

re: PIN block
I’m not sure about European standards, but where I’ve worked there are all sorts of rules surrounding PIN entry keypads. Specifically, they must contain an additional layer of encryption separate to the rest of the transaction device. The ‘additional data which may be PIN-related’ (my paraphrasing) is likely to be a DES or 3-DES block containing a salted hash of the PIN. Given the situation, you could make a chosen-plaintext attack against this layer, but it’s still a thorny problem. Keys are rotated frequently. Well, they’re meant to be.

One possibility is that the thieves are hoping to grab a large volume of track 2 data and perform a reverse-brute-force attack (same password, many accounts) using two or three common PINs.

If they were able to prevent the encryption layer from triggering, this should prevent the transaction from completing (as the acquirer will be expecting an encrypted PIN block), although this could be defeated with a social attack (first transaction ALWAYS fails with ‘Incorrect PIN’, second transaction turns the encryption layer back on).

All of that aside, I still suspect (as ge suggested) that the author wants to sell the banks some service or software.

Filias Cupio • June 10, 2009 9:25 PM

“One of the risks of using a commercial OS for embedded systems like ATM machines: it’s easier to write malware against it”

“Don’t use a commercial OS for ATM machines” would be a security through obscurity measure. Rather I would say “Don’t use a large complex general purpose OS for ATM machines.” (Especially one which has a poor reputation for security.)

Salach Shabati • June 10, 2009 11:25 PM

In Europe almost all ATMs support smartcards, which give a higher-bandwidth channel to the ATM. Still it requires intimate knowledge to mount an attack via this channel, so i guess the infection was done in a different way and not as speculated in the article. As someone else said wisely – once the malware is in place a card could be used to trigger it into action, but it seems unlikely that it was injected that way.
The theory that the company is advancing some sort of product they want to sell seems also very valid.

paul • June 11, 2009 12:28 AM

@bob:

I dont understand why people sell “limited use” computers, like ATMs, Voting Machines, GPSs, automobiles that use an OS for “general purpose” systems like Win, Mac, Linux etc.

I think it’s pricing. If they can use already-written software, it means they don’t have to develop it themselves, which means shorter development time, which means lower cost, which means lower price, which means competitive advantage. Might also mean more successful attacks, but they don’t include that in their RFP responses haha.

Cybergibbons • June 11, 2009 2:40 AM

I don’t think it would be particularly hard to exploit these machines. I’ve frequently seen machines which have been partially or entirely broken open, giving access to a CD-ROM drive and even a keyboard. This is more common with the stand-alone ATMs found in petrol stations and shopping centres.

An example is http://s3.amazonaws.com/twitpic/photos/large/3840363.jpg?AWSAccessKeyId=0ZRYP5X5F6FSMBCCSE82&Expires=1244706734&Signature=N1WQtUSrznEJC8sur6kwN6ac65w%3D
and http://s3.amazonaws.com/twitpic/photos/large/3840515.jpg?AWSAccessKeyId=0ZRYP5X5F6FSMBCCSE82&Expires=1244706735&Signature=l1lIn9Nx2BO%2B0y1YyYpxzEZdIA4%3D. People were still using this machine, I called the number on it to report it damaged, and they didn’t seem to care.

imarsorama • June 11, 2009 4:02 AM

@Rophuine:
“re: Initial Exploit
I read the report, and couldn’t see anything specific about the initial compromise vector. ”

The report clearly says that “The malware is installed and activated through a dropper file”

It’s all about opening the ATM case, plugging in USB device and running malware. Unimaginable number of local physical attack vectors are not addressed in most ATM OS builds – USB, CD, easy admin passwordm unlocked desktop, once even Autorun.

@Dimitris Andrakakis: You are absolutely right, Trustwave refers to that Diebold malware.

Asmor • June 11, 2009 4:38 AM

One of the risks of using a commercial OS for embedded systems like ATM machines: it’s easier to write malware against it:

Tacit endorsement of security through obscurity?

Surely the problem here is that they used a notoriously insecure OS. Don’t get me wrong, I’m a Windows user through and through, but I hope to hell my bank isn’t using it for their ATMs…

Seems like if they’re going that route, some flavor of Linux would be wise.

Mark • June 11, 2009 6:02 AM

@bob
I dont understand why people sell “limited use” computers, like ATMs, Voting Machines, GPSs, automobiles that use an OS for “general purpose” systems like Win, Mac, Linux etc.

In this case things are made worst by using a general purpose OS which has a poor distinction between “user” and “admin” tasks.

loldongs • June 11, 2009 6:07 AM

Another reason windows gets used, instead of some specialised hardened OS, is that banks like to monetize their ATMs by having them show fancy animated adverts. These are probably windows screensavers (i.e. executables that present another infection vector.)

Dimitris Andrakakis • June 11, 2009 6:16 AM

@Asmor :

I don’t see an endorsement here. Bruce merely says that it’s easier to write malware against a commercial (which I read as “widely used”) OS.

If the OS was custom built or something you don’t come across every day (think AS/400, HP-UX, Solaris or ) then the talent pool for malware programmers would be severely limited. Therefore

Note that does not imply or require for one OS to be more secure than the other.

Adam • June 11, 2009 6:26 AM

LSASS is pretty important in windows. LSASS == Local Security Authority Subsystem Service and is responsible for enforcing the security policy on Windows machines

Anonymous • June 11, 2009 6:34 AM

(My apologies for hitting “post” before completing)

@Asmor :
I don’t see an endorsement here. Bruce merely says that it’s easier to write malware against a commercial (which I read as “widely used”) OS.

If the OS was custom built or something you don’t come across every day (think AS/400, HP-UX, Solaris or even the now-extinct BeOS for that matter) then the talent pool for malware programmers would be severely limited, and the creation of malware would be inhibited.

Note that does not imply or require for one OS to be more secure than the other.

Mark R • June 11, 2009 7:25 AM

If this attack relied on physical access to install the malicious code, doesn’t that sort of make the OS irrelevant?

I would think this falls more into the realm of hardware controls and restricting what can be done at the local console. Unfortunately, 90% of the time it holds true that “local access is total access.”

Cybergibbons • June 11, 2009 7:31 AM

The cryptoprocessors in these things are very tamper resistant.

Maybe it would be a good idea for the whole thing to be tamper resistant, and at least how some form of secure auditing.

BeOS • June 11, 2009 8:21 AM

BeOS isn’t quite extinct. The audio company, IZ Technology, uses BeOS as the OS for their recording systems. I’m guessing they procured a source license from Be prior to operations shut down, but I’m just guessing. Maybe when Palm goes belly up, some other corp will get the IP and open in…

HJohn • June 11, 2009 8:38 AM

@paul: “I think it’s pricing. If they can use already-written software, it means they don’t have to develop it themselves, which means shorter development time, which means lower cost, which means lower price, which means competitive advantage. Might also mean more successful attacks, but they don’t include that in their RFP responses haha.”

It’s also continuity, and there is an upside to security. There is high turnover in IT, and any new employee would need to be trained on the OS. Further, while commercial OS would be easier for an outsider to exploit, I would image an in-house OS would be easier for an insider to exploit and harder for someone to detect.

This whole story seems a bit fishy to me, since I can’t imagine all this being initiated from a ATM card slot–unless there was collusion from the inside.

Alex • June 11, 2009 9:19 AM

  1. The “card reader buffer overflow attack” is completely on Inquirer, the brief I’ve read said it was an internal job, file was installed by bank’s employees, inside signed update package.
  2. Any ATM I’ve seen from Diebold, NCR, Siemens-Nixdorf uses heavily customized version of Windows 2000/XP Embedded. (Old IBMs use OS/2, still working:-)). Almost any management tool/protocol (rdp, wmi, rpc, remote registry) is removed or restricted. I can’t say that those ATMs are normal Windows boxes.
  3. “Eastern Europe” means one (big) bank in country located between Poland and China.

FP • June 11, 2009 9:20 AM

@bob: “They should write a dedicated OS”

In general it’s smart to use an off the shelf operating system. Means more functionality, better development and debugging tools, larger developer and user base, and generally better testing. All result is faster time to market for less cost.

How many bugs would a dedicated OS have?

Sound development practices need to be applied either way.

Shane • June 11, 2009 11:08 AM

@Filias Cupio
“‘Don’t use a commercial OS for ATM machines’ would be a security through obscurity measure.”

@Asmor
“Tacit endorsement of security through obscurity?”

Are you guys high? No, really?

Not using a full on windows desktop OS on an ATM is not ‘security through obscurity’, it’s just plain common sense.

This isn’t a desktop home computer, it has a very specific and very sensitive (people are sensitive about their money) set of tasks. Using a bloated, buggy OS chalk full of all the best security holes of the day is just plain ignorant. Using a streamlined, hardened to the brink OS written with the hardware, tasks and major security concerns kept in mind is, again, common sense.

I’m also quite certain that, given the man, Bruce would much prefer a solution that was open for peer review. The ‘we promise it is safe’ bit doesn’t cut it around here.

Doug Coulter • June 11, 2009 9:46 PM

I’ve rolled my own OS’s for quite a large number of embedded devices. Even for ones that do a lot more than an ATM, it’s just not that hard compared to a general purpose gui desktop system, and needn’t necessarily introduce more security bugs or issues. You just keep it simple, cooperative multitasking at most, eg main loop just calls state machines that do things and return when done or between chunks of lengthy jobs. Reset the watchdog timer each time around, done.

You probably don’t need a filesystem or a lot of other complex I/O driver stuff if you design the thing right.

By simply leaving out things the application doesn’t need, but which are hard to strip (or tempting not to for debug reasons) from a big OS, you gain quite a bit in security. And since the boot time is now effectively zero, you can have it reboot or hit a watchdog timer if anything seems the least bit fishy and most users won’t notice or complain.
Makes it real hard to crack.

In embedded systems, any memory, cycles, whatever that isn’t used is a waste of money. When you’re making millions of them (think paging or telephony systems) being able to use a small 8 bit controller vs a windows CE class computer is a very big deal — you only pay for the software effort once, not for every unit. We’ve heard CEO’s chortling down the hall that we only charged them a few hundred K$ for software they were going to make millions from (and they did).

Calling this security by obscurity is like calling encryption the same thing in my opinion.
Heck, 99% of the secure systems I did for lots of 9’s reliability didn’t even have the ability to write the code store at all (took an external programmer of some sort) — cheaper and avoids quite a lot of trouble.

That all companies don’t do it this way perhaps speaks more to the lack of good programmers more than anything else. With a general purpose OS, after all, you can use drag/drop/java code monkies who can’t really program well, but are common and cheap — even though it would be cheaper to hire a pro for 3-5 times the hourly rate, if you could just find one of us.

And our results are better, faster, cleaner and more secure, by design, because we had control over the design, and didn’t have to leverage things we couldn’t understand (not because we were dumb, but because the design was a secret like windows source code, for example). And in fact, when an opysys gets that complex, I’d submit that no one truly understands all the possible interactions that can lead to a breach. It’s just not smart to go that way.

Steve Friedl • June 11, 2009 10:57 PM

@Shane: ATMs and other systems use XP Embedded, and this is not the same thing you have at home. The build/configuration systems offer more than 10,000 options (really!) for excluding this component or including that one. It’s incredibly tunable: if you don’t want notepad or a desktop or an IP layer, you can exclude them.

Diebold says that the hack required physical access to the inside of the machine: http://www.diebold.com/ATMs_illegalsoftware_Russia/default.htm

I’m not sure if any OS could withstand this kind of inside attack, and it seems disingenuous to use this to justify any position on choice of software.

Peter Maxwell • June 12, 2009 6:59 AM

There is a very specific reason why a large proportion of the ATMs you’ll come across – at least in the UK anyway – will be using Windows; and it has nothing to do with ease of software design, maintenance, OS security, or for that matter anything about the ATM unit itself. Unfortunately, it is probably covered by the confidentiality clause from my last job so I’ll have to stop short of pointing out what it actually is.

Eric S. • June 13, 2009 12:45 AM

@Bob: I once saw an ATM crash when I put my card in, and I got to watch as OS/2 booted up. That was surreal. Oh, and it ate my card. 🙂

bobalink • June 14, 2009 12:39 PM

Another big reason to use Windows is the programmer pool. It’s orders of magnitude larger than the pool for embedded OSes.

Euan • June 14, 2009 10:45 PM

Commercial is the wrong term. An open source OS can still be commercial.

Proprietary or closed source would be more accurate.

Angel One • June 16, 2009 1:47 PM

The problem with Windows is not that it is commercial or common, but that it is general purpose. A windows machine can surf the web, make word documents, read acrobat files, watch movies, and edit photos. None of these are functions that you want your ATM to be performing. The advantage to embedded devices is not that they are unknown, but that they do nothing other than what they are supposed to do, and therefore greatly reduce the chances of vulnerabilities being found.

Peter Maxwell • June 17, 2009 5:31 PM

@Angel One:”The advantage to embedded devices is not that they are unknown, but that they do nothing other than what they are supposed to do…”

It is also the disadvantage of embedded devices. Windows, disregarding all the debate over pros and cons, has a massive associated base of software, hardware, etc that only works with windows. So say you are managing the role out of a big project… you see a product which is cost effective, maintainable and pretty much the best on the market, it however only runs with windows – what do you do? Do you force the company you work for to spend over the odds on an inferior product, or do you use the one that must run on windows?

malware • November 10, 2009 1:08 PM

“I am highly skeptical of a buffer overflow attack being mounted through the magstripe reader. Not only do cards only contain a limited amount of data (but could be theoretically infinite if a card emulator was used), but the character set is EXTREMELY limited, especially on track 2. I would be VERY impressed if someone managed to write a successful buffer overflow that only used this limited character set.”
@Karl I think they use multiple malicious cards- one to get in, and a few more to install malware. If so, you wouldnt necessarily be limited to a character limit, but by the chance of someone getting in line behind you. Or the security “cameras” whom someone said were mostly non-funcitonal…..

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.