The ATM Vulnerability You Won't Hear About

The talk has been pulled from the BlackHat conference:

Barnaby Jack, a researcher with Juniper Networks, was to present a demonstration showing how he could jackpot a popular ATM brand by exploiting a vulnerability in its software.

Jack was scheduled to present his talk at the upcoming Black Hat security conference being held in Las Vegas at the end of July.

But on Monday evening, his employer released a statement saying it was canceling the talk due to the vendor’s intervention.

More:

“The vulnerability Barnaby was to discuss has far reaching consequences, not only to the affected ATM vendor, but to other ATM vendors and—ultimately—the public,” wrote Brendan Lewis, director of corporate social media relations for Juniper in a statement posted to the company’s official blog last week. “To publicly disclose the research findings before the affected vendor could properly mitigate the exposure would have potentially placed their customers at risk. That is something we don’t want to see happen.”

More news articles: 1, 2, 3, 4, and 5.

Tags: , ,

Posted on July 9, 2009 at 12:56 PM • 46 Comments

Comments

ac • July 9, 2009 1:33 PM

A fully loaded ATM can hold up to $600,000.
Safe to assume they would open the door or something, not be dispensing this through the little slot?

Mark • July 9, 2009 1:45 PM

Phew…that was a close one. Thankfully we’re all safe now because no one knows what the vulnerability is!

John Faughnan • July 9, 2009 2:12 PM

I wonder if it’s an OS/2 bug. Apparently it’s still used in ATMs.

Since OS/2 is no longer supported, fixing it could be rather non-trivial.

Chris • July 9, 2009 2:19 PM

Duh! No news here…

This is why people need to pick duller titles, and why conference organizers need to help keep the secret. There are a few presenters who, without fail, always come up with very good talks. Have one or two slots available for “______ is going to talk about something interesting.”

moo • July 9, 2009 2:41 PM

I hope they do release the info later, after the vendor has had some time to mitigate.

In this case I don’t have a problem with the temporary suppression of the information, because releasing it would probably increase the number of ATMs that get ripped off for Real Cash Money(tm), before the vendor is able to patch them. At least, I assume they aren’t going to stick their fingers in their ears and going “La, la,la,lalalala” since this is ATMs and Real Cash Money(tm) we’re talking about.

Lyel • July 9, 2009 2:44 PM

@John Faughnan

From the second link in Bruce’s post:

“The presentation would have focused on exploiting vulnerabilities in devices running the Windows CE operating system, including some ATMs, according to a source familiar with the details.”

Nicko • July 9, 2009 3:22 PM

One wonders if the ATM company might have been less inclined to intervene if he’d had a more nondescript title for the talk. Calling your talk “ATM Jackpot” seems calculated to raise the wrong type of attention, sort of like last year’s pulled talk: “How To Get Free Subway Rides For Life.”

eve wears a badge • July 9, 2009 4:34 PM

E pur si muove!

This news makes me physically feel sick to my Stomach.

Every year Defcon gets more corrupt, and more of an industry tool. Defcon should not promote security through obscurity. It’s so sad to see hacker culture take such a nose dive in terms of academic integrity and ethics. At least there is still the CCC.

Clive Robinson • July 9, 2009 4:58 PM

Sadly what is not clear is if it is the ATM vendor that is to blaim for a bug in their code, or that their code uses a “creative feature” in the Micro$haft OS code.

If it is the latter then potentialy it is not just ATMs that will be open if the exploit is revealed prematurly.

However I have little sympathy for people developing what are effectivly embedded systems on an OS that has a reputation for being like “Emmental”

billswift • July 9, 2009 5:31 PM

From the Technology Review article Bruce linked: “The presentation would have focused on exploiting vulnerabilities in devices running the Windows CE operating system, including some ATMs, according to a source familiar with the details. While the presentation was canceled to allow manufacturers more time to fix the vulnerabilities, Juniper had originally notified the company almost eight months ago, says the source, who asked not to be named.”

