General

general@lists.hackerspace.pl

1063 discussions

Fwd: Strong Security Processes Require Strong Privacy Protections
by rysiek 18 Jul '14

18 Jul '14

---------- Treść przekazywanej wiadomości ---------- Temat: Strong Security Processes Require Strong Privacy Protections Data: piątek, 18 lipca 2014, 06:16:09 Od: coderman Do: Full Disclosure <fulldisclosure(a)seclists.org>, liberationtech <liberationtech(a)mailman.stanford.edu>, cpunks <cypherpunks(a)cpunks.org>, oss- security(a)lists.openwall.com "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 ----------------------------------------- -- Pozdr rysiek

1 0

Zbiórki publiczne
by Maria Skrzypek 18 Jul '14

18 Jul '14

Tak jakby ktoś się jeszcze zastanawiał co to za dziwo: http://wiadomosci.ngo.pl/wiadomosci/996625.html :)

4 3

Fwd: the NSA revelations all in one chart
by rysiek 17 Jul '14

17 Jul '14

---------- Treść przekazywanej wiadomości ---------- Temat: the NSA revelations all in one chart Data: czwartek, 17 lipca 2014, 15:09:14 Od: Eugen Leitl <eugen(a)leitl.org> Do: cypherpunks(a)cpunks.org http://projects.propublica.org/nsa-grid/ The NSA Revelations All in One Chart This is a plot of the NSA programs revealed in the past year according to whether they are bulk or targeted, and whether the targets of surveillance are foreign or domestic. Most of the programs fall squarely into the agency’s stated mission of foreign surveillance, but some – particularly those that are both domestic and broad-sweeping – are more controversial. Just as with the New York Magazine approval matrix that served as our inspiration, the placement of each program is based on judgments and is approximate. For more details, read our FAQ or listen to our podcast. Also, take our quiz to test your NSA knowledge. ----------------------------------------- -- Pozdr rysiek

2 1

Fwd: BadBIOS forensics
by rysiek 16 Jul '14

16 Jul '14

---------- Treść przekazywanej wiadomości ---------- Temat: BadBIOS forensics Data: środa, 16 lipca 2014, 07:19:47 Od: Bluelotus <bluelotus(a)openmailbox.org> Do: cypherpunks(a)cpunks.org I am donating BadBIOS infected laptops, flashdrives, tampered live fedora CD, infected personal files (plain text files, MP3, PDF, jpg, tiff, doc), infected external DVD writer, etc. to any one interested in conducting forensics. I wrote threads on my limited ability to perform forensics in /r/badBIOS subreddit of reddit.com. My other threads are in other subreddits. Look at my submit history. My laptops were indicted, infected and implanted. ----------------------------------------- -- Pozdr rysiek

1 0

Orkiestra górniczo-monetarystyczna [bitcoin]
by Marcin 15 Jul '14

15 Jul '14

Pozdrawiam wszystkich Kopaczy! https://www.youtube.com/watch?v=XEthXBHsEac MZ

1 0

Consciousness on-off switch
by rysiek 10 Jul '14

10 Jul '14

OHAI, "When the team zapped the area with high frequency electrical impulses, the woman lost consciousness. She stopped reading and stared blankly into space, she didn't respond to auditory or visual commands and her breathing slowed. As soon as the stimulation stopped, she immediately regained consciousness with no memory of the event. The same thing happened every time the area was stimulated during two days of experiments (Epilepsy and Behavior, doi.org/tgn)." -- http://www.newscientist.com/article/mg22329762.700 Aleksander? :) -- Pozdr rysiek

1 0

No Silver Bullet - De-identification still doesn't work
by TeMPOraL 09 Jul '14

09 Jul '14

http://randomwalker.info/publications/no-silver-bullet-de-identification.pdf Taki paper będący odpowiedzią na jakiś inny, który rzuca troszkę światła na problem anonimizacji danych. (moim zdaniem pokładanie jakiejkolwiek nadziei w anonimizacji czegokolwiek jest bardzo nierozsądne) Jacek Złydach, http://temporal.pr0.pl/devblog | http://esejepg.pl | http://hackerspace-krk.pl TRC - Bringing you tomorrow's solutions yesterday.

1 0

Free State Project
by rysiek 09 Jul '14

09 Jul '14

Hej, dobry polityczno-społeczny hack jest dobry. :) Projekt przeprowadzenia się 20000 osób do New Hampshire w celu uzyskania realnego wpływu na politykę stanu, w tym tematy związane z prywatnością, i stworzenie "wolnego stanu": http://freestateproject.org/ -- Pozdr rysiek

11 10

Fwd: messing with XKeyScore
by rysiek 06 Jul '14

06 Jul '14

Trololo. ---------- Treść przekazywanej wiadomości ---------- Temat: messing with XKeyScore Data: piątek, 4 lipca 2014, 16:56:41 Od: Eugen Leitl Do: cypherpunks(a)cpunks.org http://blog.erratasec.com/2014/07/jamming-xkeyscore_4.html?m=1 Errata Security Advanced persistent cybersecurity Friday, July 04, 2014 Jamming XKeyScore Back in the day there was talk about "jamming echelon" by adding keywords to email that the echelon system was supposedly looking for. We can do the same thing for XKeyScore: jam the system with more information than it can handle. (I enumerate the bugs I find in the code as "xks-00xx"). For example, when sending emails, just send from the address "bridges(a)torproject.org" and in the email body include: https://bridges.torproject.org/ bridge = 0.0.0.1:443 bridge = 0.0.0.2:443 bridge = 0.0.0.3:443 ... Continue this for megabytes worth of bridges (xks-0001), and it'll totally mess up XKeyScore. It has no defense against getting flooded with information like this, as far as I can see. Note that the regex only cares about 1 to 3 digit numbers, that means the following will be accepted by the system (xks-0002): bridge = 75.748.86.91:80 The port number matches on 2 to 4 digits ([0-9]{2,4}). Therefore, bridges with port numbers below 10 and above 9999 will be safe. I don't know if this code reflect a limitation in Tor, or but assuming high/low ports are possible, this can be used to evade detection (xks-0011). Strangely, when the port number is parsed, it'll capture the first non-digit character after the port number (xks-0012). This is normally whitespace, but we could generate an email with 256 entries, trying every possible character. A character like < or ' might cause various problems in rendering on an HTML page or generating SQL queries. You can also jam the system with too many Onion addresses (xks-0003), but there are additional ways to screw with those. When looking for Onion addresses, the code uses a regex that contains the following capture clause: ([a-z]+):\/\/) This is looking for a string like "http://" or "https://", but the regex has no upper bounds (xks-0004) and there is no validation. Thus, you can include "goscrewyourself://o987asgia7gsdfoi.onion:443/" in network traffic, and it'll happily insert this into the database. But remember that "no upper bounds" means just that: the prefix can be kilobytes long, megabytes long, or even gigabytes long. You can open a TCP connection to a system you feel the NSA is monitoring, send 5 gigabytes of lower-case letters, followed by the rest of the Onion address, and see what happens. I mean, there is some practical upper bound somewhere in the system,, and when you hit it, there's a good chance bad things will happen. Likewise, the port number for Onion address is captured by the regex (d+), meaning any number of digits (xks-0005). Thus, we could get numbers that overflow 16-bits, 32-bits, 64-bits, or 982745987-bits. Very long strings of digits (megabytes) at this point might cause bad things to happen within the system. There is an extra-special thing that happens when the schema part of the Onion address is exactly 16-bytes long (xks-0006). This will cause the address and the scheme to reverse themselves when inserted into the database. Thus, we can insert digits into the scheme field. This might foul up later code that assumes schemes only contain letters, because only letters match in the regex. In some protocol fields, the regexes appear to be partial matches. The system appears to match on HTTP servers with "mixminion" anywhere in the name. Thus, we start causing lots of traffic to go to our domains, such as "mixminion.robertgraham.com", that will cause their servers to fill up with long term storage of sessions they don't care about (xks-0007) Let's talk X.509, and the following code: fingerprint('anonymizer/tor/bridge/tls') = ssl_x509_subject('bridges.torproject.org') or ssl_dns_name('bridges.torproject.org'); Code that parses X.509 certificates is known to be flaky as all get out. The simplest thing to do is find a data center you feel the NSA can monitor, and then setup a hostile server that can do generic fuzzing of X.509 certificates, trying to crash them. It's likely that whatever code is parsing X.509 certificates is not validating them. Thus, anybody can put certificates on their servers claiming to be 'bridges.torproject.org' (xks-0008). It's likely that the NSA is parsing SSL on all ports, so just pick a random port on your server not being used for anything else, create a self-signed CERT claiming to be "bridges.torproject.org', then create incoming links to that port from other places so at least search-engines will follow that link and generate traffic. This will cause the NSA database of bridges to fill up with bad information -- assuming it's not already full from people screwing with the emails as noted above :). <img src="http://www.google.com/?q=tails+usb" /> Putting the above code in a web page like this one will cause every visitor to trigger a search for TAILS in the XKeyScore rules. The more people who do this, the less useful it becomes to the NSA (xks-0009) in labeling people as suspicious. Likewise, putting <title>tails.boum.org/<.title> in your webpages will cause the same effect, even when CSS/JavaScript makes such a title invisible. In theory, the NSA should only be monitoring foreign traffic, and not traffic originating from the United States (or, apparently, the other five-eyes). So here is the fun thing (xks-0010): run your jamming tools from United States IP addresses against those servers in Iran you know the NSA is monitoring. Since the code should already be ignoring the traffic because it originates from the United States, then they can't complain if you've filled up their databases full of Tor Onion and bridge addresses. Robert Graham ----------------------------------------- -- Pozdr rysiek

5 11

Microsoft rozdaje Intel Galileo
by Kuba Niewiarowski 04 Jul '14

04 Jul '14

Chyba jeszcze nie było, więc podrzucam - może ktoś się załapie: http://www.windowsondevices.com/ -- Pozdrawiam, Kuba Niewiarowski.IT

16 35

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

General