Follow by Email

Thursday, December 18, 2014

Unfolding The Hidden Tor Users

Kevin Poulson has a good article up on Wired about how the FBI used a Metasploit variant to identity Tor users.

Words About Sony Hack

I don't have a lot to say about the Sony hack, which seems to still be ongoing. I want to highlight a few points, though.
  1. At this point, the attacks seem to be a few hackers and not the North Korean government. (My guess is that it's not an insider, either.) That we live in the world where we aren't sure if any given cyberattack is the work of a foreign government or a couple of guys should be scary to us all.
  2. Sony is a company that hackers have loved to hate for years now. (Remember their rootkit from 2005?) We've learned previously that putting yourself in this position can be disastrous. (Remember HBGary.) We're learning that again.
  3. I don't see how Sony launching a DDoS attack against the attackers is going to help at all.
  4. The most sensitive information that's being leaked as a result of this attack isn't the unreleased movies, the executive emails, or the celebrity gossip. It's the minutiae from random employees:
    The most painful stuff in the Sony cache is a doctor shopping for Ritalin. It's an email about trying to get pregnant. It's shit-talking coworkers behind their backs, and people's credit card log-ins. It's literally thousands of Social Security numbers laid bare. It's even the harmless, mundane, trivial stuff that makes up any day's email load that suddenly feels ugly and raw out in the open, a digital Babadook brought to life by a scorched earth cyberattack.
    These people didn't have anything to hide. They aren't public figures. Their details aren't going to be news anywhere in the world. But their privacy has been violated, and there are literally thousands of personal tragedies unfolding right now as these people deal with their friends and relatives who have searched and read this stuff.
    These are people who did nothing wrong. They didn't click on phishing links, or use dumb passwords (or even if they did, they didn't cause this). They just showed up. They sent the same banal workplace emails you send every day, some personal, some not, some thoughtful, some dumb. Even if they didn't have the expectation of full privacy, at most they may have assumed that an IT creeper might flip through their inbox, or that it was being crunched in an NSA server somewhere. For better or worse, we've become inured to small, anonymous violations. What happened to Sony Pictures employees, though, is public. And it is total.
    Gizmodo got this 100% correct. And this is why privacy is so important for everyone.
I'm sure there'll be more information as this continues to unfold.

Limited Number Of CISO & Hard to Find

This article is reporting that the demand for Chief Information Security Officers far exceeds supply:
Sony and every other company that realizes the need for a strong, senior-level security officer are scrambling to find talent, said Kris Lovejoy, general manager of IBM's security service and former IBM chief security officer.
CISOs are "almost impossible to find these days," she said. "It's a bit like musical chairs; there's a finite number of CISOs and they tend to go from job to job in similar industries."
I'm not surprised, really. This is a tough job: never enough budget, and you're the one blamed when the inevitable attacks occur. And it's a tough skill set: enough technical ability to understand cybersecurity, and sufficient management skill to navigate senior management. I would never want a job like that in a million years.
Here's a tip: if you want to make your CISO happy, here's her holiday wish list.
"My first wish is for companies to thoroughly test software releases before release to customers...."
Can we get that gift wrapped?

Wednesday, December 10, 2014

Version 2.0 of Heart Bleed The Poodlebleed Bug

Poodlebleed is a vulnerability in the design of SSL version 3.0. Poodle is actually an acronym for Padding Oracle On Downgraded Legacy Encryption. The vulnerability allows the decryption to plaintext of secure connections. The bug was discovered by Google Security Team researcher Bodo Möller in collaboration with Thai Duong and Krzysztof Kotowicz.

This bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. 

Although SSL 3.0 is almost 15 years old, many servers and web browsers still use it today. When web browsers fail at connecting on a newer SSL version (i.e. TLS 1.0, 1.1, or 1.2), they may fall back to a SSL 3.0 connection. This is where the trouble begins.
Because a network attacker can cause connection failures, including the failure of TLS 1.0/1.1/1.2 connections, they can force the use of SSL 3.0 and then exploit the poodle bug in order to decrypt secure content transmitted between a server and a browser. For nitty-gritty details on what exactly the poodlebleed bug is, please see the pdf announcement under resources.

Clients and Browsers

For the best client-end browser security, it is recommended to completely disable SSL 3.0. Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, however, this presents significant compatibility problems for servers running old encryption protocols. Therefore the recommended response is to support TLS_FALLBACK_SCSV. Most major browsers will support TLS_FALLBACK_SCSV in the coming months. Until then, you can protect yourself by disabling SSL 3.0 support in your browser.
In firefox, this can be done by going to about:config and setting security.tls.version.min to 1

This browser test by Qualys, Inc. can provide further details on the TLS and SSL methods supported by your browser. If your browser currently supports SSL 3.0 or SSL 2.0 and does not support TLS_FALLBACK_SCSV, you are vulnerable to the poodle bug and need to upgrade to Google Chrome or disable SSL 2/3 support. Currently, only Google Chrome version 33.0.1750 (February 2014 Build) and newer supports TLS_FALLBACK_SCSV, all other browsers are safest disabling SSL 3.0.

Servers

The below form can be used to test if your server is running with SSL 3.0 enabled. Although disabling SSL 3.0 may cause failed connections to your ssl service for small portion of users running older browsers, this action prevents the large portion of modern browsers from being eavesdropped while attempting to access your services in a secure manner. Here is a great resource on disabling SSL 3.0 on your server running apache or nginx.

