 SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | reply to seqrets
Re: Malware steals ATM accounts and PIN codes 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:said by the article :
What financial institutions do after that will be up to them, of course. But we'd suggest that they look toward replacing their vulnerable ATMs running Windows XP with other machines that don't run any Microsoft software, as it is known to be insecure Oh please.
One can only properly blame XP if XP had some power to prevent the shenanigans, and "known to be insecure" is just crappy journalism.
Edit — Thanks to Exidor  more info comes out: this did involve physical access to the inside of the machine, and I don't know how any OS could withstand this kind of attack.
Steve
--
Stephen J. Friedl | Unix Wizard | Microsoft Security MVP | Orange County, California USA | my web site |
