Category Archives: Banking security

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

Non-cooperation in the fight against phishing

Tyler Moore and I are presenting another one of our academic phishing papers today at the Anti-Phishing Working Group’s Third eCrime Researchers Summit here in Atlanta, Georgia. The paper “The consequence of non-cooperation in the fight against phishing” (pre-proceedings version here) goes some way to explaining anomalies we found in our previous analysis of phishing website lifetimes. The “take-down” companies reckon to get phishing websites removed within a few hours, whereas our measurements show that the average lifetimes are a few days.

These “take-down” companies are generally specialist offshoots of more general “brand protection” companies, and are hired by banks to handle removal of fake phishing websites.

When we examined our data more carefully we found that we were receiving “feeds” of phishing website URLs from several different sources — and the “take-down” companies that were passing the data to us were not passing the data to each other.

So it often occurs that take-down company A knows about a phishing website targeting a particular bank, but take-down company B is ignorant of its existence. If it is company B that has the contract for removing sites for that bank then, since they don’t know the website exists, they take no action and the site stays up.

Since we were receiving data feeds from both company A and company B, we knew the site existed and we measured its lifetime — which is much extended. In fact, it’s somewhat of a mystery why it is removed at all! Our best guess is that reports made directly to ISPs trigger removal.

The paper contains all the details, and gives all the figures to show that website lifetimes are extended by about 5 days when the take-down company is completely unaware of the site. On other occasions the company learns about the site some time after it is first detected by someone else; and this extends the lifetimes by an average of 2 days.

Since extended lifetimes equate to more unsuspecting visitors handing over their credentials and having their bank accounts cleaned out, these delays can also be expressed in monetary terms. Using the rough and ready model we developed last year, we estimate that an extra $326 million per annum is currently being put at risk by the lack of data sharing. This figure is from our analysis of just two companies’ feeds, and there are several more such companies in this business.

Not surprisingly, our paper suggests that the take-down companies should be sharing their data, so that when they learn about websites attacking banks they don’t have contracts with, they pass the details on to another company who can start to get the site removed.

We analyse the incentives to make this change (and the incentives the companies have not to do so) and contrast the current arrangements with the anti-virus/malware industry — where sample suspect code has been shared since the early 1990s.

In particular, we note that it is the banks who would benefit most from data sharing — and since they are paying the bills, we think that they may well be in a position to force through changes in policy. To best protect the public, we must hope that this happens soon.

Making bank reimbursement statutory

Many of the recommendations of the House of Lords Science and Technology Committee report on Personal Internet Security have been recycled into Conservative Party policy [*] — as announced back in March. So, if you believe the polls, we might see some changes after the next election or, if you’re cynical, even before then as the Government implements opposition policy!

However, one of the Committee recommendations that the Conservatives did not take up was that the law should be changed so that banks become liable for all eBanking and ATM losses — just as they have been liable since 1882 if they honour a forged cheque. Of course, if the banks can prove fraud (for cheques or for the e-equivalents) then the end-user is liable (and should be locked up).

At present the banks will cover end-users under the voluntary Banking Code… so they say that there would be no difference with a statutory regime. This is a little weak as an objection, since if you believe their position it would make no difference either way to them. But, in practice it will make a difference because the voluntary code doesn’t work too well for a minority of people.

Anyway, at present the banks don’t have a lot of political capital and so their views are carrying far less weight. This was particularly clear in last week’s House of Lords debate on “Personal Internet Security”, where Viscount Bridgeman speaking for the Conservatives said:

“I entirely agree with the noble Lord, Lord Broers, that statutory control of the banks in this respect is required and that we cannot rely on the voluntary code.”

which either means he forgot his brief! or that this really is a new party policy. If so then, in my view, it’s very welcome.

[*] the policy document has inexplicably disappeared from the Conservative website, but a Word version is available from Microsoft here.

Card Wars: The Phantom Menace

Just like George Lucas can’t help but return to his old projects, I have been returning to mine. After three years of stagnation, I am pleased to announce the re-launch of phantomwithdrawals.com, freshly re-vamped, updated and turned into a wiki editable by the general public.

In fact, it’s not just great artists like Mr. Lucas and I starting up old projects, our honourable colleagues wearing the black hats have got the same idea. We have new victims reporting in, rumours abound of an auth system compromise at Citi, the Ombudsman is backlogged with months of disputed withdrawal cases, and some like Alain Job are even going to court.

One original contributor to the phantom case histories has just been hit by a second phantom withdrawal five years on and is chalking up another case in the files. While her new phantom is a bread-and-butter skim incident (a magstripe clone used in the far east), amongst this mass, true phantoms — the real mystery cases — are on the rise too. Two new victims with whom I have been corresponding very kindly offered to fund the hosting for the revamped site.

Let’s consider one of these mysteries. The McGaughey case has been reported in the media in Northern Ireland: dozens of withdrawals taking place over four weeks, totaling almost five thousand pounds, all within a ten mile radius of the McGaughey’s home. Summarised that way it looks like a classic first party fraud (couple short on cash withdraw money, then deny it later). But no-one in the family is short on cash, the McGaugheys look after their card details carefully, and have solid alibis at the time of many of the withdrawals, and the interlocking pattern of real and disputed withdrawals is such that any third party would have a hard time taking and returning the card (whether covertly or in collusion with the McGaugheys). No-one appears to have either the means or the motive.

Unusually the bank has been very cooperative, providing logs from their authorisation system (BASE24), including all of the cryptograms, input data and transaction parameters covering the affected transactions. Everything turns on the Application Transaction Counter (ATC), an on-card counter which increments with every transaction initiated. If an EMV chip can be fully cloned (secret keys and all), then it will have to submit an ATC value when transacting, and if used in parallel with the real card, it won’t be long before the same number pops up twice in the auth system, or large gaps in the sequence appear. The McGaughey’s ATC sequence appears to interlock perfectly: clearly the original card was used?

Of course logs can be misinterpreted (Badger) or even faked, auth systems may not work as expected, and customers may lie and cheat following all sorts of agendas; just around the corner the missing piece of the jigsaw may lie, which reveals the truth behind the case. And there is the totally separate matter of who should suffer the loss in the interim, whilst the truth remains unclear. Liability for disputed withdrawals is the most hotly contested issue of all.

phantomwithdrawals.com can’t do much more for the McGaugheys, but it can bear witness. Documenting the incidence of phantoms and the experiences of customers disputing them adds much needed transparency to the process, and helps researchers and experts seek out the really interesting cases.

Maybe we can lift the lid and discover the truth behind the “phantom menace” — everyone is united in that goal at least — but let’s also hope that Episode 2: Attack of the Clones has not yet started shooting!

Slow removal of child sexual abuse image websites

On Friday last week The Guardian ran a story on an upcoming research paper by Tyler Moore and myself which will be presented at the WEIS conference later this month. We had determined that child sexual abuse image websites were removed from the Internet far slower than any other category of content we looked at, excepting illegal pharmacies hosted on fast-flux networks; and we’re unsure if anyone is seriously trying to remove them at all!
Continue reading Slow removal of child sexual abuse image websites

PED vulnerability paper receives "Most Practical Paper" award at Oakland

In February, Steven Murdoch, Ross Anderson and I reported our findings on system-level failures of widely deployed PIN Entry Devices (PED) and the Chip and PIN scheme as a whole. Steven is in Oakland presenting the work described in our paper at the IEEE Symposium on Security and Privacy (slides).

We are very pleased that we are the recipients of the new “Most Practical Paper” award of the conference, given to “the paper most likely to immediately improve the security of current environments and systems”. Thanks to everyone who supported this work!

IEEE Security & Privacy Magazine Award

Second edition

The second edition of my book “Security Engineering” came out three weeks ago. Wiley have now got round to sending me the final electronic version of the book, plus permission to put half a dozen of the chapters online. They’re now available for download here.

The chapters I’ve put online cover security psychology, banking systems, physical protection, APIs, search, social networking, elections and terrorism. That’s just a sample of how our field has grown outwards in the seven years since the first edition.

Enjoy!

New Banking Code shifts more liability to customers

The latest edition of the Banking Code, the voluntary consumer-protection standard for UK banks, was released last week. The new code claims to “give customers the most up to date information on how to protect their accounts from fraud.” This sounds like a worthy cause, but closer inspection shows customers could be worse off than they were before.

Clause 12.11 of the code deals with liability for losses:

If you act fraudulently, you will be responsible for all losses on your account. If you act without reasonable care, and this causes losses, you may be responsible for them. (This may apply, for example, if you do not follow section 12.5 or 12.9 or you do not keep to your account’s terms and conditions.)

Clauses 12.5 and 12.9 include some debatable advice about anti-virus software and clicking on links in email (more on this in a later post). While malware and phishing emails are a serious fraud threat, it is unrealistic to suggest that home users’ computers can be adequately secured to defeat attacks.

Fraud-detection algorithms are more likely to be effective, since they can examine patterns of transactions over all customers. However, these can only be deployed by the banks themselves.

Existing phishing schemes would be defeated by two-factor authentication, but UK banks have been notoriously slow at rolling out these, despite being widespread in many other European countries. Although not perfect, these defences might cause fraudsters to move to easier targets. Two-channel and transaction authentication techniques additionally give protection against man in the middle attacks.

Until the banks are made liable for fraud, they have no incentive to make a proper assessment as to the effectiveness of these protection measures. The new banking code allows the banks to further dump the cost of their omission onto customers.

When the person responsible for securing a system is not liable for breaches, the system is likely to fail. This situation of misaligned incentives is common, and here we see a further example. There might be a short-term benefit to banks of shifting liability, as they can resist introducing further security mechanisms for a while. However, in the longer term, it could be that moves like this will degrade trust in the banking system, causing everyone to suffer.

The House of Lords Science and Technology committee recognized this problem of the banking industry and recommended a statutory change (8.17) whereby banks would be held liable for electronic fraud. The new Banking Code, by allowing banks to dump yet more costs on the customers, is a step in the wrong direction.

A false accusation of "hacking"

One particular style of phishing email runs something like this (edited for brevity):


From: service@paypalL.com
Subject: Your account was hijacked by a third party.

Dear PayPal valued account holder,

We recently noticed one or more attempts to log in your PayPal account from a foreign IP address and we have reasons to believe that your account was hijacked by a third party without your authorization.

If you recently accessed your account while traveling, the log in attempts may have initiated by you.

However if you are the rightful holder of the account, click on the link below and submit, as we try to verify your account.

The log in attempt was made from:

ISP host: sargon.cl.cam.ac.uk

etc...

well, spare a thought for the lucky owner of sargon.cl.cam.ac.uk (not its real name), because sometimes when people receive these emails they see it as compelling evidence (kindly supplied by PayPal) of someone who was trying to hack into their account and steal all their money.

In practice of course, the accusation is as false as the rest of the email, which is merely designed to get you to click on a link to visit a phishing website and reveal your PayPal login credentials to the criminals.

We’ve found examples of emails mentioning our machine name in several web archives, so it looks as though this part of the rubric isn’t entirely random, but is chosen from a shortlist… and on two recent occasions people have worked out where this machine is located and have decided to get in touch with our hardworking sysadmins to complain about, it is assumed, some students who are acting in a criminal manner.

Such complaints would be straightforward to deal with, except that the “sargon” machine happens to be used for monitoring phishing website lifetimes. Fairly regularly this leads to correspondence, when people clearing up an intrusion into their machine come across our monitoring visits in their web server logs. Of course once we explain the nature of our research, everyone is happy.

