Last updated at Thu, 20 Jul 2017 18:58:22 GMT

The security community is all about the publicizing the horrors of being insecure. The focus has always been on finding the next exploitation, the next vulnerability or the most recent data breach.  Rarely is the focus on how well a company has secured a product or service.  This is especially true in the arena of embedded devices.  It is widely known that I do not use an insulin pump to manage my Type I diabetes, especially after the research that I have published on the security and software failures that I have seen. There is a medical device that I still rely heavily on though, and that is my Dexcom G4 Continuous Glucose Monitoring system. This is a passive electronic system that tracks my blood sugar values and notifies me if they are over or under certain dangerous conditions. It uses a 2.4ghz transmitter and a separate receiver unit that looks similar to pager to accomplish this.

Last month I got a notification from Dexcom that the FDA approved a new firmware update for my Dexcom G4.  This is the first time that I have ever seen a firmware update for any of my Dexcom devices (going back to their first generation product over 8 years ago).  It is also one of the first times I have seen an FDA approval of a firmware update.  I have long been an advocate of medical device vendors being able to support firmware updates.  Many of the security vulnerabilities I have found in my medical device research have not been able to be patched due to medical devices being hard coded with firmware. The Dexcom G4 Firmware is also updateable directly by the user. Obviously as a consumer of this device and as a security researcher I was very intrigued by this.  I set forth to analyze how my device was being updated to verify that the process was secure.

What I found was quite surprising. All too often, I see these scenarios and there is zero concern for security. Typically all network communications are done without encryption. That the firmware code is left out in the open for reverse engineering and tampering. After a day of analysis, I walked away thinking that this was a really well thought out process.  There are three things that I want to point out that impressed me, and that other medical device manufacturers should model going forward.

  1. Firmware Updates: This might seem trivial, but this is one of the first major medical devices I have owned that has the ability for the patient to update the firmware. This is huge.  Far too many vendors are stuck in the mindset that firmware has to be hardcoded.  This really is a detriment when it comes to security, as vendors cannot patch devices that are already in the field and in use.
  2. Encrypted Network Communications: The Dexcom Update tool downloads the firmware from the internet.  It only does this after the device has been connected and validated.  In analyzing the traffic and network calls I found that all the traffic was SSL encrypted. Additionally, when making attempts to proxy that traffic or perform Man-in-the-Middle (MitM) attacks the Update program promptly threw an error and closed.  Not only is Dexcom using encryption, but they are also performing certificate checking and validation. 
  3. Firmware Files: Being a security researcher, I wanted to get my hands on the firmware itself. All too often in my research, access to the firmware image is a treasure of information and potential vulnerabilities. When I went looking for that file though, I did not find one.  Through further analysis (using tools like FileMon and Process Monitor) I found that the firmware was not being written to disk.  While this defensive step is not a silver bullet, it certainly raises the bar on being able to access or modify the firmware.  This is not typically seen, but is a good defensive measure to take in protecting the firmware code.

In the end, I happily updated my Dexcom G4 to the latest firmware. One thing to note is that this firmware had to be approved by the FDA due to the additional medical related features related to the “Artificial Pancreas” research that Dexcom is involved in. If the firmware update was only for non-medical related changes (Example: a buffer overflow vulnerability were patched) then the FDA does NOT need to approve the firmware update, it could go directly out to the patients and owners.  Dexcom deserves to be credited for their attention to security in their devices and being one of the first that I have seen “getting it right”. 

*Note: Dexcom is not a Rapid7 customer, nor is this post sponsored in any way by Dexcom.  Jay Radcliffe's relationship with Dexcom is only as a paying customer and user of the Dexcom system.