It is important to note that this is NOT a flaw in SSL certificates, their private keys, or their design but in the old SSLv3 protocol.  SSL Certificates are not affected and customers with certificates on servers supporting SSL 3.0 do not need to replace them.
It’s believed to not be as serious as the Heartbleed bug in OpenSSL, since the attacker needs to have a privileged position in the network to exploit the latest.  The usage of Hotspots, public Wi-Fi, makes this attack a real problem. This type of attack falls into the “Man-in-the-middle” category.
Background
brook-4.png
While SSL 3.0 was introduced in 1996, it is currently supported by nearly 95% of Web browsers according to Netcraft’s latest report.  Many Transport Layer Socket (TLS) clients downgrade their cryptography protocol to SSL 3.0 when working with legacy servers. According to Google, an attacker that controls the network between the computer and server could interfere with the handshake process used to verify which cryptography protocol the server can accept using a “protocol downgrade dance”. This will force computers to use the older SSL 3.0 protocol to protect data that is being sent. Attackers can then exploit the bug by carrying out a man-in-the-middle (MITM) attack to decrypt secure HTTP cookies, which could let them steal information or take control of the victim’s online accounts.  Although, at the time to writing, webmasters have been disabling moving to TLSv1 and above and a rapid pace, there still remains a lot of work to be done.  If Heartbleed taught us anything, it’s that the largest companies act fast while many small companies drag their heels in patching critical vulnerabilities.
What Businesses Need to Do
In order to mitigate the bug there are a few courses of action:
  1. Check to see if your webservers are vulnerable using our free SSL Toolbox.
  2. Use tools that support TLS_FALLBACK_SCSV, a mechanism that prevents attackers from forcing Web browsers to use SSL 3.0.
  3. Disable SSL 3.0 altogether, or disable SSL 3.0 CBC-mode ciphers
  4. A cloud-based Web Application Firewall can help protect against this kind of vulnerability.  For more information please visit the website.
  5. Be leery of any spam messages from scammers trying to capitalize on uncertainty and a lack of technical knowledge.
 Christoffer Olausson gives a few tips on how to fix this on Apache:
> SSLProtocol All -SSLv2 -SSLv3                   <- Removes SSLv2 and SSLv3
> apachectl configtest                                   <- Test your configuration
> sudo service apache restart                      <- Restart server
Google added that it will remove SSL 3.0 support from all of its products in the next few months. Mozilla also said it would disable SSL 3.0 in FireFox 34, which will be released at the end of November.


Monday, December 8, 2014

Eavesdrop on Any Conversation?

Interesting essay on the future of speech recognition, microphone miniaturization, and the future ubiquity of auditory surveillance.

Why do HTTPS Encryption Fails

Interesting paper: "Security Collapse of the HTTPS Market." From the conclusion:
Recent breaches at CAs have exposed several systemic vulnerabilities and market failures inherent in the current HTTPS authentication model: the security of the entire ecosystem suffers if any of the hundreds of CAs is compromised (weakest link); browsers are unable to revoke trust in major CAs ("too big to fail"); CAs manage to conceal security incidents (information asymmetry); and ultimately customers and end users bear the liability and damages of security incidents (negative externalities).
Understanding the market and value chain for HTTPS is essential to address these systemic vulnerabilities. The market is highly concentrated, with very large price differences among suppliers and limited price competition. Paradoxically, the current vulnerabilities benefit rather than hurt the dominant CAs, because among others, they are too big to fail.

Uber Tracks Users Our Data Is Our Rights

In the Internet age, we have no choice but to entrust our data with private companies: e-mail providers, service providers, retailers, and so on.
We realize that this data is at risk from hackers. But there's another risk as well: the employees of the companies who are holding our data for us.
In the early years of Facebook, employees had a master password that enabled them to view anything they wanted in any account. NSA employees occasionally snoop on their friends and partners. The agency even has a name for it: LOVEINT. And well before the Internet, people with access to police or medical records occasionally used that power to look up either famous people or people they knew.
The latest company accused of allowing this sort of thing is Uber, the Internet car-ride service. The company is under investigation for spying on riders without their permission. Called the "god view," some Uber employees are able to see who is using the service and where they're going -- and used this at least once in 2011 as a party trick to show off the service. A senior executive also suggested the company should hire people to dig up dirt on their critics, making their database of people's rides even more "useful."
None of us wants to be stalked -- whether it's from looking at our location data, our medical data, our emails and texts, or anything else -- by friends or strangers who have access due to their jobs. Unfortunately, there are few rules protecting us.
Government employees are prohibited from looking at our data, although none of the NSA LOVEINT creeps were ever prosecuted. The HIPAA law protects the privacy of our medical records, but we have nothing to protect most of our other information.
Your Facebook and Uber data are only protected by company culture. There's nothing in their license agreements that you clicked "agree" to but didn't read that prevents those companies from violating your privacy.
This needs to change. Corporate databases containing our data should be secured from everyone who doesn't need access for their work. Voyeurs who peek at our data without a legitimate reason should be punished.
There are audit technologies that can detect this sort of thing, and they should be required. As long as we have to give our data to companies and government agencies, we need assurances that our privacy will be protected.