No security ever built into Obamacare site: Hacker(cnbc.com)
cnbc.com
No security ever built into Obamacare site: Hacker
http://www.cnbc.com/id/101225308
68 comments
I don't think it's unreasonable to expect that a website which people are legally obligated to use by a certain deadline, entering very sensitive information in the process, have a decent standard of security at launch. I don't see "having the crap beat out it in production" as a good strategy here, and certainly is worth complaining about, even if not worth re-writing over. Would you be comfortable entering your SSN at healthcare.gov?
Fun fact: You can guess an individual's SSN using information often available on their Facebook profile and about 100 lines of code. (Someone demonstrated this to me using a TI-82 program in high school. The result has since been replicated in more reputable literature. http://www.ssnstudy.org/)
Man I remember learning this and having my mind blown. It's scary.
Last first: yes.
For the rest: if you have standards or expectations for the security of any site than handles your personal information, you are bound to be disappointed. I am less worried about the information I post to a site like Healthcare.gov than I am about online banks. How secure do you think new, production, real-money online banking sites are? Here's a hint: you have more to worry about than open redirects.
For the rest: if you have standards or expectations for the security of any site than handles your personal information, you are bound to be disappointed. I am less worried about the information I post to a site like Healthcare.gov than I am about online banks. How secure do you think new, production, real-money online banking sites are? Here's a hint: you have more to worry about than open redirects.
Well, that's horrifying too. My point stands, at least from a perspective of moral obligation. I'll grant I'm not optimistic about it working out in real life.
I don't see "having the crap beat out it in production" as a good strategy here
Absolutely. The people who will pay the price for that design philosophy are not the ones making the decision to use that design philosophy.
It really doesn't matter if poor security engineering is the common case, we should expect better from a modern system with the budget of a federal project and the legal requirement that we use it.
Absolutely. The people who will pay the price for that design philosophy are not the ones making the decision to use that design philosophy.
It really doesn't matter if poor security engineering is the common case, we should expect better from a modern system with the budget of a federal project and the legal requirement that we use it.
I hope I don't sound like I'm sticking up for the procurement process that generated this site. The site was bought was, I'm sure, a pile of poop. I just have trouble with people's utterly unrealistic expectations of how security works in real applications. Forget Healthcare.gov; I mean real applications, ones people rely on every day.
Nothing is secure from the start. Everything has bugs.
Nothing is secure from the start. Everything has bugs.
Nothing is secure from the start. Everything has bugs.
Sure, all aspects of programming are subject to bugs. My concern with the site is an apparent lack of design for security. Admittedly the linked article only talks about symptoms, I'm inferring poor design from a previous article which said the developers put security at the bottom of the list of priorities.
Sure, all aspects of programming are subject to bugs. My concern with the site is an apparent lack of design for security. Admittedly the linked article only talks about symptoms, I'm inferring poor design from a previous article which said the developers put security at the bottom of the list of priorities.
That was my immediate reaction. I'm glad to hear it from an expert in the field of security.
Hearings like this tend to be partisan by their very nature, and committee members can and will cherry-pick the experts whose testimony makes the best headlines. I lost any expectation I had that this would be a fruitful inquiry when they had Kathleen Sebelius up and most of the questions were along the lines of "why did Obama do this?" "why did Obama say that?" "what did Obama know about this other thing?" as opposed to, say, "what went wrong with the website?" "what are you doing to fix it?" and "how can we stop this from happening again?"
Hearings like this tend to be partisan by their very nature, and committee members can and will cherry-pick the experts whose testimony makes the best headlines. I lost any expectation I had that this would be a fruitful inquiry when they had Kathleen Sebelius up and most of the questions were along the lines of "why did Obama do this?" "why did Obama say that?" "what did Obama know about this other thing?" as opposed to, say, "what went wrong with the website?" "what are you doing to fix it?" and "how can we stop this from happening again?"
The story reads like "Area Consultant Advises Government To Pay Exorbitant Fees For His Services".
'tptacek is right, for the most part. Regardless of what issues may or may not have been found, most developers don't think of security at the start or "bake it in." We've been trying to make it incredibly easy to do that, and our customers love it, but it is definitely not the norm.
Hopefully one day it will be.
Hopefully one day it will be.
The people doing the laughing shouldn't be allowed near government. I was one of thousands whose personal information was "lost" by the Canadian government this year, and I wasn't laughing. http://www.ctvnews.ca/canada/hrsdc-apologizes-for-losing-per...
There ought to be a version of the precautionary principle for private information: if a contractor can't prove they have made efforts to secure personal information, they shouldn't be working for government.
There ought to be a version of the precautionary principle for private information: if a contractor can't prove they have made efforts to secure personal information, they shouldn't be working for government.
Get used to banking using those weird drive-up pneumatic tubes then, because nobody's going to be allowed to stand up a retail banking app.
In a project this convoluted...not in terms of actual feature complexity, but the shitwork that was generated by bureaucracy and political infighting...how could Healthcare.gov not have serious issues with XSS and SQL?
Think back to Egor Homanov's amazing hack of Github using a Rails vulnerability to well-known to Rails core team that argued it was not an issue because only fools wouldn't use attr_protected. Github has brilliant programmers and (one would hope) a well-oiled engineering environment and still was vulnerable to this fatal flaw.
Now imagine a project with far lesser engineers, highly paid but no real ownership, controlled by people who care more about political deadlines than actual functionality. And top it off with what seems like a hodgepdoge of arcane technology and processes. How could there not be at least a few catastrophic holes?
On a sidenote...I've seen a few references to "MarkLogic" being the datastore for Healthcare.gov. It's not open-source and has little adoption in the developer community:
http://slashdot.org/story/13/11/24/1437203/nyt-healthcaregov...
Whose genius idea was it to use a non-notable proprietary database software for this? And what was the reasoning? Technical, or political?
Think back to Egor Homanov's amazing hack of Github using a Rails vulnerability to well-known to Rails core team that argued it was not an issue because only fools wouldn't use attr_protected. Github has brilliant programmers and (one would hope) a well-oiled engineering environment and still was vulnerable to this fatal flaw.
Now imagine a project with far lesser engineers, highly paid but no real ownership, controlled by people who care more about political deadlines than actual functionality. And top it off with what seems like a hodgepdoge of arcane technology and processes. How could there not be at least a few catastrophic holes?
On a sidenote...I've seen a few references to "MarkLogic" being the datastore for Healthcare.gov. It's not open-source and has little adoption in the developer community:
http://slashdot.org/story/13/11/24/1437203/nyt-healthcaregov...
Whose genius idea was it to use a non-notable proprietary database software for this? And what was the reasoning? Technical, or political?
I don't have the reference handy, but I recall an article from this past Summer that said the designers of the site had put security on the back-burner. Their plan was to get the system working and worry about security afterwards.
That really alarmed me. Being more than a little involved with security implementations over the last decade, the #1 rule is that you can't tack-on security afterwards. If you try, it will be fragile and ultimately ineffective. You absolutely must design with security as a major requirement from the start.
So, I am not surprised to see this report, it lines up exactly with what I've been expecting since Summer.
That really alarmed me. Being more than a little involved with security implementations over the last decade, the #1 rule is that you can't tack-on security afterwards. If you try, it will be fragile and ultimately ineffective. You absolutely must design with security as a major requirement from the start.
So, I am not surprised to see this report, it lines up exactly with what I've been expecting since Summer.
>According to the Department of Health and Human Services, which oversaw the implementation of the website, the components used to build the site are compliant with standards set by Federal security authorities.
This sounds similar to saying the steel plating on the Titanic was compliant with industry standards. All because you have sound components doesn't mean they will result in a sound product. Unfortunately, I don't expect many people outside this industry will realize how hollow this statement is.
This sounds similar to saying the steel plating on the Titanic was compliant with industry standards. All because you have sound components doesn't mean they will result in a sound product. Unfortunately, I don't expect many people outside this industry will realize how hollow this statement is.
You'd think by now someone would have done a weekend project open-source version of this site. I wonder if the specs are available (I have no idea how involved the site actually is, but surely it's not 500M LOC worth.).
I think you may have misunderestimated the scope of this "site." To be fair, you'd be in pretty good company with many people in the Administration.
The following would not be easy to complete during your weekend:
1) HIPAA compliance
2) Verifying income against IRS records to determine eligibility for subsidies.
3) Automatically forwarding gathered information to insurers, in a patchwork quilt of formats, many of which are under-specified
I believe one could get to at least two dozen requirements which are similar in complexity to the above three without breaking a sweat.
The following would not be easy to complete during your weekend:
1) HIPAA compliance
2) Verifying income against IRS records to determine eligibility for subsidies.
3) Automatically forwarding gathered information to insurers, in a patchwork quilt of formats, many of which are under-specified
I believe one could get to at least two dozen requirements which are similar in complexity to the above three without breaking a sweat.
Also verifying citizenship with DHS, verifying no benefits are currently being received by Medicare, Medicaid or through Veterans Affairs. I'm sure a lot more.
It's a nightmare combination of legacy DB integration where if you make one mistake that ends up in an illegal immigrant getting healthcare your ass will be hauled into Congress to testify.
It's a nightmare combination of legacy DB integration where if you make one mistake that ends up in an illegal immigrant getting healthcare your ass will be hauled into Congress to testify.
Yeah... I was somewhat expecting to be told about frustrating complexities only a government can grow. Alas, it is not a project I wish to be anywhere near. Would it be easier to change legislation rather than deal with a mutating creature of obfuscation? (that's rhetorical)
Weekend project of integrating with ancient healthcare mainframes? OK.
I laughed. No first-hand experience, but a buddy of mine has to work on fancy web code that just has to deal with just 1 ancient COBOL backend from an insurance company - he spent over half of his project's time dealing with it. And he was lucky: The original COBOL Programmer was still on the payroll and available for questions!
I've worked on two roughly similar but much smaller projects, one of them with an AS/400 admin who had to be sent documentation on what JSON is (he was "familiar with" XML but hadn't used it before), and another working through a middleman company which had built a reasonably sane API to query a small subset of the offerings of several insurance companies across a particular set of states. Both projects were a huge pain in the ass, and neither of them even required testing for eligibility.
When I think of healthcare.gov, I think of that same pain in the ass multiplied by the large number of states and additional insurance companies involved... as well as testing for eligibility, doing income validation, calculating subsidies... probably some state-by-state regulatory requirements... just the sheer number of external organizations and systems involved boggles the mind.
Frankly, I'm shocked it works even to the extent it does.
Incidentally, the complexity involved in building a site like this for so much of the country is why the ACA was set up for every state to implement their own exchange. Unfortunately, a lot of states didn't pull their weight and now it's the feds' mess to clean up.
When I think of healthcare.gov, I think of that same pain in the ass multiplied by the large number of states and additional insurance companies involved... as well as testing for eligibility, doing income validation, calculating subsidies... probably some state-by-state regulatory requirements... just the sheer number of external organizations and systems involved boggles the mind.
Frankly, I'm shocked it works even to the extent it does.
Incidentally, the complexity involved in building a site like this for so much of the country is why the ACA was set up for every state to implement their own exchange. Unfortunately, a lot of states didn't pull their weight and now it's the feds' mess to clean up.
I'll do it in MS Frontpage for the cost of a sixer of beer and a box of twinkies.
Toss in a bag of M&M's and I'll do up some animated gifs, too.
Toss in a bag of M&M's and I'll do up some animated gifs, too.
The bit about the federal government not being required to alert users to any security breaches is alarming as well.
I guess that's not surprising. But, "monitor your own credit" isn't a risk I'm willing to take just to use a barely functioning website.
I guess that's not surprising. But, "monitor your own credit" isn't a risk I'm willing to take just to use a barely functioning website.
This guy claims SQL injection and XSS.
Where did you see those claims? I would not be amazed to learn that there was SQLI on the site, but I don't see it in his report.
Are you talking about his report to the press earlier in November? He appeared to have been referring to cached search autocomplete terms with SQL syntax in them, evidence of people attempting SQL injection against the site. Which, of course, people would do whether the site was Healthcare.gov or CatBnb.com.
Are you talking about his report to the press earlier in November? He appeared to have been referring to cached search autocomplete terms with SQL syntax in them, evidence of people attempting SQL injection against the site. Which, of course, people would do whether the site was Healthcare.gov or CatBnb.com.
Maybe he didn't, I tried to guess what he meant when he says,
> "Everything from hacking someone's computer so when you visit a website it tries your computer back to being able to extract first names, last names, locations"
at 0:24 and guessed XSS + SQLI but I could be wrong about the SQLI now that I'm paying closer attention to how he phrased it.
> "Everything from hacking someone's computer so when you visit a website it tries your computer back to being able to extract first names, last names, locations"
at 0:24 and guessed XSS + SQLI but I could be wrong about the SQLI now that I'm paying closer attention to how he phrased it.
Dave Kennedy is a reputable source of security info. If he claims something, I would be inclined to listen.
[deleted]
"Poking and prodding" can get them in legal hot water. I understand (and please correct me if I am wrong) Only NSA legally, are allowed to "poke and prod sites". Well, and I guess by legally you can interpret that as "they are legally allowed to" or "nobody is really prepared to tell them no".
Anyway, a lot of anti-hacking laws are written that "poking and prodding is not benign" admitting to too many details of that on national media might be a case of bad judgement.
Anyway, a lot of anti-hacking laws are written that "poking and prodding is not benign" admitting to too many details of that on national media might be a case of bad judgement.
Get who in hot water? The botnets that continually, around the clock 365 days a year "poke and prod" nearly every IP address that responds to port 80 or 443?
David Kennedy, they guy who just admitted it on TV?
> The botnets that continually, around the clock 365 days a year "poke and prod" nearly every IP address that responds to port 80 or 443?
If you can find an operator that confesses it publicly. How many do it? Pretty sure if say Vasile Bogdan from Bucharest, calling CNN confessing he just broke into Bank of America CC processing center, he might find himself on Interpol's most wanted list.
> The botnets that continually, around the clock 365 days a year "poke and prod" nearly every IP address that responds to port 80 or 443?
If you can find an operator that confesses it publicly. How many do it? Pretty sure if say Vasile Bogdan from Bucharest, calling CNN confessing he just broke into Bank of America CC processing center, he might find himself on Interpol's most wanted list.
You are very wrong. Poking and proding is completely legal and isn't going to send anyone to jail.
He's not performing a full pen-test on the site. He's not looking to get a shell. He's just checking out best practices. Is there an HSTS header? Is my input validated? etcetc.
The main hacking law that applies here is the CFAA and Dave definitely isn't violating it. To violate it you have to access something you're not allowed to. Nobody will EVER go to jail for an XSS or the types of things he's poking around for. This is because the computer the code is running on is his own....
He's not performing a full pen-test on the site. He's not looking to get a shell. He's just checking out best practices. Is there an HSTS header? Is my input validated? etcetc.
The main hacking law that applies here is the CFAA and Dave definitely isn't violating it. To violate it you have to access something you're not allowed to. Nobody will EVER go to jail for an XSS or the types of things he's poking around for. This is because the computer the code is running on is his own....
Reflected XSS testing can easily end up disrupting the whole site for every user; all it takes is for input to some endpoint to get stored and replayed across the site. Relying on the idea that any kind of active testing against a site you don't own is safe, technically or legally, is a bad idea.
Reflected XSS? Do you mean stored? If Dave is testing for reflected XSS he's going to be alert(1)'ing or using img tag....Which is not a persistent xss...
For reflected xss to affect every user on the site he's going to have to use his own toolkit to send a malicious link to every user on the site....
For reflected xss to affect every user on the site he's going to have to use his own toolkit to send a malicious link to every user on the site....
I mean reflected. The kind you don't expect to get stored. If that's a surprise to you, you might not test a lot of websites, because this comes up somewhat regularly.
By the way, the XSS payload has nothing to do with the persistence of the attack. You alert() stored XSS in testing too.
By the way, the XSS payload has nothing to do with the persistence of the attack. You alert() stored XSS in testing too.
I do test a lot of websites actually but I mis-understood what you meant.
Like the other guy said this area is grey. If he accidentally finds a stored xss of the magnitude you suggest I'm 100% sure he still wouldn't go to jail. Who tests with a malicious payload? There would be no malicious intent in the situation and no unauthorized access...still.
Like the other guy said this area is grey. If he accidentally finds a stored xss of the magnitude you suggest I'm 100% sure he still wouldn't go to jail. Who tests with a malicious payload? There would be no malicious intent in the situation and no unauthorized access...still.
You didn't say this was a grey area. You said "Nobody will EVER go to jail for an XSS" and then cited the CFAA as evidence of that fact, suggesting that you might have some minor gaps on how XSS works and that you definitely have major gaps on how CFAA works.
Pro-tip: avoid stringing "Nobody will EVER go to jail for" and "CFAA" together in the same paragraph.
Pro-tip: avoid stringing "Nobody will EVER go to jail for" and "CFAA" together in the same paragraph.
Let me rephrase. Nobody will go to jail for the level of poking and prodding I expect Dave is trying. I'm 100% sure the CFAA won't send anyone to jail for alert(1)
My 100% is a gut feeling. I'll quit computers if I'm wrong
My 100% is a gut feeling. I'll quit computers if I'm wrong
I doubt anyone is going to get in trouble over the PDF report I read about Healthcare.gov, but that's not why I'm commenting.
I am probably somewhat wrong, not very wrong. It depends on what "poking and prodding means". That is why I said, it _can_ get him in legal hot water.
Even port scanning was not always a free pass. Around 10+ years ago there were a couple of court cases that revolved around it. Luckily the judge ruled in favor of the defendant. But what if it was an SQL injection, or what if he did a GET request and obtain the list of plain text passwords, what if he pinned the CPU to 100% by testing one of the vulnerabilities. That is not 100% clear cut.
Even port scanning was not always a free pass. Around 10+ years ago there were a couple of court cases that revolved around it. Luckily the judge ruled in favor of the defendant. But what if it was an SQL injection, or what if he did a GET request and obtain the list of plain text passwords, what if he pinned the CPU to 100% by testing one of the vulnerabilities. That is not 100% clear cut.
It's not 100% for a nobody like theboss but I can 100% guarantee you the FBI isn't going to come after Dave of all people...an extremely well-respected, knowledgeable, former-NSA employee...
I hope not, personally I am on his side as well. But the govt, especially the executive branch, is not a stranger to vindictiveness and petty agenda following prosecutions.
This'd be a great use case for a bug bounty. It's a situation where you have tons of bugs[1] and tons of cash to pay out a bounty. It'd probably be cheaper to open source all the code and hire one full time person to manage the bounty program then whatever they're trying out right now.
[1]: Pure speculation as I have neither used the site or looked at the code but I'm assuming most people will agree with me
[1]: Pure speculation as I have neither used the site or looked at the code but I'm assuming most people will agree with me
I'm sure by putting that message out there, we are about to see HealthCare.gov be put to the test...
It has been and will be put to the test by all hat colors regardless of press.
David Kennedy's Bio: https://www.trustedsec.com/about-us/leadership/
His bio said he spoke at Black Hat. I can't find anything listed by him except for an "Arsenal" talk, which is a lightning talk people can give about open-source tools they've written. Can someone find a real BH talk this guy has given?
Under his site's "Presentations" section (https://www.trustedsec.com/downloads/presentations/), it lists this talk...
"July 2010 – Blackhat and Defcon Presentation on PowerShell" (http://www.trustedsec.com/files/PowerShell_Defcon.pdf)
"July 2010 – Blackhat and Defcon Presentation on PowerShell" (http://www.trustedsec.com/files/PowerShell_Defcon.pdf)
Thanks. Yep, that counts.
The guy co-authored Metasploit: The Penetration Testers Guide book. Doesn't the fact that you're unaware of this prominent person call into question your own credibility?
Exactly why would I be impressed by someone writing a trade press book about a tool someone else wrote?
I know who HD Moore is. I know who Matt Miller is. They started the Metasploit project. Most people in my field know those people. They're famous. HD Moore has, last I checked, a special Metasploit Porsche. It says Metasploit on it, in neon or some shit. (No disrespect to the Metasploitmobile, whatever it is).
Similarly: I know who Gordon Lyon is; he wrote nmap. Everyone knows him.
Who the hell knows the authors of _Nmap In The Enterprise: Your Guide To Network Scanning_? Nobody.
The author of "Metasploit: The Penetration Testers Guide" does not drive a special Metasploit: The Penetration Testers Guide Porsche.
I know who HD Moore is. I know who Matt Miller is. They started the Metasploit project. Most people in my field know those people. They're famous. HD Moore has, last I checked, a special Metasploit Porsche. It says Metasploit on it, in neon or some shit. (No disrespect to the Metasploitmobile, whatever it is).
Similarly: I know who Gordon Lyon is; he wrote nmap. Everyone knows him.
Who the hell knows the authors of _Nmap In The Enterprise: Your Guide To Network Scanning_? Nobody.
The author of "Metasploit: The Penetration Testers Guide" does not drive a special Metasploit: The Penetration Testers Guide Porsche.
No. 'tptacek is a VERY well respected individual within the infosec community. Moreover, if I knew every author or every infosec book, I would have very little time to do anything else.
[deleted]
This is what happens when you build a website with contractors from several different places. Things slip through the cracks, in this case security was one of those things.
[deleted]
Does anyone in California know if you can get a discount on private health insurance if you're currently unemployed (healthy non-smoker) trying to start a business and don't want to sign up for Medi-Cal because the only doctors are far away and crowded?
Also the Covered CA site has an expired security certificate.
Also the Covered CA site has an expired security certificate.
sensationalist headline with little content to back it up
Smart power ™
I see a whole lot of blowhards running their mouths about potential security problems with the site. I've heard of one actual password-reset vulnerability. If the site were completely full of holes like people claim, there would be scores of "security research companies" clamoring to be the first to name them. Yet we're not seeing that. I'm really not buying it.
That's not quite right.
The site does have issues. Naming the vulnerabilities is subject to responsible disclosure. Hypothetically, were Tinfoil Security to find any issues, we would disclose them to the feds and give them ample time to fix the issues (which, for the government, would potentially be months) before we went out publicly to name what the issues were.
The site does have issues. Naming the vulnerabilities is subject to responsible disclosure. Hypothetically, were Tinfoil Security to find any issues, we would disclose them to the feds and give them ample time to fix the issues (which, for the government, would potentially be months) before we went out publicly to name what the issues were.
And the 'bad guys' are likely exploiting anything they've found so far
Like every other piece of software put on the Internet by the government, banks, health care consortiums, arms manufacturers, cat sharing startups or network equipment vendors, Healthcare.gov will achieve some semblance of security over the long term by having the crap beat out of it in production. Hopefully by good people first. They won't get there by starting over on the advice like this.
This story is an embarrassment for my field.
† I found the "report" to Congress; documented vulnerabilities include "undisclosed", open redirects, attacker control over the XML output of a search endpoint, a "test" subdomain on the Internet (no additional findings), Google search results with the token "test" in them (no additional findings), publicly indexed profiles on DATA.HEALTHCARE.GOV (the public dataset site), username enumeration via "this name taken" errors, the fact that they use Experian, the presence of jquery.fileupload.js, and CORS. I'm not sure any of these would even be sev:medium in a Matasano report; many would be sev:info, and a few, like Experian, wouldn't be documented at all.