Category Archives: Meta

About the blog itself

Light Blue Touchpaper now on HTTPS

Light Blue Touchpaper now supports TLS, so as to protect passwords and authentication cookies from eavesdropping. TLS support is provided by the Pound load-balancer, because Varnish (our reverse-proxy cache) does not support TLS.

The configuration is intended to be a reasonable trade-off between security and usability, and gets an A– on the Qualys SSL report. The cipher suite list is based on the very helpful Qualys Security Labs recommendations and Apache header re-writing sets the HttpOnly and Secure cookie flags to resist cookie hijacking.

As always, we might have missed something, so if you notice problems such as incompatibilities with certain browsers, then please let us know on <lbt-admin@cl.cam.ac.uk>. or in the comments.

PhD Position on Privacy Enhancing Technologies and Anonymous Communications

Applications are invited for one PhD position in the Security Group at the Computer Laboratory to work with Dr Steven Murdoch. Funding for this position is provided by the Engineering and Physical Sciences Research Council (EPSRC) in collaboration with the Royal Society.

The successful candidate will undertake research on methods to analyse the security of anonymous communication systems and privacy enhancing technologies. This broad research topic falls within an EPSRC priority area and provides considerable scope for the PhD candidate to find his or her own research direction.

Further details can be found in the advertisement (NR27372). The closing date for applications is 31 May 2013.

Static Consent and the Dynamic Web

Last week Facebook announced the end of regional networks for access control. The move makes sense: regional networks had no authentication so information available to them was easy to get with a fake account. Still, silently making millions of weakly-restricted profiles globally viewable raises some disturbing questions. If Terms of Service promise to only share data consistent with users’ privacy settings, but the available privacy settings change as features are added, what use are the terms as a legal contract? This is just one instance of a major problem for rapidly evolving web pages which rely on a static model of informed consent for data collection. Even “privacy fundamentalists” who are careful to read privacy policies and configure their privacy settings can’t be confident of their data’s future for three main reasons:

  • Functionality Changes: Web 2.0 sites add features constantly, usually with little warning or announcement. Users are almost always opted-in for fear that features won’t get noticed otherwise. Personal data is shared before users have any chance to opt out. Facebook has done this repeatedly, opting users in to NewsFeed, Beacon, Social Ads, and Public Search Listings. This has generated a few sizeable backlashes, but Facebook maintains that users must try new features in action before they can reasonably opt out.
  • Contractual Changes: Terms of Service documents can often be changed without notice, and users automatically agree to the new terms by continuing to use the service. In a study we’ll be publishing at WEIS next month evaluating 45 social networking sites, almost half don’t guarantee to announce changes to their privacy policies. Less than 10% of the sites commit to a mandatory notice period before implementing changes (typically a week or less). Realistically, at least 30 days are needed for fundamentalists to read the changes and cancel their accounts if they wish.
  • Ownership Changes: As reported in the excellent survey of web privacy practices by the KnowPrivacy project at UC Berkeley, the vast majority (over 90%) of sites explicitly reserve the right to share data with ‘affiliates’ subject only to the affiliate’s privacy policy. Affiliate is an ambiguous term but it includes at least  parent companies and their subsidiaries. If your favourite web site gets bought out by an international conglomerate, your data is transferred to the new owners who can instantly start using it under their own privacy policy. This isn’t an edge case, it’s a major loophole: websites are bought and sold all the time and for many startups acquisition is the business model.

For any of these reasons, the terms under which consent was given can be changed without warning. Safely disclosing personal data on the web thus requires continuously monitoring sites for new functionality, updated terms of service, or mergers, and instantaneously opting out if you are no longer comfortable. This is impossible even for privacy fundamentalists with an infinite amount of patience and legal knowledge, rendering the old paradigm of informed consent for data collection unworkable for Web 2.0.

Hardened stateless session cookies

The root cause behind the last-but-one WordPress cookie debacle was that the authors invented their own password hashing and cookie generation scheme. This is generally a bad idea, since it’s hard even for experts to get these right. Instead, whenever possible, a well-studied proposal should be chosen. It is for this reason that I suggested the phpass library for password hashing, and the Fu et al. stateless session cookie proposal.

These choices would be a substantial improvement on the previous custom design (had they been implemented correctly), but I still was not quite satisfied. The Fu et al. scheme has the property that an attacker who can read the cryptographic key stored in the database can create spoofed cookies. Given the history of WordPress security, it seems likely that there will eventually be a vulnerability discovered which allows the key, which authenticates cookies, to be leaked.

It’s good practice in security engineering to design systems with the widest possible range of attacker capabilities in mind. I therefore designed a cookie scheme which would do all that the Fu et al. design did, but also maintained some of its security properties if the attacker has read-access to the authentication database and knows the cookie authentication key. I published a paper on this topic — Hardened stateless session cookies — at the 2008 Security Protocols Workshop.

The trick behind my scheme is to store the hash of the user’s password in the cookie, and the hash of that in the authentication database. This means that it’s possible for the server to verify cookies, but the authentication database doesn’t contain enough information to create a fake cookie. Thus an attacker with read-access to the database still needs to know the user’s password to log in, and that isn’t stored. There are some additional subtleties to resist different attacks, and those are described in the paper.

I hope this proposal will trigger discussion over this important problem and lead to improved cookie authentication schemes.

WordPress 2.5 cookie integrity protection vulnerability

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.

Theme is back

Dan Cvrček has very kindly ported over the old Blix-based theme to be compatible with WordPress 2.3 (and also hopefully more maintainable). There are a few bugs to be ironed out, for example the Authors and About pages don’t work yet, but these are being worked on. If you spot any other problems, please leave a comment on this post, or email lbt-admin @cl.cam.ac.uk.

Update 2007-11-28: Authors and About should now work.

WordPress cookie authentication vulnerability

In my previous post, I discussed how I analyzed the recent attack on Light Blue Touchpaper. What I did not disclose was how the attacker gained access in the first place. It turned out to incorporate a zero-day exploit, which is why I haven’t mentioned it until now.

As a first step, the attacker exploited an SQL injection vulnerability. When I noticed the intrusion, I upgraded WordPress then restored the database and files from off-server backups. WordPress 2.3.1 was released less than a day before my upgrade, and was supposed to fix this vulnerability, so I presumed I would be safe.

I was therefore surprised when the attacker broke in again, the following day (and created himself an administrator account). After further investigation, I discovered that he had logged into the “admin” account — nobody knows the password for this because I set it to a long random string. Neither me nor other administrators ever used that account, so it couldn’t have been XSS or another cookie stealing attack. How was this possible?

From examining the WordPress authentication code I discovered that the password hashing was backwards! While the attacker couldn’t have obtained the password from the hash stored in the database, by simply hashing the entry a second time, he generated a valid admin cookie. On Monday I posted a vulnerability disclosure (assigned CVE-2007-6013) to the BugTraq and Full-Disclosure mailing lists, describing the problem in more detail.

It is disappointing to see that people are still getting this type of thing wrong. In their 1978 summary, Morris and Thompson describe the importance of one way hashing and password salting (neither of which WordPress does properly). The issue is currently being discussed on LWN.net and the wp-hackers mailing list. Hopefully some progress will be made at getting it right this time around.

Google as a password cracker

One of the steps used by the attacker who compromised Light Blue Touchpaper a few weeks ago was to create an account (which he promoted to administrator; more on that in a future post). I quickly disabled the account, but while doing forensics, I thought it would be interesting to find out the account password. WordPress stores raw MD5 hashes in the user database (despite my recommendation to use salting). As with any respectable hash function, it is believed to be computationally infeasible to discover the input of MD5 from an output. Instead, someone would have to try out all possible inputs until the correct output is discovered.

So, I wrote a trivial Python script which hashed all dictionary words, but that didn’t find the target (I also tried adding numbers to the end). Then, I switched to a Russian dictionary (because the comments in the shell code installed were in Russian) but that didn’t work either. I could have found or written a better password cracker, which varies the case of letters, and does common substitutions (e.g. o → 0, a → 4) but that would have taken more time than I wanted to spend. I could also improve efficiency with a rainbow table, but this needs a large database which I didn’t have.

Instead, I asked Google. I found, for example, a genealogy page listing people with the surname “Anthony”, and an advert for a house, signing off “Please Call for showing. Thank you, Anthony”. And indeed, the MD5 hash of “Anthony” was the database entry for the attacker. I had discovered his password.

In both the webpages, the target hash was in a URL. This makes a lot of sense — I’ve even written code which does the same. When I needed to store a file, indexed by a key, a simple option is to make the filename the key’s MD5 hash. This avoids the need to escape any potentially dangerous user input and is very resistant to accidental collisions. If there are too many entries to store in a single directory, by creating directories for each prefix, there will be an even distribution of files. MD5 is quite fast, and while it’s unlikely to be the best option in all cases, it is an easy solution which works pretty well.

Because of this technique, Google is acting as a hash pre-image finder, and more importantly finding hashes of things that people have hashed before. Google is doing what it does best — storing large databases and searching them. I doubt, however, that they envisaged this use though. 🙂

Upgrade and new theme

Regular readers may have noticed that Light Blue Touchpaper was down most of today. This was due to the blog being compromised through several WordPress vulnerabilities. I’ve now cleaned this up, restored from last night’s backups and upgraded WordPress. A downside is that our various customizations need substantial modification before working again, most notably the theme, which is based on Blix and has not been updated since WordPress 1.5. Email also will not work due to this bug. I am working on a fix to this and other problems, so please accept my apologies in the mean time.