Broadband Tech > Security > Security > Malware steals ATM accounts and PIN codes

Malware steals ATM accounts and PIN codes

quote:

---

Pwns ATMs under Windows XP
By Robert Munro
Friday, 5 June 2009, 00:21

INSECURITY FIRM Trustwave Spiderlabs has reported that automated teller machines (ATMs) running Microsoft Windows XP are vulnerable to an automated attack that can nick bank account numbers and personal identifying number (PIN) codes.

The briefing (PDF) says that several variants of the malicious software were discovered on hacked cash machines in Eastern Europe.

Reading between the lines, it seems apparent that it will be only a matter of time before criminals deploy such attacks more widely at ATM machines located throughout the world.

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.

---

This is scary.

reply to seqrets
This seems unlikely.

INSECURITY FIRM Trustwave Spiderlabs

Seriously?

I love the attack vector... we just get the ATM to click a link in an email advertising fake antivirus... and then WE HAVE THEM!

ALL OF YOUR ATM ARE BELONG TO US.
--
My place : »www.schettino.us

I could see this vector of attack coming from code in the mag stripe. All it may need to do is have a legit card coded at the bank of the hacker, enter the PIN and you have an infected system. It may not be so out there as you think.
--
"In the future, that which is not mandatory will be illegal"
"Nobody knows the age of the human race, but everybody agrees that it is old enough to know better" - Anonymous

You think they're going to load code off the mag strip?

Really?

I think that security firm will soon release a "antivirus for ATMs" product.

That's where I'm putting my money.
--
My place : »www.schettino.us

reply to seqrets
More details on the Diebold ATM Trojan horse case:

»www.sophos.com/blogs/gc/g/2009/0···se-case/

(Posted on March 18th, 2009 by Graham Cluley, Sophos)

***************************

Diebold's Response To Software Attacks On ATMs in Russia:

»www.diebold.com/ATMs_illegalsoft···ault.htm

reply to seqrets
This report is mighty thin on details, especially on the all-critical infection vector. Let's see what we can figure out by thinking about it a bit.

The first thing I notice is that the isadmin.exe program (the dropper) is about 50kbytes, but there is no way this could have been introduced by a standard magstripe card.

Looking at the magstripe standards, a back-of-the-envelope calculation shows that cards can hold a max of around 76 bytes of information per track (but track 2 holds just 27 bytes), so even if you ignore formatting issues there's less than 200 bytes available on the card. It would take hundreds of swipes to clock that much data into an ATM.

What strikes me as more likely is a special card that has not a mag stripe but a transducer that sits just below the read head and can clock data in all day long. This is what I'd do if I were trying to hack one of these.

Second, my strong suspicion is that these machines were not running standard XP, but XP Embedded, which has an astonishingly granular method of selecting parts you want to include in your build — more than 10,000 configuration options that let you include or exclude stuff you want. It's highly likely that such a machine didn't come with the full XP feature set.

But this all comes down to the infection vector, and one can't assess any blame until one knows how the bad stuff got in.

Most of us would agree that if the bad guys somehow got physical access to the operating system hard drive (or flash drive, whatever), and simply copied the file on the system manually, it would be game-over for nearly any system. I personally have keys to a few kinds of common ATMs, and though they won't get me in the vault, they would certainly get me access to the electronics.

If it's not by physical access, they speculate on a buffer overflow. I am going to rule out one of these via any kind of standard magstripe card because there is simply not enough data available to do this kind of thing, but specialized hardware might.

So if this is a buffer overflow, the central question is: who owned the buffer that was overflowed?

It's possible - but unlikely - that this was in a low-level operating system buffer, because magstripe systems typically use serial I/O or emulate keyboards, and they are very poor candidates for overflow because they don't inspect the data, they just pass it onto the higher layer.

My suspicion is that the application itself is what's been overflowed, because this is simply where it happens most of the time. If that's the case, you blame the owner of the buffer (the application vendor) and not anybody else.

What I can say is that the writing in the article is pretty crappy:

reply to seqrets
Oh yeah, game over once they're inside the gates.

But it sounds so much more ominous as written, don't you think? Far better for selling ad space.
--
My place : »www.schettino.us

reply to seqrets
Well, I have nothing to worry about. My bank's ATMs run on DOS (I saw one boot up). Major bank, too.

reply to Steve
Thanks for this detailed response. Sometimes it's hard to distinguish fact from heaven knows what.

reply to seqrets

quote:

---

Yes. Very scary that ATM machines run on Windows XP

---

reply to seqrets
I wonder how long before this spreads to self-checkouts. The ones at both of our local chain food stores run Windows.
--
Every Kurt has his Courtney. You need a Yoko to do it right.

reply to seqrets
ATM's use a variety of OS's depending upon the manufacturer and model.

OS/2 is still used on some. Many of the smaller white label ATM's run their own proprietary software. Many now use some form of Windows - CE and XP (embedded/specialized versions)being the most popular. Win98 and NT4 have been used as well.

reply to owlyn