Re: Security by asking the drunk whether he's drunk
At 10:19 PM -0500 12/30/08, Jerry Leichter wrote: >Robert Graham writes in Errata Security >(http://erratasec.blogspot.com/2008/12/not-all-md5-certs-are-vulnerable.html) >that the attack depends on being able to predict the serial number field that >will be assigned to a legitimate certificate by the CA. That part is true. >Only a few CA's use predictable "serial numbers" That part, I think, is wrong. I looked into this a bit earlier this month and found that most of the ones I looked at are still using sequential numbers. >- the field is actually arbitrary text If by "arbitrary text" you mean "a non-negative integer". >and need only be certainly unique among all certificates issued by a given CA. True as well. >So: The current attack is only effective against a very small number of CA's >which both use MD5 *and* have predictable sequence numbers. The attack is on end users who trust a root store that has a trust anchor from *any single* CA that uses MD5 and has predictable sequence numbers. The attack lets the attacker become a subordinate CA for that CA. At that point, the attacker can issue their own certs for any purpose. >So the sky isn't falling It never does. That's why it is the sky. >- though given how hard it is to "decertify" a CA (given that the "known good" >CA's are known to literally billions of pieces of software, and that hardly >anyone checks CRL's - and are there even CRL's for CA's?) this is certainly >not a good situation. There are not CRLs for CAs. That's why is it is a root store. Oh, and how do you create a definitive list of CAs that use MD5 in their signatures? >This also doesn't mean that, now that the door has been opened, other attacks >won't follow. In fact, it's hard to imagine that this is the end of the >story Quite right. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
On Dec 30, 2008, at 4:21 PM, Sidney Markowitz wrote: Sidney Markowitz wrote, On 31/12/08 10:08 AM: or that CA root certs that use MD5 for their hash are still in use and have now been cracked? I should remember -- morning coffee first, then post. The CA root certs themselves have not been cracked -- It is the digital signatures created by some CAs who still use MD5 to sign the certs that they issue that have been hacked: The known weakness in MD5 allows one to create two certs with the same MD5 hash, one that is legitimate to get signed by the CA, and another one for rogue use that can be given the same signature. Robert Graham writes in Errata Security (http://erratasec.blogspot.com/2008/12/not-all-md5-certs-are-vulnerable.html ) that the attack depends on being able to predict the serial number field that will be assigned to a legitimate certificate by the CA. Only a few CA's use predictable "serial numbers" - the field is actually arbitrary text and need only be certainly unique among all certificates issued by a given CA. Of course, we've seen in the past that having too much freedom to insert "known to be random" (hence uncheckable) stuff into a signed piece of text can itself be hazardous in other ways. So: The current attack is only effective against a very small number of CA's which both use MD5 *and* have predictable sequence numbers. So the sky isn't falling - though given how hard it is to "decertify" a CA (given that the "known good" CA's are known to literally billions of pieces of software, and that hardly anyone checks CRL's - and are there even CRL's for CA's?) this is certainly not a good situation. This also doesn't mean that, now that the door has been opened, other attacks won't follow. In fact, it's hard to imagine that this is the end of the story -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
Sidney Markowitz writes: >So which is worse, that anyone (allegedly) can get a cert from Comodo for any >domain without any proof of identity or verification of control of the domain, >or that CA root certs that use MD5 for their hash are still in use and have >now been cracked? ... or the fact that one in ten signed Windows binaries are comercial CA- certified signed malware, or that we have a multibillion dollar global phishing industry built around the failure of SSL certs to do what they were supposed to? On this, the final day of 2008, the 30th anniversary of certificates and the 20th anniversary of X.509, I declare commercial PKI... ... failed [0][1]. It's had thirty years, let's get over it and move on to something that actually has a hope of working. Peter (who doesn't see much chance of that happening, unfortunately). [0] Except to people holding stock in certificate manufacturers, who aren't doing so badly. [1] Or at least "obviously failed", as opposed to the earlier "failed but we can pretend there isn't a problem". - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
Sidney Markowitz wrote, On 31/12/08 10:08 AM: > or that CA root certs that use MD5 for their hash are > still in use and have now been cracked? I should remember -- morning coffee first, then post. The CA root certs themselves have not been cracked -- It is the digital signatures created by some CAs who still use MD5 to sign the certs that they issue that have been hacked: The known weakness in MD5 allows one to create two certs with the same MD5 hash, one that is legitimate to get signed by the CA, and another one for rogue use that can be given the same signature. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
On Tue, Dec 30, 2008 at 4:25 AM, Peter Gutmann wrote: > Ben Laurie writes: > >>what happens when the cert rolls? If the key also changes (which would seem >>to me to be good practice), then the site looks suspect for a while. > > I'm not aware of any absolute figures for this but there's a lot of anecdotal > evidence that many cert renewals just re-certify the same key year in, year > out (there was even a lawsuit over the definition of the term "renewal" in > certificates a few years ago). So you could in theory handle this by making a > statement about the key rather than the whole cert it's in. OTOH this then > requires the crawler to dig down into the data structure (SSH, X.509, > whatever) to pick out the bits corresponding to the key. Not really a serious difficulty. > Other alternatives > are to use a key-rollover mechanism that signs the new key with old one > (something that I've proposed for SSH, since their key-continuity model kinda > breaks at that point), and all the other crypto rube-goldbergisms you can > dream up. Yeah, that's pretty much the answer I came up with - another option would be to use both the old and new certs for a while. But signing the new with the old seems easiest to implement - the signature can go in an X509v3 extension, which means CAs can sign it without understanding it, and only Google has to be able to verify it, so all that needs to change is CSR generating s/w... - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
Ben Laurie writes: >what happens when the cert rolls? If the key also changes (which would seem >to me to be good practice), then the site looks suspect for a while. I'm not aware of any absolute figures for this but there's a lot of anecdotal evidence that many cert renewals just re-certify the same key year in, year out (there was even a lawsuit over the definition of the term "renewal" in certificates a few years ago). So you could in theory handle this by making a statement about the key rather than the whole cert it's in. OTOH this then requires the crawler to dig down into the data structure (SSH, X.509, whatever) to pick out the bits corresponding to the key. Other alternatives are to use a key-rollover mechanism that signs the new key with old one (something that I've proposed for SSH, since their key-continuity model kinda breaks at that point), and all the other crypto rube-goldbergisms you can dream up. In any case though at the moment we have basically no assurance at all of key/cert information so even a less-than-perfect mechanism like trusting Google and having problems during cert rollover is way, way better than what we've got now. In any case if Google decides to go bad then redirecting everyone's searches to www.drivebymalware.ru is a bigger worry than whether they're sending out inaccurate Perspectives responses. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
On Mon, Dec 29, 2008 at 10:10 AM, Peter Gutmann wrote: > David Molnar writes: > >>Service from a group at CMU that uses semi-trusted "notary" servers to >>periodically probe a web site to see which public key it uses. The notaries >>provide the list of keys used to you, so you can attempt to detect things >>like a site that has a different key for you than previously shown to all of >>the notaries. The idea is that to fool the system, the adversary has to >>compromise all links between the target site and the notaries all the time. > > I think this is missing the real contribution of Perspectives, which (like > almost any security paper) has to include a certain quota of crypto rube- > golbergism in order to satisfy conference reviewers. The real value isn't the > multi-path verification and crypto signing facilities and whatnot but simply > the fact that you now have something to deal with leap-of-faith > authentication, whether it's for self-generated SSH or SSL keys or for rent-a- > CA certificates. Currently none of these provide any real assurance since a > phisher can create one on the fly as and when required. What Perspectives > does is guarantee (or at least provide some level of confidence) that a given > key has been in use for a set amount of time rather than being a here-this- > morning, gone-in-the-afternoon affair like most phishing sites are. In other > words a phisher would have to maintain their site for a week, a month, a year, > of continuous operation, not just set it up an hour after the phishing email > goes out and take it down again a few hours later. > > For this function just a single source is sufficient, thus my suggestion of > Google incorporating it into their existing web crawling. You can add the > crypto rube goldberg extras as required, but a basic "this site has been in > operation at the same location with the same key for the past eight months" is > a powerful bar to standard phishing approaches, it's exactly what you get in > the bricks-and-mortar world, "Serving the industry since 1962" goes a lot > further than "Serving the industry since just before lunchtime". Two issues occur to me. Firstly, you have to trust Google (and your path to Google). Secondly, and this seems to me to be a generic issue with Perspectives and SSL - what happens when the cert rolls? If the key also changes (which would seem to me to be good practice), then the site looks suspect for a while. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
David Molnar writes: >Service from a group at CMU that uses semi-trusted "notary" servers to >periodically probe a web site to see which public key it uses. The notaries >provide the list of keys used to you, so you can attempt to detect things >like a site that has a different key for you than previously shown to all of >the notaries. The idea is that to fool the system, the adversary has to >compromise all links between the target site and the notaries all the time. I think this is missing the real contribution of Perspectives, which (like almost any security paper) has to include a certain quota of crypto rube- golbergism in order to satisfy conference reviewers. The real value isn't the multi-path verification and crypto signing facilities and whatnot but simply the fact that you now have something to deal with leap-of-faith authentication, whether it's for self-generated SSH or SSL keys or for rent-a- CA certificates. Currently none of these provide any real assurance since a phisher can create one on the fly as and when required. What Perspectives does is guarantee (or at least provide some level of confidence) that a given key has been in use for a set amount of time rather than being a here-this- morning, gone-in-the-afternoon affair like most phishing sites are. In other words a phisher would have to maintain their site for a week, a month, a year, of continuous operation, not just set it up an hour after the phishing email goes out and take it down again a few hours later. For this function just a single source is sufficient, thus my suggestion of Google incorporating it into their existing web crawling. You can add the crypto rube goldberg extras as required, but a basic "this site has been in operation at the same location with the same key for the past eight months" is a powerful bar to standard phishing approaches, it's exactly what you get in the bricks-and-mortar world, "Serving the industry since 1962" goes a lot further than "Serving the industry since just before lunchtime". Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
On Dec 27, 2008, at 10:02 AM, Ben Laurie wrote: On Fri, Dec 26, 2008 at 7:39 AM, Peter Gutmann wrote: Adding support for a service like Perspectives (discussed here a month or two back) would be a good start since it provides some of the assurance that a commercial PKI can't (and as an additional benefit it also works for SSH servers, since it's not built around certificates). So, when will Google add Perspectives support to their search database? :-). I can't find discussion of Perspectives - hint? Try http://www.cs.cmu.edu/~perspectives/perspectives_usenix08.pdf -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
Ben Laurie wrote: > > I can't find discussion of Perspectives - hint? Service from a group at CMU that uses semi-trusted "notary" servers to periodically probe a web site to see which public key it uses. The notaries provide the list of keys used to you, so you can attempt to detect things like a site that has a different key for you than previously shown to all of the notaries. The idea is that to fool the system, the adversary has to compromise all links between the target site and the notaries all the time. Paper, code, and Firefox extension: http://www.cs.cmu.edu/~perspectives/ signature.asc Description: OpenPGP digital signature
Re: Security by asking the drunk whether he's drunk
* Jerry Leichter: > I got in touch with the company and actually received intelligent > responses both at their 800 number - I placed my order that way - and > in a response from their customer service people. Most remarkable - > almost all organizations ignore such communication. It's ironic that > those who appear to be trying the hardest are being screwed over by > the system that's currently in place - and will inadvertently be > involved in training users to simply bypass yet another kind of bad > cert warning. This is also why I don't want browser vendors to remove CAs for which they haven't got enough documentation, at least at this stage. After a few rounds of competitors attacking each other (and themselves as well, because who knows who controls some of the older private keys these days), the only CAs left are those where initiating RA procedures is sufficiently difficult for law-abiding citizens--and cost is a very likely discriminator in this area. And for most sites, those extra $$$ are better spent on hosting with some sort of security monitoring. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
On Fri, Dec 26, 2008 at 7:39 AM, Peter Gutmann wrote: Adding support for a > service like Perspectives (discussed here a month or two back) would be a good > start since it provides some of the assurance that a commercial PKI can't (and > as an additional benefit it also works for SSH servers, since it's not built > around certificates). > > So, when will Google add Perspectives support to their search database? :-). I can't find discussion of Perspectives - hint? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
On Dec 26, 2008, at 2:39 AM, Peter Gutmann wrote: d...@geer.org writes: I'm hoping this is just a single instance but it makes you remember that the browser pre-trusted certificate authorities really needs to be cleaned up. Given the more or less complete failure of commercial PKI for both SSL web browsing and code-signing (as evidenced by the multibillion-dollar cybercrime industry freely doing all the things that SSL certs and code-signing were supposed to prevent them from doing), it's not so much "cleaned up" as "replaced with something that may actually work" I just had an interesting experience with a different sort of failure: I tried to buy a DVD from The Teaching Company (www.teach12.com ). When I went to check out - or even if when I connect to the top level at https://www.teach12.com - I get a complaint that their cert is signed by a unknown authority. It turns out that they recently put an EV certificate in place. It's issued by "VeriSign Class 3 Extended Validation SSL SGC CA" - which neither Safari 3.2.1 nor Firefox 3.0.5 on my Mac have ever heard of! I got in touch with the company and actually received intelligent responses both at their 800 number - I placed my order that way - and in a response from their customer service people. Most remarkable - almost all organizations ignore such communication. It's ironic that those who appear to be trying the hardest are being screwed over by the system that's currently in place - and will inadvertently be involved in training users to simply bypass yet another kind of bad cert warning. (I can highly recommend the courses that The Teaching Company distributes, by the way. I usually borrow them from the library, but I've bought a few of the best here and there - especially when they have sales, as they do right now.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
d...@geer.org writes: >I'm hoping this is just a single instance but it makes you remember that the >browser pre-trusted certificate authorities really needs to be cleaned up. Given the more or less complete failure of commercial PKI for both SSL web browsing and code-signing (as evidenced by the multibillion-dollar cybercrime industry freely doing all the things that SSL certs and code-signing were supposed to prevent them from doing), it's not so much "cleaned up" as "replaced with something that may actually work". Adding support for a service like Perspectives (discussed here a month or two back) would be a good start since it provides some of the assurance that a commercial PKI can't (and as an additional benefit it also works for SSH servers, since it's not built around certificates). So, when will Google add Perspectives support to their search database? :-). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
Just one minor observation: On Dec 22, 2008, at 5:18 AM, Peter Gutmann wrote: 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. This one is a bit more complicated. Attackers have access to large amounts of money *in relatively small units*. No matter how many credit card accounts you steal, it would be pretty much impossible to create an actual, properly populated, physical storefront in a decent shopping area. You can be fairly confident that a physical store is what it appears to be. Granted, what you're discussing is on-line fraud. My point is that this is yet another difference between the on-line and brick-and- mortar worlds, and one that leads us astray when we try to apply our real-world reasonableness filters to the on-line world. There are many inter-related elements here. Perhaps the biggest factor is *time*: On-line frauds can be setup, draw in victims, and disappear very quickly - only to reappear someplace else. This allows them to built using what is effectively the float on stolen identities - much of which will be found and revoked by the end of a billing cycle. The real world has much more inertia - there are many steps involved in building out a physical storefront, they take time, and your money has to be "good" across that entire time. Note that many real-world frauds rely on the ability to short-cut what are normally time- consuming procedures and disappear before the controls can kick in. (Think of check kiting, or of the guys from what appear to be long- established local paving companies that "pave" your driveway with cheap oil and are gone by the next morning.) EV certificates (unsuccessfully) attempt to bring some of this real- world checking on line: They are expensive, and you have to pay in one lump. They're not going to accept a bunch of credit cards. They check your identity, which if done right takes time *and indirectly checks that you actually have a history*. Of course, the actual practice is different and, given the incentives in the industry - where there is no penalty for giving out an invalid EV certificate, and a reward for getting the job done quickly - this is all illusion. Long-running frauds, while certainly not unknown (hello, Bernie Madoff), are relatively rare: Every day out there is another chance to get caught. The preferred mode of fraud will always be "get 'em hooked, fleece 'em, get out of town - as fast as you can". Can we get some of the advantages of this real-world fact in the on-line world? The best example I know of is CMU's Perspectives effort: If something "looks the same" to many observers over a period of time, it's more likely to be trustworthy. Of course, if this kind of thing catches on, it will be much harder for a startup to gain instant recognition. The Internet "need for speed" isn't compatible with safety. Some tradeoffs are inevitable. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
Adam Shostack writes: >Thank you! I hadn't seen this either, and it's exactly what I was looking >for. One note of caution with the statistics given on that page, those figures are apparently as reported by the Malicious Software Removal Tool (MSRT) (see http://www.microsoft.com/security/portal/sir.aspx) so they'll represent the output of a basic malware removal tool (not a full-blown malware/AV scanner), and since it's only run on up-to-date Windows systems with auto-updates (and therefore security hotfixes and whatnot) actively applied (MSRT is itself supplied via auto-updates) it's likely that the real situation is a lot worse than that, i.e. a full-blown AV program might find even more malware, and any system that's regularly running the MSRT and applying security updates is going to be less malware-infested than a general random sample of systems. So while they're a (really scary, much, much worse than I thought) indicator of how bad it is, it's likely that things are even worse than that. I've written to the person who wrote the blog entry to try and get clarification on some issues raised there. (Oh, and I assume people have seen Eddy Nigg's article on how easy it is to get a certificate for a site belonging to someone else from a commercial CA, https://blog.startcom.org/?p=145, which also made Slashspot earlier today). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
or asking "Can I trust you?" --- http://blog.startcom.org/?p=145 Slashdot and others are reporting on this story about how it was possible for a person to receive a completely valid certificate for a random domain of his choosing without any questions or verification. In this case he generated a certificate for mozilla.com from a reseller of the Comodo certificate authority. I'm hoping this is just a single instance but it makes you remember that the browser pre-trusted certificate authorities really needs to be cleaned up. If it's not obvious enough, this is not good for Tor users due to the fact that we try to rely on SSL certificates to make sure that traffic isn't sniffed while using Tor. -Roc Tor Admin --- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
Adam Shostack writes: >I'd be estatic with a frequency analysis that I could show to people. This always happens right after you hit ^D... it turns out that Microsoft actually has published figures for this, although it's fairly recent so I hadn't seen it before now: http://blogs.technet.com/mmpc/archive/2008/11/06/malware-and-signed-code.aspx ... approximately 135,000 validly signed malware files were reported to Microsoft [there were 173K files in total, but 38K were expired/revoked/whatever]. Of signed detected files, severity of the threats tended to be high or severe, with low and moderate threats comprising a much smaller number of files. Going directly to the source gets you much better stats than talking to malware researchers at conferences :-). "High" and "severe" typically means 0day rootkit-type exploits, so that's scary stuff, particularly since that's only malware reported to MS and not all the malware that's out there. Hmm, I wonder if it's just coincidence that the malware authors only bother signing the most effective/vicious malware to ensure a good success rate and for the less effective ones they just leave them as is? Another interesting figure: valid code signing certificates were reported on over 1.78 million distinct non-malicious files to the MMPC So from Microsoft's figures it looks like roughly every tenth signed file is active (i.e. non-revoked/expired/whatever) malware. Ouch! Peter (so what we need now is EV certs for code-signing. Yeah, that'll fix it). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Security by asking the drunk whether he's drunk
Adam Shostack 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 re
Re: Security by asking the drunk whether he's drunk
[Moderator's note: top posting and failing to trim what you're replying to are both considered bad form... --Perry] Peter, 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.) Ditto with the business impersonation. I'd like stories, I'd be estatic with a frequency analysis that I could show to people. Adam Out of my own curiosity only, not speaking for my employer or yours. On Mon, Dec 22, 2008 at 01:18:31AM +1300, Peter Gutmann wrote: | In recently had an opportunity to talk to someone who had had a family member | become a victim of identity fraud, not in the usual manner to target them | directly but as a springboard to target others by registering a phishing site | in their name. Variations on this theme include using stolen identities to | buy code-signing certificates for malware and a variety of other end-runs | around identity-based accountability mechanisms. The problem here is the fact | that the market is so awash with stolen identities that vendors have to sell | them in bulk lots just to turn a profit. In other words a system designed to | defeat the problem of identity theft relies on the flawless functioning of a | global identity-based accountability infrastructure in order to work, a | classic catch22-situation. If it's possible to buy stolen identities with | almost arbitrary amounts of accompanying verification data to authenticate | them for purposes of financial fraud: | | We sell all you need to hack, shop & cashout. | CardTipe / * CC Name / * CC Number / * CC Expiry / * CVV2 / * CC PIN | First & Last Names / * Address & City / * State & Zip/Postal code / * | Country (US) / * Phone # | MMN [Mother's maiden name] / * SSN [Social security number] / * DOB | [Date of birth] | Bank Acc No / * Bank Routine [Routing] No | | On our forum you can buy: | Active eBay accounts with as many positive feedbacks as you need | Active and wealthy PayPal accounts | PINs for prepaided AT&T and Sprint phone cards | Carded Western Union accounts for safe and quick money transfers | Carded UPS and FedEx accounts for quick and free worldwide shipping of | your stuff | Full info including Social Security Info, Driver Licence #, Mother' | Maiden Name and much more | Come and register today and get a bonus by your choice: | One Citybank account with online access with 3k on board, or 5 | COB' cards with 5k credit line | 10 eBay active eBay accounts with 100+ positive feedbacks | 25 Credit Cards with PINs for online carding | | then it's just as easy to turn those identities towards facilitating further | identity fraud, and indeed it's become pretty much standard practice to | register fraudulent domains and buy fraudulent X.509 certificates with stolen | credentials paid for with stolen financial information. As a result, 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, | possibly someone who doesn't even use a computer. Even the argument that at | least the signed malware allows for the use of CRLs to disable it falls flat | when you consider the difference in speed between having the malware | identified and blocked by anti-virus software and the ponderous delays of the | CRL issue process, assuming that the end-user software even checks them. | | Another online fraud technique that's seen use in some countries, although | it's not widespread because it's still much easier to do the same thing via | less labour-intensive means, is to use stolen credentials to establish an | online presence for an existing business with a good credit history, use it | for whatever fraud you want to perpetrate, and then vanish before anyone's the | wiser, for example before the end of the monthly billing cycle when the real | business either gets sent paperwork that it isn't expecting or doesn't get | sent paperwork that it is. Since this is borrowing the identity of a bona | fide business rather than an individual, there's almost no way to catch such | problems because any (rational) amount of checking will simply confirm that | it's a long-established legitimate business. This type of fraud could | probably even defeat the verification used for EV certificates (at least as | set out in the guidelines published by some CAs), although at the moment it's | entirely unnecessary since it's possible to achieve the same ends through far | less laborious means. | | This is a classic case of asking the drunk whether he's drunk - a system | rampant with identity fraud is expected to function as the ba
Security by asking the drunk whether he's drunk
In recently had an opportunity to talk to someone who had had a family member become a victim of identity fraud, not in the usual manner to target them directly but as a springboard to target others by registering a phishing site in their name. Variations on this theme include using stolen identities to buy code-signing certificates for malware and a variety of other end-runs around identity-based accountability mechanisms. The problem here is the fact that the market is so awash with stolen identities that vendors have to sell them in bulk lots just to turn a profit. In other words a system designed to defeat the problem of identity theft relies on the flawless functioning of a global identity-based accountability infrastructure in order to work, a classic catch22-situation. If it's possible to buy stolen identities with almost arbitrary amounts of accompanying verification data to authenticate them for purposes of financial fraud: We sell all you need to hack, shop & cashout. CardTipe / * CC Name / * CC Number / * CC Expiry / * CVV2 / * CC PIN First & Last Names / * Address & City / * State & Zip/Postal code / * Country (US) / * Phone # MMN [Mother's maiden name] / * SSN [Social security number] / * DOB [Date of birth] Bank Acc No / * Bank Routine [Routing] No On our forum you can buy: Active eBay accounts with as many positive feedbacks as you need Active and wealthy PayPal accounts PINs for prepaided AT&T and Sprint phone cards Carded Western Union accounts for safe and quick money transfers Carded UPS and FedEx accounts for quick and free worldwide shipping of your stuff Full info including Social Security Info, Driver Licence #, Mother' Maiden Name and much more Come and register today and get a bonus by your choice: One Citybank account with online access with 3k on board, or 5 COB' cards with 5k credit line 10 eBay active eBay accounts with 100+ positive feedbacks 25 Credit Cards with PINs for online carding then it's just as easy to turn those identities towards facilitating further identity fraud, and indeed it's become pretty much standard practice to register fraudulent domains and buy fraudulent X.509 certificates with stolen credentials paid for with stolen financial information. As a result, 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, possibly someone who doesn't even use a computer. Even the argument that at least the signed malware allows for the use of CRLs to disable it falls flat when you consider the difference in speed between having the malware identified and blocked by anti-virus software and the ponderous delays of the CRL issue process, assuming that the end-user software even checks them. Another online fraud technique that's seen use in some countries, although it's not widespread because it's still much easier to do the same thing via less labour-intensive means, is to use stolen credentials to establish an online presence for an existing business with a good credit history, use it for whatever fraud you want to perpetrate, and then vanish before anyone's the wiser, for example before the end of the monthly billing cycle when the real business either gets sent paperwork that it isn't expecting or doesn't get sent paperwork that it is. Since this is borrowing the identity of a bona fide business rather than an individual, there's almost no way to catch such problems because any (rational) amount of checking will simply confirm that it's a long-established legitimate business. This type of fraud could probably even defeat the verification used for EV certificates (at least as set out in the guidelines published by some CAs), although at the moment it's entirely unnecessary since it's possible to achieve the same ends through far less laborious means. This is a classic case of asking the drunk whether he's drunk - a system rampant with identity fraud is expected to function as the basis for an identity-based accountability mechanism. Or to put it another way, on the remote chance that someone does finally figure out what it'll take to make PKI work, it still won't actually work. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
