Biz & IT —

HealthCare.gov deferred final security check, could leak personal data

Site shares identifying data with analytics vendors, might expose more to attackers.

Ben Simo's analysis of data sent by HealthCare.gov to analytics providers shows information that could be used to hijack a user's account.
Ben Simo's analysis of data sent by HealthCare.gov to analytics providers shows information that could be used to hijack a user's account.

Apparently, HealthCare.gov isn't just having a few backend problems. A software quality researcher studying the besieged online health insurance exchange has discovered a number of issues that could expose the personally identifiable information of applicants to third parties and leave that information vulnerable to attacks by hackers.

Those problems may be in part due to the long-delayed security testing of the entire integrated exchange system, which was put off as last-minute development work that was done to ready the site for launch. Recently published internal government documents indicate that the site was only given provisional security approval before launch because a substantial amount of testing had not been completed just days before the site's October 1 launch date.

The problems uncovered by researcher Ben Simo hint at how slapdash some of the coding done to integrate the site was. He found personally identifiable information embedded both in Web addresses sent to reset user passwords and in data being sent to third-party sites not directly involved in the health insurance certification process. HealthCare.gov's website also pushes personal data having nothing to do with site functionality back to browsers. While that data is sent over an encrypted connection, it could be vulnerable to exploits targeting HealthCare.gov users.

Security alert

A government memorandum signed off on by CMS Administrator Marilyn Tavenner allowed HealthCare.gov to launch without final security checks.
Enlarge / A government memorandum signed off on by CMS Administrator Marilyn Tavenner allowed HealthCare.gov to launch without final security checks.

On September 27—just three days before HealthCare.gov's legislatively mandated go-live date—the Center for Medicare and Medicaid Services (CMS) Administrator Marilyn Tavenner signed off on a request to buy more time for the Security Control Assessment (SCA) of the site. CMS Deputy CIO Henry Chao and Consortium Administrator for Medicare Health Plan Operations James Kerr submitted the request, noting:

From a security perspective, the aspects of the system that were not tested due to the ongoing development exposed a level of uncertainty that can be deemed as a high risk… Although throughout the three rounds of SCA testing all of the security controls have been tested on different versions of the system, the security contractor has not been able to test all of the security controls in one complete version of the system.

The proposal approved by Tavenner outlined a set of steps CMS would take to cover its assets during the first year of HealthCare.gov's operation, including the use of continuous monitoring tools to perform daily and weekly assessments of activity and weekly testing of all the "border devices" between the Internet and the overall system, "including Internet facing Web servers." The plan also included a full SCA evaluation on the HealthCare.gov "stable environment" within 90 days of the site's launch. CMS' CIO Tony Trenkle, Enterprise Information Security Group Director Teresa Fryer, and Chief Operating Officer Michelle Snyder all signed off on the recommendations, acknowledging the elevated security risk.

One of the mitigating factors cited in the plan was that the whole HealthCare.gov infrastructure would be migrated once the site went live into CMS' Virtual Data Center, a set of geographically dispersed data centers operated by a collection of eight contractors. The Virtual Data Center facilities have all already passed security certification, and migration of the site from the temporary capacity provided by Verizon Terremark during development was supposed to begin this month.

In retrospect, the decision to move HealthCare.gov into the distributed data center might have come a little bit too late—Terremark's single data center hosting the HealthCare.gov site has suffered two outages since the launch.

Privacy problems

Whatever security assessments were done on the code that shipped October 1, analysis by Ben Simo shows it didn't include checks against the site's own privacy policy.

First, Simo found holes in the site's password reset function. While a bug that revealed the e-mail address and password reset code for a user through a Web debug tool was repaired, another flaw in the reset process remains: the username and reset code are sent in clear text in e-mail as part of the link users are asked to click on to perform the reset. Also, the password-reset code is apparently permanent—meaning that if it is compromised, someone could use the code and username over and over to attempt to hijack a user's account.

The latest vulnerability unearthed by Simo is in a pile of data passed by the site to the user's browser and in the information sent to analytics sites used to track the site's performance. That data, Simo discovered, includes the user's username and password reset code.

HealthCare.gov sends data to analytics providers such as Google's DoubleClick and Pingdom. As Simo reviewed the Web requests being made as part of his movement through the HealthCare.gov site, he found requests sent to these two providers that included his visit to the password reset page—and all of the user data that was generated by the page. That runs counter to the privacy policy on HealthCare.gov, which states that no personally identifiable information will be collected by site analytics tools. This is the same sort of behavior that the Federal Trade Commission has fined social networks such as Facebook and MySpace for in the past.

Even more information gets pushed back to the browser as a user moves through the site. Simo found a JSON data structure being pushed back to his browser that included most of the personal information for his account, including various unique user IDs and his name, address, date of birth, phone number, and e-mail address, plus a field for his social security number if he had provided it—along with the password reset code.

While all this data is transmitted over a secure connection and isn't stored as a cookie or in some other relatively permanent form, Simo told Ars, "it's increasing the harm if an account can be compromised." The information isn't used by the site once an account is created, so it shouldn't be sent back to the users each time they log in, he said. "I get the impression they weren't thinking about security as they designed these pieces of the site."

Channel Ars Technica