Configuration errors lead to HealthCare.gov breach

HHS says an attacker gained access to the HealthCare.gov server, but no personal information was compromised

The Health and Human Services Department (HHS) said that HealthCare.gov, the nation's health insurance enrollment website, was breached in July and that the attackers uploaded malware to the server.

The breach, which is the first successful intrusion into the website, was discovered on August 25 by a CMS security team after an anomaly was detected in the security logs of one of the servers on the compromised system.

[ Prevent corporate data leaks with Roger Grimes' "Data Loss Prevention Deep Dive" PDF expert guide, only from InfoWorld. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

Officials say that while the attacker did gain access to the server, no personal information was compromised.

In a statement to CSO, an HHS spokesperson said that based on their analysis of the intrusion, as well as additional attempted intrusions on other government and private sector websites, "we do not believe HealthCare.gov was targeted."

"Our review indicates that the server did not contain consumer personal information; data was not transmitted outside the agency," the spokesperson added.

According to reports on the incident from HHS, the breach occurred because a development server wasn't properly configured.

While the system was supposed to remain segmented and unavailable to the general public, someone connected it to the Internet. On July 8, the test server was compromised and had upload malware to it.

The malware uploaded to the test server is described as commonplace, and was designed to add the server to a botnet and launch a Denial of Service attacks against other websites, or deliver spam when activated. Analysis of the malware didn't reveal any functions designed to exfiltrate personal information.

However, the malware remained idle, which according to HHS is why detection took so long. The agency has said that the website undergoes quarterly security audits, as well as daily security scans and hacking exercises.

Exact details on how the breach occurred were not shared with the public, but sources close to the investigation said that the development server was poorly configured and used default credentials. In addition, it's possible that the attack itself was automated, as server logs showed similar scans across multiple government websites.

"While it's great to hear that this impacted server doesn't seem to have directly impacted user's personal data, it is concerning that such a related server could have been using a default password as is being reported at this time. Any system related to HealthCare.gov should be treated with great focus on security," commented Mark Stanislav, Security Evangelist at Duo Security.

While HHS says that the incident will not impact the second open enrollment period on HealthCare.gov, which begins November 15, the fact that the incident happened at all will once again bring the website under fire for having problems with security.

Last year, a CBS News report detailed how security checks for the website were delayed three times, and the final overall security assessment was never performed. Despite being fully aware of the missing security checks, the Obama administration granted itself a waiver to launch HealthCare.gov with a level of uncertainty that was deemed as high risk.

"If this was a server used to test code for healthcare.gov, I would assume that the test servers are configured in a way that reflects the production environment. Depending on what data was used in the testing environment, this could be a bigger deal than we know," commented Rapid7's Trey Ford.

In the aftermath of this most recent incident, HHS said that they've "taken measures to further strengthen security."

This story, "Configuration errors lead to HealthCare.gov breach" was originally published by CSO.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies