[@torproject] shared a link (on identi.ca and Twitter) to an unsettling Wikileaks post…
A California court has issued a subpoena demanding Google reveal the IP addresses of journalists writing for a corruption busting journal from the Caribbean.
The August 28 subpoena, issued by the Superior Court, County of Santa Clara, as part of a “libel tourism” action taken by non-US property developers, demands detailed information about the operators of “tcijournal@gmail.com”. The account is the main email address of the TCI Journal, the most influential journal covering the Turks & Caicos Islands. The Islands are a tourist mecca and tax haven in the Caribbean sea, and until August 14 were an independent British protectorate.
(This story was also covered over at NewsCred and syndicated, via ReadWriteWeb, at USA Today)
For those of you with short-term memories (or minds that block out “the bad things”), this isn’t the first time Google’s been slapped the big SUBP — DoJ anyone? How about Rhino Sports v. Sport Court? Or maybe even the deleted email debacle?
Now would be a good time to remind everyone to use (and support) The Tor Project. Stay safe!
(Hi-LAR-ious Strongbad image CC licensed from thefleeg)
I have a confession to make: I’m not a whiz-bang, controversial, rock star security researcher (go ahead, GASP!). I’ve revealed a few bugs here and there, created some proofs-of-concept, but I’ve never dropped a crazy leet 0-day, had someone sick a legal team on me (yet), or dealt with miles and miles of red tape. I do, however, happen to know many fine folks that have been put through the ringer for disclosure, responsible or otherwise, and it sucks to see/hear/read about.
Lawsuits, gag orders, controversy…just some of the negative things I’ve witnessed my contemporaries and friends undergo after approaching a software vendor about some bug they uncovered. This type of reaction can be very discouraging for a security researcher, possibly resulting in them eschewing communication with the vendor in favor of disclosing it outright or selling the details on the black market.
Now, the “responsible disclosure” debate is one that’s been run dry; reconstituted; run over by a tank; re-assembled; annihilated by a nuclear bomb; and then somehow turned into a zombie mutant that just won’t die; so, with that in mind, I will spare you the usual rigmarole.
I think that it’s important to mention the EFF’s “Coders’ Rights Project Vulnerability Reporting FAQ“, as this is not only a great guide but also serves as somewhat of a basis for my proposal (also, I’ve got a huge crush on the EFF). I’ll give you a moment to go ahead and peruse the aforementioned FAQ. *waits patiently* Okay, let’s move on.
Note the last section in the EFF vuln. reporting FAQ. It summarizes the points that a researcher should consider when embarking on the potentially perilous journey that is vulnerability disclosure. I’d venture to guess that I’m not alone in saying that these points are essential, but it would be naive to think that following them to a ‘T’ will result in a happy, grateful vendor. While vendors and researchers alike have made great strides in strengthening their relationships, many (on both sides) remain opposed to any semblance of responsible disclosure (for various reasons).
After all that, on to my point: I would like to propose the creation of a site that lets security researchers share their experience(s) when going through the vulnerability disclosure process with particular vendors. This would allow other researchers to get a sense of how certain vendors might react, the timelines they might deal with, and other points involved in the disclosure process. While this type of discussion already happens on mailing lists and disparate forums, I know of no central location for this info.
Of course, this isn’t without its challenges. Just to cite a few:
1. Authenticity of a researcher’s claim about their experience. How do we verify that a researcher’s interaction with a given vendor is legitimate?
2. Utility and attractiveness (not aesthetically speaking) of the site. How do we get people to want to use this without having it become just another outlet for frustrated researchers? They should want others to benefit from their experiences, and hopefully avoid the same pitfalls or tribulations.
3. The “(Security) Assassination Market.” How do we minimize any negative influence this site may have (e.g. researchers going after soft targets because of good/bad experiences)?
I’m going to cut it right there and see who bites and who bitches (plus, I’m tired). 
UPDATE (2009-07-17 08:50): After a few responses from people (off the blog), I realized I failed to list the challenge of protecting the identity of whomever posts a story to the site. Naturally, this is something that would need to be balanced against the authenticity piece.
(CC licensed image from twenty_questions)
Ah, open standards. They’re fabulous, aren’t they? Take OAuth for instance. Idealism and interoperability! What’s the gist behind OAuth? Well…
Imagine you’ve got a service that allows you to, say, microblog your life. Then you’ve got another service that allows you to post and share photos on the Internet. You want to make these two services work together — when you upload a new image, the photo sharing service should update the microblogging service to notify your friends about it. Now, maybe the photo sharing service wants your microblog credentials, but you don’t want to give them up. Ah, but it turns out both services support OAuth! So, you tell the photo sharing service about your microblogging service, the microblogging service asks you if you want to grant the photo sharing service access, they exchange some information, and voila: the photo sharing service can notify your friends about your uploads without ever knowing your password!
This concept is so simple, so effective that it makes sense for it to eventually catch on. Sure, OAuth popped up here and there, but what seems to have pushed it into the mainstream was its adoption by Twitter. As a public beta, Twitter recently started supporting OAuth in their service, a well received move. But on the morning of April 22, Twitter unexpectedly pulled the plug on the protocol, as noted by TechCrunch; a comment on the TechCrunch story noted that Yahoo’s OAuth support had been yanked, too. One TechCrunch reader noted that it “sounds like there’s some massive security hole they’re busily patching up.”
It wasn’t but a few hours later when CNET broke the news that the real issue was, indeed, security-related:
A security hole in OAuth, the open-source protocol that acts as a “valet key” for users’ login information, has led services like Twitter and Yahoo to temporarily pull their support, CNET News has learned…. In the interest of online safety, CNET News has chosen not to make the details of the security hole public. Here are the basics: The hole makes it possible for a hacker to use social engineering tactics to trick users into exposing their data.
Twitter even issued an official stance on the whole debacle over at their blog:
This week, we received word from the folks at OAuth that they were looking closely at a security issue within the protocol. We take security seriously and felt the responsible thing to do was temporarily disable OAuth while this matter was sorted out. Yahoo and others made similar decisions.
“Yes, yes, that’s all well and good, you waffle-faced bastard, but what’s the issue?!” Well, it all comes down to a token, of course. Per the OAuth advisory*, released on Thursday, April 23 at 03:00 AM EDT (12:00 AM PDT), there exists a nasty, but obvious-in-the-way-the-spec-is-written-good-deity-how-did-this-get-overlooked, session fixation vulnerability:
The attack starts with the attacker logging into an account he owns at the (honest) Consumer site. The attacker initiates the OAuth authorization process but rather than follow the redirect from the Consumer to obtain authorization, the attacker instead saves the authorization request URI (which includes the Request Token). Later, the attacker convinces a victim to click on a link consisting of the authorization request URI to approve access to the victim’s Protected Resources to the (honest) Consumer.
By clicking on the link, the victim continues the request that the attacker initiated, including the Request Token that the (honest) Consumer issued to the attacker. Note that the victim is redirected to the legitimate approval page at the Service Provider and prompted by the Service Provider to approve the (honest) Consumer. It is not possible for the victim to detect that there is an ongoing attack.
After the victim grants approval, the attacker can use the saved Request Token to complete the authorization flow, and access whatever Protected Resources are exposed by the (honest) Consumer site as part of its service.
XSRF protections at the Consumer site do not mitigate against this attack.
(Update 2009-04-23 06:33) — The OAuth advisory also points to a more detailed analysis of the attack over at Hueniverse. I recommend reading this as well.
As someone who advocates open standards such as OAuth and OpenID, which are oftentimes used as complements to one another, it pains me to see such a nasty flaw rear its head — especially right after it seemed to be getting some traction. A revised OAuth specification is forthcoming that should address this issue.
* – please note that we honoured the timeframe set forth by OAuth by publishing this post only when the officialy advisory had been released. (And no, we did not discover this flaw. We merely had, uh, accurate discussion and speculation around it.)
As someone who once purchased a used Newton MessagePad 130 loaded with military command software (I’m not kidding), I couldn’t help but find this story simultaneously interesting and amusing.
Newsweek is reporting that the U.S. military is considering (and, if the article is correct in its suggestion, issuing) iPod Touches to soldiers, to provide such facilities as language translation and intelligence sharing. And it makes sense, really:
The future of “networked warfare” requires each soldier to be linked electronically to other troops as well as to weapons systems and intelligence sources. Making sense of the reams of data from satellites, drones and ground sensors cries out for a handheld device that is both versatile and easy to use.
(Gizmodo reported a similar story back in December 2008, discussing translation software.)
Yes, the iPhone and iPod Touch both bear a fantastic, intuitive interface, and can be made to do so much thanks to the App Store (not to mention jailbreaking, which opens up a world of near endless possibilities for the devices). Heck, the devices have even shown that they can pass muster with military’s tough requirements:
Typically sheathed in protective casing, iPods have proved rugged enough for military life. And according to an Army official in Baghdad, the devices have yet to be successfully hacked.
Come again. “Yet to be successfully hacked”? Maybe they missed 2007’s Mobile Safari TIFF exploit, or more recently, the (possible) iPhone shellcode execution vuln discovered by Charlie Miller. Additionally, the same jailbreaking that provides access to additional software and functionality often comes with the ability to install services, such as OpenSSH. Combining that with the well known password for the “mobile” and “root” users on the iPhone/iPod Touch (it’s “alpine”, btw), and soldiers’ intelligence-sharing, word-translating, Tap-Tap-Revolution-playing, network-accessible, probably-associated-to-an-attacker-controlled-WiFi-network are ripe targets.
(Update: 2009041000) Craig Ingram (@cji) notes something that I, in all of my wizdumb, didn’t discuss — there’s no mention of remote wipe being configured for these devices. Save for using Microsoft Exchange with the iPhone/iPod Touch, I don’t know of a built-in facility for remote wipe.
Read the Newsweek article for more of their story — you know, beyond the “yet to be hacked” stuff.
The BBC is reporting that a Sheffield Hallam University journalism student made a rather juicy purchase from a homeless man: a BlackBerry containing “the personal details of cabinet ministers, top civil servants and police officers:”
Journalism student Darryl Curtis said it held hundreds of phone numbers, with data which led him to think it belonged to an ex-Sheffield council chief.
Details of cabinet ministers including Ed Balls and David Miliband were on the BlackBerry, said Mr Curtis, 44.
Police believe it was stolen from a car and that they have traced the owner.
Curtis purchased the device after the homeless man informed him that the device held “the numbers for Tony Blair and Buckingham Palace.” However, the fun doesn’t stop at just phone numbers, folks…
Mr Blair’s number was not stored on the device. However, Mr Curtis said he found the National Insurance number, home address and computer passwords of a former chief executive of Sheffield City Council.
Score! I wonder where else those passwords are used. Anyway, STOP LEAVING YOUR MOBILE DEVICE IN YOUR CAR. That is all.
(CC licensed image from Marvin Kuo)
Circling the ‘tubez right now is an FTC complaint filed by the Electronic Privacy Information Center (EPIC) regarding the privacy and security risks surrounding Google services. (This comes hot on the heels of the Google Docs SNAFU.) The complaint covers all the basics: the fast adoption of Cloud Computing; the fundamental right to privacy; identity theft; and the whimsy with which consumers throw (potentially) sensitive data into the *gulp* “Cloud”. The most significant eyebrow raiser of the document, however, is Section 57:
57. Enjoin Google from offering Cloud Computing Services until safeguards are verifiably established.
Say WHAAAAT? Pause the juggernaut? Surely you jest! Oh, and surely they’ll cough up the dough for the Privacy Pizza, as cited in Section 58:
58. Compel Google to contribute $5,000,000 to a public fund that will help support research concerning privacy enhancing technologies, including encryption, effective data anonymization, and mobile location privacy.
(Although, Section 58 does sound a bit secksy, and I’m all for furthering this type of research.)
Earlier today, I posted my opinion on this whole kerfuffle to the PaulDotCom mailing list:
It’s almost as though EPIC need to remind everyone that they still exist
and haven’t become entirely decrepit and overshadowed by the EFF. The
document is well assembled, citing examples that most users *don’t*
consider when using Google services (or just about any *aaS, for that
matter). Incidentally, the complaint references a recently published
report from the World Privacy Forum on privacy risks in Cloud
Computing[1]. Both documents raise a few similar points.For example, how many of us actually read, end-to-end, the TOS and
privacy policy of the Provider? How many of us validate claims like
“your data are safe from unauthorized access when you store it on our
Cumulonimbus Mega Awesome Cloud Storage Platform”?I, for one, laud EPIC’s past efforts and the heart whence this complaint
emerges. However, like a few others, the request for enjoinment
basically negated my support for the complaint in its entirety.[1] http://www.worldprivacyforum.org/pdf/WPF_Cloud_Privacy_Report.pdf
The questionability of Google’s approach to (user) security and privacy is nothing new, but it doesn’t warrant a suspension of service altogether. Educating users about the inherent risks of placing anything outside of your own, little trust-boundary-bubble is paramount. We can start by teaching our own “EPIC” phrase: “When it comes to outsourced providers, Expecting Privacy Is Comical.”
Flame on.
(CC licensed image from Erica Marshall)
