Trojan.Skimer.18 infects ATMs | Hacker News Reader

Trojan.Skimer.18 infects ATMs

news.drweb.com

38 pointsnapolux42 comments

I'm still really surprised every time I see a windows-based ATM. Why would a full, general-purpose OS be included in those machines that need to do just under 10 operations?

I know it's easier to deal with it that way, but just to limit the exposed code, it could be based on something much more restricted. If it was small enough, it could even reboot / netboot itself between each operation to prevent any modifications being stored locally.

They need a full stack OS with TCP/IP, crypto, UI, etc... Plus with Windows they can reuse a lot of their libs which are written in C# or Java.

But why they use outdated consumer oriented versions of Windows? Why they all are XP Home Edition?

I thought Windows-based ATM mostly use XP Embedded, not Home Edition.

May be it is a selection bias, but as unlucky customer I had seen hundreds failed ATMs from various banks on streets and almost all were with XP Home, exceptions were XP Professional, Linux, Windows 98 SE, OS/2 and DOS.

I am from Russia, so corruption may be explanation.

Why home? Because home editions are cheaper, and they really don't need any extra features of the more pro editions. So in one word: cost

Because it was probably cheaper that way. The manufacturers are passing the security buck to the banks themselves, and folks who work in banking IT/infrastructure don't generally know enough to understand what these machines do. As long as the cash counts in the cassettes matches up with the receipt at the end of the week no one is worried.

Besides, insurance!

There are full TCP/IP and crypto stacks for pretty much any chip that can support enough IO ports to communicate with a network card. UI is not that difficult to implement if the only thing you need to display is a full screen background with one row of changing text. Even if you want to play movies, this can be offloaded to a GPU and done almost entirely in hardware.

Look at it the other way - the only functional difference between a payment terminal and an ATM is the cash dispenser. Payment terminals implement modems, networking, bluetooth, crypto (actually that's done in hardware anyway, you just talk to a chip), UI on an almost completely custom system - it's being done right now.

C# and Java developers are cheap. So fuck security we'll throw more dev sat it.

Signed NCR, Diebold, et al.

Yet, devs for embedded systems are harder to come by than devs for Windows. Makes initial costs as well as maintenance costs lower.

For the same reason that Airports and subways use Windows. Developers.

developers. developers.

It is based on something more restricted (or, some were, anyway) -- Windows CE. It's a "Build-your-own OS" style thing, you pick the parts of the OS stack you want and build up your ROM. It's kinda cool, though I only ever played with it somewhat illegitimately.

Then there are some ATMs running Windows XP. Which, yes, is really dumb.

I used to program ATMS about 10 years back. NONE of them were running Windows CE. It wass all NT and 2000.

Oh true? The one that a friend worked for used CE here in Australia, though that was more than 10 years ago now. Fair enough!

Every ATM I've seen running Windows XP was running Windows XP Embedded. I didn't know about Windows CE being componentized so I looked it up and XP Embedded is the same way, which is something I guess.

Most of the machines in service were older and running OS/2 which was an awesome system. Some major banks (BoA, Chase, WellsFargo, etc.) ran newer machines that had fancier features like check image recognition. Those meant a move to newer OSes but that was a limited case.

The actual reason OS/2 is gone and all these ATMS are running Windows is because of companies like NCR and Diebold lobbying the government to put new language in the Americans with Disabilities Act [1]. It required every ATM to be capable of text-to-speech translation which the older hardware and OS/2 systems were not capable of (most of the machines I was pulling had 133Mhz processors and less than 64MB of RAM). This meant 1) new hardware sales, 2) new software sales, and 3) selling custom ad campaigns to run on the shiny new color screens and new hardware.

The industry had been stagnant for awhile in hardware and software sales, the deadline of March 15, 2012 was a great shot in the arm for NCR and Diebold. Lest you think this really was about helping people with disabilities, the vast majority of ATMs that I 'upgraded' were drive-through units sitting on concrete pallets in bank parking lots too high or too inconveniently placed for anyone to use unless they were driving in a car. I did get some very positive feedback from the blind and their friends(who knew the IRS employs so many blind folk?) when I installed some of the walk-up units, but the large majority were drive-throughs.

[1] - http://www.americanbanker.com/magazine/121_10/atm-accessibil...

Thank you for eliminating the last remnants of hope I had for our system of government. I know lots of people say that nothing is done without a monetary reason, but I still held out hope that at least some legislation was created with entirely benevolent reasons.

Bah.

Welcome to my world :)

I thought in the US, things might work differently though, but it seems just like "the grass is greener on the other side"

Sorry for the curiosity, by "I 'upgraded'", did you mean you were working for NCR/Diebold, or the banks to go upgrade the ATMs?

The NCR/Diebold techs charge out at 200-300 an hour which regional banks cannot really afford. I was working for a 3rd party servicing company which existed only because of the duopoly's insanely high service rates. We were contracted by the banks to purchase the appropriate amounts of licensed software and then install it on their machines.

One way NCR/Diebold would screw customers is by having the software upgrade process take so effing long. If you wanted to upgrade the software on one of these machines it was multiple CDs with a total boot / reboot / loading time of 5 to 6 hours. I've torn through all the code and programs I could find on those machines while in the shop, there is NOTHING that could possibly be taking that long to load and install. The entire customer interface is an XML config file with a few PNGs and text-to-speech running for selected parts of the XML. (This is also a fun way to hack an ATM to say things like "FEED ME A STRAY CAT"). We really suspected the companies greatly padded the install time to increase their service bills. We got the contracts to upgrade from the regional banks because we would instead build new cages with the correct CPU/RAM/audio spec, preload the software with a bunch of cloned hard drives, swap the cages and then bring the machine back on the network. This was MUCH cheaper than paying the factory technicians.

