- cypherpunks - lists.cpunks.org

minimum viable toolset for low level malware forensics [was: BadBIOS forensics]
by coderman 20 Jul '14

20 Jul '14

On Wed, Jul 16, 2014 at 4:19 AM, Bluelotus <bluelotus(a)openmailbox.org> wrote: > ... > I wrote threads on my limited ability to perform forensics for those technical, the minimum viable toolset for identifying low level subversive programming is: - a solid base (clean hw, clean installs, clean environment) in a separate location with RF shielding. (a closed metal barn out in the country, for example. if you're a geek you love the thought of a faraday closet ;) - instrumented runtime (e.g. volatility memory forensics, system performance profiling, all to append only storage) on any systems you are using as suspect to attack. - obstructed runtime (see thread on "how to hack your systems before someone else") - this is optional; a modified system that appears to be vulnerable / stock condition will exhibit undefined behavior under attempted enabling, sometimes. otherwise it may be difficult to identify a successful infection. - direct flash memory pinout rig (specs for all chips including flash memory associated with BIOS, integrated management controllers, network devices, I/O ports, keyboard, trac pad or mouse, HD/DVD/CD drives, graphics memory, wifi, 4g, and bluetooth wireless adapters will be needed you're programming an FPGA to perform reads directly from the flash chips. converting flash memory into high level block storage the next black art upward. - wide band high performance software defined radio. you will be building custom GNU radio blocks and running many from third party repositories or research projects. you are using a two stage process, where wide sweeps and auto ranging are applied to sample swaths of signal of interest to storage. then parallel processing on other hardware or later time (off-use-hours) extracting known / useful data and anomalies for further analysis. - in-line network archival, shaping, and cut-out for link to internet / local network. this works best as a zero visibility transparent ethernet bridge with ARP spoofing and ether mangling at each end. that does not speak IP at all. the shaping is used to squelch suspect or unexpected peak traffic (both a signalling system for malicious activity and a means to constrain the reach once compromised) as per the kit above, you are instrumenting a system to observe its runtime behavior on an external audit system. this is because the advanced attacks inject into processes and ring0, persisting only what is needed / chosen (enabling hooks). you need to capture the active payloads that are delivered on-demand in host memory space. you are observing the network and RF space for anomalies and discrepancies. for example, a wifi radio disabled yet still emitting into 2.4Ghz/5.xGhz spectrum. network captures also provide evidence to correlate with malicious memory, for example identifying a payload delivered over the network, with keys from volatility used to decrypt the encrypted communications containing the payload identified in memory. you are (sometimes destructively) sampling all flash memory as parts of advanced payloads persist outside of the OS and storage level interface visibility. (stealth at bus/bios level). discrepancies in blocks that should not have changed, executable code segments where not expected, strange carvings of wear leveling around "protected" offsets. all of these are indicators for further scrutiny and instruction level reversing (if corresponding to microcontroller programming instructions for manipulating streams read or written to and from device, for example :) last but not least, you are not getting attached to any hardware, because at any moment you may find it all suspect and have to replace all laptops, desktops, routers, printers, mobile devices, storage media, media servers, smart televisions, and god forbid you installed one of those intelligent thermostats. [ laugh for sanity, then go back and read the list, and then understand that the far end of the nation state malware asymptote is full of freaky exotics. i also hope you never hit that level of "all systems go" *grin* ] best regards,

1 0

Rainforest Connection and WildLeaks
by grarpamp 20 Jul '14

20 Jul '14

Nice to have Eugen back, wherever did he go? Thanks for posting this applied tech ink.

1 0

first reference to "data diodes" in NSA documents or leaks
by coderman 20 Jul '14

20 Jul '14

i am trying to find the first reference to "data diodes" in any NSA documents or leaks. bonus points for background on where this technical structure originated and why :) best regards,

1 0

Re: Strong Security Processes Require Strong Privacy Protections, Re: [liberationtech] Foxacid payload
by John Young 18 Jul '14

18 Jul '14

