Monthly Archives: April 2009

Temporal Correlations between Spam and Phishing Websites

Richard Clayton and I have been studying phishing website take-down for some time. We monitored the availability of phishing websites, finding that while most phishing websites are removed with a day or two, a substantial minority remain for much longer. We later found that one of the main reasons why so many websites slip through the cracks is that the take-down companies responsible for removal refuse to share their URL lists with each other.

One nagging question remained, however. Do long-lived phishing websites cause any harm? Would removing them actually help? To get that answer, we had to bring together data on the timing of phishing spam transmission (generously shared by Cisco IronPort) with our existing data on phishing website lifetimes. In our paper co-authored with Henry Stern and presented this week at the USENIX LEET Workshop in Boston, we describe how a substantial portion of long-lived phishing websites continue to receive new spam until the website is removed. For instance, fresh spam continues to be sent out for 75% of phishing websites alive after one week, attracting new victims. Furthermore, around 60% of phishing websites still alive after a month keep receiving spam advertisements.

Consequently, removal of websites by the banks (and the specialist take-down companies they hire) is important. Even when the sites stay up for some time, there is value in continued efforts to get them removed, because this will limit the damage.

However, as we have pointed out before, the take-down companies cause considerable damage by their continuing refusal to share data on phishing attacks with each other, despite our proposals addressing their competitive concerns. Our (rough) estimate of the financial harm due to longer-lived phishing websites was $330 million per year. Given this new evidence of persistent spam campaigns, we are now more confident of this measure of harm.

There are other interesting insights discussed in our new paper. For instance, phishing attacks can be broken down into two main categories: ordinary phishing hosted on compromised web servers and fast-flux phishing hosted on a botnet infrastructure. It turns out that fast-flux phishing spam is more tightly correlated with the uptime of the associated phishing host. Most spam is sent out around the time the fast-flux website first appears and stops once the website is removed. For phishing websites hosted on compromised web servers, there is much greater variation between the time a website appears and when the spam is sent. Furthermore, fast-flux phishing spam was 68% of the total email spam detected by IronPort, despite this being only 3% of all the websites.

So there seems to be a cottage industry of fairly disorganized phishing attacks, with perhaps a few hundred people involved. Each compromises a small number of websites, while sending a small amount of spam. Conversely there are a small number of organized gangs who use botnets for hosting, send most of the spam, and are extremely efficient on every measure we consider. We understand that the police are concentrating their efforts on the second set of criminals. This appears to be a sound decision.

The Curtain Opens on Facebook's Democracy Theatre

Last month we penned a highly-critical report of Facebook’s proposed terms of service and much-hyped “public review” process. We categorised them as “democracy theatre”, a publicity stunt intended to provide the appearance of community input without committing to real change. We included our report in Facebook’s official forum, and it was backed by the Open Rights Group as their official expert response as requested by Facebook. Last night, Facebook published their revised terms of service and unveiled their voting process, and our scepticism about the process has been confirmed. We’ve issued a press release summarising our opposition to the new terms.

Taking a look at the diff output from the revised terms, it’s clear that as we anticipated, no meaningful changes were made. All of the changes are superficial, in fact Section 2 is now slightly less clear and a few more shady definitions have been pushed to the back of the document. Facebook received hundreds of comments in addition to our report during the public review process, but their main response was a patronising FAQ document which dismissed user’s concerns as being merely misunderstandings of Facebook’s goodwill. Yet, Facebook still described their new terms as “reflecting comments from users and experts received during the 30-day comment period. ” We would challenge Facebook to point to a single revision which reflected a specific comment received.

The voting process is also problematic, as we predicted it would be. The new terms were announced and instantly put to a 7-day vote, hardly enough time to have a serious debate on the revised terms. Depending on your profile settings it can be quite hard to even find the voting interface. For some profiles it is prominently shown on one’s home page, for others it is hidden and can’t even be found through search. The voting interface was outsourced to a third-party developer called Wildfire Promotion Builder and has been frequently crashing in the first 12 hours of voting, despite a relatively low turnout (50,000 votes so far). This is particularly damning since the required quorum is 60 million votes over 7 days, meaning Facebook was unprepared technically to handle 1% of the required voting traffic.

The poorly done voting interface summarises the situation well. This process was never about democracy or openness, but about damage control from a major PR disaster. Truly opening the site up to user control is an interesting option and might be in Facebook’s long-term interest. They are also certainly within their rights as well to run their site as a dictatorship using the older, corporate-drafted terms of service. But it’s tough to swallow Facebook’s arrogant insistence that it’s engaging users, when it’s really doing no such thing.

Update, 24/04/2009: The vote ended yesterday. About 600,000 users voted, 0.3% of all users on the site and less than 1% of the required 30%. Over 25% of voters opposed the new terms of service, many of which can be interpreted as voting in protest. For Facebook, it was still a win, as they experienced mostly good press and have now had their new terms ratified.

