Is Healthcare.gov security now fixed?

I first attempted to use HealthCare.gov to learn about options for covering my granddaughter, who is not covered by my employer-subsidized insurance. I encountered the same kinds of account creation issues others have reported, but I decided to turn on my web browser’s built-in developer tools to see if I might see details as to why form submissions were failing. I quickly discovered that the main browser window would often display a status other than what was actually occurring. For example, the form submission would fail to get a response from the server but the user interface would report that the form was submitted. Once I saw this behavioral mismatch between what was displayed in the browser and what was actually happening, I kept developer tools on as I used the site.

I do not consider using developer tools to watch data moving in and out of my own computer to be “hacking.” I have NOT “hacked” Healthcare.gov. I have only observed what is sent to my computer. I have NOT attempted to gain unauthorized access to Healthcare.gov accounts. Attempting to gain unauthorized access would be both unethical and illegal. Please don't try it.

While watching the interactions between my web browser and the Healthcare.gov servers, I saw information being sent to my computer that likely should not have been sent by the server. After I was told that Healthcare.gov will not take reports of security concerns, I started blogging them.

Then I came across a very serious issue.

I discovered a design defect that subsequently led to me receiving a great deal of media attention. Little did I know that my findings would be mentioned in Wednesday's congressional hearings:

ESHOO: On the issue of security, there was a security breach that arose recently, that I read about at any rate. And what I think is very important here, because the issue of privacy has been raised, and I think that that has been answered. Very importantly, there isn't any health information in these systems. But there is financial information, so my question to you is, has a security wall been built, and are you confident that it is there and that it will actually secure the financial information that applicants have to disclose?

SEBELIUS: Yes, ma'am, I -- I would tell you that there was not a breach, there was a blog by a sort of skilled hacker that if a certain series of incidents occurred, you could possibly get in and obtain somebody's personally identifiable...

(CROSSTALK) ESHOO: But isn't that telling? Isn't that telling?

SEBELIUS: And we immediately corrected that problem, so there wasn't a -- it was a theoretical problem that was immediately fixed. I would tell you we are storing the minimum amount of data, because we think that's very important. The hub is not a data collector. It is actually using data centers at the IRS, at Homeland Security, at Social Security to verify information, but it stores none of that data, so we don't want to be.....

Secretary Sebelius is correct: I did not breach or exploit any of the vulnerabilities that I reported on my blog. And it is nice that she thinks I’m “sort of skilled” as a hacker, when I’m actually a highly-experienced software tester.

I identified a series of steps that could be easily automated to collect usernames, password reset codes, security questions, and email addresses from the system -- without any kind of authentication.

Attackers could use this information to go phishing. Exposing this information gives attackers sufficient information to gain trust and trick people into disclosing their security question answers.

If I were a malicious phisherman, I might send users email that directs them to a site masquerading as HealthCare.gov, and then ask victims to provide their security questions in order to revalidate their account. After collecting this information, I could then reset the password and access information the user provided to HealthCare.gov.

I found this issue last Thursday night (October 24th). I notified HealthCare.gov customer service immediately.  The next morning, I found someone who could help pass information about my discovery to people within HHS. CMS patched the most serious hole the same day, and made further changes on Monday before making a public statement about the issue.

“We are eliminating this theoretical vulnerability by preventing users from seeing the specific reset functionality when trying to reset their password... There is no public evidence that these design flaws were ever exploited to compromise user accounts." - Brian Cook, CMS Spokesman

While I am appalled that the issue existed in the first place, I applaud the quick response.

Monday night, after CMS publicly confirmed the fix, I took a quick look at the new "fixed" password reset functionality.

I saw a couple of positive changes:

1. The password reset code is no longer returned to the web browser. This closes the biggest hole. Exploiting weaknesses in the password reset system will now require that password reset codes be obtained by intercepting email, or some other mechanism.

2. The system asks for security question answers and a new password before submitting the request. This slows down manual security question guessing attempts, but will have little impact on an automated attack.

I also saw that many potential security issues still exist:

1. The system still confirms whether a username or email address exists in the error messages returned by the underlying services. Given that these are not public identifiers in the Insurance Marketplace, these should not be revealed. (As of 11/07, this still exists.)

2. The system still transmits both the username and password reset code via email. Email is generally not a secure means of communication. A more secure way to do this would be to send the user only half of the equation: the reset code; and then prompt the user for the username after they follow the reset link. (As of 11/08, this still exists.)

