[fc-discuss] Financial Cryptography Update: It's official - doing due diligence is a criminal offence!

[iang@iang.org]

 Financial Cryptography Update: It's official - doing due diligence is a criminal offence! 

                            October 12, 2005


------------------------------------------------------------------------

https://www.financialcryptography.com/mt/archives/000570.html



------------------------------------------------------------------------

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.

http://www.theregister.co.uk/2005/10/11/tsunami_hacker_followup/
====8<=======8<================
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.
==============>8=========>8====

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:

http://www.channelregister.co.uk/2005/10/06/tsunami_hacker_convicted/
====8<=======8<================
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."
==============>8=========>8====

The message is loud and clear, but what is also clear is that the
Metropolitan's Computer Crime Unit is blissfully unaware of the
unintended consequences it has unleashed.  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):

http://www.theregister.co.uk/2005/02/11/dec_hack_charges/
====8<=======8<================
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.
==============>8=========>8====

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:

====8<=======8<================
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"
==============>8=========>8====

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 its begun.

-- 
Powered by Movable Type
Version 2.64
http://www.movabletype.org/