Chip and PIN on Trial

The trial of Job v Halifax plc has been set down for April 30th at 1030 in the Nottingham County Court, 60 Canal Street, Nottingham NG1 7EJ. Alain Job is an immigrant from the Cameroon who has had the courage to sue his bank over phantom withdrawals from his account. The bank refused to refund the money, making the usual claim that its systems were secure. There’s a blog post on the cavalier way in which the Ombudsman dealt with his case. Alain’s case was covered briefly in Guardian in the run-up to a previous hearing; see also reports in Finextra here, here and (especially) here.

The trial should be interesting and I hope it’s widely reported. Whatever the outcome, it may have a significant effect on consumer protection in the UK. For years, financial regulators have been just as credulous about the banks’ claims to be in control of their information-security risk management as they were about the similar claims made in respect of their credit risk management (see our blog post on the ombudsman for more). It’s not clear how regulatory capture will (or can) be fixed in respect of credit risk, but it is just possible that a court could fix the consumer side of things. (This happened in the USA with the Judd case, as described in our submission to the review of the ombudsman service — see p 13.)

For further background reading, see blog posts on the technical failures of chip and PIN, the Jane Badger case, the McGaughey case and the failures of fraud reporting. Go back into the 1990s and we find the Halifax again as the complainant in R v Munden; John Munden was prosecuted for attempted fraud after complaining about phantom withdrawals. The Halifax couldn’t produce any evidence and he was acquitted.

A truly marvellous proof of a transaction

When you transact with an EMV payment card (a “Chip and PIN” card), typical UK operation is for the bank to exchange three authentication “cryptograms”. First comes the request from the card (the ARQC), then comes the response from the bank (the ARPC) and finally the transaction certificate (TC). The idea with the transaction certificate is that the card signs off on the correct completion of the protocol, having received the response from the bank and accepted it. The resulting TC is supposed to be a sort of “proof of transaction”, and because it certifies the completion of the entire transaction at a technical level, one can presume that both the money was deducted and the goods were handed over. In an offline transaction, one can ask the card to produce a TC straight away (no AQRC and ARPC), and depending on various risk management settings, it will normally do so. So, what can you do with a TC?

Well, the TC is sent off to the settlment and clearing system, along with millions of others, and there it sits in the transaction logs. These logs get validated as part of clearing and the MAC is checked (or it should be). In practice the checks may get deferred until there is a dispute over a transaction (i.e. a human complains). The downside is, if you don’t check all TCs, you can’t spot offline fraud in the chip and pin system. Should a concerned party dispute a transaction, the investigation team will pull the record, and use a special software tool to validate the TC – objective proof that the card was involved.

Another place the TC gets put is on your receipt. An unscientific poll of my wallet reveals 13 EMV receipts with TCs present (if you see a hex string like D3803D679B33F16E8 you’ve found it) and 7 without – 65% of my receipts have one. The idea is that the receipt can stand as a cryptographic record of the transaction, should the banks logs fail or somehow be munged.

But there is a bit of a problem: sometimes there isn’t enough space for all the data. It’s a common problem: Mr. Fermat had a truly marvellous proof of a proposition but it wouldn’t fit in the margin, and unfortunately while the cryptogram fits on the receipt, you can’t check a MAC without knowing the input data, and EMV terminal software developers have a pretty haphazard approach to including this on the receipts… after all, paper costs money!

Look at the following receipts. Cab-Inn Aarhus has the AID, the ATC and various other input goodies to the MAC (sorry if I’m losing you in EMV technicalities); Ted Baker has the TC, the CVMR, the TSI, TVR and IACs (but no ATC), and the Credit Agricole cash withdrawal has the TC and little else. One doesn’t want to be stuck like Andrew Wiles spending seven years guessing the input data! Only at one shop have I seen the entire data required on the receipt (including CID et al) and it was (bizarrely) from a receipt for a Big Mac at McDonalds!

Various POS receipts

Now in case of dispute one can brute force the missing data and guess up to missing 40 bits of data or so without undue difficulty. And there is much wrangling (indeed the subject of previous and current legal actions) about exactly what data should be provided, whether the card UDKs should be disclosed to both sides in a dispute, and generally what constitutes adequate proof.

A "fake" transaction certificate
A “fake” transaction certificate

But most worrying is something I observed last week, making a credit card purchase for internet access at an Airport: a fake transaction certificate. I can tell its a fake because it firstly its the wrong length, and secondly, it’s online — I only typed in my card number, and never plugged my card into a smartcard reader. Now I can only assume that some aesthetically minded developer decided that the online confirmation needed a transaction certificate so took any old hex field and just dumped it. It could be an innocent mistake. But whether or not the “margin was too small” to contain this TC, its a sad reflection on the state of proof in EMV when cryptographic data fields only appear for decorative purposes. Maybe some knowledgeable reader can shed some light on this?