Oracle attack on WordPress

Cryptology, Meta

This post describes the second of two vulnerabilities I found in WordPress. The first, a XSS vulnerability, was described last week. While the vulnerability discussed here is applicable in fewer cases than the previous one, it is an example of a comparatively rare class, oracle attacks, so I think merits further exposition.

An oracle attack is where an attacker can abuse a facility provided by a system to gain unauthorized access to protected information. The term originates from cryptology, and such attacks still crop up regularly; for example in banking security devices and protocols. The occurrence of an oracle attack in WordPress illustrates the need for a better understanding of cryptography, even by the authors of applications not conventionally considered to be cryptographic software. Also more forgiving primitives and better robustness principles could reduce the risk of future weaknesses.

The vulnerability is a variant of the ‘cache’ shell injection bug reported by rgodm. This is caused by an unfortunate series of design choices by the WordPress team, leading to arbitrary PHP execution. The WordPress cache stores commonly accessed information from the database, such as user profile data, in files for faster retrieval. Despite them being needed only by the server, they are still accessible from the web, which is commonly considered bad practice. To prevent the content being read remotely, the data is placed in .php files, commented out with //. Thus when executed by the web server, in response to a remote query, they return an empty file.

However, putting user controlled data in executable files is inherently a risky choice. If the attacker can escape from the comment then arbitrary PHP can be executed. rgodm’s shell injection bug does this by inserting a newline into the display name. Now all the attacker must do is guess the name of the .php file which stores his cached profile information, and invoke it to run the injected PHP. WordPress puts an index.php in the cache directory to suppress directory indexing, and filenames are generated as MD5(username || DB_PASSWORD) || “.php”, which creates hard to guess name. The original bug report suggested brute forcing DB_PASSWORD, the MySQL authentication password, but the oracle attack described here will succeed even if a strong password is chosen.

Continue reading Oracle attack on WordPress →

Censoring science

Internet censorship, Legal issues, News coverage

I’ve written a rebuttal in today’s Guardian to an article that appeared last week by Martin Rees, the President of the Royal Society. Martin argued that science should be subjected to more surveillance and control in case terrorists do bad things with it.

Those of us who work with cryptography and computer security have been subjected to a lot of attempts by governments to restrict what we do and publish. It’s a long-running debate: the first book written on cryptology in English, by Bishop John Wilkins in 1641, remarked that ‘If all those useful Inventions that are liable to abuse, should therefore be concealed, there is not any Art or Science which might be lawfully profest’. (John, like Martin, was Master of Trinity in his day.)

In 2001–2, the government put an export control act through Parliament which, in its original form, would have required scientists working on subjects with possible military applications (that is, most subjects) to get export licenses before talking to foreigners about our work. FIPR colleagues and I opposed this; we organised Universities UK, the AUT, the Royal Society, the Conservatives and the Liberals to bring in an amendment in the Lords creating a research exemption for scientists. We mustn’t lose that. If scientists end up labouring under the same bureaucratic controls as companies that sell guns, then both science and nonproliferation will be seriously weakened.

Some people love to worry: Martin wrote a whole book wondering about how the human race will end. But maybe we should rather worry about something a bit closer to hand — how our civilisation will end. If a society turns inwards and builds walls to keep the barbarians out, then competition abates, momentum gets lost, confidence seeps away, and eventually the barbarians win. Imperial Rome, Ming Dynasty China, … ?

Anatomy of an XSS exploit

Meta, Security engineering

Last week I promised to follow up on a few XSS bugs that I found in WordPress. The vulnerabilities are fixed in WordPress 2.0.3, even though the release notes do not mention their existence. I think there are a number of useful lessons that can be drawn from them, so in this post I will describe some more details.

The goal of a classic XSS exploit is to run arbitrary Javascript, in the context of a another webpage, which retrieves the user’s cookies. With WordPress I will concentrate on the comment management interface. Here, the deletion button has a Javascript onclick event handler to display a confirmation dialog, which includes the comment author’s name. If malicious input can break out of the dialog box text, then when an administrator activates the button, the attacker’s Javascript is run, allowing access to the admin user’s cookies. I found two classes of bugs which allowed me to do this.

Continue reading Anatomy of an XSS exploit →

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.

The Rising Tide: DDoS by Defective Designs and Defaults

Security economics, Security engineering

Dedicated readers will recall my article about how I tracked down the “DDoS” attack on stratum 1 time servers by various D-Link devices. I’ve now had a paper accepted at the 2nd Workshop on Steps to Reducing Unwanted Traffic on the Internet (SRUTI’06) which runs in California in early July.

The paper (PDF version available here and HTML here) gives rather more details about the problems with the D-Link firmware. More significantly, it puts this incident into context as one of a number of problems suffered by stratum 1 time servers over the past few years AND shows that these time server problems are just one example of a number of incidents involving different types of system that have been “attacked” by defective designs or poorly chosen defaults.

My paper is fairly gloomy about the prospects for improvement going forward. ISPs are unlikely to be interested in terminating customers who are running “reputable” systems which just happen to contribute to a DDoS on some remote system. There’s no evidence that system designers are learning from past mistakes — and the deskilling of program development is meaning that ever more clueless people are involved. Economic and legal approaches don’t seem especially promising — it may have cost D-Link (and Netgear before them) real dollars, but I doubt that the cost been high enough yet to scare other companies into auditing their systems before they too cause a similar problem.

As to the title… I suggest that if a classic, zombie-originated, DDoS attack is like directing a firehose onto a system; and if a “flash crowd” (or “slashdotting”) is like a flash flood; then the sort of “attack” that I describe is like a steadily rising tide, initially easy to ignore and not very significant, but it can still drown you just the same.

Hence it’s important to make sure that your security approach — be it dams and dikes, swimming costumes and life-jackets, or wetsuits and scuba gear (or of course their Internet anti-DDoS equivalents) — is suitable for dealing with all of these threats.

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.

XSS vulnerabilities fixed in WordPress 2.0.3

Meta, Security engineering

Users are strongly urged to upgrade their version of WordPress to 2.0.3 (as you will see that we have already!) This release fixes two XSS vulnerabilities that I reported to WordPress on 14 Apr 2006 and 4 May 2006, although they are not mentioned in the release announcement. These are exploitable in the default installation and can readily lead to arbitrary PHP code execution.

I think there a number of interesting lessons to learn from these vulnerabilities, so I plan to post more details in 10 days time (thereby giving users a chance to upgrade). The nature of the problem can probably be deduced from the code changes, so there is limited value in waiting much longer.

I will also discuss a refinement of the ‘cache’ shell injection bug reported by rgodm, which is also fixed by WordPress 2.0.3. The new attack variant I discovered no longer relies on a guessable database password, but only applies when the Subscribe To Comments plugin is also activated. The latest version of the plugin (2.0.4) mitigates this attack, but upgrading WordPress is still recommended.

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.