Application Security // Database Security
8/20/2014
04:23 PM
Connect Directly
Twitter
RSS
E-Mail
100%
0%

Heartbleed Not Only Reason For Health Systems Breach

Community Health Systems' bad patching practices are nothing compared to its poor encryption, network monitoring, fraud detection, and data segmentation, experts say.

A security researcher has announced that the notorious OpenSSL bug, Heartbleed, was the initial point of entry for the attack on Community Health Systems (CHS) that netted 4.5 million identity records -- but other researchers point out that Heartbleed is only the beginning of the problem.

David Kennedy, CEO of TrustedSec, first announced Heartbleed's involvement on Fox News and in a TrustedSec blog post Wednesday afternoon. Kennedy says he had this confirmed by three people close to the incident, who remain anonymous. CHS has not yet publicly confirmed this and could not be reached for comment as of press time.

"The initial attack vector was through the infamous OpenSSL 'heartbleed' vulnerability which led to the compromise of the information... Attackers were able to glean user credentials from memory on a CHS Juniper device via the heartbleed vulnerability (which was vulnerable at the time) and use them to login via a VPN," Kennedy said in yesterday's blog post.

"This is why we put up Heartbleed.com," says David Chartier, CEO of Codenomicon, which discovered the Heartbleed bug, in conjunction with Neel Mehta of Google Security. "We were very passionate about telling people how to recover from this."

Codenomicon advised vulnerable parties to not only upgrade to a new version of OpenSSL, but also to revoke encryption keys, issue new encryption keys, and make users change their passwords.

Trouble is, not everyone followed those recovery steps (if any), nor in a timely manner. Chartier says that revoking and re-issuing keys, in particular, took some time for security managers to do. The Heartbleed vulnerability became public April 7. CHS believes the intrusion in their systems occurred in April and June. Chartier says he will be "not at all surprised" if it turns out that Heartbleed was part of how attackers obtained the records in this attack.

The CHS breach is being hailed as the biggest security incident Heartbleed has caused so far -- at least the biggest one we know about.

"Although it is irrational to think that Heartbleed hasn’t already been utilized in even larger-scale attacks prior to the Community Health Systems breach, this is just the largest thus far where the investigation proved Heartbleed was what got them the data," says Evan Keiser, security analyst for SilverSky. "Taking into account how long many major corporations, hospitals, government, and healthcare servers were vulnerable to the Heartbleed bug I would be extremely surprised if this was the biggest attack in terms of scale."

Regardless of whether or not CHS has suffered the worst blow from the bludgeoning of the OpenSSL bug, some caution that we should not focus too much on one unpatched vulnerability; there are plenty of other mistakes CHS made.

"It seems pretty obvious to me that Heartbleeed could have played a role, but it's not how [attackers] got their hands on the data," says Dr. Vincent Berk, CEO of FlowTraq.

Berk compares Heartbleed to sonar pings. Just like most of the pings a submarine sends out aren't going to be echoed with anything interesting, Heartbleed hacks can, but rarely will, come back with valuable data like privileged access credentials. "There's no way really to tell what kind of data you [are going to] get, and most of it is trash."

As Berk explains, because of the extensive attention in both industry and consumer media, everyone knew about Heartbleed, and surely competent, caring security professionals would have made sure all systems were adequately patched. "Either [CHS] didn't care or they're just not qualified" to manage their systems, says Berk. Assuming they did care, and just failed to patch for such a well-publicized vulnerability, says Berk, "I can only imagine how many other ways to get in there are... If it wasn't Heartbleed, it would have been something else."

One of CHS's biggest offenses, says Berk, is that they were only watching for what came into the network, not for what was going out of it -- like 4.5 million customer records. Exfiltrating such a large set of data would take time and computing resources that should have raised red flags.

"That is just downright embarrassing," says Berk. "Nobody was watching. Nobody was stopping it."

Similarly, just like the large-scale exfiltration of protected data is abnormal, there are other kinds of uncharacteristic behavior that was probably exhibited by the attackers using a legitimate employees' credentials.

"It's very easy to get your hands on valid credentials," says Nir Polak, CEO and co-founder of Exabeam. Whether it's a leak through Heartbleed or merely spearfishing, Polak says, legitimate logins will be lifted and borrowed by attackers.

Trying to prevent that from happening is a worthwhile endeavor, says Polak, but organizations need to act under the assumption that sometimes it's going to happen anyway -- and start looking for ways to tell if a legitimate user is behaving strangely.

"It's been happening in the fraud protection industry for a long time," says Polak, noting how banks now routinely monitor for inconsistencies in customers' purchasing activities. If an expensive purchase is made at a point-of-sale machine in Italy, when the legitimate customer is still buying groceries in New York as usual, the account may be flagged and frozen. "[Those methods] just need to be applied to information security."

New technologies are being created to do just that; for example, the BioCatch "passive biometrics" solution DarkReading has covered before.

Patching a highly publicized vulnerability in open-source code is just one small task companies must do to fulfill a bigger responsibility to lock down all the computing tools they use. Chartier points out that some companies may not have realized that OpenSSL was part of their environment, because it might have been located in embedded systems.

"It is part of an enterprises’ obligation to their customers and stakeholders, that they understand their supply chains," says Veracode CTO Chris Wysopal. "To help, they must look into third-party code auditing programs so they can rapidly assess their deployed environment for software vulnerabilities, even in the case where the software is on an appliance.

"Vendors need a way to quickly understand where they have built products with open-source components," Wysopal says. "All products should use Software Composition Analysis with an alerting mechanism for rapid response when a new vulnerability is made public in an open source component. And if the software component analysis tool integrates with a SAST solution, all the better so they can instantly find all locations components in their previously scanned code."

Another weakness in CHS's infrastructure is the apparent lack of segmentation in their customer database. CHS owns, leases, or operates 206 hospitals in 29 US states, none of which served 4.5 million patients all on their own.

Heartbleed's role in the CHS breach is noteworthy, but more noteworthy are the pile of best practices (and common sense practices) that the hospital chain failed to do.

"While Heartbleed was how the credentials were stolen this time," says Joshua Roback, security architect for SilverSky, "this could have just as easily been a common spear phishing attack, similar to the Target attack earlier this year. The real concern is the ability to hack into the database once logged in, and then exfiltration [of] the data."

As of press time, Community Health Systems' stock price continues to rise. In fact, it is nearing its 52-week high.

Sara Peters is Senior Editor at Dark Reading and formerly the editor-in-chief of Enterprise Efficiency. Prior that she was senior editor for the Computer Security Institute, writing and speaking about virtualization, identity management, cybersecurity law, and a myriad ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
Some Guy
50%
50%
Some Guy,
User Rank: Strategist
8/29/2014 | 3:45:02 PM
Re: Like NSA & Snowden, data needs to be encrypted at rest
And if the CC data had been encrypted in the POS terminal the attack would have yielded ... nothing. We all agree it's inevitable. What we need to be doing is 1) defending against the obvious and known, and 2) deploying defense in depth, so that it doesn't matter if they get through. Encrypting data at rest and in motion is part of #1.

Patient: "Doc, it hurts when I do that."

Doctor: "Don't do that!"

 
AnonymousMan
50%
50%
AnonymousMan,
User Rank: Moderator
8/29/2014 | 11:30:01 AM
Re: Like NSA & Snowden, data needs to be encrypted at rest
I disagree with your assessment of the Target breach.  Ram scraping malware wasn't created for Target, it has existed and been used in many POS breaches. that wasn't the point anyway. Ultimately, preventing breaches is damn near impossible.  No one said "do nothing". What I'm suggesting is that even if you do everything right (which is actually impossible in any sufficiently large organization), you still might get breached. Anyone who thinks their environment is perfectly secure either has a non-functioning business or is wrong. these  are going to keep happening and in fact it will get far worse IMHO.
Some Guy
50%
50%
Some Guy,
User Rank: Strategist
8/25/2014 | 12:50:22 PM
Re: Like NSA & Snowden, data needs to be encrypted at rest
Target did NOT lose encrypted data; they lost clear text because of a specification error that didn't immediately encrypt it and because they didn't use whitelisting. Eventual vulnerabilities are no excuse to do nothing. Agreed that encryption is not a magic bullet. Yet encryption of data in flight and at rest needs to be the bare minimum starting point and we aren't even there yet.
eamonwalsh80
50%
50%
eamonwalsh80,
User Rank: Apprentice
8/25/2014 | 11:10:26 AM
No excuses
While nobody is immune to these attacks indeed - there is really no excuse for not being able to update your security barriers once you know the nature and breadth of the breach on table. Heartbleed has certainly told you some serious markers on how not to handle data. Ultimately though, no amount of data security can account for the security habits and practices that a security manager of a big enterprise can put in process. Enterprise security (as outlined here goo.gl/a67V8i) may never be foolproof, but a lot of it is a matter of internal discipline and keeping an eye out. You must care about sensitive data your customer trust you with, for your own sake!
AnonymousMan
100%
0%
AnonymousMan,
User Rank: Moderator
8/22/2014 | 4:09:00 PM
Re: Like NSA & Snowden, data needs to be encrypted at rest
it's symptomatic of every single large IT environment in existence.  NO ONE is immune. Not the banks. Not the Gov't, or their contactors. Not security companies.  And, not your organization. Encryption isn't a magic cure for breaches.  Target encrypted the data that was stolen at resta and in transit.  But at some point the data has to be in clear text to be useful, and whatever processes involved can be subverted. 
Some Guy
100%
0%
Some Guy,
User Rank: Strategist
8/22/2014 | 9:24:31 AM
Like NSA & Snowden, data needs to be encrypted at rest
This is just symptomatic of no defense in depth. Data needs to be protected in flight AND at rest. And hiding behind a single Curtain Wall didn't even work in castles 600 years ago. Just like the NSA Snowden fiasco, CHS owes it to their patients, stakeholders and regulators to take irrevocable corrective action.
RyanSepe
100%
0%
RyanSepe,
User Rank: Ninja
8/22/2014 | 9:02:21 AM
Re: Communication Gap
I agree with your last statement. But the risk can be lowered substantially through a strong security posture. However, as attacks evolve so must the protections and unfortunately the attacks are evolving faster than the patrol.
AnonymousMan
100%
0%
AnonymousMan,
User Rank: Moderator
8/21/2014 | 6:54:01 PM
Re: Communication Gap
Neither would have netflow, unless their network traffic patterns are very predictible and/or the attackers were very stupid.  Often neither is the case. Let's assume each record was average 200 bytes and 10:1 compression.  Even a single file with all 4.5 million records would not be very big in the grand scheme of what often flows across a network. And that assumes the file wasn't split into smaller parts.

Sadly, the reality is that breaches are now just a part of life on the Internet.  Even organizations with relatively strong security can become victims if there is sufficient motivation. 
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
8/21/2014 | 9:17:45 AM
Re: What we do not know yet.
@aws0513 writes that "the only question that remains is in how transparent the organization leadership is in notifying share holders, law or regulatory entities, and the general public when a breach is identified."

Sadly I think that unless organizations are required by law to be transparent, the status quo will continue for a long time for all but the most security-focused businesses. It's a tragedy-in-the- making for healthcare not to be counted among them. 
Robert McDougal
100%
0%
Robert McDougal,
User Rank: Ninja
8/21/2014 | 8:47:54 AM
Re: Communication Gap
Great points Ryan!

I would also like to point out that simply standing up a IDS would not have prevented or even alerted this type of attack.  Based on what I have read, the only way to have caught this would be to monitor netflow data and look for spikes.  

Most organizations, not just healthcare, do not have someone assigned to monitor the netflow data 24x7 so I think this would have gone unnoticed in many organizations.
Page 1 / 2   >   >>
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-2413
Published: 2014-10-20
Cross-site scripting (XSS) vulnerability in the ja_purity template for Joomla! 1.5.26 and earlier allows remote attackers to inject arbitrary web script or HTML via the Mod* cookie parameter to html/modules.php.

CVE-2012-5244
Published: 2014-10-20
Multiple SQL injection vulnerabilities in Banana Dance B.2.6 and earlier allow remote attackers to execute arbitrary SQL commands via the (1) return, (2) display, (3) table, or (4) search parameter to functions/suggest.php; (5) the id parameter to functions/widgets.php, (6) the category parameter to...

CVE-2012-5694
Published: 2014-10-20
Multiple SQL injection vulnerabilities in Bulb Security Smartphone Pentest Framework (SPF) before 0.1.3 allow remote attackers to execute arbitrary SQL commands via the (1) agentPhNo, (2) controlPhNo, (3) agentURLPath, (4) agentControlKey, or (5) platformDD1 parameter to frameworkgui/attach2Agents.p...

CVE-2012-5695
Published: 2014-10-20
Multiple cross-site request forgery (CSRF) vulnerabilities in Bulb Security Smartphone Pentest Framework (SPF) 0.1.2 through 0.1.4 allow remote attackers to hijack the authentication of administrators for requests that conduct (1) shell metacharacter or (2) SQL injection attacks or (3) send an SMS m...

CVE-2012-5696
Published: 2014-10-20
Bulb Security Smartphone Pentest Framework (SPF) before 0.1.3 does not properly restrict access to frameworkgui/config, which allows remote attackers to obtain the plaintext database password via a direct request.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.