Category Archives: Banking security

The security of the banking system, as well as hardware and software commonly used in such installations

Chip and skim 2

Banking security, News coverage

The 12:30 ITN news on ITV1 today featured a segment (video) on Chip and PIN, and should also be shown at 19:00 and 22:30. It included an interview with Ross Anderson and some shots of me presenting our Chip and PIN interceptor. The demonstration was similar to the one shown on German TV but this time we went all the way, borrowing a magstripe writer and producing a fake card. This was used by the reporter to successfully withdraw money from an ATM (from his own account).

More details on how the device actually works are on our interceptor page. The key vulnerabilities present in the UK Chip and PIN cards we have tested, which the interceptor relies on, are:

  • The entered PIN is sent from the terminal to the card in unencrypted form
  • It is still possible to use magstripe-only cards to withdraw cash, with the same PIN used in shops
  • All the details necessary to create a valid magstripe are also present on the chip

This means that a crook could insert a miniaturised version of the interceptor into the card slot of a Chip and PIN terminal, without interfering with the tamper detection. The details it collects include the PIN and enough information to create a valid magstripe. The fake card can now be used in ATMs which are willing to accept cards, which from its perspective, have a damaged chip — known as “fallback”. Some ATMs might even not be able to read the chip at all, particularly ones abroad.

The fact that the chip also includes the magstripe details is not strictly necessary, since a skimmer could also read this, but the design of some Chip and PIN terminals, which only cover the chip, make this difficult. One of the complaints against the terminals used in the Shell fraud was that they make it impossible to read the chip without reading the magstripe too. This led to suggestions that customers should not use such terminals, or even that they wipe their card’s magstripe to prevent skimmers from reading it.

While it is possible that the Shell fraudsters did read the magstripe, wiping it will not be a defence against them reading the communication between terminal and chip, which includes all the needed details. Even the CVV1, the code used to verify that a magstripe is valid, is on the chip (but not the CVV2, which is the 3 digit code printed on the back, used by ecommerce). This was presumably a backwards-compatibility measure, as was magstripe fallback. As shown by countless examples before, such features are frequently the source of security flaws.

How to use a chip card whose PIN you don't know

Banking security, Legal issues

We’ve got emails from several people complaining that after their card had been stolen, someone did a fraudulent transaction on it — without knowing the PIN. In some cases the victim had never used the card in a retail transaction and didn’t know the PIN.

An article in yesterday’s Daily Mail hints at how. In technical language, you read the card, which gives you everything except the MAC key. You now write this data to a fresh card, for which you know the PIN. If this clone card is used in an offline terminal, the transaction will go through and the log will show the PIN was correctly entered. The moral, I suppose, is that customers in dispute with their banks should demand that the banks disclose the MAC key and show that the MAC on the transaction log was correct. Whether their systems support this is of course another story.

ATMs and Disclosure Laws

Banking security, Legal issues, Security economics

My local freesheet had an article entitled ‘Skimming device found at Tesco’ (‘Bedfordshire on Sunday’, May 21, p 30). This managed barely 6 column inches, so common is the offence these days. What caught my eye was an appeal by the police for anyone who used the machine at Flitwick between 1030 and 1130 AM on Tuesday last week to check their accounts and report any unauthorised transactions.

Now hang on. What can’t the bank that operates the machine help them? They have the definitive list of potential victims. Come to think of it, when a skimmer is found on Barclays’ machine, and they see that customer X from Lloyds just used it, why don’t they write to Lloyds suggesting they invite her to check her account? Well, you can imagine what Barclays’ lawyers would think of that, but where does the public interest lie?

The Americans do this sort of thing much better. California has a law mandating prompt notification of individuals potentially affected by information compromises, and many other states are trying to follow. According to survey reported by SANS, 71% of Americans want this to become a federal law, and 46% said that they would have serious doubts about political candidates who did not support improving the law.

I initially had my doubts about the Californian initiative, but Tescos in Flitwick are helping convince me.

What's a security problem?

Banking security, Legal issues, Security economics

On Wednesday I was driving back from Oxford and dropped off at Tesco to buy some food. They had an offer ‘5 for 4’ — buy any 5 items of packaged fruit or vegetables and get the cheapest of them for free. I bought seven items. I would have expected to get the fifth cheapest item free, but their computer instead gave me the seventh cheapest item. Here is the evidence.

A few years ago, it was common for website designers to make errors in logic that enabled customers to get unanticipated discounts. These were seen as ‘security failures’. Nowadays it seems that programmers err on the other side. Thankfully, this has stopped the security problems.

Or has it? Here’s how to attack Tesco if you don’t like them. Go and buy six packs of fruit and veg, then take the receipt to your local Trading Standards and make a formal complaint. If a hundred people do that, it’ll cost them plenty.

The Internet allows the rapid dissemination, and anonymous exploitation, of vulnerability information, as Microsoft has learned over the last five years. Maybe there are variants of this lesson that will be even more widely learned.

Watching them watching me

Banking security, Privacy technology

On and off for the past two years, I have been investigating anti-counterfeiting measures in banknotes, in particular the Counterfeit Detection Systems (CDS). At the request of the Central Banks Counterfeit Deterrence Group (CBCDG), this software was added to scanner and printer drivers, as well as to image manipulation packages, in order to detect images of currency and prevent them from being processed.

I wrote a webpage on some experiments I ran on the CDS and gave a talk presenting the results of reverse engineering. Unsurprisingly this drew the attention of the involved parties, and while none of them contacted me directly, I was able to see them in my web logs. In September 2005, I first noticed Digimarc, who developed the CDS, followed a few hours later by the European Central Bank and the US Treasury (both CBCDG members), suggesting Digimarc tipped them off.

However none of these paid as much attention as the Bank of England (also a CBCDG member) who were looking at my pages several times a week. I didn’t notice them for a while due to their lack of reverse DNS, but in December I started paying attention. Not only was their persistence intriguing, but based on referrer logs their search queries indicated a particular interest in me, e.g. Project Dendros Steven Murdoch (Dendros is one of my research projects).

Perhaps they just found my work of interest, but in case they had concerns about my research (or me), I wanted to find out more. I didn’t know how to get in contact with the right person there, so instead I rigged my webpage to show visitors from either of the Bank of England’s two IP ranges a personalised message. On 9 February they found it, and here is what happened…

Continue reading Watching them watching me →

The mythical tamper-proof PIN pad?

Banking security, News coverage

As reported in many places (BBC News and The Register amongst others), Shell have stopped accepting Chip and PIN transactions at all 600 of their directly owned petrol stations in the UK. It is reported that eight arrests have been made, but only a few details about the modus operandi of the fraudsters have reached the media.

Most reports contain a quote from Sandra Quinn, of APACS:

They have used an old style skimming device. They are skimming thecard, copying the magnetic details – there is no new fraud here. Theyhave managed to tamper with the PIN pads. These pads are supposed tobe tamper resistant, they are supposed to shut down, and so that has obviously failed.

It is not clear from the information that has been released so far whether the “magnetic details” were obtained by the attackers through reading the magnetic stripe, or by intercepting the communication between the card and the terminal. Shell-owned petrol stations seem to use the Smart 5000 PIN pad, produced by Trintech. These devices are hybrid readers: it is impossible to insert a card (for a Chip and PIN transaction) without the magnetic stripe also passing through a reader. With this design, there seem to be two possible methods of attack.

  1. A hardware attack. Given the statement that “[the attackers] have managed to tamper with the PIN pads”, perhaps the only technical element of the fraud was the dismantling of the pads in such a way that the output of the magnetic card reader (or the chip reader) could be relayed to the bad guys by some added internal hardware. Defeating the tamper-resistance in this way might also have allowed the output from the keypad to be read, providing the fraudsters with both the magnetic stripe details and a corresponding PIN. It seems fairly unlikely that any “skimming” device could have been attached externally without arousing the suspicion of consumers; the curved design of the card receptacle, although looking ‘suspicious’ in itself, does not lend itself to the easy attachment of another device.
  2. A software-only attack. The PIN pads used by Shell run the Linux kernel, and so maybe an attacker with a little technical savvy could have replaced the firmware with a version the relays the output of the magstripe reader and PIN pad to the bad guys. The terminals can be remotely managed — a successful attack on the remote management might have allowed all the terminals to be subverted in one go.

