{"id":90812,"date":"2018-08-11T17:00:03","date_gmt":"2018-08-12T00:00:03","guid":{"rendered":"https:\/\/securingtomorrow.mcafee.com\/?p=90812"},"modified":"2025-05-27T19:58:45","modified_gmt":"2025-05-28T02:58:45","slug":"80-to-0-in-under-5-seconds-falsifying-a-medical-patients-vitals","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/80-to-0-in-under-5-seconds-falsifying-a-medical-patients-vitals\/","title":{"rendered":"80 to 0 in Under 5 Seconds: Falsifying a Medical Patient\u2019s Vitals"},"content":{"rendered":"

The author thanks Shaun Nordeck, MD, for his assistance with this report. <\/em><\/p>\n

With the explosion of growth in technology and its influence on our lives, we have become increasingly dependent on it.\u00a0The medical field is no exception: Medical professionals trust technology to provide them with accurate information and base life-changing decisions on this data. McAfee\u2019s Advanced Threat Research team is exploring these devices to increase awareness about their security.<\/p>\n

Some medical devices, such as pacemakers and insulin pumps, have already been examined for security concerns. To help select an appropriate target for our research, we spoke with a doctor. In our conversations we learned just how important the accuracy of a patient\u2019s vital signs is to medical professionals. \u201cVital signs are integral to clinical decision making\u201d explained Dr. Shaun Nordeck. Bedside patient monitors and related systems are key components that provide medical professionals with the vital signs they need to make decisions; these systems are now the focal point of this research.<\/p>\n

Exploring the attack surface<\/strong><\/h2>\n

Most patient monitoring systems comprise at minimum of two basic components: a bedside monitor and a central monitoring station. These devices are wired or wirelessly networked over TCP\/IP. The central monitoring station collects vitals from multiple bedside monitors so that a single medical professional can observe multiple patients.<\/p>\n

With the help of eBay, we purchased both a patient monitor and a compatible central monitoring station at a reasonable cost. The patient monitor monitored heartbeat, oxygen level, and blood pressure. It has both wired and wireless networking and appeared to store patient information. The central monitoring station ran Windows XP Embedded, with two Ethernet ports, and ran in a limited kiosk mode at start-up. Both units were produced around 2004; several local hospitals confirmed that these models are still in use.<\/p>\n

The two devices offer a range of potential attack surfaces. The central monitoring station operates fundamentally like a desktop computer running Windows XP, which has been extensively researched by the security community. The application running on the central monitoring station is old; if we found a vulnerability, it would likely be tied to the legacy operating system. The patient monitor\u2019s firmware could be evaluated for vulnerabilities; however, this would affect only one of the two devices in the system and is the hardest vector to exploit. This leaves the communication between the two devices as the most interesting attack vector since if the communication could be compromised, an attack could possibly be device independent, affecting both devices by a remote attack. Given this possibility, we chose networking as the first target for this research. Dr. Nordeck confirmed that if the information passing to the central monitoring system could be modified in real time, this would be a meaningful and valid concern to medical professionals. Thus the primary question of our research became \u201cIs it possible in real time to modify a patient\u2019s vitals being transmitted over the network?\u201d<\/p>\n

Setup<\/strong><\/h2>\n

When performing a vulnerability assessment of any device, it is best to first operate the device as originally designed. Tracking vital signs is the essence of the patient monitor, so we looked for a way to accurately simulate those signs for testing. Many hardware simulators are on the market and vary drastically in cost. The cheapest and easiest vital sign to simulate turned out to be a heartbeat. For less than $100 we purchased an electrocardiogram (ECG) simulator on eBay. The following image illustrates our test network:<\/p>\n

\"\"<\/a><\/p>\n

In our test bed, the patient monitor (left), central monitoring station (right), and a research computer (top) were attached to a standard switch. The research computer was configured on a monitor port of the switch to sniff the traffic between the central monitoring device and the patient monitor. The ECG simulator was attached to the patient monitor.<\/em><\/p>\n

Reconnaissance<\/strong><\/h2>\n

With the network configured, we turned to Wireshark to watch the devices in action. The first test was to boot only the central monitor station and observe any network traffic.<\/p>\n

\"\"<\/a><\/p>\n

In the preceding screenshot a few basic observations stand out. First, we can see that the central station is sending User Datagram Protocol (UDP) broadcast packets every 10 seconds with a source and destination port of 7000. We can also see clear-text ASCII in the payload, which provides the device name. After collecting and observing these packets for several minutes, we can assume this is standard behavior. Because the central station is running on a Window XP embedded machine, we can attempt to verify this information by doing some quick reverse engineering of the binaries used by the application. After putting several libraries into Interactive Disassembler Pro, it is apparent that the symbols and debugging information has been left behind. With a little cleanup and work from the decompilers, we see the following code:<\/p>\n

\"\"<\/a><\/p>\n

This loop calls a function that broadcasts Rwhat, a protocol used by some medical devices. We also can see a function called to get the amount of time to wait between packets, with the result plugged into the Windows sleep function. This code block confirms what we saw with Wireshark and gives us confidence the communication is consistent.<\/p>\n

Having gained basic knowledge of the central monitoring station, the next step was to perform the same test on the patient monitor. With the central station powered down, we booted the patient monitor and watched the network traffic using Wireshark.<\/p>\n

\"\"<\/a><\/p>\n

We can make similar observations about the patient monitor\u2019s broadcast packets, including the 10-second time delay and patient data in plaintext. In these packets we see that the source port is incrementing but the destination port, 7000, is the same as the central monitoring station\u2019s.\u00a0 After reviewing many of these packets, we find that offset 0x34 of the payload has a counter that increments by 0xA, or 10, with each packet. Without potentially damaging the patient monitor, there is no good way to extract the firmware to review its code. However, the central monitoring station must have code to receive these packets. With a bit of digging through the central station\u2019s binaries, we found the section parsing the broadcast packets from the patient monitor.<\/p>\n

\"\"<\/a><\/p>\n

The first line of code parses the payload of the packet plus 12 bytes. If we count in 12 bytes from the payload on the Wireshark capture, we can see the start of the patient data in clear text. The next function called is parse_logical_name, whose second parameter is an upper limit for the string being passed. This field has a maximum length of 0x20, or 32, bytes. The subsequent code handles whether this information is empty and stores the data in the format logical_name. This review again helps confirm what we see in real time with Wireshark.<\/p>\n

Now that we understand the devices\u2019 separate network traffic, we can look at how they interact. Using our network setup and starting the ECG simulator we can see the central monitor station and the patient monitor come to life.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

With everything working, we again use Wireshark to examine the traffic. We find a new set of packets.<\/p>\n

\"\"<\/a><\/p>\n

In the preceding screen capture we see the patient monitor at IP address 126.4.153.150 is sending the same-size data packets to the central monitoring station at address 126.1.1.1. The source port does not change.<\/p>\n

Through these basic tests we learn a great deal:<\/p>\n