20131031

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.

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:

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.

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:

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.)

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.)

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.)

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.)

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.)

In the unfortunate event that an account is compromised:

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.)

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.)

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.

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.)

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.)

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.)

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:

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.)

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.

How do we report an issue with the Healtcare.gov site? We have never been able to bring up our application online. When we click on the "Find my existing application", we immediately get the "Sorry you've tried to find an application too many times" error message. This is a feature we do not appreciate and time is almost out for us.

I have been getting the same error "sorry u have tried too many times", and even by talking to customer support several times, the message didnt disappear.Now i have no visibility on my application status.

did this issue fix yet? same error I'm getting since I applied in back in feb.2016 and I been talking to customer service rep since march 1st for same error but nothing done as of yet! I bave been spend at 3hrs when call marketplace and every call end up with feed back.

Usability Heuristics

Visibility of system status Visibility of system status: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world Match between system and the real world: The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom User control and freedom: Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards Consistency and standards: Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Error prevention Error prevention: Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Recognition rather than recall Recognition rather than recall: Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Flexibility and efficiency of use Flexibility and efficiency of use: Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design Aesthetic and minimalist design: Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors Help users recognize, diagnose, and recover from errors: Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation Help and documentation: Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

Security Vulnerabilities

1. Injection Injection: Injection flaws occur when untrusted data is sent to an interpreter as part of a command. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without authorization.

2. Broken authentication and session management
Broken authentication and session management:
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

4. Insecure Direct Object References
Insecure Direct Object References:
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to gain unauthorized access to data.

5. Security Misconfiguration
Security Misconfiguration:
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

6. Sensitive Data Exposure
Sensitive Data Exposure:
Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

7. Missing Function Level Access Control
Missing Function Level Access Control:
Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

8. Cross-Site Request Forgery
Cross-Site Request Forgery (CSRF):
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

9. Using Components with Known Vulnerabilities
Using Components with Known Vulnerabilities:
Running software components with known vulnerabilities can compromise the vulnerable components and anything those components can access -- undermining defenses.

10. Unvalidated Redirects and Forwards
Unvalidated Redirects and Forwards:
Using untrusted data, without validation, to determine the destination of redirects and forwards can enable attackers to redirect victims to phisihing or malware sites.