The reaction to the fraud (the suspension of Chip and PIN transactions in all 600 stations) is interesting; it suggests that either Shell cannot tell remotely which terminals have been compromised, or perhaps that every terminal was compromised. The former case suggests a “hardware attack”; the latter a (perhaps remote) “software attack”.

Even if the only defeat of the tamper resistance was the addition of some hardware to “skim” the magstripe of all inserted cards, corresponding PINs could have been obtained from, for example, CCTV footage.

Attacks like this look set to continue, given the difficulty of enabling consumers to check the authenticity of the terminals into which they insert their cards (and type their PINs). Even the mythical tamper-proof terminal could be replaced with an exact replica, and card details elicited through a relay attack. Members of the Security Group have been commenting on these risks for some time, but the comments have sometimes fallen on deaf ears.

Browser storage of passwords: a risk or opportunity?

Banking security, Security economics

Most web browsers are happy to remember user’s passwords, but many banks disable this feature on their website, shifting the task to customers. This decision might have been rational when malware was the major threat, but doing so hides a cue shown when a known website changes its address. The rise of phishing could thus make their choice counter-productive. We discuss why.

“Autocompletion”, provided by Mozilla/Firefox, Internet Explorer and Opera, saves details entered in web forms, including passwords. This improves usability, as users are no longer required to remember passwords but has some adverse effects on security (we leave aside the privacy problems). In particular, passwords must be stored unencrypted, so putting them at risk of compromise, both by other users of the same computer and malware on the machine. Mozilla improves the situation slightly, by allowing the password database to be encrypted on the hard disk, and unlocked with a master password. However, this is not the default so few will use it; in either case if the browser is left running other users can exploit the passwords, and malware can take them from the process memory.

For this reason, many banks have disabled password autocompletion, by adding autocomplete="off" to the form. This prevents Mozilla and IE storing the password (Opera ignores the website’s request), so resisting the above threats, but does it introduce more problems than it solves? By being imposed with the responsibility of remembering his password, the customer might reduce security in order to manage. He could write down the password and keep this near the computer or on his person; this allows secure passwords but is at risk of compromise by those with physical access. Alternatively he might choose a easy to remember, low security password, and/or use the same one on multiple websites, introducing vulnerabilities from electronic attackers.

More topically, autocompletion resists phishing attacks. A form field is autocompleted if it is at the same URL (IE) or same hostname and field name (Mozilla) as when the password was entered. If a potential victim is sent to a phishing site, autocomplete will not trigger, hopefully causing the user to investigate the site more carefully before remembering and entering the password. Rather than making entering a password a reflex action, autocomplete turns it into an exceptional case, allowing and encouraging pause for thought. However this will not happen for banks; all those I was able to test disabled the feature (Halifax, Egg and Lloyds). Does this improve the security, or just allow banks to shift liability onto customers? Is it the result of a carefully performed risk analysis or simple a knee-jerk reaction against a new feature, more the result of folk-wisdom than sense?

Security economics might help answer these questions. A simplistic analysis is that autocompletion resists phishing but increases the risk of malware and fraud by members of a customer’s household. Deciding on the best course of action requires access to detailed fraud statistics, but the banks keep these as closely guarded secrets. Nevertheless, something still can be said about the comparative risk to customers of the above attacks. Anecdotal evidence suggests that fraud through malware attacks is small compared to phishing, so that just leaves intra-household fraud. At least after the fact, phishing can be easy for the customer to deny. He might have the email, and the transactions are typically international. Fraud by members of a household is considerably more difficult to refute; the transactions might be in person, leaving less of an audit trail and are likely to be local. So rationally banks should enable autocompletion, reducing phishing attacks which they have to pay out for and shifting fraud to the household, which they can pass onto customers.