Anyway, last weekend someone complained about us hijacking his PayPal account, and it was immediately assumed that it just someone else looking at their logs, and so there was little here to be unduly worried about.

The complainant was promptly asked for the evidence, and he sent back a copy of the email. Unfortunately, the University of Cambridge spam filter quietly discarded it, because it contained a phishing URL. Everyone here assumed that the matter had been forgotten about, and nothing proactive was done to follow it up.

Unfortunately, at the other end of the conversation, it looked as if Cambridge wasn’t responding, and perhaps the sysadmins were part of the criminal conspiracy. So, still concerned about the safety of their PayPal account, contact was made with the Metropolitan Police and the local Cambridgeshire constabulary… which would be an interesting experiment in seeing whether eCrime is ever investigated if it hadn’t, at heart, been an unfortunate misunderstanding. So far, no officers have appeared at our door, so hopefully not too much police time has been spent on this.

Eventually, after a little more to-ing and fro-ing, a copy of the original email arrived with the sysadmins via a @gmail account (which doesn’t completely discard phishing URLs), the penny dropped and it was all sorted out on the phone.

I’d like to draw a moral from this story, but apart from noting the wickedness of discarding valuable email merely because it superficially resembles spam, it’s not easy to cast fault more in one place than another. In particular, it’s clearly nonsense to suggest that people should just “know” that emails like this are fraudulent. If phishing emails didn’t mislead a great many people, then they’d evolve until they did!

Chip & PIN terminals vulnerable to simple attacks

Steven J. Murdoch, Ross Anderson and I looked at how well PIN entry devices (PEDs) protect cardholder data. Our paper will be published at the IEEE Symposium on Security and Privacy in May, though an extended version is available as a technical report. A segment about this work will appear on BBC Two’s Newsnight at 22:30 tonight.

We were able to demonstrate that two of the most popular PEDs in the UK — the Ingenico i3300 and Dione Xtreme — are vulnerable to a “tapping attack” using a paper clip, a needle and a small recording device. This allows us to record the data exchanged between the card and the PED’s processor without triggering tamper proofing mechanisms, and in clear violation of their supposed security properties. This attack can capture the card’s PIN because UK banks have opted to issue cheaper cards that do not use asymmetric cryptography to encrypt data between the card and PED.

Ingenico attack Dione attack

In addition to the PIN, as part of the transaction, the PED reads an exact replica of the magnetic strip (for backwards compatibility). Thus, if an attacker can tap the data line between the card and the PED’s processor, he gets all the information needed to create a magnetic strip card and withdraw money out of an ATM that does not read the chip.

We also found that the certification process of these PEDs is flawed. APACS has been effectively approving PEDs for the UK market as Common Criteria (CC) Evaluated, which does not equal Common Criteria Certified (no PEDs are CC Certified). What APACS means by “Evaluated” is that an approved lab has performed the “evaluation”, but unlike CC Certified products, the reports are kept secret, and governmental Certification Bodies do not do quality control.

This process causes a race to the bottom, with PED developers able to choose labs that will approve rather than improve PEDs, at the lowest price. Clearly, the certification process needs to be more open to the cardholders, who suffer from the fraud. It also needs to be fixed such that defective devices are refused certification.

We notified APACS, Visa, and the PED manufactures of our results in mid-November 2007 and responses arrived only in the last week or so (Visa chose to respond only a few minutes ago!) The responses are the usual claims that our demonstrations can only be done in lab conditions, that criminals are not that sophisticated, the threat to cardholder data is minimal, and that their “layers of security” will detect fraud. There is no evidence to support these claims. APACS state that the PEDs we examined will not be de-certified or removed, and the same for the labs who certified them and would not even tell us who they are.

The threat is very real: tampered PEDs have already been used for fraud. See our press release and FAQ for basic points and the technical report where we discuss the work in detail.

Update 1 (2008-03-09): The segment of Newsnight featuring our contribution has been posted to Google Video.

Update 2 (2008-03-21): If the link above doesn’t work try YouTube: part1 and part 2.