Fwd: [guardian-dev] Piñata server intrusion bounty
---------- Forwarded message ---------- From: Patrick Connolly <patrick.c.connolly@gmail.com> Date: Tue, Feb 10, 2015 at 1:38 PM Subject: [guardian-dev] Piñata server intrusion bounty To: Guardian Dev <guardian-dev@lists.mayfirst.org> https://news.ycombinator.com/item?id=9027743 Would this be an interesting thing to put on a duplicate (...or production?) system and publicize? Might be an interesting practise for creating a form of canary, especially for projects that perhaps can't afford full and constant audits. Patrick -------------------------------------------- Q: Why is this email [hopefully] five sentences or less? | A: http://five.sentenc.es NOTE that my incoming emails are delayed from arriving in my inbox until 9am daily. If you need to reach me sooner, please use other means of getting in touch. #slowwebmovement _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: guardian-dev-unsubscribe@lists.mayfirst.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Hi, On 02/11/2015 06:49, grarpamp wrote:> ---------- Forwarded message - ----------
From: Patrick Connolly <patrick.c.connolly@gmail.com> Date: Tue, Feb 10, 2015 at 1:38 PM Subject: [guardian-dev] Piñata server intrusion bounty To: Guardian Dev <guardian-dev@lists.mayfirst.org>
https://news.ycombinator.com/item?id=9027743
Would this be an interesting thing to put on a duplicate (...or production?) system and publicize?
Might be an interesting practise for creating a form of canary, especially for projects that perhaps can't afford full and constant audits.
I'm one of the authors of OCaml-TLS, and we setup the bounty. So why did we do it? Because lots of company security bounties are very bureaucratic and intransparent - in order to receive the bounty you've to argue with the company - you might not disclose the vulnerability, they might not agree to the vulnerability, etc. (see https://www.schneier.com/crypto-gram/archives/1998/1215.html#contests and http://www.ieee-security.org/Cipher/PastIssues/1996/issue9602/issue9602.txt [I don't share all arguments of both articles]). Thus, having a transparent way [the blockchain] and an automated transmission (the server replies after successful authentication with the private key - no interaction from myself or the other author needed) - motivated us to put something against those security bounties. Unfortunately, it can only show the existence of issues, not their absence. The amount of the bounty is high enough to get some attention - - but might be too low for professionals to properly analyse (but then, they'd be able to brag about their success and get some fame). A too high bounty would put myself and the other author too much into the focus of a targeted attack. Obviously we have access to that private key in some way or another.. If you consider doing something like that again (which I appreciate), please take care to not deduce the security of YYY from no successful attack on the bounty (it depends very much on time, publicity, bounty - - whether it gets interest). It is crucial that such a bounty does not replace proper code audits (I don't have a good definition of "proper" here). Also, it would be neat to think about a good way how the server can prove that it actually has the private key to the bounty - but I believe it is impossible (similar to that the server cannot prove it runs the software we claim it does). So far we had roughly 75000 accesses to the website, and roughly 5000 TLS handshakes to the client/server/reverse client - which very much shows that it primarily gets publicity. I especially like our setup that you can short-circuit the server with its client and observe a successful TLS handshake which afterwards transmits the private key over the encrypted channel. I'm happy to discuss this further, and get feedback on the setup, hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJU2yjjAAoJELyJZYjffCjuYTIQAJJ6ZDR9+pjHUubrN0SNexlm wJGHJ75Lbcgorjvf76vMhx8kB773E+EspluxOqrAU8NSM/nfMypO9PqcAJtWKI4f Bsvm0cNuvoCMTLQA3SM3DZEwNlTtOJSEixYm1xy0/+O6BzXNGPYhmFTwKDEKLrV0 nuBcZGGK0bvS4Mh855nwJYJEhIDXfIqlxCIL7ROAqV3n/HzeeFbIfFcM3zRNWjKg WMiUzeF4ReQhTadhkF+CWO5gWTSqGEgeW04g6wvA3FCWF17vQJZOz4XhA/h5ds3Z sRStWF/j1+wmCo7fDPnQQF1U9nQ4IjRjO9hdXoJAAmH2aN/FWPbgbCarxvX7pFMk 6IRjtjoo3XvJrAI848Gegr41BkV+qLn5ZHeP4pG/KAHE30pg2RBkBXhfzFTTnSBW VHAJ4qczH6tMSIptY/X7GPQjm8UBJh716VZiAYW23fA1Yxzy8CGTyAiYM0C9hhWn KZj+mcL2Gcsnl095iQNGg1Pbs+gSLWW4DH4TEYqxBCalLvmPLfLGIFgHGshw3/+w gRITIk+zHvMPEzNf5EMZYTnItiektPtMCHKsD/aPq2onjVQMvAdzUI7Xd0z58Sfx gvBYKjPZMcd08q3RW1Wf5o9mfUcf66zMHs9haonZIWyDhNyG7G8jokzqhHBkDxee ex0MH6YIA+1734Hymr/S =y6vy -----END PGP SIGNATURE-----
On Wed, Feb 11, 2015 at 10:03:15AM +0000, Hannes Mehnert wrote:
Also, it would be neat to think about a good way how the server can prove that it actually has the private key to the bounty - but I believe it is impossible (similar to that the server cannot prove it runs the software we claim it does).
couldn't remote attestation be used for this? -- otr fp: https://www.ctrlc.hu/~stef/otr.txt
On 02/11/2015 12:43, stef wrote:
On Wed, Feb 11, 2015 at 10:03:15AM +0000, Hannes Mehnert wrote:
Also, it would be neat to think about a good way how the server can prove that it actually has the private key to the bounty - but I believe it is impossible (similar to that the server cannot prove it runs the software we claim it does).
couldn't remote attestation be used for this?
sure - at least in theory. do you have any concrete implementation/strategy in mind? (I'm not an expert in RA)... hannes
participants (3)
-
grarpamp -
Hannes Mehnert -
stef