But the banks haven’t done this. Have they just not thought about this, or does the evidence justify their decision? I welcome your comments.

[Thanks to Ross Anderson for his comments on this issue.]

Fraud or feature?

Banking security

Dual use technologies are everywhere. Myself and colleagues have been presenting Phish and Chips, and the Man-in-the-Middle Defence at the Security Protocols Workshop this week, in which we describe how the EMV protocol suite can be modified in unintended ways, and that a card interceptor can be used for both fraudulent and beneficial activities.

A second example is how the waters in which internet phishermen angle for account details regularly become muddied by the marketing departments of enterprising banks. Every once in a while, these chaps manage to send out genuine emails entreating the user to click on the link in the email, or to navigate to a site not clearly part of the bank’s site, then provide their personal details.

Today I discovered that the same dilemma has been playing out in the fight to secure the fascia of cash machines against the attachment of illicit skimmers. I was off to work promtly this morning, to open up shop for an ITN TV crew doing a piece on Chip and PIN. After cleverly managing to miss my train, I was forced to take a rather expensive taxi ride to Cambridge — so much so that I had to have the taxi stop for me to withdraw some cash. It was then that I spotted this device attached to the slot of the Barclays Bank ATM on White Horse road in Baldock, Hertfordshire.

ATM attachment detail side

Continue reading Fraud or feature? →

Chip and skim

Banking security, News coverage

We recently built an EMV transaction interceptor to aid us in understanding the viciously complex EMV protocol suite. A useful byproduct is that we can now give demonstrations of interception and relay attacks on Chip and PIN — topics discussed in our paper Chip and Spin. Since German TV picked up on our interceptor experiments, there has been some discussion about whether these attacks really work, and what it means for Chip and PIN security.

First off, intercepting smartcard communications is not rocket science; EMV is built on the ISO 7816 standard for smartcards. Interceptor hardware necessarily exists for test purposes (Micropross is a well known test rig manufacturer) but it doesn’t come cheap. Not willing to cough up a grand, we decided to do it on the cheap: we wrote a very basic microcontroller program which samples the smartcard I/O data line as fast as it can, and passes the data back via USB for decoding on a laptop.

EMV Interceptor picture

This prototype is a useful price point for the cost of a smartcard interceptor: for example, we bought a suitable microcontroller development board from Siphec for about $60. Our Chip and PIN (EMV) Point-of-Sale Terminal Interceptor page describes both this device and claims that sufficient information can be captured from a trace of an EMV transaction to recover the customer PIN, and to produce a magnetic stripe counterfeit of the card.

