Re: [Full-disclosure] Recent claims that windows update is broken
On Fri, Sep 09, 2011 at 03:09:25PM -0700, Dan Kaminsky wrote: On Thu, Sep 8, 2011 at 2:55 AM, Georgi Guninski gunin...@guninski.comwrote: http://www.theregister.co.uk/2011/09/07/diginotar_hacker_proof/ I'm able to issue windows update, he [Comodohacker] wrote. Microsoft's statement about Windows Update and that I can't issue such update is totally false! The original Comodohacker statement is at: http://pastebin.com/85WV10EL Is this true? For the record, no. Windows Update doesn't just depend on WinVerifyTrust, it also calls CertVerifyCertificateChainPolicy with the CERT_CHAIN_POLICY_MICROSOFT_ROOT flag, documented here: http://msdn.microsoft.com/en-us/library/aa377163(v=vs.85).aspx By your logic there would be no exploits just because the documentation writes so. I bothered to ask mainly for these reasons: 1. It is unclear to me what collection of private keys/certs Comodohacker has 2. From thereg article: Microsoft declined to comment. -- georgi ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Western Union Certificate Error
On Sat, 10 Sep 2011 09:39:37 +0700, JT S said: It wouldn't be that hard to set up an SVN repo with the public key of someone like google. I could then check it out, take the copy over to some notary or the company themselves, verify it, sign it, check it back in. And before you sign it, you and the notary verify that it's actually Google's public key and not an imposter, how, exactly? And more importantly, does your scheme still work if you and the notary discover that, in fact, nobody's bothered to check the public key for Billy Bob's Bait, Tackle, and App Store so you can't rely on Wow, 3,495,435 people signed it, it *must* be right? This is a problem that a CA usually solves by doing whatever verification of the request (consider the difference between a regular CA-signed SSL cedrtificate and an :Extended Validation certificate), and PGP solves with key-signing parties that involve checking of driver's licenses and the like. And are you really willing to pay out of *your* pocket to do the checking that an Extended Validation cert requires? How many times will you do that? It really doesn't scale well anyhow - how many times do you think Google wants to answer the phone and say Yes, *yawn* key 3,494,342 is really us (and more importantly - how did you verify that it was Google answering the phone?). At this point, your scheme them becomes the first guy who bothers to check the key becomes a CA - and you trust that guy, *why*, exactly? Does your scheme continue to work in a world where I have 12 signatures on my PGP key, and I've blacklisted 6 keys because I *know* they signed my key without doing any proper validation? tl;dr: The hardest part of crypto is always key management. pgpbPSOwKomsZ.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Western Union Certificate Error
It wouldn't be that hard to set up an SVN repo with the public key of someone like google. I could then check it out, take the copy over to some notary or the company themselves, verify it, sign it, check it back in. Then google could pull the key nightly and verify it hasn't been modded, just signed. Someone could make a simple browser plugin to do all this. Problem solved and no more CAs need be involved. I'm probably going to switch to firefox+convergenge plugin as it seems to have some of this already. As we enter an era when governments are spying on people without probable cause in order to crack down on dissent and free speech, I can see no other alternative. At this stage of history, one of two things is possible: Either the general population will take control of its own destiny and will concern itself with community interests guided by values of solidarity and sympathy and concern for others, or alternatively there will be no destiny to control.~Chomsky On Fri, Sep 9, 2011 at 10:34 PM, valdis.kletni...@vt.edu wrote: On Fri, 09 Sep 2011 16:23:50 +0700, JT S said: revoke. For all I know, anyone who breaks into any CA which is trusted by my browser can issue and sign a cert for any domain and the browser will blindly accept it. Yep. That's how it works... I personally would prefer that the browsers only trust keys that I have signed, have low trust for keys signed by keys I have signed, and no trust for the rest. Paging Phil Zimmerman I'd really like the ability to walk into western union or my bank or local google office and sign their key as well as the ability to revoke my signature without revoking my key. A big chunk of the problem there is that although you might *like* that ability, it really presupposes the existence of an office you can walk into. I've never seen a local Google office, and at least around here, Western Union offices are just a terminal at the customer service desk of supermarkets. There's a second, more subtle problem - if you *did* find an office, what exactly are you attesting by signing something? If you talk to me at a key signing party, I'll claim that key B4D3D7B0 is mine - and more importantly, I can (at least in theory, if I have my laptop with me) *prove* I control it by generating signatures with it. However, if you walk into a Western Union branch office, all the guy can claim is Yeah, that fingerprint you have for our key matches what was on the piece of paper they mailed us last year. However, *the guy at the branch is no more able to verify that piece of paper than you are*. He can't prove control of the key by signing something with the Western Union key (and if he *could*, that's even *more* scary). Then there's the third problem - currently, I have *6* keys on my PGP keyring that are specifically flagged as do not trust because I've found copies of my key signed by them when I know for a fact I've never met the person and had them verify my key. Ming you, there's only about a dozen valid signatures on my key. In other words, my personal set of personally verified as Doing It Wrong is half the size of people who do it right. And that's among people that are smart enough to use PGP. What is the meaning of any single given signature (including yours) on a key when every Joe Sixpack who doesn't even really understand keysigning is going around and signing keys? What do you do if a key has 3 million signatures, but 1M of them are probably bogus? I won't discuss the question of how you maintain a web-of-trust structure with 10M entries in it - the current PGP strong set has only about 45K in it at the moment. -- James Snodgrass (303) 736-9452 CONFIDENTIALITY NOTICE This E-Mail transmission (and/or the documents accompanying it) is for the sole use of the intended recipient(s) and may contain information protected by the attorney-client privilege, the attorney-work-product doctrine or other applicable privileges or confidentiality laws or regulations. If you are not an intended recipient, you may not review, use, copy, disclose or distribute this message or any of the information contained in this message to anyone. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of this message and any attachments. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Western Union Certificate Error
It doesn't matter who signed it because I only look for whether or not I signed it or if my favorite notary signed it. I would imagine that a digital notary would have their own key and goog could walk in and get their cert signed the same way we do documents. If that notary get's breached I can stop trusting their signature but still trust goog unless they get breached too. So essentially each person would have the ability to issue their own cert and get it notarized. If the signatures of the notaries match on my cert and someone else's cert, I know they are who they say they are to the limit possible with notaries(e.g. you could still use a fake ID). I suppose it could be scaled by issuing an RFC which lays out the method of notarization and have all the notaries sign each other's keys etc. On Sat, Sep 10, 2011 at 7:30 PM, valdis.kletni...@vt.edu wrote: On Sat, 10 Sep 2011 09:39:37 +0700, JT S said: It wouldn't be that hard to set up an SVN repo with the public key of someone like google. I could then check it out, take the copy over to some notary or the company themselves, verify it, sign it, check it back in. And before you sign it, you and the notary verify that it's actually Google's public key and not an imposter, how, exactly? And more importantly, does your scheme still work if you and the notary discover that, in fact, nobody's bothered to check the public key for Billy Bob's Bait, Tackle, and App Store so you can't rely on Wow, 3,495,435 people signed it, it *must* be right? This is a problem that a CA usually solves by doing whatever verification of the request (consider the difference between a regular CA-signed SSL cedrtificate and an :Extended Validation certificate), and PGP solves with key-signing parties that involve checking of driver's licenses and the like. And are you really willing to pay out of *your* pocket to do the checking that an Extended Validation cert requires? How many times will you do that? It really doesn't scale well anyhow - how many times do you think Google wants to answer the phone and say Yes, *yawn* key 3,494,342 is really us (and more importantly - how did you verify that it was Google answering the phone?). At this point, your scheme them becomes the first guy who bothers to check the key becomes a CA - and you trust that guy, *why*, exactly? Does your scheme continue to work in a world where I have 12 signatures on my PGP key, and I've blacklisted 6 keys because I *know* they signed my key without doing any proper validation? tl;dr: The hardest part of crypto is always key management. -- James Snodgrass (303) 736-9452 CONFIDENTIALITY NOTICE This E-Mail transmission (and/or the documents accompanying it) is for the sole use of the intended recipient(s) and may contain information protected by the attorney-client privilege, the attorney-work-product doctrine or other applicable privileges or confidentiality laws or regulations. If you are not an intended recipient, you may not review, use, copy, disclose or distribute this message or any of the information contained in this message to anyone. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of this message and any attachments. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] List Charter
[Full-Disclosure] Mailing List Charter John Cartwright jo...@grok.org.uk - Introduction Purpose - This document serves as a charter for the [Full-Disclosure] mailing list hosted at lists.grok.org.uk. The list was created on 9th July 2002 by Len Rose, and is primarily concerned with security issues and their discussion. The list is administered by John Cartwright. The Full-Disclosure list is hosted and sponsored by Secunia. - Subscription Information - Subscription/unsubscription may be performed via the HTTP interface located at http://lists.grok.org.uk/mailman/listinfo/full-disclosure. Alternatively, commands may be emailed to full-disclosure-requ...@lists.grok.org.uk, send the word 'help' in either the message subject or body for details. - Moderation Management - The [Full-Disclosure] list is unmoderated. Typically posting will be restricted to members only, however the administrators may choose to accept submissions from non-members based on individual merit and relevance. It is expected that the list will be largely self-policing, however in special circumstances (eg spamming, misappropriation) then offending members may be removed from the list by the management. An archive of postings is available at http://lists.grok.org.uk/pipermail/full-disclosure/. - Acceptable Content - Any information pertaining to vulnerabilities is acceptable, for instance announcement and discussion thereof, exploit techniques and code, related tools and papers, and other useful information. Gratuitous advertisement, product placement, or self-promotion is forbidden. Disagreements, flames, arguments, and off-topic discussion should be taken off-list wherever possible. Humour is acceptable in moderation, providing it is inoffensive. Politics should be avoided at all costs. Members are reminded that due to the open nature of the list, they should use discretion in executing any tools or code distributed via this list. - Posting Guidelines - The primary language of this list is English. Members are expected to maintain a reasonable standard of netiquette when posting to the list. Quoting should not exceed that which is necessary to convey context, this is especially relevant to members subscribed to the digested version of the list. The use of HTML is discouraged, but not forbidden. Signatures will preferably be short and to the point, and those containing 'disclaimers' should be avoided where possible. Attachments may be included if relevant or necessary (e.g. PGP or S/MIME signatures, proof-of-concept code, etc) but must not be active (in the case of a worm, for example) or malicious to the recipient. Vacation messages should be carefully configured to avoid replying to list postings. Offenders will be excluded from the mailing list until the problem is corrected. Members may post to the list by emailing full-disclosure@lists.grok.org.uk. Do not send subscription/ unsubscription mails to this address, use the -request address mentioned above. - Charter Additions/Changes - The list charter will be published at http://lists.grok.org.uk/full-disclosure-charter.html. In addition, the charter will be posted monthly to the list by the management. Alterations will be made after consultation with list members and a consensus has been reached. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Western Union Certificate Error
On Sat, 10 Sep 2011 19:50:57 +0700, JT S said: It doesn't matter who signed it because I only look for whether or not I signed it or if my favorite notary signed it. You missed the point. You care you signed it - but how do you know you signed a valid cert that actually belonged to Google, and you didn't sign a fake Googlle cert? And if you only trust it because my favorite notary signed it, how is it different from the *current* CA model, where you trust a cert only because a CA you trust signed it? I would imagine that a digital notary would have their own key and goog could walk in and get their cert signed the same way we do documents. If that notary get's breached I can stop trusting their signature but still trust goog unless they get breached too. Umm.. we do that *now* - it's called a CA. And we know how well that works. This notary called DigiNotar got breached recently, and everybody is installing patches to not trust their signature. Except that without some valid signature on it *that you trust*, you have no reason to trust the Google cert after the CA gets breached. Think this through: You're trusting the Google cert because the CA/notary/whatever told you it was Google. Now if you discover the registrar is bad, you should *not* trust the Google cert anymore *either*. Consider the recent DigiNotar mess - they actually issued (among many other things) a signed invalid cert for *.google.com. Everybody who revoked DigiNotar is then protected against that invalid cert. But if you had signed/ flagged it trusted/whatever because DigiNotar said it was OK, and then revoked DigiNotar but then continued to trust that cert because you signed it - *you are still vulnerable to that bad cert*. So essentially each person would have the ability to issue their own cert and get it notarized. If the signatures of the notaries match on my cert and someone else's cert, I know they are who they say they are to the limit possible with notaries(e.g. you could still use a fake ID). I suppose it could be scaled by issuing an RFC which lays out the method of notarization and have all the notaries sign each other's keys etc. Congratulations. You've re-invented *exactly* how CA's work now, (right down to the 'issue their own cert and get it notarized - the PKCS standards call this a certificate signing request - see PKCS#10 or RFC2986) except for three details: 1) It isn't the signatures match - the check made is the cert was signed by the same key that I have a trusted copy of the public key to verify the signature with (the actual signatures will *never* match unless somebody manages to force a signature collision, which is generally a Really Bad Thing ;) 2) the part about notaries signing each other's keys, which doesn't actually buy you much except for being able to establish a trust for a totally new notary. But currently everybody seems to be OK with I have no reason to trust these 600 CAs other than their certs came with my browser, so we'll probably just wait for your vendor to send you an update with 601 CA keys in it rather than trying to deploy a cross-signature scheme. 3) It doesn't address the two biggest validation weaknesses in the CA scheme - (a) that somebody uses faked credentials to get the CA to sign the cert (see the CERT advisory from 2001 about Verisign accidentally signing a bogus Microsoft cert), and (b) somebody can steal the digital equivalent of the notary's stamp (I'm looking at you, DigiNotar.. ;) And yes, there *is* a standard (set of them, actually) for all this: https://secure.wikimedia.org/wikipedia/en/wiki/PKCS So we don't need any new RFCs. ;) pgpKGAv7oHeDs.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Recent claims that windows update is broken
For the record, no. Windows Update doesn't just depend on WinVerifyTrust, it also calls CertVerifyCertificateChainPolicy with the CERT_CHAIN_POLICY_MICROSOFT_ROOT flag, documented here: http://msdn.microsoft.com/en-us/library/aa377163(v=vs.85).aspx By your logic there would be no exploits just because the documentation writes so. Nothing's stopping you from hooking CertVerifyCertificateChainPolicy and seeing for yourself :) See also: http://twitter.com/#!/thierryzoller/status/112240979079204864 @thierryzoller: @dakami that finally explains why i didnt succeed in mitm it few years ago I bothered to ask mainly for these reasons: 1. It is unclear to me what collection of private keys/certs Comodohacker has He's been hitting certificates that have public interfaces, because as we know, most public interfaces are terrible. I do not expect the Microsoft Root to have a public interface. 2. From thereg article: Microsoft declined to comment. Microsoft commented rather clearly here: http://bit.ly/q0JpIT Attackers are not able to leverage a fraudulent Windows Update certificate to install malware via the Windows Update servers. The Windows Update client will only install binary payloads signed by the actual Microsoft root CA certificate, which is issued and secured by Microsoft. Also, Windows Update itself is not at risk, even to an attacker with a fraudulent certificate. Obviously the guy's got all sorts of illicit access. Just probably not this. -- georgi ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Using QR tags to Attack SmartPhones (Attaging)
I'd like to share this paper with all. English version http://kaoticoneutral.blogspot.com/2011/09/using-qr-tags-to-attack-smartphones_10.html Version en español http://kaoticoneutral.blogspot.com/2011/09/using-qr-tags-to-attack-smartphones.html Thanks to all ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
