Re: [liberationtech] Foxacid payload
On Tue, Jul 22, 2014 at 1:48 AM, coderman coder...@gmail.com wrote: ... perhaps someone to help answer the question is Google, if they felt inclined. more context, although less sophisticated than TAO tech: When Governments Hack Opponents: A Look at Actors and Technology - http://www.icir.org/vern/papers/govhack.usesec14.pdf ''' Computer security research devotes extensive efforts to protecting individuals against indiscriminate, large-scale attacks such as those used by cybercriminals. Recently, the problem of protecting institutions against targeted attacks conducted by nation-states (so-called “Advanced Persistent Threats”) has likewise elicited significant research interest. Where these two problem domains intersect, however—targeted cyber attacks by nation-states against individuals —has received virtually no significant, methodical research attention to date. This new problem space poses challenges that are both technically complex and of significant real-world importance. In this work we undertake to characterize the emergent problem space of nation-state Internet attacks against individuals engaged in pro-democracy or opposition movements. While we lack the data to do so in a fully comprehensive fashion we provide extensive detail from both technical and operational perspectives as seen in three countries. We view such characterizations as the fundamental first step necessary for the rigorous, scientific pursuit of a new problem space. For our study we draw upon several years of research we have conducted into cases from Bahrain, Syria and the United Arab Emirates. We frame the nature of these attacks, and the technology and infrastructure used to conduct them, in the context of their impacts on real people. We hope in the process to inspire additional research efforts addressing the difficult problem of how to adequately protect individuals with very limited resources facing powerful adversaries. ''' -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
On Fri, Jul 18, 2014 at 12:22 PM, Denis 'GNUtoo' Carikli gnu...@no-log.org wrote: ... If the adversary looses one exploit each times he attacks someone, then... perhaps someone to help answer the question is Google, if they felt inclined. per re:publica 2014 - Morgan Marquis-Boire: Fear and Loathing on the Internet - https://www.youtube.com/watch?v=bOK_KAXbTe8 (better archive?) at one point most large media organizations (21 of 25) received targeted malware through email. most of that is weaponized-unpatched, not weaponized-0day[s]. Google has implemented both more prominent notifications to warn users directly, and published research on hacking by governments with HackingTeam, Gamma, etc. publicly. it would be interesting for Google to report specifically 0day attack trends, past and current, to determine if they've successfully moved the more advanced attacks to other mediums of communication outside their purview. --- using a different reference, it is difficult to get a sense of how the detection landscape has changed for TAO and JTRIG like groups, as the leaks only indicate that attacks are almost always successful, and presumably that also means undetected. out of 100,000's of implants, only dozens identified and dissected by research groups or anti-virus companies. one trend is clear, which is away from email attachments or click bait toward in-line attacks on downloads, updates, browser software, chat clients, and other attack surfaces. best regards, -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
if Google start actively looking for bugs, aren't they going to have a ranking per vendor every year to incentive bad vendors to improve? What are the other means they can incentive vendors, without making too much of a fuss that users don't loose confidence in web security overall? On Thu, Jul 17, 2014 at 11:07 PM, Richard Brooks r...@g.clemson.edu wrote: On 07/17/2014 05:57 PM, Griffin Boyce wrote: Andy Isaacson wrote: this is exactly why some who have received these payloads are sitting on them, rather than disclosing. Hmmm, that seems pretty antisocial and shortsighted. While the pool of bugs is large, it is finite. Get bugs fixed and get developers to write fewer bugs going forward, and we'll rapidly deplete the pool of 0day and drive up the cost of FOXACID style deployments. Forcing deployments to move to more interesting bugs will also give insight into IAs' exploit sourcing methodologies. Solidarity is really important here. Increased security for those who actively set honeytraps doesn't really scale at all, and most people will never reap the rewards of this work. =/ Forcing the government and defense contractors to burn through 0day at a high rate is far, FAR better than coming across one or two on your own and hiding it. These backdoors need to be revealed if we're to protect ourselves. Let's sunburn these motherfuckers. You are forgetting moral hazard. Why are there so many bugs? The laws relieve software manufacturers of liability for the flaws of their programs. It is cheaper to let clients do the testing for you. If a 3rd party like Google takes over the software testing for free, there is even less incentive to make the slightest effort to test pre-release software and make non-faulty products. You will not exterminate all the bugs, you will give the bug makers (software manufacturers) more incentive to flood the world with faulty products. Which I think is why the open source/free products are more reliable than the commercial ones. The economic incentives are to build crap quickly. If you are not doing the work for profit motives, you can afford to make a decent product. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
On Fri, Jul 18, 2014 at 1:40 AM, Wasa Bee wasabe...@gmail.com wrote: if Google start actively looking for bugs, aren't they going to have a ranking per vendor every year to incentive bad vendors to improve? you'll be able to read the vendor responses yourself in the Project Zero blog. two timelines were stated: - 60 to 90 days for Google discovered issues to be responsibly resolved (then they publish) - 7 days for in-the-wild exploits to be resolved (then they publish) i approve of this timeline, and am anxious to see if NSL's are used to trump some exploits. (how would you know? good question :) What are the other means they can incentive vendors, without making too much of a fuss that users don't loose confidence in web security overall? carrot: we found this bug in your software this way. you should add this type of testing to your continuous build and test infrastructure so we don't have to keep reporting issues like this, and we can all be more productive! stick: when company X in your industry failed to address serious security concerns, the public noticed, and the hit to their bottom line was insert number here -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 17 Jul 2014 12:19:31 -0700 Andy Isaacson a...@hexapodia.org wrote: But don't pretend that patching the specific attack your adversary is currently using will disable or even seriously inconvenience the adversary. Well, going public about it is important still: If the adversary looses one exploit each times he attacks someone, then: * He lost the exploit(which also costs about 10$ to 40$). * He get caught and can be attacked in a court of law. = At the end attacking becomes way more risky, and some adversary do evaluate the risk before attacking, which at the end protects people. Denis. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJTyXPvAAoJENWQk6o21VqZaq8P/2aXxoeDdfIFbqv7+Ols4TyS ty5/jqRbPmtbnnTCVG/Ko758BzMclMlQ0r+Lr2zAwXiq52KyFDDf9vYb4aJ1muZ/ dQY5V/W2f7mYJCEOZwOTRZba7c7gYsZvh/4Nys4CWeeXQT27v8hGOZJrIWW0L8i6 q04fgB20lileRvS56t/rAHT50TcOpx6dQdwdshqWlo2aUjJjDESRs5L7aDt4IsZp /TnljSAhLV2JWNO+Jbngwi3AHv8EudtL7a9JIai9uWjYKsZztx7sj7588LSJI3ZA VJEgpUFYw3dywrrOh+UM0IW5qhGjJWrEmyJskNCDOhbradqMIzyWN1fnc3OTy2vZ fWRPAGbA/rY0Gvphme2e68DRmpGVho/1VxSZu2/8DD+BDgY80Jvw9RJwXQtTwg9n BvODeRc9MSKmv/bWOOw5fzUs7UWrfECEnjznwAmL6Ka867V9vgyiNV3cddpCv3ry +uiGPAdU8u55EcBliUsMtK4jRcuhL3OkjeEPsoeqDOW+JohQz6SztJ20pS6GFTPA Ksm5n3mu46DwENYu3GANZpQYlNgOHFjq9D0sck5uudHjymr2cCuxPUMrQINrhgH0 ZRKshQ/TBj8u32eRWOwPhB087zlPqtEaJS6inAXzkTqJ8qEd7hI8fiIz0cR9pEvC hePyDi962FwGOwuaoUFX =5fko -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
On 07/18/2014 06:12 AM, coderman wrote: [...] i approve of this timeline, and am anxious to see if NSL's are used to trump some exploits. (how would you know? good question :) * U.S. National Security Letters * U.S. National Exploit Stockpile * Effective public bug-quashing program in U.S. Pick two. -Jonathan -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] Foxacid payload
Hello list, We know something about the selectors that could trigger Foxacid attacks, and we can record the data sent to a machine running Tor Browser Bundle. So has anyone set up a sitting duck to trigger and record the payload of the attack? Once the payload is known then Firefox could be patched, no? -Jonathan -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
On Thu, Jul 17, 2014 at 03:14:32PM -0400, Jonathan Wilkes wrote: We know something about the selectors that could trigger Foxacid attacks, and we can record the data sent to a machine running Tor Browser Bundle. So has anyone set up a sitting duck to trigger and record the payload of the attack? Once the payload is known then Firefox could be patched, no? And once you've patched this bug, FOXACID will update to issue another 0day. It's worth doing, for sure! Patching bugs makes us all incrementally safer. But don't pretend that patching the specific attack your adversary is currently using will disable or even seriously inconvenience the adversary. -andy -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
On Thu, Jul 17, 2014 at 12:32:26PM -0700, coderman wrote: And once you've patched this bug, FOXACID will update to issue another 0day. It's worth doing, for sure! Patching bugs makes us all incrementally safer. this is exactly why some who have received these payloads are sitting on them, rather than disclosing. Hmmm, that seems pretty antisocial and shortsighted. While the pool of bugs is large, it is finite. Get bugs fixed and get developers to write fewer bugs going forward, and we'll rapidly deplete the pool of 0day and drive up the cost of FOXACID style deployments. Forcing deployments to move to more interesting bugs will also give insight into IAs' exploit sourcing methodologies. Hasn't someone already created an open FOXACID observatory tracking potential deployments of this and similar APT exploit deployments? it is more useful to mitigate privately, and observe how/when an exploit is used, than burn it publicly for zero effective security improvement. That seems unlikely to be correct even in the medium term. (the less scrupulous would sell to highest bidder for other clandestine hacks) You can always make a quick buck by screwing the public interest. :) -andy -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
On Thu, Jul 17, 2014 at 1:11 PM, coderman coder...@gmail.com wrote: ... Forcing deployments to move to more interesting bugs will also give insight into IAs' exploit sourcing methodologies. this is absolutely true and useful, and does not require making specific exploits public. i have high hopes for Google's Project Zero: http://www.wired.com/2014/07/google-project-zero/ we'll see how the effort plays out! best regards, -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
On Thu, Jul 17, 2014 at 1:11 PM, coderman coder...@gmail.com wrote: ... - if you want to thwart FOXACID type attacks there are ways to do it without knowing specific payloads. (architectural and broad techniques, not fingerprints on binaries or call graphs) some specific examples: A: exploit reuse to arbitrary execution, persist via pivot D: run vulnerable app in Throw away Qubes VM, log traffic for inspection through gateway VM. exploit unable to persist, exploit vector captured. A: android intent misuse to elevate privs, then exfiltrate data. D: root your device to restrict intent use and network communication by application, preventing vulnerable app from being usefully exploitable. A: baseband exploit to device crypto key retrieval used D: apply software defined radio to confirm compromise at baseband level via suspect emissions, use SDR instead of proprietary radios to communicate. (you can't mitigate against a compromised baseband, in most cases.) convenience is the cost of privacy - who said this? very true in this instance. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
On 07/17/2014 04:11 PM, coderman wrote: On Thu, Jul 17, 2014 at 12:41 PM, Andy Isaacson a...@hexapodia.org wrote: ... this is exactly why some who have received these payloads are sitting on them, rather than disclosing. Hmmm, that seems pretty antisocial and shortsighted. While the pool of bugs is large, it is finite. consider, having recv a payload: - who do i trust to evaluate / dissect? This is the reason why I asked on this list and didn't attempt, for example, to try to capture the payload myself. If competent security specialists do the baiting and the evaluating/dissection, it's a non-issue. - would it be better to fix a class of bugs than a specific instance? Well if you mitigate privately, how do you go about luring additional 0days out of FoxAcid's queue? And even then how do you know you've reached the queue, or are sufficiently deep into it that releasing bug reports won't burn potentially valuable information? But if you mean instead that the effort should be focused on redesigning browser security in some way to address a broader class of exploits of which FoxAcid is a part, how does keeping a payload private/unpatched further that goal? - what information would be lost if burned? looking over the JTRIG and TAO catalogs you see how pervasive vulnerabilities are in all our systems. there is a process at work churning out weaponized exploits. That's a great reason to focus more effort on browser security (and security in general), finding sustainable and diverse models of funding for such efforts, etc. But I fail to see how that is relevant fixing a bug related to a specific payload. However, your comments do lead me to believe some private mitigation must be happening as we speak. There must be some valuable information being gleaned by not releasing details about the payloads. It's just difficult to surmise what that would be, given that the attackers know the cat is out of the bag and can probably guess that people are privately inspecting the payloads they are sending out. -Jonathan the only exception might be a heartbleed type bug, where the vulnerability is pervasive and the risk high. (this is also the type of bug least likely to be used capriciously against targets. you would need to be high value to get a high value exploit your direction.) Get bugs fixed and get developers to write fewer bugs going forward, and we'll rapidly deplete the pool of 0day and drive up the cost of FOXACID style deployments. i was young once, too. ;) in all seriousness, we don't know how to build systems resistant to the attacks of collaborating nation states. you can dodge some attacks, some of the time, at best. research continues... Forcing deployments to move to more interesting bugs will also give insight into IAs' exploit sourcing methodologies. this is absolutely true and useful, and does not require making specific exploits public. Hasn't someone already created an open FOXACID observatory tracking potential deployments of this and similar APT exploit deployments? various security companies or research groups drop docs for publicity or other self interest. the work some NGOs are doing to protect human rights workers in foreign lands may touch on it now and then. (burning HackingTeam's tech, for example) it is more useful to mitigate privately, and observe how/when an exploit is used, than burn it publicly for zero effective security improvement. That seems unlikely to be correct even in the medium term. let's have a chat at a conference over strong drinks and plausible deniability... to recap: - if you want to thwart FOXACID type attacks there are ways to do it without knowing specific payloads. (architectural and broad techniques, not fingerprints on binaries or call graphs) - burning specific payloads does nothing to protect against the threat, as they are trivially replaced. (this is a continuous process with envious resources) - all options for disseminating caught exploits involve trust in third parties which you may not give. (sorry, i'm a skeptic by nature and nurture :) - private use for signalling/discovery (see honey tokens, etc.) is useful as a testing / integrity check in some ways, given no other more useful options. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Isaacson wrote: this is exactly why some who have received these payloads are sitting on them, rather than disclosing. Hmmm, that seems pretty antisocial and shortsighted. While the pool of bugs is large, it is finite. Get bugs fixed and get developers to write fewer bugs going forward, and we'll rapidly deplete the pool of 0day and drive up the cost of FOXACID style deployments. Forcing deployments to move to more interesting bugs will also give insight into IAs' exploit sourcing methodologies. Solidarity is really important here. Increased security for those who actively set honeytraps doesn't really scale at all, and most people will never reap the rewards of this work. =/ Forcing the government and defense contractors to burn through 0day at a high rate is far, FAR better than coming across one or two on your own and hiding it. These backdoors need to be revealed if we're to protect ourselves. Let's sunburn these motherfuckers. ~Griffin - -- Wherever truth, love and laughter abide, I am there in spirit. - -Bill Hicks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyEa/AAoJEAPPSgqzx5pjH8cH/RoDfbJUWc8saUF0kN9h4NfX KFv0/4Ayv7f/FqU1rnWNCcvap9Yb+ud61+RkfjCLki+iq9Q+grKLF1HdSN6vRLRK v4dhgbN+X5Inu6DzXirbMIqjAfauQjxBXHX4ZC5MjE3AYa/G9vF34q1o3H9uKiKm n0NYlstSdN/xJprHU1QKD1K5pncLp/+d2KDSn8LTJ1Fk048rwlOjN82xeCQvC9G9 9FFcPMkT9nS/EI2xIWpOcpI430lGGhxfPSmgrQNA9vGkdQxF6AZJqoBrkE0Ov55t sblM8DxblEzRZinv6JF+0ko60mcHXQna83F/OXNCPr1QdubvM2XDwWA4mHeRoIs= =gdo2 -END PGP SIGNATURE- -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] Foxacid payload
On 07/17/2014 05:57 PM, Griffin Boyce wrote: Andy Isaacson wrote: this is exactly why some who have received these payloads are sitting on them, rather than disclosing. Hmmm, that seems pretty antisocial and shortsighted. While the pool of bugs is large, it is finite. Get bugs fixed and get developers to write fewer bugs going forward, and we'll rapidly deplete the pool of 0day and drive up the cost of FOXACID style deployments. Forcing deployments to move to more interesting bugs will also give insight into IAs' exploit sourcing methodologies. Solidarity is really important here. Increased security for those who actively set honeytraps doesn't really scale at all, and most people will never reap the rewards of this work. =/ Forcing the government and defense contractors to burn through 0day at a high rate is far, FAR better than coming across one or two on your own and hiding it. These backdoors need to be revealed if we're to protect ourselves. Let's sunburn these motherfuckers. You are forgetting moral hazard. Why are there so many bugs? The laws relieve software manufacturers of liability for the flaws of their programs. It is cheaper to let clients do the testing for you. If a 3rd party like Google takes over the software testing for free, there is even less incentive to make the slightest effort to test pre-release software and make non-faulty products. You will not exterminate all the bugs, you will give the bug makers (software manufacturers) more incentive to flood the world with faulty products. Which I think is why the open source/free products are more reliable than the commercial ones. The economic incentives are to build crap quickly. If you are not doing the work for profit motives, you can afford to make a decent product. -- Liberationtech is public archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