That we built a working interceptor is not under dispute, but is the above claim true? Would it actually work in practice? For this goal, a number of extrapolations must hold true:

  • The PIN must travel in the clear across the wires to the smartcard. UK cards are SDA cards, so the PIN is not encrypted. In theory the PIN could be routed for verification at the bank rather than by the card, but the UK also opted for local verification only.
  • The customer PAN and CVV1 must be sent by the smartcard. More generally, all the information required to reconstruct the magnetic stripe must be present. The PAN is clearly sent as it is required for the EMV transaction itself. In the half dozen or so UK cards we have examined, the same CVV1 appeared to present in the chip data as on the magstripe, though we were aware of some suggestions that the CVV1 was blanked out on the chip equivalent data. The EMV specification says that all records stored on the chip are read out during a transaction, and the traces appear to confirm this.
  • There must be no further secret authentication mechanisms for the card or magstripe. In Germany, magstripe cards carry a hidden “MM-code” which is correlated with a copy encoded on the magstripe; the method to read the MM-code is kept secret. In the USA there is some use of automated counterfeit hologram detection. It seems no such methods are in use in the UK; journalist Jonathan Maitland from Tonight with Trevor MacDonald successfully produced and used a counterfeit white card produced purely from a dump of track 1 and 2 magstripe data.
  • A suitable target ATM must be found at which to use the counterfeit card. Clearly there are plenty of ATMs in foreign countries which do not support Chip and PIN, so targets do exist. Within the UK there are three ways for an ATM to be vulnerable. First, if it has not been upgraded to support chip cards, it must necessarily use the magstripe. Second, if the chip-enabled ATM cannot tell with certainty that a card is supposed to be a chip card, then it may assume it is a magstripe card. Seeing as practically all UK ATMs are online the issuing bank can always be queried, so this second vulnerability mode is unlikely. Third, if the ATM supports fallback to magstripe, for instance in the case of damaged chips, then it will work. Conditions under which ATMs permit fallback actually appear to be quite complex, dependent for example on time of day and fraud history on that machine. There was certainly no problem finding viable ATMs in the UK when the Trevor MacDonald program aired, this time last year.
  • It must be possible to adequately miniaturise and camouflage the interceptor. Miniaturisation of the circuitry is not the bottleneck here, very small form-factor microcontrollers can be found, and few other discrete components are needed. The real miniaturisation challenge comes in gaining physical access to the electrical contacts covertly. The reader slot is wide enough to admit a thin second item, such as a flexible PCB, or maybe some other sort of plastic sheet with conductive ink, but the space is of the order of 0.1 mm, a typical card being about 0.8 mm thick. The alternative is not to go for a miniature solution per se, but a well camouflaged fake slot which sits outside the main slot. Different form-factor terminals would clearly have different optimal designs for cheap interceptors.
  • The POS terminal must not be able to detect the presence of an interceptor. Some modernised ATMs are able to detect unauthorised attachments designed to directly skim PIN and magstripe, there is no fundamental reason why such technology could not be applied to POS terminals as well. However we have found that there definitely are UK POS terminals which do not detect such attachments, for reasons of cost, we suspect.

Is there missing piece to this jigsaw that we have overlooked in our investigations, or are banks simply reluctant to admit that POS terminals are at least equally vulnerable to the same sorts of magstripe skimming attacks as ATMs? I’m eager to find out.

Banks don’t help fight phishing

Banking security, Privacy technology

I recently got an email from Bank of America offering me a pretty good credit card deal. Usually, I chuck those offers away as spam (both electronic and physical) but this time I decided to bite.

The “apply now” button pointed to http://links.em.bankofamerica.com:8083/…, fair enough. I click. But wait… IE6 says…

Certificate warning IE

Firefox provides more info without layers of abstraction…

Certificate warning FF

I clicked “OK” and got to… https://www.mynewcard.com/! (you’ll notice that going there directly redirects to https://mynewcard.bankofamerica.com/, so only when you click “apply” do you get to see mynewcard.com.)

I consequently emailed BofA with my concerns and got this (surprisingly expedient) reply:

“We recognize that any unsolicited e-mail, legitimate or otherwise, is reason for concern. I can assure you that www.mynewcard.com is a legitimate website of Bank of America.”

Well, not much assurance there since I replied to the original email (cardservices@replies.em.bankofamerica.com), but a whois query confirms that mynewcard.com indeed belongs to BofA. What percentage of the population would go beyond clicking that “OK” on the IE warning as just another annoyance? You know the answer.

So, BofA got three things wrong. Firstly, they had links in the body of the email; the argument has been beaten to the ground… don’t educate people to click them. If the bank has great offers, they should have them available when people log into their accounts. Secondly, they messed up on the certificate… it’s for mynewcard.bankofamerica.com, not what appears in the address bar, mynewcard.com. And finally, they used an unfamiliar domain to process the application. Why? I think the answer lies somewhere in the marketing department where they decided that mynewcard.com is cooler sounding than sound security measures and long term good customer training.

Update: Richard mentioned that the rapid response meant that BofA have heard this concern once before. I found this thread [dansanderson.com] discussing mynewcard.com in August 2003! Which adds a fourth thing BofA did wrong: they didn’t fix it!