Security by asking the drunk whether he's drunk

Peter Gutmann pgut001 at cs.auckland.ac.nz
Mon Dec 22 05:18:44 EST 2008


Adam Shostack <adam at homeport.org> writes:

>Do you have evidence of either Authenticode or business impersonation? I
>agree that they're highly plausible, but you say " if the putative owner of
>an AuthentiCode certificate used to sign a piece of malware is ever tracked
>down then it's invariably some innocent victim somewhere..." which would
>indicate that there are several of these reported on.  (Using 'reporting' in
>its English, not academic sense.)

The sentence actually referred to the use of stolen credentials to facilitate
multiple crimes, the use to register fraudulent domains is widespread and
documented in blogs and cybercrime reports, e.g. the APWG's phishing surveys
and... well, lots of places, a Google search on something like "phishing
domain stolen credit card" should turn up a pile of hits.  The code-signing
and business impersonation is a lot rarer because it's mostly unnecessary to
do it, it's been done a number of times but barely reported in public so you
hear about it talking to security researchers at conferences as interesting
anecdotes but there's little public reporting on it ("Estonia nuked by DDoS"
gets rather more readers than "Signed rootkit discovered").  One of the most
notorious cases was Gromozon (a particularly nasty blended attack toolkit, see
e.g. http://www.pcalsicuro.com/gromozon.pdf), which was signed with a
Verithawte certificate issued to bogus company supposedly in Panama, for which
a quick Google:

  http://www.google.com/search?q=gromozon+signed

turns up a pile of hits (note that the issuing CA just happened to be
Verithawte in this case, malware authors will use just about any CA since all
they care about is turning off the warnings, and since it's not their money
they're using they don't care whether they're using cheap or expensive
certs... it's a nasty corollary to Ben Laurie's "proof-of-work proves not to
work", alongside effectively infinite CPU power the attackers also have access
to effectively infinite financial resources so they don't mind spending
whatever it takes of someone else's money to facilitate their attacks, e.g. in
registering large numbers of bogus accounts or domains for phishing purposes.
I've actually seen one of these live while monitoring a social networking site
that had paid premium accounts, they were using a script to register a user in
every locality in the countries served by the site for a total cost of
thousands of dollars of someone else's money, and the site admins then had to
manually go through and weed them all out again since they were set up to shut
down individual accounts based on user complaints but had never anticipated
anyone going in at this level).

The Sunbelt folks have blogged about signed malware they've discovered several
times as part of their investigation of malware, for this particular one:

  http://sunbeltblog.blogspot.com/2008/02/dangerous-new-fake-american-greetings.html

they tracked down the signer details (shown in the screen shots in the blog).
Again, a Google search like:

  http://www.google.com/search?q=signed+malware

should turn up about all that's been publicly written about this, but there's
a lot of further info that's circulated anecdotally.  All that sounds horribly
imprecise but I it's because it's something that's mostly a curiosity for now,
if you can get X zillion victims with unsigned/un-"authenticated" malware then
there's not much need to even try to bypass certificates, so only a bunch of
malware researchers and a few PKI geeks care about it.  In other words the
attackers haven't even bothered with the (supposed) defences yet, although the
small number of trial runs done so far indicate that if they ever need to
attack them they won't have any problems.

(Incidentally, there's a nice illustration of the closing-the-gate-after-the-
horse-has-bolted nature of CRLs in the Register:

  http://www.theregister.co.uk/2008/08/16/certified_malware/

  Within an hour of the reported incident we had attempted to examine the
  executable.  However, the site was no longer live.  After an unsuccessful
  attempt to contact the company by telephone we decided the best course of
  action in the short term would be to revoke the certificate.

So they revoked the cert after discovering that the hosting site had already
been taken down).

>Ditto with the business impersonation.

That one I can't give any references for, sorry, it was something that was
discussed at a cybercrime conference a few years ago as an example of the
impedance mismatch between bricks-and-mortar security mechanisms and the
Internet, but I don't know whether it's been formally documented.

(If anyone knows of anywhere where this is publicly documented, please let me
know).

>I'd like stories, I'd be estatic with a frequency analysis that I could show
>to people.

I doubt you'll be able to get this, for the reasons given above (and mentioned
in the original post), there's no need to go to this length yet so most
attackers don't bother.  As a result what we're seeing is proof-of-concept
stuff demonstrating that the defences don't work, but not enough to get
serious statistics for.  In mathematical terms we've got a there-exists rather
than a for-all.

This leads to a scary rule of thumb for defenders:

1. The attackers have more CPU power than any legitimate user will ever have,
   and it costs them nothing to apply it.  Any defence based on resource
   consumption is in trouble.

2. The attackers have more money than any legitimate user will ever have, and
   it costs them nothing to apply it.  Any defence built around financial
   outlay as a limiting factor is in trouble.

   Corollary: Systems that can't defend themselves against a situation where
   the financial cost of any operation (for example registering a new account)
   is effectively zero is in trouble.

3. The attackers have as much identity information as any legitimate user, but
   they have (effectively) infinite quantities of it.  Any defence based on
   identity-based accountability mechanisms is in trouble.

Anyone wanna try fighting that with cryptography?

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list