One of my interest recently has been what I call "SCADA@Home". I use this term to refer to all the Internet connected devices we surround ourself with. Some may also call it "the Internet of devices". In particular for home use, these devices are built to be cheap and simple, which hardly ever includes "secure". Today, I want to focus on a particular set of gadgets: Healthcare sensors. 

Like SCADA@Home in general, this part of the market exploded over the last year. Internet connected scales, blood pressure monitors, glucose measurement devices, thermometers and activity monitors can all be purchased for not too much money.I personally consider them "gadgets", but they certainly have some serious health care uses. 

I will not mention any manufacturer names here, and anonymized some of the "dumps". The selection of devices I have access to is limited and random. I do not want to create the appearance that these devices are worse then their competitors. Given the consistent security failures I do consider them pretty much all equivalent. Vendors have been notified.

There are two areas that appear to be particularly noteworthy:

- Failure to use SSL: Many of the devices I looked at did not use SSL to transmit data to the server. In some cases, the web site used to retrieve the data had an SSL option, but it was outright difficult to use it. (OWASP Top 10: Insufficent Transport Layer Protection)

- Authentication Flaws: The device does use weak authentication methods, like a serial number. (OWASP Top 10: Broken Authentication and Session Management)

First of all, there are typically two HTTP connections involved: The first connection is used by the device to report the data to the server, in some cases, the device may retrieve settings from the server. The second HTTP connection is from the users browser to the manufacturers website. This connection is used to review the data. The data submission uses typically a web service. The web sites themselves tend to be Ajax/Web 2.0 heavy with the associated use of web services.

The device is typically configured by connecting it via USB to a PC or to a Smartphone. The smart phone or desktop software would provide a useable interface to configure passwords, a problem that is common for example among bluetooth headsets which don't have this option. Most of the time, the data is not sent from the device itself, but from a smartphone or desktop application. The device uploads data to the "PC", then the PC submits the data to the web service. This should provide access to the SSL libraries that are available on the PC. In  a few cases, the device sends data directly via WiFi. In the examples I have seen, these devices still use a USB connection to configure the device from a PC.

Example 1: "Step Counter" / "Activity Monitor"

The first example is an "activity monitor". Essentially a fancy step counter. The device clips on your belt, and sends data to a base station via an unspecified wireless protocol. The base station also doubles as a charger. The user has no direct control over when the device uploads data, but it happens frequently as long as the device is in range of the base station. Here is a sample "POST":

POST /device/tracker/uploadData HTTP/1.1
Host: client.xxx.com:80
User-Agent: 
Content-Length: 163
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Cookie: JSESSIONID=1A2E693AD5B28F4F153EE9D23B9237C8
Connection: keep-alive

beaconType=standard&clientMode=standard&clientId=870B2195-xxxx-4F90-xxxx-67CxxxC8xxxx&clientVersion=1.2&os=Mac OS X 10.7.4 (Intel%2080486%10)

The session ID appears to be inconsequential, and the only identifier is the client ID. Part of the request was obfuscated with "xxx" to hide the identity of the manufacturer. The response to this request:

<?xml version="1.0" ?> 
<xxxClient version="1.0"> 
<response host="client.xxx.com" 
          path="/device/tracker/dumpData/lookupTracker" 
          port="80" secure="false"></response>
<device type="tracker" pingInterval="4000" action="command" >
<remoteOps errorHandler="executeTillError" responder="respondNoError"> 
<remoteOp encrypted="false">
<opCode>JAAAAAAAAA==</opCode> 
<payloadData></payloadData>
</remoteOp>
</remoteOps>
</device>
</xxxClient>

It is interesting how some of the references in this response suggest that there may be an https option. For example in line 5: port="80" and secure="false" may indicate an HTTPS option. 

Example 2: Blood Pressure Sensor

The blood pressure sensor connects to a smart phone, and the smart phone will then collect the data and communicate with a web service. The authentication looks reasonable in this case. First, the smart phone app sends an authentication request to the web service:

GET /cgi-bin/session?action=new&auth=jullrich@sans.edu&hash=xxxxx& 
  duration=60&apiver=6&appname=wiscale&apppfm=ios&appliver=307 HTTP/1.1

The "hash" appears to be derived from the user provided password and a nonce that was sent in response to a prior request. I wasn't able to directly work out how the hash is calculated (which is a good sign) and assume it is a "Digest like" algorithm. Based on the format of the hash, MD5 is used as a hashing algorithm, which isn't great, but I will let it pass in this case.

All this still happens in clear text, and nothing but the password is encrypted. The server will return a session ID, that is used for authentication going forward. The blood pressure data itself is transmitted in the clear, using proprietary units, but I assume once you have a range of samples, it is easy to derive them:

action=store&sessionid=xxxx-4fc6c74e-0affade3&data=* TIME unixtime 1338427213
* ID mac,hard,soft,model
02-00-00-00-xx-01,0003000B,17,Blood Pressure Monitor BP
* ACCOUNT account,userid
jullrich@sans.edu,325xxx
* BATTERY vp,vps,rint,battery %25
62xx,53xx,77xx,100
* RESULT cause,sys,dia,bpm
0,137xx,90xx,79xx
* PULSE pressure,energy,centroid,timestamp,amplitude
x1x4,x220,6xx98,1x60x,x9
x6x9,x450,6xx58,2x58x,x0
x4x9,x086,6xx02,2x12x,x1

(some values are again replaced with "x" . In case you wonder... BP was a bit high but ok ;-)

In my case, the device sent a total of 12 historic values, in addition to the last measured value. So far, I only had taken 12 measurements with the device.

Associated web sites

The manufacturers of both devices offer web sites to review the data. Both use SSL to authenticate, but later bounce you to an HTTP site, adding the possibility of a "firesheep" style session hijack attack. For the blood pressure website, you may manually enter "https" and it will "stick". The activity monitor has an HTTPS website, but all links will point you back to HTTP. A third device, a scale, which I am not discussing in more detail here as it is very much like the blood pressure monitor, suffers from the same problems.

A quick summary of the results:

 I have no idea if HIPAA or other regulation would apply to data and devices like this. Like I said, these are "gadgets" you would find in a home, not in a doctor's office. I also tested a scale that was very much like the blood pressure monitor.  It used decent authentication but no SSL. If you have any devices like this, let me know if you know how they authenticate and/or encrypt.

So how bad is this? I doubt anybody will be seriously harmed by any of these flaws. This is not like the wireless insulin pumps or infusion drips that have been demonstrated to be weak in the past. However, it does show a general disrespect for the privacy of the user's data, and an unwillingness to fix pretty easy to fix problems.

-----
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter