Application Security
08:00 AM

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
Oldest First  |  Newest First  |  Threaded View
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
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.