Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
US Lawmakers Seek Regulatory Exemptions for Some Mobile Medical Devices/Apps http://www.emergogroup.com/blog/2014/02/us-lawmakers-seek-regulatory-exemptions-some-mobile-medical-devices-and-apps If this description of the planned legislation is accurate, this would create disturbing loopholes that would likely compromise software safety and therefore patient safety.
The Queenstown-Lakes District council manages a public library system with fourteen branches. Last year it made several of the staff redundant. According to page 9 of today (15 Feb 2014)'s issue of the *Otago Daily Times*, '"some files" were accidentally deleted from the Wanaka file server' -- located in another district). Surprise: 'the recovery process "didn't work as expected"'. Fortunately, some of the redundant staff had copies of the lost files at home. (What was that about "redundant"?) The manager claimed that 'the back-up and recovery process had worked well previously and was based on accepted practice.' (:-) She is quoted as saying '"We have put an extra step in place for files created in Wanaka, to include them in the Queenstown system back-up process as an additional safeguard."
http://www.wjla.com/articles/2014/02/umd-cyber-attack-exposes-personal-info-of-students-faculty-staff-100387.html Roz Plater, WJLA.com, 19 Feb 2014 The University of Maryland says it had just recently doubled its number of IT security engineers, analysts, and security tools. But still, hackers somehow managed to carry out a sophisticated attack early Tuesday morning. "It's scary," says student Ricky Bailey. "I just got the email about an hour ago, and I don't think people realize how serious it is just yet." In a letter sent on Wednesday evening, President Wallace Loh said that the database that was breached contained more than 300,000 records of faculty, staff, students, and affiliated personnel from the College Park and Shady Grove campuses since 1998. Those records include name, social security number, date of birth, and university ID number. [...]
Joe Nocera's op-ed column in *The New York Times* today says he thinks “it would be a useful exercise to call some privacy experts and ask them what should be in such a bill''—relating to desired privacy legislation. His top-level amplifies on these topics: * Regulate data brokers. * Give companies an incentive to prevent data breaches. * No more secrets. Nocera concludes, “As much as the companies like Google and Facebook and Acxiom would oppose privacy legislation, they need it—for their sake as well as ours. Sometimes government has to save business from itself.'' Marc Rotenberg (head of the Electronic Privacy Information Center) is quoted: “You should have the right to know what information is being collected about you, who has access to it, how it is being used, and to limit that use. And if companies violate those rights, there should be consequences.'' The title of the column is attributed to Barry Steinhardt (founder of Friends of Privacy USA): “The United States is basically the Wild West of privacy.''
No, I Don't Trust You!—One of the Most Alarming Internet Proposals I've Ever Seen http://lauren.vortex.com/archive/001076.html If you care about Internet security, especially what we call "end-to-end" security free from easy snooping by ISPs, carriers, or other intermediaries, heads up! You'll want to pay attention to this. You'd think that with so many concerns these days about whether the likes of AT&T, Verizon, and other telecom companies can be trusted not to turn our data over to third parties whom we haven't authorized, that a plan to formalize a mechanism for ISP and other "man-in-the-middle" snooping would be laughed off the Net. But apparently the authors of IETF (Internet Engineering Task Force) Internet-Draft "Explicit Trusted Proxy in HTTP/2.0" (14 Feb 2014) haven't gotten the message ( http://j.mp/1fkCtnb [IETF] ). What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping. Of course, they don't phrase it exactly that way. You see, one of the "problems" with SSL/TLS connections (e.g. https:) -- from the standpoint of the dominant carriers anyway—is that the connections are, well, fairly secure from snooping in transit (assuming your implementation is correct ... right?) But some carriers would really like to be able to see that data in the clear -- unencrypted. This would allow them to do fancy caching (essentially, saving copies of data at intermediate points) and introduce other "efficiencies" that they can't do when your data is encrypted from your client to the desired servers (or from servers to client). When data is unencrypted, "proxy servers" are a routine mechanism for caching and passing on such data. But conventional proxy servers won't work with data that has been encrypted end-to-end, say with SSL. So this dandy proposal offers a dandy solution: "Trusted proxies"—or, to be more straightforward in the terminology, "man-in-the-middle attack" proxies. Oh what fun. The technical details get very complicated very quickly, but what it all amounts to is simple enough. The proposal expects Internet users to provide "informed consent" that they "trust" intermediate sites (e.g. Verizon, AT&T, etc.) to decode their encrypted data, process it in some manner for "presumably" innocent purposes, re-encrypt it, then pass the re-encrypted data along to its original destination. Chomping at the bit to sign up for this baby? No? Good for you! Ironically, in the early days of cell phone data, when full capability mobile browsers weren't yet available, it was common practice to "proxy" so-called "secure" connections in this manner. A great deal of effort went into closing this security hole by enabling true end-to-end mobile crypto. Now it appears to be full steam ahead back to even worse bad old days! Of course, the authors of this proposal are not oblivious to the fact that there might be a bit of resistance to this "Trust us" concept. So, for example, the proposal includes the assumption of mechanisms for users to opt-in or opt-out of these "trusted proxy" schemes. But it's easy to be extremely dubious about what this would mean in the real world. Can we really be assured that a carrier going through all the trouble of setting up these proxies would always be willing to serve users who refuse to agree to the proxies being used, and allow those users to completely bypass the proxies? Count me as skeptical. And the assumption that users can even be expected to make truly informed decisions about this seems highly problematic from the git-go. We might be forgiven for suspecting that the carriers are banking on the vast majority of users simply accepting the "Trust us—we're your friendly man-in-the-middle" default, and not even thinking about the reality that their data is being decrypted in transit by third parties. In fact, the fallacies deeply entrenched in this proposal are encapsulated within a paragraph tucked in near the draft's end: "Users should be made aware that, different than end-to-end HTTPS, the achievable security level is now also dependent on the security features/capabilities of the proxy as to what cipher suites it supports, which root CA certificates it trusts, how it checks certificate revocation status, etc. Users should also be made aware that the proxy has visibility to the actual content they exchange with Web servers, including personal and sensitive information." Who are they kidding? It's been a long enough slog just to get to the point where significant numbers of users check for basic SSL status before conducting sensitive transactions. Now they're supposed to become security/certificate experts as well? Insanity. I'm sorry gang, no matter how much lipstick you smear on this particular pig -- it's still a pig. The concept of "trusted proxies" as proposed is inherently untrustworthy, especially in this post-Snowden era. And that's a fact that you really can trust.
[From Dave Farber's IP distribution] https://firstlook.org/theintercept/2014/02/24/jtrig-manipulation/ “Over the last several weeks, I worked with NBC News to publish a series of articles about `dirty trick' tactics used by GCHQ's previously secret unit, JTRIG (Joint Threat Research Intelligence Group). These were based on four classified GCHQ documents presented to the NSA and the other three partners in the English-speaking `Five Eyes' alliance. Today, we at the Intercept are publishing another new JTRIG document, in full, entitled The Art of Deception: Training for Online Covert Operations.'' By publishing these stories one by one, our NBC reporting highlighted some of the key, discrete revelations: the monitoring of YouTube and Blogger, the targeting of Anonymous with the very same DDoS attacks they accuse `hacktivists' of using, the use of `honey traps' (luring people into compromising situations using sex) and destructive viruses. But, here, I want to focus and elaborate on the overarching point revealed by all of these documents: namely, that these agencies are attempting to control, infiltrate, manipulate, and warp online discourse, and in doing so, are compromising the integrity of the Internet itself. Among the core self-identified purposes of JTRIG are two tactics: (1) to inject all sorts of false material onto the Internet in order to destroy the reputation of its targets; and (2) to use social sciences and other techniques to manipulate online discourse and activism to generate outcomes it considers desirable. To see how extremist these programs are, just consider the tactics they boast of using to achieve those ends: `false flag operations' (posting material to the Internet and falsely attributing it to someone else), fake victim blog posts (pretending to be a victim of the individual whose reputation they want to destroy), and posting `negative information' on various forums. "
Nathaniel Popper and Rachel Abrams, *The New York Times*, 25 Feb 2014 http://www.nytimes.com/2014/02/25/business/apparent-theft-at-mt-gox-shakes-bitcoin-world.html?hpw&rref=technology&_r=0 The most prominent Bitcoin exchange appeared to be on the verge of collapse late Monday, raising questions about the future of a volatile marketplace. On Monday night, a number of leading Bitcoin companies jointly announced that Mt. Gox, the largest exchange for most of Bitcoin's existence, was planning to file for bankruptcy after months of technological problems and what appeared to have been a major theft. A document circulating widely in the Bitcoin world said the company had lost 744,000 Bitcoins in a theft that had gone unnoticed for years. That would be about 6 percent of the 12.4 million Bitcoins in circulation. While Mt. Gox did not respond to numerous requests for comments, and the companies issuing the statement scrambled to determine the exact situation at Mt. Gox, which is based in Japan, the news helped push the price of a single Bitcoin below $500 for the first time since November, when it began a spike that took it above $1,200. [...] DealBook: Defending Bitcoin, Andreessen Says Mt. Gox Is Like MF Global 25 Feb 2014. But at the same time that the news about Mt. Gox was emerging, a New York firm announced plans to create an exchange that could draw the world's largest banks into the virtual currency market for the first time [Dave Jevans commented out of band to PGN: Let's see if the speculation matches what they eventually disclose. If they really did lose 744,000 bitcoins, it more than doubles the worldwide total of 2013 bitcoin thefts, and we're only in February!]
FYI—But every computer scientist already knew that GOTO's are considered harmful ! So why does anyone trust "closed source" systems anymore? I smell an NSA rat_H_H_HANT. I checked an older Mac Safari and an iPhone 3S Safari, neither of which had this problem; I did find this problem on a later iPad Safari browser, but not on the iPad Opera browser. This problem seems to be _precisely_ what NSA's "ANT" team was talking about when they said that they had no trouble compromising iPhones. Notice that Apple hasn't promised to fix _all_ their phones & computers still in service, so the net effect to Apple will be increased profits due to more upgrades of old phones & computers. Somehow, Apple shouldn't be allowed to profit from security screwups like this one. http://www.wired.com/threatlevel/2014/02/gotofail/ Behind iPhone's Critical Security Bug, a Single Bad *Goto* Kevin Poulsen, 22 Feb 2014 Like everything else on the iPhone, the critical crypto flaw announced in iOS 7 yesterday turns out to be a study in simplicity and elegant design: a single spurious *goto* in one part of Apple's authentication code that accidentally bypasses the rest of it. Apple released iOS 7.0.6 yesterday to patch the bug in its implementation of SSL encryption --- the Internet's standard defense against eavesdropping and web hijacking. The bug essentially means that when you're e-mailing, tweeting, using Facebook or checking your bank account from a shared network, like a public WiFi or anything tapped by the NSA, an attacker could be listening in, or even maliciously modifying what goes to your iPhone or iPad. But the terse description in Apple's announcement yesterday had some of the Internet's top crypto experts wondering aloud about the exact nature of the bug. Then, as they began learning the details privately, they retreated into what might be described as stunned silence. “Ok, I know what the Apple bug is,'' tweeted Matthew Green, a cryptography professor at Johns Hopkins. “And it is bad. Really bad.'' By this morning, the details had surfaced on Hacker News, and Adam Langley, a web encryption expert at Google, posted a detailed breakdown of the bug based on his reading of Apple's published source code. Some software bugs are infinitely subtle and complicated. Others are comprehensible almost at a glance to anyone who dabbled in BASIC as a kid. The iOS 7 bug is in the latter group. static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; // ????????????????????????????????????? if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; } Did you see it? This function is called when a iPhone connects to an encrypted site over SSL: it's meant to verify that the encryption key is being vouched for --- digitally signed --- by the operator of the website. But notice the two “goto fail'' lines, one after the other. The first one belongs there. The second is a typo. That extra, duplicative line diverts the program's execution, like a bypass stent, right past a critical authentication check. The part where the digital signature is actually checked is dead code, never reached. The issue, Langley confirms, is indeed fixed in the new iOS 7.0.6 (which you should install, if you're using iOS 7.) An update to iOS 6 pushed yesterday fixes the bug there as well. Reportedly, OS X 10.9.1 is still affected by the vulnerability. Using “goto'' statements in any form has long been considered a poor programming practice, though everyone does it anyway. The breathtaking simplicity of what's already being called #gotofail is spawning Snowden Era speculation that the bug was no accident at all. Google's Langley is having none of that. “I believe that it's just a mistake, he writes, “and I feel very bad for whomever might have slipped in an editor and created it.'' You can test if you're vulnerable at GotoFail.com. Kevin Poulsen is the investigations editor at Wired and author of Kingpin: How One Hacker Took Over the Billion-Dollar Cybercrime Underground (Crown, 2011). His PGP fingerprint is A4BB A435 2FE1 B4A8 46E1 7AF6 DA4B 5DFA FF09 4870. SecureDrop: poulsenjzbufll63.onion
http://j.mp/1hITWaQ (*Forbes* via) NNSquad First, Apple revealed a critical bug in its implementation of encryption in iOS, requiring an emergency patch. Then researchers found the same bug is also included in Apple's desktop OSX operating system, a gaping Web security hole that leaves users of Safari at risk of having their traffic hijacked. Now one researcher has found evidence that the bug extends beyond Apple's browser to other applications including Mail, Twitter, Facetime, iMessage and even Apple's software update mechanism. On Sunday, privacy researcher Ashkan Soltani posted a list of OSX applications on Twitter that he says he's determined use Apple's "secure transport" framework, the coding library that developers depend on to build programs that securely communicate online using the common encryption protocols TLS and SSL. The full list, which isn't comprehensive given that Soltani only analyzed the programs on his own PC, is shown below. (Soltani has underlined the vulnerable application names in red.) [...]
FYI—This particular incident should be investigated by Congress to make sure that any "cowboys" in the NSA get lassoed. John Gruber http://daringfireball.net/2014/02/apple_prism On the Timing of iOS's SSL Vulnerability and Apple's *Addition* to the NSA's PRISM Program Jeffrey Grossman, on Twitter, 22 Feb 2014 I have confirmed that the SSL vulnerability was introduced in iOS 6.0. It is not present in 5.1.1 and is in 6.0. iOS 6.0 shipped on 24 September 2012. According to slide 6 in the leaked PowerPoint deck on NSA's PRISM program, Apple was *added* in October 2012. These three facts prove nothing; it's purely circumstantial. But the shoe fits. Sure would be interesting to know who added that spurious line of code to the file. Conspiratorially, one could suppose the NSA planted the bug, through an employee mole, perhaps. Innocuously, the Occam's Razor explanation would be that this was an inadvertent error on the part of an Apple engineer. It looks like the sort of bug that could result from a merge gone bad, duplicating the goto fail; line. Once the bug was in place, the NSA wouldn't even have needed to find the bug by manually reading the source code. All they would need are automated tests using spoofed certificates that they run against each new release of every OS. Apple releases iOS, the NSA's automated spoofed certificate testing finds the vulnerability, and boom, Apple gets `added' to PRISM. (Wasn't even necessarily a fast turnaround—the NSA could have discovered the vulnerability over the summer, while iOS 6 was in developer program beta testing.) Or, maybe nothing, and this is all a coincidence. I see five levels of paranoia: * Nothing. The NSA was not aware of this vulnerability. * The NSA knew about it, but never exploited it. * The NSA knew about it, and exploited it. * NSA itself planted it surreptitiously. * Apple, complicit with the NSA, added it. Me, I'll go as far as #3. #1 In fact, I think that's actually the optimistic scenario—because we know from the PRISM slides that the NSA claims some ability to do what this vulnerability would allow. So if this bug, now closed, #2 is not what the NSA was exploiting, it means there might exist some other vulnerability that remains open. “Never ascribe to malice that which is adequately explained by incompetence.''—Hanlon's Razor? Closed on iOS, that is. As of this writing, it remains open on Mac OS X 10.9.1. I expect it to be closed there soon, though.
"LinkedIn Expands in China With Local Site Limiting Content" http://j.mp/1h8kxLL (*Businessweek* via NNSquad) "LinkedIn Corp. (LNKD:US) is establishing a Chinese-language website that will restrict some content to adhere to state censorship rules, moving to expand in a country where U.S. technology companies have clashed with the government ... The new website puts LinkedIn deeper into a country where social-media peers such as Twitter Inc. and Facebook Inc. are blocked after they balked at government censorship rules. Facebook hasn't built up operations in China beyond hiring contractors to help advertisers reach people outside of the country, spokeswoman Debbie Frost has said. Google ran afoul of Chinese authorities in 2010 for refusing to abide by local censorship requirements, leading to the company shutting its unfiltered search tools there and redirecting users to pages in Hong Kong."
Jeremy Kirk, InfoWorld, 07 Feb 2014 Fazio Mechanical Services, which specializes in refrigeration, said it maintained a 'data connection' with Target http://www.infoworld.com/d/security/target-contractor-says-it-was-victim-of-cyber-attack-235905 A contractor for Target said Thursday it was also a victim of a cyber attack, supporting the retailer's claim that hackers gained entry to its network via a third party. [...]
Please report problems with the web pages to the maintainer