No security ever built into Obamacare site: Hacker
cnbc.com
cnbc.com
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.
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.
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.
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.
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?"
Hopefully one day it will be.
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.
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?
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.
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.
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.
Toss in a bag of M&M's and I'll do up some animated gifs, too.
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.
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.
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.
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.
> "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.
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.
> 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.
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....
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....
By the way, the XSS payload has nothing to do with the persistence of the attack. You alert() stored XSS in testing too.
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.
Pro-tip: avoid stringing "Nobody will EVER go to jail for" and "CFAA" together in the same paragraph.
My 100% is a gut feeling. I'll quit computers if I'm wrong
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.
[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
"July 2010 – Blackhat and Defcon Presentation on PowerShell" (http://www.trustedsec.com/files/PowerShell_Defcon.pdf)
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.
Also the Covered CA site has an expired security certificate.
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.