Application Security
11/15/2013
08:00 AM
Connect Directly
RSS
E-Mail
50%
50%

LinkedIn Lesson: Detail Security First, Feature Fest Second

Memo to businesses with an information security trust deficit: Prove how you're going to keep our data secure.

Memo to any business that wants to handle people's private information: Tell us how you're going to keep our data safe. And, especially if you've mishandled information security practices in the past, provide copious details of your new security approach, so we can decide whether to trust you.

Or you can take an alternate approach, recently practiced by LinkedIn: Talk about how great your new product is, while appearing to gloss over your business's recent security and privacy shortcomings. That was the PR mess the social networking site recently created for itself, after launching its new Intro service via a blog post that extolled the iOS app's feature set, while providing vague assurances about practicing responsible information security.

To be clear: Intro isn't evil. The social networking tool -- an extension of Rapportive, which LinkedIn purchased last year -- offers functionality that people might find helpful. "I've been using Rapportive with Gmail for a couple of years and find it useful for providing social context around my email correspondence, making it easy to see who I'm communicating with and a little bit about them, as well as whether I have an existing social network connection with them or might want to establish one," InformationWeek's David Carr commented when Intro was introduced.

So far, so good. But what about security? As befits any service that wants to play go-between -- in this case, between your iOS Mail app and email service provider -- users should be able to trust that LinkedIn is handling the information in a secure manner, and decide for themselves if the potential privacy tradeoff is worth it.

Trust deficits
Where information security and trust are concerned, however, LinkedIn enjoys a deficit. Last year, notably, the business lost 6.5 million users' passwords, and only spotted the related breach after those passwords surfaced on an underground password-hacking forum. Adding insult to injury, LinkedIn had committed a basic security error by hashing, yet not salting, those passwords, thus making them relatively easy for attackers to crack.

Also last year, researchers at Skycure accused the company of creating a privacy leak, due to an optional feature that allows the LinkedIn iOS app to grab information about people with whom users have scheduled meetings. According to Skycure, LinkedIn's approach didn't just grab information about meeting participants, as would be expected, but also sensitive meeting details -- including time, location, meeting subjects, phone numbers, passcodes, and more -- for anyone who activated the feature.

Fast-forward to LinkedIn's Intro announcement, which included a short and vague "security and privacy" section near the end. "We will do everything we can to make sure that it is safe," wrote LinkedIn software engineer Martin Kleppmann. "Our principles and key security measures are detailed in our pledge of privacy."

But security talk is cheap; what did LinkedIn actually do? "LinkedIn has a documented history of insecure design practice," according to a blog post from security consulting firm Bishop Fox. "As anybody who has ever assessed a vendor would want to know: Who did the security review of the Intro app? Are there outstanding security vulnerabilities? Can we see a copy of a Letter of Assessment?"

All told, Bishop Fox detailed 10 Intro security and privacy concerns, including the fact that two Intro servers used SSLv2 -- a weak cipher -- for transport layer security. "SSLv2 is known to be insecure. In fact, it's a violation of many standards and guidelines, such as PCI DSS, to allow SSLv2," according to Bishop Fox. "We always suggest using strong encryption. Against the large scale, government-backed spying, it may help. It may be your only hope."

Meanwhile, security researcher Jordan Wright detailed how would-be phishers could spoof Intro into saying that an email was from a legitimate connection, even if it was sent by attackers and linked to a malicious website. In other words, he warned, Intro might lull users into a false sense of security.

LinkedIn responds
Three days after Intro's launch, in a blog post, Cory Scott, LinkedIn's senior manager of information security, provided some basic Intro security details. Notably, he said that Intro data was stored on a secure network segment that was separated from the rest of the company's infrastructure, that security consulting firm iSEC Partners was hired to "perform a line-by-line code review of the credential handling and mail parsing/insertion code" in Intro, and that LinkedIn's own security team had pen-tested the app.

LinkedIn also responded to the concerns raised by Bishop Fox and mitigated some related flaws, including discontinuing the use of SSLv2. Likewise, LinkedIn issued a fix to address the phishing vulnerability identified by Wright. He applauded the company's "quick and effective response," though questioned whether attackers might still be able to employ CSS tricks to spoof Intro users.

To date, not every last Intro-related security and privacy question has been settled. "The big question is whether we're really ready to trust our private email communications with a social media company with a strong focus on mining data," security researcher Troy Hunt said. "We worry about sharing small pieces of information with Facebook; are we ready to share every single email -- every single attachment -- with one of the world's largest social media companies?"

Would-be Intro users can answer that question for themselves, knowing that from a security standpoint -- based on the basic details belatedly shared by LinkedIn -- their data is likely relatively safe. Likewise, Intro's security has been further improved in response to flaws spotted by third-party researches, though notably not LinkedIn's own penetration testing team.

Next time, however, when it comes to LinkedIn -- or any other technology vendor or social network provider -- launching a new product or service, why not prevent this type of PR fallout by instead detailing exactly how you're going to keep our information secure? For many would-be users, glossing over security triggers is cause for concern -- especially in these NSA digital dragnet days.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
kelleyd1
50%
50%
kelleyd1,
User Rank: Apprentice
11/17/2013 | 3:28:00 PM
Where's the outrage?
The problem isn't the lack of security controls, it is the fact that the public doesn't get angry enough about breaches and privacy concerns to move their business elsewhere. More than 617M records... yes 617 MILLION... (according to the Privacy Rights Clearinghouse) have been breached in the past 7 years. But most of the high-profile companies have not been adversely affected by the breaches (think stock prices of breached companies). These companies can ride the bad PR for a while as the news cycle changes pretty quickly. Most consumers don't express thier displeasure with the pocketbooks. Until they do, things won't change.   
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
DevOpsí Impact on Application Security
DevOpsí Impact on Application Security
Managing the interdependency between software and infrastructure is a thorny challenge. Often, itís a ďdevelopers are from Mars, systems engineers are from VenusĒ situation.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0993
Published: 2014-09-15
Buffer overflow in the Vcl.Graphics.TPicture.Bitmap implementation in the Visual Component Library (VCL) in Embarcadero Delphi XE6 20.0.15596.9843 and C++ Builder XE6 20.0.15596.9843 allows remote attackers to execute arbitrary code via a crafted BMP file.

CVE-2014-2375
Published: 2014-09-15
Ecava IntegraXor SCADA Server Stable 4.1.4360 and earlier and Beta 4.1.4392 and earlier allows remote attackers to read or write to arbitrary files, and obtain sensitive information or cause a denial of service (disk consumption), via the CSV export feature.

CVE-2014-2376
Published: 2014-09-15
SQL injection vulnerability in Ecava IntegraXor SCADA Server Stable 4.1.4360 and earlier and Beta 4.1.4392 and earlier allows remote attackers to execute arbitrary SQL commands via unspecified vectors.

CVE-2014-2377
Published: 2014-09-15
Ecava IntegraXor SCADA Server Stable 4.1.4360 and earlier and Beta 4.1.4392 and earlier allows remote attackers to discover full pathnames via an application tag.

CVE-2014-3077
Published: 2014-09-15
IBM SONAS and System Storage Storwize V7000 Unified (aka V7000U) 1.3.x and 1.4.x before 1.4.3.4 store the chkauth password in the audit log, which allows local users to obtain sensitive information by reading this log file.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
CISO Insider: An Interview with James Christiansen, Vice President, Information Risk Management, Office of the CISO, Accuvant