Don't even get me started on what NCR/Diebold do with the DMCA. They would do things like releasing an identical hardware component (receipt printer, etc.) but with a new driver, and if anyone bought a used component (for about 10% of the new price) and dared to update the driver so it would work with newer machines (which refused to work with the old drivers) they would sue and win.

It's a bit sad that TTS could not be enabled on 133MHz machines with 64MB of RAM, but that's just how it is now-a-days:

http://en.wikipedia.org/wiki/Software_Automatic_Mouth

> I'm still really surprised every time I see a windows-based ATM.

So you're surprised every time you see an ATM? They're all Windows-based (unless there are still some OS/2 ones around, which would not surprise me much).

> Why would a full, general-purpose OS be included in those machines that need to do just under 10 operations?

Among other things: Because the maker of that OS defined an API (XFS, mentioned in the article) to access the custom peripheral hardware used by ATMs.

> but just to limit the exposed code, it could be based on something much more restricted.

What exposed code? These machines aren't connected to the internet, talk only to their own servers, and have a very limited end user interface.

> So you're surprised every time you see an ATM?

No. I'm also surprised every time I see people constructing sql queries by joining strings with no escaping. Which also happens all the time.

> What exposed code?

We're commenting on an article about a trojan using dynamic linking to inject itself. Try doing that with code loaded straight from flash which is verified by a separate chip. These machines have a chance to verify their whole code before running... but can't really do that if they're running a general-purpose OS. That's what I mean by exposed code. They should crash/report issue as soon as any modification is made.

Yeah, and it would be even safer of the entire functionality of the ATM were implemented as an ASIC. Except that's completely impractical.

My point is that a system's resilence against manipulation is not all that important if the way it is operated affords little or no opportunity for manipulation. Note that the trojan described in the article apparently requires a criminal to be physically present at the machine to harvest the collected information and says nothing about how the machine would get infected. Remote infection (which is impossible for a normally operated ATM) wouldn't be much use when profiting from it requires physical access, so I infection probably also requires physical access to the inside of the machine. That's a worst case security scenario anyway.

> Yeah, and it would be even safer of the entire functionality of the ATM were implemented as an ASIC. Except that's completely impractical.

I agree. That's why I haven't even mentioned it. Running from flash and self-verification is already what most payment terminals do. This is not something new.

Want to be even more surprised? The UI that you're looking at and interacting with - that's HTML pages being displayed in Internet Explorer.

The screenshot shows APTRA which means this is an NCR machine. I've commented on threads here before about how freaking vulnerable and buggy many of the NCR machines are, since they are essentially running Windows XP and are infrequently manually patched with the monthly fixes. There's only three major lock types for the older machines and the internal cage has several PS/2 and USB drives open. There's a manufacturer admin password (one for APTRA Advance and one for APTRA Edge) that lets you get into XP and then you can do whatever you want.

That's an incredibly bad job at blurring the sample. It's both visible through the blur.. and on the text view on the right.

http://st.drweb.com/static/news/20131216-trojan.skimer.18/1g...

I wonder, why blur it at all? What's so useful/dangerous there?

Text view in code page 866:

http://en.wikipedia.org/wiki/Code_page_866

I'd completely forgotten the name of it, thanks!

Many countries with EMV standards implemented (Canada, European countries, Japan, etc.) will use chip over the mag stripe on the back. When this article refers to Track 2 data, it is referring to the magnetic stripe.

Of course, if your card has a mag stripe, it is still susceptible to this attack if you use it in an ATM which reads the track data and has the virus.

The malware reaches extremely deep into the ATM software to decrypt the PIN - it could easily also capture the data which the machine got from the chip.

You obviously don't understand how chip cards work.

Unlike mag-stripe, data elements are not accessible on the chip. The PIN check is performed on the chip card itself, and a PIN cryptogram returned for use in the online transaction. The PIN does not get decrypted at the ATM.

Actually I didn't know the details but had thought that would be the safest method to deal with the PIN. But I assumed you were talking about the equivalent of the "Track 2 data", i.e. issuer ID, account number, etc. Is that also kept away from the ATM?

As for the PIN - if the encryption happens in the chip card, how does it get from the PIN pad to the card in a way that cannot be intercepted?

And finally, what prevents compromised ATM software from displaying "please enter PIN now" while keeping the PIN pad int the direct mode used to enter the amount?

Personally, I consider this the real problem 'fire and forget' systems based on large complex code bases. The US Military invested a ton of money in the development of Ada to try to address some common issues (like you can verify the code still meets the specification).

Why implement a card skimmer? It 'd be far more profitable to write a program which dumps the whole cash in the ATM upon insertion of a special card... saves the cloning costs.

I don't think dumping tens of ATMs is more profitable and less risky than stealing thousands of cards (and who knows for how many months an infection of ATMs could remain undetected, so it maybe even tens of thousands or more).

Cards can be safely resold on black market, and riding all over the city robbing ATMs sounds much more risky activity.

That's an obvious way of stealing money, just by taking the cash. I'm assuming the serial numbers of the money in an ATM is noted, or known by the distributor, so proving a criminal used stolen money after the fact is not too hard to prove.

The operation of this trojan is much more subversive and discreet, whereby it waits and skims card details to be sold on to a third party (assumedly), and is then able to revert the ATM back to a factory state, so it's much more difficult to detect if there's an audit on the machine, or it breaks and sent for repair.

NOTE TO THE NSA/GCHQ: These are educated guesses, I'm not a thief/trojan writer etc

How can I tell if an ATM I'm about to use is vulnerable to this?

Reply on news.ycombinator.com