Many state health care exchanges vulnerable to login theft

Many state health care exchanges vulnerable to login theft

Summary: Research by a forensics firm shows that Wifi users of many state health care exchanges could have their usernames and passwords unknowingly sniffed.

SHARE:

A report on KSTP News, ABC's Minneapolis/St. Paul affiliate, claims that an investigation they conducted has determined that many state-run health care exchanges, are vulnerable to an unspecified "Wifi attack."

Citing work done for them by Computer Forensic Services of Minnetonka, MN, the station says that Wifi users of the vulnerable exchanges could have usernames and passwords sniffed. They specifically name Maryland, DC, New York, Nevada, Hawaii, Colorado, New Mexico and their own Minnesota as vulnerable. They list several other exchanges as not vulnerable: Kentucky, Massachusetts, Rhode Island, California, and Vermont.

The report is silent on any details about the nature of the attack, but we spoke to Mark Lanterman of Computer Forensic Services and got more details. The scenario involves a rogue wireless access point (WAP). On the vulnerable sites, if the rogue WAP strips the 'S' off of an 'HTTPS' link, the site allows the user to proceed with their session, including logging in, buying insurance and changing account settings. Because all the traffic in the scenario is HTTP rather than HTTPS, which is to say it is unencrypted, the access point can capture all the details, including but not limited to the username and password.

When the session is intercepted in this way the user sees HTTP links in the address line of the browser, but this is a subtle point that many will miss. According to Lanterman, on Internet Explorer 11, the browser continued to display the lock icon along with the HTTP link. Safari, Chrome and Firefox did not display the lock.

Lanterman says that this problem is not unheard of on private sites, including banks, but many of the other state exchanges and the Federal exchange (healthcare.gov) handle the situation properly: If you attempt to connect over HTTP to a page for which the site expects HTTPS, the site tells the user that there's a problem and stops the session.

Lanterman adds that, based on their research, if the user manually connects to the site with an HTTPS link, or uses an HTTPS bookmark to do so, the rogue access point can't strip out the HTTPS and the session will continue encrypted and protected. So users in affected states should attempt to make HTTPS bookmarks for the exchange.

The report also includes an odd and clumsy attempt to criticize the Federal exchange for being hosted on Google servers months ago, before rollout. They claim that while Google was hosting the service it was collecting MAC addresses from users for reasons which are unclear. Lanterman says the collection of MAC addresses is unusual, that he doesn't know why they would be collected and that he doesn't see it as much of a concern.

Topics: Security, Government US, Health

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

3 comments
Log in or register to join the discussion
  • Oops!

    Looks like it's time for the state exchanges to take some of the heat. Hopefully, the security issues can be fixed quickly.
    John L. Ries
    • can != will

      This will probably take months to fix.
      frylock
  • Not a "WiFi" attack

    Seems like some grandstanding or sensationalism on this via the media.

    This isn't specifically a WiFi attack as it can be done on a wired network just as easy. (arguably WiFi makes this easier to target people)

    This is probably an attack using the tool SSLstrip. The attacker is man-in-the-middleing the connection and taking advantatge of a weakness in the exchange between the client browser and the server. Overall, if you can be man-in-the-middled on the network you are connected, you have bigger problems.

    As the article indicates, there are many many more sites than the exchanges exposed in this fashion.
    JohnXDz