So it’s Windows CE and they have already had 8 months to fix it.

Pat • July 9, 2009 7:39 PM

Corrections: Most (if not all) ATMs cannot physically support more than a few tens of thousands of dollars at a time, and the majority of deployments are refilled with smaller amounts more frequently to minimize risk (insurance compliance).

Also, not every ATM runs on OS/2 or Windows CE. In fact, may run their own platforms with their own software from the ground-up. Windows-powered ATMs are just starting to make a significant influence on the market (after many in the industry resisted the adoption of such due to security concerns), which can be, of course, unfortunate to those who realize the potential of embedded Linux and BSD systems.

Even if the security vulnerability was announced eight months before the talk, it is extremely expensive to install updates on ATMs (usually, if not always, requires a physical visit to the ATM by a service person) and ATM operators (banks, bank-independent convenience stores, etc.) do not usually wish to spend money to update their 20, 50, or 100 or more ATMs and constantly beg to push back update deadlines and shift liability for upgrades to others. It is unfortunate, but most ATMs do not yet have the connectivity necessary to perform frequent, sequential updates (like PCs and servers do), so we will be seeing this pattern of delayed patching for another five or ten years.

Josh • July 9, 2009 9:47 PM

@Pat “It is unfortunate, but most ATMs do not yet have the connectivity necessary to perform frequent, sequential updates (like PCs and servers do), so we will be seeing this pattern of delayed patching for another five or ten years.”

I’d say it’s probably for the best that ATMs generally don’t have outside connectivity 🙂 Until they can make the machines absolutely foolproof against physical tampering via the keypad (and running Windows isn’t going to help that), putting any sort of network connection on it seems risky.

dob • July 9, 2009 11:03 PM

Uh, of course ATM’s have outside connectivity. They have to verify PIN and adjust balances.

loudambiance • July 10, 2009 12:05 AM

@dob, your statement is only half correct. The ATMs do have to adjust balances via an outside connection, however, your pin number is stored on the magnetic strip.

Wilbur • July 10, 2009 12:24 AM

@loudambiance: “however, your pin number is stored on the magnetic strip.”

Really? So how come I can change my PIN when I go into a bank, and they only swipe my card through a reader?

I don’t know your source, but your claim doesn’t ring true to me.

Ian • July 10, 2009 1:38 AM

The PIN is not stored on the magnetic stripe. One way PINs are handled is as follows: The card number is hashed using a secure algorithm to produce a “natural” PIN. The difference between the cardholder’s PIN and the natural PIN is called the PIN offset, and is carried on the magnetic stripe of the card. The message to the bank includes the card number and PIN offset, as well as the encrypted PIN that was entered at the ATM. The bank holds the key to recalculate the natural PIN and confirms that the entered PIN together with the PIN offset on the card matches the natural PIN.

Clive Robinson • July 10, 2009 4:46 AM

There appears to be a bit of confusion over peoples PINs being stored on the cards.

It is and the reason is historical for “off line” transactions.

It you look up the American Bankers Ascociation (ABA) documents for the format of the card and three data tracks on the mag strip you will find how the pin “hash” was to be stored (effectivly the least significant 16 bits of the resulting encryption of the pin number etc).

The reason for doing this was that twenty or so years ago computers (even mainframes) where slow and data comms not at all reliable (think long distance dial up and modem for a comparison today).

This meant that at certain times of the day no ATM could not communicate with the “data center” due to it being off line for backups/maintanence/etc (usually an hour in the early morning). And intermitantly at other times of the day depending on the loading and interferance on the data coms network.

So for “customer conveniance” and the banks reputations “off line mode” was considered desirable. It also alowed banks to put ATM machines in at conventions, fairs and other temporary places where comms would be to difficult or expensive to justify (just over 1/4 of a century ago it could take over three months to get a phone line connected let alone a leased data line in many many places).

The real problem is that “off line” working is a great big security hole which card scammers have and still use at our (not the banks) expense.

Worse in the UK the advent of “chip-n-pin” has actually made the security worse for the customer not better because if the “chip” does not work or cannot be used for “Customer conveniance” Chip-n-Pin auto defaults back to the ABA Mag Stripe…

So Card Scammers still read you pin and stripe at ATM machines and instead of using “cloned cards” in the UK they use them in parts of Europe that do not have Chip-n-Pin for buying “white goods” and fuel in large quantaties.

And because the rules of Chip-n-Pin are different to credit cards the bank can pass the cost back to you for “not taking care of your PIN”…

So the scammers win the banks win and you the poor customer get right royaly 5cr3wd by both of them.

Steve • July 10, 2009 5:38 AM

Of course there are less technically elegant, and possibly more effective methods to remove cash from an ATM.

http://www.eyeoncrime.co.za/?q=node/167

Admitedly its not exactly inconspicuous, but some entrepreneurs in South Africa have proven it to be quite repeatable after a short ‘repair’ interval.

Rob • July 10, 2009 6:14 AM

Speculation… The only people who would have benefited (financially) from this demonstration are the same niche group of people who would benefit from a similar online banking crack.

If that’s the case, why are (proprietary) algorithm attacks published?

Jurjen • July 10, 2009 7:23 AM

@Peter
Didn’t anyone notice the resemblance between the Diebold protection “blue glowing bubbles” and soap bubbles? I find the choice of methaphore quite appropriate, actually.
Their honesty was probably unintentional.

sooth sayer • July 10, 2009 8:12 AM

Why blame the ATM vendor alone? Aren’t banks the real culprit for having nuts running around collecting TARP and letting the money ooz out from the pockets?

Vendors will built what sells .. and if the banks want to buy junk that’s really not a vendors problem.

I am glad this time Bruce wasn’t attacking his favorite lapdog company; but most comments seem to. I wish Bruce had clarified — I think IBM/NCR are the other 2 big vendors of ATM machines — are they complicit too?

Clive Robinson • July 10, 2009 8:31 AM

@ Rob,

“If that’s the case, why are (proprietary) algorithm attacks published?”

The simple answer “Fame and Fortune”.

If you get the reputation of being able to find security weaknesses in peoples code “sight unseen” then you will usually find that your name will become known (Fame) and people will make use of your services at the rates you like to charge (Fortune) simply because of the “fame” you achive with your publication.

As far as security is concerned “There be gold in them there hills” and you have two ways of benifiting by it, firstly dig it up yourself the second rent your services out as a “gold finder” of the two the second is by far the easiest if people will pay you which is where reputation/fame come in from having previously dug up a few large nuggets. Oddly if you play it right you can earn money without finding gold by saying where it won’t be… but that just makes you an overpaid consultant which I guess is just another form of gold digger 😉

Rob • July 10, 2009 9:10 AM

@ Clive,

Thanks for your answer!

Well in that case, I urge Barnaby Jack and his fellows at Juniper Networks to run to them there hills, heavy laden with gold and the secrets of renewable (but not indefinite) wealth!

Thanks again!

Ian • July 10, 2009 9:35 AM

@Clive Robinson
I was describing Visa PVV, which is one of the most common ways that PINs are handled.

Your offline scenario requires the ATM to have a copy of the bank’s encryption key. Perhaps the bank would trust their own ATMs with this key, but they probably wouldn’t distribute it more widely.

Offline authorization also opens the bank up to fraud by their own customers, since the balance is not checked, so a customer could overdraw their account, not just on one ATM but on multiple different ATMs while offline.

Clive Robinson • July 10, 2009 10:49 AM

@ Ian,

“I was describing Visa PVV, which is one of the most common ways that PINs”

Yes that’s one ot the major ways it’s done today. However I personaly think it should not be there even as a hash as I said,

“It is and the reason is historical for “off line” transactions.”

Which thirty years ago might have been reasonable but in no way is today, which is why I also said,

‘The real problem is that “off line” working is a great big security hole which card scammers have and still use at our (not the banks) expense.’

