Hacker Says He Could Access 70,000 Healthcare.Gov Records In 4 Minutes 351
cold fjord writes with this excerpt from Computerworld: "[W]hite hat hacker David Kennedy, CEO of TrustedSec, may feel like he's beating his head against a stone wall. Kennedy said, 'I don't understand how we're still discussing whether the website is insecure or not. ... It is insecure — 100 percent.' Kennedy has continually warned that healthcare.gov is insecure. In November, after the website was allegedly 'fixed,' he told Congress it was even more vulnerable to hacking and privacy breaches. ... 'Out of the issues identified last go around, there has been a half of a vulnerability closed out of the 17 previously disclosed ... other security researchers have also identified an additional 20+ exposures on the site.' ... Kennedy said he was able to access 70,000 records within four minutes ... At the House Science and Technology Committee hearing held last week ... elite white hat hackers — Kevin Mitnick, Ed Skoudis, Chris Nickerson, Eric Smith, Chris Gates, John Strand, Kevin Johnson, and Scott White – blasted the website's insecurity. ... Mitnick, the 'world's most famous hacker' testified: '... It would be a hacker's wet dream to break into Healthcare.gov ... A breach may result in massive identity theft never seen before — these databases house information on every U.S. citizen! It's shameful the team that built the Healthcare.gov site implemented minimal, if any, security best practices.'"
Every citizen? (Score:4, Interesting)
Re:Every citizen? (Score:5, Interesting)
As I understand it, the system is tied into other federal databases. Just because you haven't signed up, doesn't mean you aren't in one of the other databases that healthcare.gov is connected to.
I can almost imagine how it might be done (Score:5, Interesting)
Disclaimer: I've never been to the site, but I can almost imagine how such a hack might be done, because it's so easy to code a bad webapp:
1. Create an account on the site. /showUserProfile?userID=70001
2. Log in.
3. Notice that your URL ends in something like
4. While still in your session, tweak the URL's userID to some other numbers to see if you can bring another user's profile up. If you can, then:
5. Automate the grabbing of userIDs 1 through 70000 via a Perl/Python/whatever script.
A properly-designed app would validate the authenticated session against any data it was trying to access. A poorly-designed one would not, and so be vulnerable to this sort of attack.
Re:Okay, but... (Score:3, Interesting)
I'm not saying government is more secure, I'm just saying the dangers aren't unique to healthcare.gov.
Re:I can almost imagine how it might be done (Score:5, Interesting)
Yep. I see this all the time. Sometimes it's a little more subtle, though. Like, say, storing that value in a cookie. Most people never look at their cookies, but a web security expert (on either side) is more likely to see the cookies than they are to see the actual site rendering. Or the value might be something that in the abstract is impossible to guess (like 59340341412091985) but if you happen to know your SSN and your birthdate, you might recognize those values in that 17-digit mess (it's even easier if, for example, there's a | character between the parts) and then you can (relatively easily) start guessing other peoples' pairs.
Sometimes it's even more subtle and requires some actual work to get at it, like storing an ID value concatenated with some other garbage like the date in a cookie encrypted with a static key (this one is actually fairly commonly done as a method of generating a token *identifying* the authenticated session, after all, if you don't have the key you can't generate the authentication token, right?). However, if you can guess which bits of that token are the ID (not hard; they're the ones that are the same whenever a given account signs on, but different for every account) you can twiddle the bits and basically brute-force the search space of valid IDs. There are still many ways to make this at least *somewhat* harder to attack, but a lot of developers won't bother... and there are ways to do it *worse*, too, like using an XOR with a constant mask instead of a merely re-using the key with a real cipher.
Re:Okay, but... (Score:5, Interesting)
Two things:
According to the article, the government is not REQUIRED to tell you about hacking attempts. HIPPA and other laws require that they disclose "hacks"
Second, as Sysadmin for a major healthcare company for 9 years, every single "hack" was the loss of a laptop or hard drive. No one ever "hacked" into the systems for access to data beyond the one account they hacked.
Re:Okay, but... (Score:2, Interesting)
At one place I used to work, we had to run our site through an automated testing utility that had over 1000 hack attempts. It found 8 on our site (that had never been hacked to my knowledge). We took care of 6 easily, 1 more without too much effort and finally convinced the powers that be that the 8th one would cost more than they were willing to pay.
Sure, it was a pain, but it really wasn't that hard to secure an additional 7 hack attempts (6 of which I had never heard of, despite all my years in the industry).
It sounds like Healthcare.gov would fail 500 of the 1000.
Re:How do I get clients like this? (Score:5, Interesting)
I get between a few hundred and a few thousand USD for any given contract, and my clients actually expect their software to work. How does one go about getting this much money for a steaming pile of shit?
My first job out of college was working for the Department of Defense as a civilian programmer (I worked for a specific branch of the US military, but I'd prefer not to name it). I can tell you based on what I saw that the answer to your question is "Get a contract awarded to you." My first job was that I was hired to work with a small team trying to finish up a salvage operation on some old IBM hardware that the contractor never completed the project on. We were finishing up making it work after the contractor gave up and gave us the computers. I can't say this with 100% absolute certainty, but the senior guy on the project insisted that the contract got fully paid and the vendor never was sued for giving up on the project without meeting what the project called for. He said they just turned over the computers and the source code for as far as they had gotten and called it a day with Uncle Sam just shrugging his shoulders about it. I learned while working there that literally anything can be justified if it's on a contract. No cost is so high that it can't be justified if it's on a contract between the DoD and a private company. The right wingers unfortunately help to waste US taxpayer money here by insisting that everything there is can be done "cheaper" (ha ha ha) by any private company. Almost all of my DoD career was spent working on various projects where the government reclaimed them from a contractor (sometimes after completion, sometimes when the contractor just gave up on it) and everything was significantly cheaper for us once we took over the projects. So what happens is that unscrupulous vendors bid cheaply on contracts they can't be sure that they can actually complete because they're rarely sued and they can usually get fully paid or close to it for any half-way attempt they make on the project. Nobody on the right ever questions the wisdom of this process because it is "saving money".
Re:Government! (Score:4, Interesting)
I'm guessing the specs didn't include "Allow everyone and his kid brother to access other people's personal information as an aid to identity theft." I'm guessing they also didn't include "Crash all the time" and "Fail to actually allow people to sign up for health care."
Here's how I see this general situation:
1. Government contracts with company C to do task X.
2. Company C, instead of doing X, does the much cheaper Y that looks kind of like X and says they did X.
3. Conclusion: Company C defrauded the government, and should be held liable, as well as removed from any future consideration for any government contract.
4. Second conclusion: If government continues to do business with Company C or failed to sue the pants off of the company for breach of contract, then the government screwed up (or is corrupt).
5. Invalid conclusion: The government screwed up but Company C had nothing to do with it.