Monthly Archives: April 2008

Second edition

Banking security, Electronic voting, Internet censorship, Privacy technology, Security economics, Security engineering

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!

WordPress 2.5 cookie integrity protection vulnerability

Academic papers, Cryptology, Meta

Recently, I was preparing to give a talk on web authentication so was looking at the source code of WordPress, which I had just upgraded to version 2.5. Unfortunately, I found a rather nasty security hole, which has now been disclosed. If a WordPress installation is configured to permit account creation, the vulnerability allows an attacker to gain administrator access.

The problem is to do with how cookies are generated. The authentication code was substantially overhauled for WordPress 2.5, in part to deal with security problems in the password database. Now, the authentication cookies take the form of:

wordpress_.COOKIEHASH = USERNAME . | . EXPIRY_TIME . | . MAC

Where:
COOKIEHASH
MD5 hash of the site URL (to maintain cookie uniqueness)
USERNAME
The username for the authenticated user
EXPIRY_TIME
When cookie should expire, in seconds since start of epoch
MAC
HMAC-MD5(USERNAME . EXPIRY_TIME) under a key derived from a secret and USERNAME . EXPIRY_TIME.

This scheme is based on two papers: Dos and Don’ts of Client Authentication on the Web by Fu et al. and A Secure Cookie Protocol by Liu et al. However, there is a small difference and, as is common in cryptographic systems, small changes can have big impact.

The problem is that USERNAME and EXPIRY_TIME are not delimited when calculating the MAC. This means that a MAC for one cookie is valid for any other, provided that USERNAME . EXPIRY_TIME is unchanged. So an attacker can register a username starting with “admin”, log in as usual, then modify their cookie so it’s valid for the administrator account.

Fu et al. called this the “cryptographic splicing” attack in their paper (Section 3.3), and is one of the many ways they show how people can slip up when implementing web authentication. Unfortunately, dynamic website frameworks, especially PHP, offer little assistance to programmers trying to implement secure applications.

I will expand on this topic in a future post but in the mean time, if you run WordPress, you really should upgrade to 2.5.1. While WordPress 2.3.3 doesn’t have the problem described here, it is still not secure.

There is some more detail on the cookie vulnerability in my disclosure (CVE-2008-1930). WordPress have mentioned it in their release announcement and I’ve also just sent it to the usual mailing lists.

Stealing Phorm Cookies

Legal issues, News coverage, Privacy technology

Last week I gave a talk at the 80/20 Thinking organised “town hall meeting” about the Phorm targeted advertising system. You can see my slides here, and eventually there will be some video here.

One of the issues I talked about was the possibility of stealing Phorm’s cookies, which I elaborate upon in this post. I have written about Phorm’s system before, and you can read a detailed technical explanation, but for the present, what it is necessary to know is that through some sleight-of-hand, users whose ISPs deploy Phorm will end up with tracking cookies stored on their machine, one for every website they visit, but with each containing an identical copy of their unique Phorm tracking number.