3. The password reset code still stays the same with each request (and is the same code used to initially activate the account). A more secure way to do this would be to change the code each time a password reset is requested or a password is reset; and in the case that a system contains sensitive information like this one does: put a time limit in which the reset code may be used. (As of 11/13, this appears to have been fixed. Reset codes are changing and old ones don't work.)

4. When requesting a password reset, the username and password reset code are still sent to 3rd party analytics companies. Even if these companies can be trusted to not misuse the data, this likely violates their terms of use and privacy policies. And if these 3rd parties aren't expecting personal information, they may not protect it as they would protect personal information. (As of 10/31, this appears to have been fixed.)

5. If any of the above (or other) issues lead to a username or password reset code being compromised, the security questions and email address associated with the account can still be retrieved from the system without authorization. (As of 11/11, the security questions can no longer be retrieved using only a username. The system now requires the emailed password reset code to retrieve security questions.)

6. In the unfortunate event that an account is compromised:

1. An attacker can change the email address associated with the account without triggering notification of the email change to the user. Once this is done, other account information can be changed without notifying the owner of the account. (As of 11/05, this still exists.)

2. The personal information used to validate a user's identity is returned to the browser each time a user logs into a system. This data is both retained and returned to the browser when it should no longer be needed. Returning it to the browser each time a user logs into the system increases the potential damage should an account be compromised.  This data includes the personal information the account owner provided to verify their identity -- sufficient information to steal another’s identify. This also include all information entered into an insurance application for each person on the application (eg: names, DOB, SSNs, disability, pregnancy, finanical) and data retrieved from back-end systems (eg: employer, and income, and last paycheck details). (As of 11/13, the identify verification data is no longer returned to the browser; however, the personal information in the insurance application is still returned to the browser.)

Have you heard?

SLAVITT: Our systems don't hold data. They just transport data through it.

ROGERS: You don't have to hold it to protect it.

Both Secretary Kathleen Sebelius and Andy Slavitt, an executive VP at QSSI (the company tasked with fixing Healthcare.gov) have downplayed security concerns. They have suggested that personal information is not at risk because The Hub, the Healthcare.gov front end, does not store information; but rather, transports information. A system is only as secure as its weakest link. If front-end security is poor, then no amount of back-end security can protect information passing through the front end.

Even if Healthcare.gov doesn't store information, it returns personal information to the browser. As outlined above, the data I once provided to verify my identity is sent to my computer each time I login to Healthcare.gov -- long after the identity verification has been completed. This information includes name, address, date of birth, phone number, and Social Security Number. It also returns data retrieved from back-end systems; including, employer, income, last paycheck details, and more.

Much of the work required to exploit these vulnerabilities can be automated.

Many of these vulnerabilities are rather benign when considered individually. However, they quickly become more serious concerns if we consider how they may be combined and the exploits automated.

I have discovered several additional vulnerabilities while using the site.

1. The email validation system demonstrated the same flaw as the password reset system: It returned the activation code (which is the same as the password reset code) to the browser; enabling one to create an account using an email address they do not own. (As of 11/5, this appears to be fixed.)

2. My username and questionnaire answers were sent over the Internet without encryption under an error condition that also led to my profile information not being displayed. (As of 11/08, this still exists.)

3. The system returned Java stack traces to the browser; potentially revealing information about the internal workings or data of the system that could be exploited to find weaknesses in security. (As of 11/05, this still exists.)

4. The security questions ask for things that are likely to be known by one's friends, family, or ex -- and are the sorts of things many will post on Facebook or other social media. (This morning, HHS Secretary Sebelius referred to these questions as "personalized questions that can only be verified by you". They aren't.) (As of 11/08, this still exists.)

We can only speculate at what other security vulnerabilities might be found by someone willing to attempt to gain unauthorized access.

But wait, there's more!

UPDATE 10/31:

1. Healthcare.gov returns the username for an account when given a user's real name and email address. (This appeared to be fixed on 11/06, then reappeared on 11/08. As of 11/10, it appears to have been fixed again.)
2. Healthcare.gov returns the security questions for an account when given a username. (As of 11/11, this appears to have been fixed. I last saw it on 11/08.)

No other authentication is required. Although this doesn't provide an attacker with the password reset code, it exposes information that should be kept private and provides sufficient information to make phishing relatively easy.

Conclusion

I am very happy that the most egregious issue was immediately fixed.

Others issues remain.

The vulnerabilities I've listed above are defects that should not make it to production.  It doesn't take a security expert or “super hacker” to exploit these vulnerabilities.

This is basic web security.  Most of these are the kinds of issues that competent web developers try to avoid; and in the rare case that they are created, are usually found by competent testers.

Rather than individual incompetence, these issues might suggest a fractured development team -- where the developers building the components don't know how they are used in the system and therefore do not have sufficient situational awareness to understand the security implications of their decisions. Still, someone has to assemble the components and the system as a whole should be tested for security. Given that I don't know what's going on within the project, I can only speculate. I have; however, seen enough to be concerned.

The volume of users, the nature of the data presumed in the system, and the political attention all contribute to making HealthCare.gov a target of interest to attackers -- of higher interest than the typical web site. This demands a higher standard. This requires that security be made a priority throughout design, implementation, testing, and monitoring of the system.

I am still concerned about Healthcare.gov security. It should concern all of us.