On two related threads: It's a challenge to work counter-spying without access to all of Snowden's alleged, note alleged -- nobody knows except Ed how many or where multiply-accumulated and -stashed from 2008-2013 and afterwards -- documents. But parsing the unknown, imagining and acting on possibilities, is the purpose counter-spying as well as spying. Failure expected, narrowing it for modest utility, no lasting triumph. Privacy as elusive as security. It could be, has been, argued that open source coding, like the Internet, is a ploy, or decoy, like comsec standards committees and spy oversight committees, even, some claim, Tor and PKC, AV and Blacknet, so forth and so on paraded here for Internet dog years. Duplicity, buyer beware and who watches the watchers inherent, is that not the wee chihuahua way of survival against greater powers of Fort Huachuca whisperers, GMO vegetables, fracked minerals, DoD-fabricated asteroids and black hos of nightsweat zombies. Whistling in the dark, whistleblowing sunshine, coding out of sight except for sneaky supra-Tempest io-germs gnawing backbone taps into HUMINT dervishing switch doctors.

1 0

Re: [liberationtech] Foxacid payload
by John Young 18 Jul '14

18 Jul '14

Some, maybe all, of those sitting on Snowden docs would/are selling to the highest bidder for other clandestine hacks. The fundamental purpose of security is to do that lulling, gulling and smiling at the ease with which trust can be exploited when a manufactured crisis drives the fearful into gaping maws of protection. The especially private kind, the higher the secrecy the higher the price, is most effective. Fake highest classification markings obligatory. The frenzy to exploit Snowden revelations, tiny as they are, has saved the security industry -- mil-com-spy-edu-org-hackers -- from post-2-war decline. BTW, what are the odds all parties to the Snowden boondoggle are placing on hot war cyberwar to surpass the cool stinking-poo of AV and security vendors planting malware to foster upticks of market? No nonsense Omidyar has bet $200 million on peddling security products generated by his $50 million investment in insecurity scare news via Snowden cornicopia of NSA scare programs, which in turn have received huge boosts of counter-Snowden actions by the usual suspects of mil-com-spy-edu-org-hackers. Nothing like it since 9/11. Thank you, Edward Snowden, thank you media, for prolonging godsent cyber fear and salvation. Dust off cyber Pearl Harbor posters for Defcon, HOPE, Blackhat, this very sordid squat. >this is exactly why some who have received these payloads are sitting >on them, rather than disclosing. > >it is more useful to mitigate privately, and observe how/when an >exploit is used, > than burn it publicly for zero effective security improvement. > >(the less scrupulous would sell to highest bidder for other clandestine hacks) > > >better ideas welcome! > > >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 companys(a)stanford.edu.

2 1

Strong Security Processes Require Strong Privacy Protections
by coderman 18 Jul '14

18 Jul '14

"Strong Security Processes Require Strong Privacy Protections" A request for all security conscious organizations handling vulnerability reports to deploy privacy enhancing technologies. --- With the Snowden disclosures and Google's Project Zero on the minds of security professionals everywhere, it is time to evaluate one more aspect of this renewed focus on 0day and targeted attacks: vulnerability submission to vendors. [0][1] Software vulnerabilities of use to nation states and espionage organizations are recognized as a threat to privacy and basic human rights. Their impact no longer dismissable or discounted given evidence of misuse. I will not discuss hardware vulnerabilities in this treatment as they entail different considerations and constraints. [2] Reporting vulnerabilities of this nature in turn requires strong privacy protections commensurate with the five and six digit monetary values they command, and the adversaries intent on discouraging their discovery or mitigation. [3][4] --- Therefore, any organization handling vulnerability reports must support strong privacy for vulnerability submission. This is mandatory even if most or all issues received via this channel are not 0day, not high value, and entail very little risk to users. The characteristics of a strong private reporting method are: - Email must not be used. In the best circumstances email leaks too much information. In common situations it is passed around clear text, trivially interfered with, and winds through software with huge usability and vulnerability problems. Email for initial security vulnerability reporting must cease immediately. [5][6] - Public web systems for vulnerability reporting must not be used. Like email, this leaks too much information and is vulnerable to a wide array of attacks destroying any privacy intended. [7][8] - Submission of reports via hidden site required. This has become fashionable in media organizations as the "secure drop" for whistleblowers, and it is equally apropriate for vulnerability reporting. This significantly raises the cost of surveilling a vulnerability reporting service, and ensures that passive interception of reported vulnerabilities is impossible. [9] - Encryption of submitted reports required. PGP and GPG are wonderful tools, despite encrypted email being a dismal failure. While the hidden drop may protect the privacy of the reporter, encryption of the report content to specific vulnerability researchers' keys ensures privacy to the receiver. A compromise of the hidden site must not lead to access of reported vulnerabilities. [10] - Submitter anonymity the default. Submissions and communication must accomodate an anonymous identity. If a researcher wishes to claim credit they must opt-in and provide additional information. No psuedonymous account requirements, no key linking across submissions. - Obfuscated disclosure should be available if desired. Capturing 0day in the wild used for espionage or cyber effects is a rare event. Publicly disclosing when, where, and how you obtained such captures ensures you're likely never to see any others. Researchers in position to observe and inspect such events should be able to report the vulnerabilities without credit and without indicating the origin. A vendor could provide a "cover story" for how the vulnerability was discovered internally, to best protect sources' ability to continue to discover these types of weaponized exploits in the wild. Finally, it goes without saying that this privacy applies during reporting and mitigation phases of defect resolution. Once a patch is prepared and public the details of the vulnerability should be public as well, via email list, public blog, or any other useful medium. --- As participants in the security industry it behooves us all to set an example for others and to demonstrate a committment to security and privacy via action. Security conscious organizations handling vulnerability reports can support strong privacy and send a clear message deploying private reporting methods described above. Security researchers must demand strong privacy from organizations they collaborate with, even in the most trivial or minor of circumstances, so that infrequent severe vulnerabilities may also be reported in confidence. Privacy is a basic human right we must all support. Let's demonstrate our support by using privacy enhancing technologies to resolve risks to privacy! best regards, 0. "The NSA Revelations All in One Chart" https://projects.propublica.org/nsa-grid/ 1. "Announcing Project Zero" No link as the announcement is only supported over HTTP; attempt HTTPS and you're redirected to plain-text. This is an embarassment that should be fixed, Google Project Zero! (the other plain-text sites below have not unreasonable exuses ;) 2. "New technologies are radically advancing our freedoms but they are also enabling unparalleled invasions of privacy" https://www.eff.org/issues/privacy 3. "A Declaration of Cyber-War" http://www.vanityfair.com/culture/features/2011/04/stuxnet-201104 '''On July 15, the day Stuxnet’s existence became widely known, the Web sites of two of the world’s top mailing lists for newsletters on industrial-control-systems security fell victim to distributed-denial-of-service attacks...''' 4. "The Real Story of Stuxnet" http://spectrum.ieee.org/telecom/security/the-real-story-of-stuxnet '''Just as Kaspersky’s engineers were tricking Gauss into communicating with their own servers, those very servers suddenly went down,...''' 5. "Universal Email Encryption Specification" http://ritter.vg/blog-uee_email_encryption.html 6. "Pond" (not like email) https://pond.imperialviolet.org/tech.html 7. "Bullrun (decryption program)" https://en.wikipedia.org/wiki/Bullrun_%28decryption_program%29 8. "How secure is HTTPS today? How often is it attacked?" https://www.eff.org/deeplinks/2011/10/how-secure-https-today 9. "How the NSA Attacks Tor/Firefox Users With QUANTUM and FOXACID" https://www.schneier.com/blog/archives/2013/10/how_the_nsa_att.html (this is what a hard to attack system looks like, and keeping disclosure entirely within the network from clients to hidden sites amplifies the difficulty significantly.) 10. "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture" https://www.ietf.org/rfc/rfc3724.txt

1 0

interesting thread on BND intercept at DE-CIX on denog@
by Eugen Leitl 18 Jul '14

18 Jul '14

The netops are not amused. You need to be a list member in order to access the archive. http://lists.denog.de/mailman/private/denog/2014-July/002049.html

1 0

CPunks @ HOPE
by Rich Jones 18 Jul '14

18 Jul '14

Any folks out there going to be in New York this weekend? Say hi to the scruffy guy in the Death Grips shirt! R

6 5

Re: [liberationtech] Foxacid payload
by Jonathan Wilkes 17 Jul '14

17 Jul '14

On 07/17/2014 04:11 PM, coderman wrote: > On Thu, Jul 17, 2014 at 12:41 PM, Andy Isaacson <adi(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 companys(a)stanford.edu.

1 0

Re: [liberationtech] Foxacid payload
by coderman 17 Jul '14

17 Jul '14

On Thu, Jul 17, 2014 at 1:11 PM, coderman <coderman(a)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 companys(a)stanford.edu.

1 0