October 09, 2013
Is the Affordable Health Care Website Secure? Probably not.
Written by
David Kennedy
Leadership
With the Affordable Health Care Act moving into full momentum - there are a lot of privacy and security concerns for any new major government program being implemented. It's no secret that the website, the infrastructure, and the staffing has been a challenge to get up in running in the appropriate timeframes. Coming purely from the security industry and seeing corporations, deadlines, and tight timeframes snag security objectives - there should be major concern on the implications this system has on what will become the largest database of Americans in recorded history.
The Affordable Health Care Act websites cost an estimated 634 million to develop. http://www.digitaltrends.com/opinion/obamacare-healthcare-gov-website-cost/. One would hope that there would be heavy security integration into the software development lifecycle and best practices followed in the most extreme circumstances. As you can imagine, the site is going to be a major target for hackers, other governments, and organized crime. There's a lot of money to be made right now in an untapped market that is fresh for the picking.
We decided to look around - please note that there was nothing malicious, no hacking, and nothing intrusive involved in this test in any regard. We simply browsed the website as a normal visitor without any type of attacks at all. Just by looking at information, you can determine the quality of the code, and whether simple best practices in security are being followed.
Below is in the "Log In" page and the "Forgot password" link. Note when you enter a username that is invalid, it returns quickly that the username is invalid.
Note when you place a valid user:
As you can see, you can enumerate valid and invalid user accounts in the database. Even worse is there are no form or appearance of automation deterrents such as CAPTCHA or image verifications that a human is attempting this. We can easily feed this through Burp Intruder for the content length from the response to see which usernames were actually valid. Essentially you could enumerate the entire database of user accounts in the new healthcare.gov website through brute forcing the response codes and finding valid usernames.
Additionally, developer comment code is plastered everywhere which gives an attacker a significant amount of understanding about the application - these are literally everywhere on almost every page that's opened and all third party files:
//global variable used for SHOP upload functionality
var myView = null;
var agentBrokerSAMLToken=null;
var postCCRApplicantIDToken=null;
var postCCRAppIDToken=null;
var postCCRState=null;
var agentEmailUUID =null;
Even crazier, doing some Google reconnaissance, we found an indexed site that a subsite used CKEditor - NOTE we did NOT attempt to even follow the link to verify if it's there.
CKEditor has a number of known exposures here: Search results for CKEditor on Exploit-DB
We've also identified some significant ones that we can't post online due to the critical nature of them and attempting to contact the development team for the website to remediate. Our intent is not to point out flaws, show flaws, or demonstrate insecurities, only to bring the light that based on viewing like a normal user, there appears to be things that would indicate that there should be major reason for concern here.
Again - nothing malicious performed here and we truly have no idea what the real exposures are without performing a full test on this, which we would have hoped would have been performed prior to any major production release.
Note when you place a valid user:
As you can see, you can enumerate valid and invalid user accounts in the database. Even worse is there are no form or appearance of automation deterrents such as CAPTCHA or image verifications that a human is attempting this. We can easily feed this through Burp Intruder for the content length from the response to see which usernames were actually valid. Essentially you could enumerate the entire database of user accounts in the new healthcare.gov website through brute forcing the response codes and finding valid usernames.
Additionally, developer comment code is plastered everywhere which gives an attacker a significant amount of understanding about the application - these are literally everywhere on almost every page that's opened and all third party files:
//global variable used for SHOP upload functionality
var myView = null;
var agentBrokerSAMLToken=null;
var postCCRApplicantIDToken=null;
var postCCRAppIDToken=null;
var postCCRState=null;
var agentEmailUUID =null;
Even crazier, doing some Google reconnaissance, we found an indexed site that a subsite used CKEditor - NOTE we did NOT attempt to even follow the link to verify if it's there.
CKEditor has a number of known exposures here: Search results for CKEditor on Exploit-DB
We've also identified some significant ones that we can't post online due to the critical nature of them and attempting to contact the development team for the website to remediate. Our intent is not to point out flaws, show flaws, or demonstrate insecurities, only to bring the light that based on viewing like a normal user, there appears to be things that would indicate that there should be major reason for concern here.
Again - nothing malicious performed here and we truly have no idea what the real exposures are without performing a full test on this, which we would have hoped would have been performed prior to any major production release.