Financial Cryptography

It's official - doing due diligence is a criminal offence!

I wrote before about rising barriers in security. We now have the spectre of our worst nightmare in security turned haptic: the British have convicted a security person for doing due diligence on a potential scam site. If you work at a British Financial Institution, be very very aware of how this is going to effect security.

[writes El Reg] On December 31, 2004, Cuthbert, using an Apple laptop and Safari browser, became concerned that a website collecting credit card details for donations to the Tsunami appeal could be a phishing site. After making a donation, and not seeing a final confirmation or thank-you page, Cuthbert put ../../../ into the address line. If the site had been unprotected this would have allowed him to move up three directories.

After running the two tests, at between 15.12 and 15.15 on New Year's Eve, Cuthbert took no further action. In fact his action set off an Intrusion Detection System at BT's offices in Edinburgh and the telco called the police.

It may well be that the facts of the case are not well preserved in the above reporting; no journalist avoids a good story, and El Reg is no exception. A reading of other reports didn't disagree, so I'll assume the facts as written:

[El Reg again] DC Robert Burls of the Met's Computer Crime Unit said afterwards: "We welcome today's verdict in a case which fully tested the computer crime legislation and hope it sends a reassuring message to the general public that in this particular case the appropriate security measures were in place thus enabling donations to be made securely to the Tsunami Appeal via the DEC website."

The message is loud and clear, but it is not the one that they wanted. The Metropolitan's Computer Crime Unit is blissfully unaware of the unintended consequences it has unleashed... Let's walk through it.

According to the testimony, the site gave some bad responses and raised red flags. A routine event, in other words. Cuthbert checked it out a little to make sure it wasn't a phishing site, and apparently found it wasn't. This would have been a very valuable act for him, as otherwise he might have had to change all his card and other details if they had been compromised by a real phishing attack (of which we have seen many).

The 'victim' in the case was named as Disasters Emergency Committee (DEC). From Cuthbert, DEC received a 30 pound donation via donate.bt.com and then said (after he was charged):

[more] There's no suggestion any money was stolen and the Disasters Emergency Committee has issued a statement reassuring the public that the internet remains a safe way to donate money to victims of the 26 December disaster.

The real victim may well be the British public who now only have BT's IDS and the Metropolitan Computer Crime Unit between them and phishing. Let's imagine we are tasked to teach users or banks or whoever how to defend themselves against phishing and other Internet frauds. What is it that we'd like to suggest? Is it:

a. be careful and look for signs of fraud by checking the domain name whois record, tracerouting to see where the server is located, probing the webserver for oddities?

Or

b. don't do anything that might be considered a security breach?

Either way, the user is in trouble because the user has no capability to determine what is and what is not an "unauthorised access". Banks won't be able to look at phishing sites because that would break the law and invite prosecution; after this treatment, security professionals are going to be throwing their hands up saying, "sorry, liability insurance doesn't cover criminal behaviour." The Metropolitan Computer Crime Unit will likewise be hamstrung by not being able to breach the very laws they prosecute.

There is a blatant choice here not only for security professionals and banks, but also for the hapless email user. Follow the law, and perform due diligence without the use of ping, traceroute, telnet, whois, or even browsers ... Or follow the protocols and send the recognised and documented requests to respond according to the letter and spirit of the RFCs, and in the meantime discover just how bona fide a site is. Tyler dug up the appropriate document in this case:

So RFC 3986 explicitly lists this construction as a valid URL. See section 5.4.2.:

5.4.2. Abnormal Examples

Although the following abnormal examples are unlikely to occur in
normal practice, all URI parsers should be capable of resolving them
consistently. Each example uses the same base as that above.

Parsers must be careful in handling cases where there are more ".."
segments in a relative-path reference than there are hierarchical
levels in the base URI's path. Note that the ".." syntax cannot be
used to change the authority component of a URI.

"../../../g" = "http://a/g"
"../../../../g" = "http://a/g"

The way the security bureaucrats are treating this war, possession of an RFC will become evidence of criminal thoughts! The battle for British cybersecurity looks over before it has begun.

Addendum: Due diligence defined and reasonably duty of care discussed. Also see Alice in Credit-Card Land and also Phishing and Pharming and Phraud - Oh My for discussions in more depth. Also, I forgot to tip my hat to Gerv for the original link.

Posted by iang at October 11, 2005 11:08 PM | TrackBack