With Healthcare.gov plagued by technical difficulties, the Obama administration is bringing in heavyweight coders and private companies like Verizon to fix the federal health exchange, pronto. But web security experts say the Obamacare tech team should add another pressing cyber issue to its to-do list: eliminating a security flaw that could make sensitive user information, including Social Security numbers, vulnerable to hackers.
According to several online security experts, Healthcare.gov, the portal where consumers in 35 states are being directed to obtain affordable health coverage, has a coding problem that could allow hackers to deploy a technique called “clickjacking,” where invisible links are planted on a legitimate web page. Using this scheme, hackers could trick users into giving up personal data as they enter it into the web site, potentially placing Americans at risk of identity theft or allowing fraudsters to file bogus health care claims. And it’s not just the federal exchange that has security problems. Some of the 15 states that have established their own online exchanges aren’t using standard encryption throughout their Obamacare websites—leaving user information at risk.
Here’s the problem: When an American signs up for Obamacare online, they must enter a good deal of personal information to verify identity—including name, Social Security number, phone number, email address, income, and employer—and identifying information for their family members. In the majority of states, Americans will enter this information directly into the Healthcare.gov website.
Kyle Wilhoit, a threat researcher at Trend Micro, a Japanese security software company, studied the Healthcare.gov portal with his security team and found a “moderate risk” for hacking due to an easy-to-fix coding problem that leaves the site vulnerable to clickjacking. Nidhi Shah, who works on research and development for Hewlett-Packard’s Web Security Research Group, found the same problem. This wouldn’t be the first time a federal site experienced coding problems: Earlier this year, SAM.gov, a government contracting award management site, automatically revealed companies’ private data, without a hacker lifting a finger, because of bad coding.
“Common clickjacking would be a popular method to attempt to exploit [the site]” says Wilhoit. “Hackers could use this information in the creation of fake identities, fake credit cards, and fake accounts very easily.” He adds that it’s relatively easy to fix, although the fixed code would need to rolled out on multiple Healthcare.gov pages and potentially state websites as well.
Asked about clickjacking concerns, the Department of Health and Human Services (HHS) referred Mother Jones to this security statement, which says that Americans don’t need to worry: “If a security incident occurs, an Incident Response capability would be activated, which allows for the tracking, investigation, and reporting of incidents.”
Other parts of Obamacare’s tech infrastructure are less vulnerable to attack. Although Healthcare.gov is at risk for clickjacking, sensitive information submitted through the website is not permanently stored in any centralized database (contrary to Republican fears), making it harder for hackers to steal Americans’ data in bulk. Instead, user information is routed through a secure “data hub” to various federal agencies, including the Social Security Administration, where it can be double-checked and verified. Then private insurance companies are directly notified that a consumer has signed up and selected a health care plan.
Experts say that the federal data hub that routes information to federal agencies is fairly secure. “A successful attack against Healthcare.gov would likely be a very well organized and financed attack and be spectacular because it would be so hard and thus so unlikely,” says Christopher Budd, threat communications manager for Trend Micro. Chris Rasmussen, policy analyst for the Center for Democracy and Technology, agrees that the hub is “encrypted and secure.”
Some state Obamacare sites could be significantly more vulnerable than the federal portal. Healthcare.gov site uses a common form of encryption called Secure Sockets Layer (SSL), which prevents information from being intercepted by a hacker after you click “send” (SSL doesn’t defend against most clickjacking). But the 15 states currently running their own independent Obamacare websites do not have explicit instructions from the HHS to use SSL. According to HHS, these states and the District of Columbia, which also has its own Obamacare site, are independently responsible for ensuring that they “develop standards to protect the privacy and security of consumers’ personal information.”
“These state sites…represent more viable targets for direct attack” than the federal data hub, Budd argues. And hackers have been known to target state healthcare programs—last year, over 280,000 Social Security numbers were stolen from Utah’s Medicaid server.
Hawaii, for example, does not automatically use SSL across its entire website, potentially leaving user information vulnerable to hackers—particularly if a visitor to the site is using an open wireless network, such as one at a coffee shop. The same is true with the online health exchanges created by Minnesota and Colorado. Budd notes that attacking state sites “rather than the more fortress-like data warehouse [like the data hub] can be easier to pull off with a greater chance of success.”
Many security experts argue that Healthcare.gov’s code would quickly improve if it was open source—posted publicly for other programmers to examine, adapt, and improve. In fact, the code for the site was originally supposed to be open source. But HHS removed its code from open-source websites after developers complained they had trouble distinguishing which code belonged to which part of the website. Since then, all of Healthcare.gov’s coding mistakes have happened behind closed doors.