If we are going to switch to Chip-n-Spin then it should be the whole hog not this idiotic fallback for “customer conveniance”. All the fall back has realy done is increase the levels of card crime at the customers exspense.

Worse in the UK for “efficiency” reasons the Police nolonger investigate individual cases of this type of card fraud. Instead they refer you back to the Bank for them to investigate.

And has been shown in court the banks do not make available to the customer how a transaction was performed against their account. Apparently there are propriatry technical reasons (according to the Banks). But it alows them to say it’s the customers fault without real fear of being accused of lying to the judge.

The sooner the UK Gove stops being enamered by these crooks and their idiotic notions that the “fox should mind the hen house” (self regulation) and hits them with good solid consumer protection law the better it will be for everybody the banks included.

I for one am tired of the mantra that the banks are vital to the economy (they are not) and to big to fail (gives them blackmail leverage), and strict regulation will force them abroad (more blackmail leverage).

The banking industry is a hostile cartel that uses just about every trick it can to prevent an open and fair market. As far as I can see much of what they do in effect would be illegal in any other industry. Oddly it looks like the EU has started to wake up to this and their new draft directives hopefully will open up some asspects of the banking industry to well overdue competition.

Clive Robinson • July 10, 2009 11:05 AM

@ Ian,

“Your offline scenario requires the ATM to have a copy of the bank’s encryption key. Perhaps the bank would trust their own ATMs with this key, but they probably wouldn’t distribute it more widely.”

Actually it does not require them to have a copy of the banks ATM key.

What you are doing is turning an encryption alg into a one way hash, and you can use and publish this key entirly seperatly from any other key.

Only when the customer has typed in their pin can you know the full plaintext and you know the key so can derive the 16bit hash value on the card to check against.

However knowing the key and the 16bits from the card does not alow you to decrypt back to the full plaintext.

You could fairly trivialy (these days) do the 10000 tries in the forward direction which is why this system (should) nolonger be in use.

And this is the real problem humans have trouble with 4 digits which is trivial to run through any hash which is why “off line” transactions and fall back transactions should never ever be performed.

trsm.mckay • July 10, 2009 2:40 PM

Don’t forget the ATM/POS industry has matured over the years. The original Barcley’s card did not have a PIN at all (having the card was enough), than they added an ATM local verification scheme, etc. Even with forced card base turnover (1-2 years for normal mag stripes, perhaps as many as 5 for HiCo), it is amazing how much legacy stuff is out there. News flash – bankers are conservative about security mechanisms 🙂

Many smaller banks still store PIN hashes on their cards, indeed one of my ATM cards has a hash written on it by a product I worked on (always cool to see things you helped produce in the field). But putting hashs on the card has become less common with the bigger banks; both because of better online connections and the security problems that arise because of offline transactions.

I’ve commented on the PIN algorithms, topics here before, particularly when Mike Bond found some HSM API issues with the IBM 3624 algo (where the natural PIN and offset terminology Ian talks about above comes from). Very common at one point, but hopefully in the decline (it has a number of security issues beyond the HSM API issues). The Visa PVV algorithm is better, but my preferred solution is to eliminate the hash altogether.

I think hashes have out lived their useful properties (primarily they don’t need confidentiality when stored on a database or card). Comparing a reversibly encrypted reference PIN eliminates any chance of synonyms (a 4-digit PIN with a typical IBM 3624 4-digit offset will have 5-10 other PINs that will verify as correct). This does require a good HSM API, because you need to separate the reference PIN from the trial PIN; and deal with the many-to-many relationship between card numbers (PAN) and customer accounts.

trsm.mckay • July 10, 2009 3:03 PM

@Clive, I can understand your hostility to the banking cartel, at least in the UK. I remember in the 90’s being surprised at how many banks still had implementations that had been eliminated as unsafe in the US (for example not XORing the account number before encrypting the PIN block). Of course there is very little in the way of checking in the US (except for not-on-us transactions which fall under PCI now), so I would not be entirely surprised if a few small US banks has some similar on-us issues.

But I have to confess your discussion of attacking PIN encryption schemes exhaustively has me puzzled. The PIN system has always been concerned about exhaustive trial PIN attacks. Every system involved with clear PINs or keys has to be designed to prevent that. This is usually done with a combination of split duties (ATM’s can accept news PINs, backend systems can verify), and velocity checking (only enter wrong PIN x number of times). As someone who designs the HSM APIs on the backend, I can assure you it is the number one analysis point when creating a new API.

I would say that the use of smartcards has not always been smooth. A number of designers did not understand the PIN system very well. I can’t tell you how many times when designing custom HSM API commands, I had to deal with clueless smartcard implementations. My least favorite was the lack of XORing the account block into the encrypted PIN (they figured it was not needed to unlock the card, forgetting about cases where the card reader is separated from the secure keypad). Some times I still could still come up with good APIs, and occasionally I even got the smartcard guys to change things (I got one change out of the 3 requests I made to EMV 🙁

ak • July 10, 2009 9:17 PM

Should really be released on wikileaks or something for the greater good. The longer the vulnerability is kept secret, the longer owners of the ATMs will keep them operational, leaving them open to the few high-tech criminals that have probably already discovered the vulnerability. Sometimes informational shockwaves are good because they create necessary attention for a security hole that needs fixing sooner rather than later.

The ATM vendors want to keep making money while the vulnerability exists without telling owners to shut down their machines. This doesn’t make sense security-wise, it only make sense in the interests of the vendor.

Xyz • July 13, 2009 12:55 PM

From the Reg article:
‘The talk, which was titled “Jackpotting Automated Teller Machines,” was to include a demonstration showing how the ATM could be forced to disburse all its cash, according to Risky.Biz, which reported the cancellation earlier.’

After you’ve executed this trick, with all the subtlety of then having to shove fistfuls of twenties into a giant sack (with a big green $ on it, of course) and pull off an escape with it, you may as well have busted the machine open with a sledgehammer.

Dude Don't Taze Me • July 13, 2009 7:12 PM

The ATM Vulnerability You Wil Cry About

http://www.int.iol.co.za/index.php?set_id=1&click_id=15&art_id=vn20090709112643917C840069

A [South African] bank has fitted 11 of its ATMs across the Cape Peninsula with pepper spray to deter criminals from tampering with them.

Absa said it had introduced the new technology to help prevent ATM bombings and card skimming after several ATMs around the country were blown up last year.

But the plan is not without its pitfalls.

The pepper spray fitted in an ATM in Fish Hoek was accidentally emitted during a routine maintenance inspection at the weekend.

Three people had to be treated after inhaling a cloud of pepper spray, Absa spokesman Gavin Mageni said.

Mageni said the new technology involved using cameras at high-risk ATMs.

Brad Freeman • July 15, 2009 7:54 AM

Ah irony!

The Deibold ATM in our lobby was last month “upgraded” from os/2 to WinCE.

I hung around and genially mocked the service tech. We kidded about viruses.

His name’s Jeff. He’s been back every week since then to fix the locked-up ATM.

Gordon • July 15, 2009 1:16 PM

Following Dude Don’t Taze Me (an entirely seperate topic…), the simplest means of extracting cash from an ATM is a kgs of commercial explosive.
Here in sunny RSA the local banks probably have 2 or 3 ATMs destroyed a week, hence the ‘deterent’ pepper spray.

As Bruce reminds us, if one has physical access to a machine, one can own the machine.

Dave • July 18, 2009 5:11 AM

One point for all of you that seem to prefer to focus on a single vendor. There is not a single Diebold, NCR or Wincor-Nixdorf ATM on the planet that runs Windows CE.

Al • July 18, 2009 9:01 PM

@eve: First, BlackHat and DEFCON aren’t the same. Second, it doesn’t look like BlackHat (or DEFCON, for that matter) pulled the presentation, but that the presenter’s employer exerted some pressure on the presenter.

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.