[liberationtech] no-disclosure / other-disclosure [was: Foxacid payload]
coderman
coderman at gmail.com
Thu Jul 17 17:02:19 PDT 2014
On Thu, Jul 17, 2014 at 2:57 PM, Griffin Boyce <griffin at cryptolab.net> wrote:
> ...
> 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. =/
it doesn't scale at all, actually. and it doesn't provide better security.
to avoid FOXACID** risk, you are not using the Internet like normal people.
(only pond over onions from wifi hotspots using gnuradio stacks on
custom built hardware?)
to catch FOXACID** 0day you are not simply browsing to www.jihad.is,
and you likely wouldn't notice it if it did implant.
** and by this i mean
TAO/QUANTUM*/TURBULENCE/TURMOIL/TUR/DUQU/FLAME/** in general.
> Forcing the
> government and defense contractors to burn through 0day at a high rate
> is far, FAR better
absolutely! this is why i like the Google effort; they are aiming for
the vulnerabilities most useful in these campaigns.
if your intent is to cause them to burn through 0day,
then burn their 0day en mass, entire classes or critical pivots at a time!
:)
> These backdoors need to be revealed if we're to protect
> ourselves.
>
> Let's sunburn these motherfuckers.
the technical detail in the TAO catalog and the JTRIG docs and the
XKeyScore source code among other leaks has been exceptionally helpful
in this regard.
it shows how hardware is compromised during shipping. it shows how
attacks are tailored to the target, out of a wide repertoire of
weaponized options (not to mention the vast trove of exploitable bugs
they've found or fuzzed and not yet weaponized into operational
capability). it shows their ability to be any host anywhere on the
public internet, negating the utility of ACLs and good practice. it
shows their affinity for in the middle attacks, where applications and
operating systems are most vulnerable. it shows their continued,
pervasive efforts to defeat crypto systems, further opening exploit
avenues. it shows their impressive budget for field gear and
up-close-and-personal exploitation direct to your radios sitting on
your bus.
and specifically, it shows how an effort to collect and distribute
captured NSA 0day will do nothing to improve security of those who
need it, but instead let NSA better target and implement their attacks
for stealth.
as thought experiment:
a hidden site is setup by presumed trustworthy experts. exploits are
funneled there, then they all dry up.
- congratulations! NSA is out of 0day! ?
- congratulations! NSA is not using 0day over Internet! ?
- technique for catching 0day has been compromised. start over,...
explain to me how any public effort will not fall into the last trap,
repeatedly.
in summary, and back to the original point:
if your concern is because your threat model is NSA attacker, your
problem is all technology, not specific exploits. a public registry
not changing that risk at all.
if your concern is security for the public, do it by making the
software we use more difficult to exploit as a whole, rather than
fixating on free exploits from NSA for a particular vulnerability
among many.
if your concern is discovering more about the attackers, catching the
free exploits is harder than you think and the time spent being able
to catch, catching them, and noticing when you caught one, is better
spent as tool to peer inside the veil of secrecy regarding tasking
these systems than publicly disclosing and starting all over on your
collection effort.
if your concern is to raise a signal of contempt for this behavior
alone and force a modest rolling of exploits used, then by all means
try and catch some NSA 0day and post it publicly! i would be curious
to see the results, i must admit.
best regards,
More information about the liberationtech
mailing list