The Phorm system strips out these cookies when it can, but the website can access them anyway, either by using some straightforward JavaScript to read their value and POST it back, or by the simple expedient of embedding an https image ( <img = "https://.... ) within their page. The Phorm system will not be able to remove the cookie from an encrypted image request.

Once the website has obtained the Phorm cookie value, then in countries outside the European Union where such things are allowed (almost expected!), the unique tracking number can be combined with any other information the website holds about its visitor, and sold to the highest bidder, who can collate this data with anything else they know about the holder of the tracking number.

Of course, the website can do this already with any signup information that has been provided, but the only global tracking identifier it has is the visiting IP address, and most consumer ISPs give users new IP addresses every few hours or few days. In contrast, the Phorm tracking number will last until the user decides to delete all their cookies…

A twist on this was suggested by “Barrie” in one of the comments to my earlier post. If the remote website obtains an account at the visitor’s ISP (BT, Talk Talk or Virgin in the UK), then they can construct an advert request to the Phorm system, using the Phorm identifier of one of their visitors. By inspecting the advert they receive, they will learn what Phorm thinks will interest that visitor. They can then sell this information on, or serve up their own targeted advert. Essentially, they’re reverse engineering Phorm’s business model.

There are of course things that Phorm can do about these threats, by appropriate use of encryption and traffic analysis. Whether making an already complex system still more complex will assist in the transparency they say they are seeking is, in my view, problematic.

New Banking Code shifts more liability to customers

Banking security, Security economics

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.

The Phorm “Webwise'' System

Legal issues, News coverage, Privacy technology

Last week I spent several hours at Phorm learning how their advertising system works — this is the system that is to be deployed by the UK’s largest ISPs to pick apart your web browsing activities to try and determine what interests you.

The idea is that advertisers can be more picky in who they serve adverts to… you’ll get travel ads if you’ve been looking to go to Pamplona for the running of the bulls, car adverts if you’ve been checking out the prices of Fords (the intent is that Phorm’s method of distilling down the ten most common words on the page will allow them to distinguish between a Fiesta and a Fiesta!)

I’ve now written up the extensive technical details that they provided (10 pages worth) which you can now download from my website.

Much of the information was already known, albeit perhaps not all minutiae. However, there were a number of new things that were disclosed.

Phorm explained the process by which an initial web request is redirected three times (using HTTP 307 responses) within their system so that they can inspect cookies to determine if the user has opted out of their system, so that they can set a unique identifier for the user (or collect it if it already exists), and finally to add a cookie that they forge to appear to come from someone else’s website. A number of very well-informed people on the UKCrypto mailing list have suggested that the last of these actions may be illegal under the Fraud Act 2006 and/or the Computer Misuse Act 1990.

Phorm also explained that they inspect a website’s “robots.txt” file to determine whether the website owner has specified that search engine “spiders” and other automated processing systems should not examine the site. This goes a little way towards obtaining the permission of the website owner for intercepting their traffic — however, in my view, failing to prohibit the GoogleBot from indexing your page is rather different from permitting your page contents to be snooped upon, so that Phorm can turn a profit from profiling your visitors.

Overall, I learnt nothing about the Phorm system that caused me to change my view that the system performs illegal interception as defined by s1 of the Regulation of Investigatory Powers Act 2000.

Phorm argue, with some justification, that their system does not permit them to identify individuals and that they meet and exceed all necessary Data Protection regulations — producing a system that is superior to other advertising platforms that profile Internet users.

Mayhap, but this is to mix up data protection and privacy.

The latter to me includes the important notion that other people, even people I’ll never meet and who will never meet me, don’t get to know what I do, they don’t get to learn what I’m interested in, and they don’t get to assume that targeting their advertisements will be welcomed.

If I spend my time checking out the details of a surprise visit to Spain, I don’t want the person I’m taking with me to glance at my laptop screen and see that its covered with travel adverts, mix up cause and effect, and think — even just for a moment — that it wasn’t my idea first!

Phorm says that of course I can opt out — and I will — but just because nothing bad happens to me doesn’t mean that the deploying the system is acceptable.

Phorm assumes that their system “anonymises” and therefore cannot possibly do anyone any harm; they assume that their processing is generic and so it cannot be interception; they assume that their business processes gives them the right to impersonate trusted websites and add tracking cookies under an assumed name; and they assume that if only people understood all the technical details they’d be happy.

Well now’s your chance to see all these technical details for yourself — I have, and I’m still not happy at all.

Update (2008-04-06):

Phorm have now quoted sections of this article on their own blog: http://blog.phorm.com/?p=12. Perhaps not surprisingly, they’ve quoted the paragraph that was favourable to their cause, and failed to mention all the paragraphs that followed that were sharply critical. They then fail, again how can one be surprised? to provide a link back to this article so that people can read it for themselves. Readers are left to draw their own conclusions.

Update (2008-04-07):

Phorm have now fixed a “tech glitch” (see comment #31) and now link to my technical report. The material they quote comes from this blog article, but they point out that they link to the ORG blog, and that links to this blog article. So that’s all right then!

A false accusation of "hacking"

Banking security, Legal issues

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!