McAfee Enterprise ATR Uncovers Vulnerabilities in Globally Used B. Braun Infusion Pump

The most important part of any product assessment is a solid understanding of the purpose and function of the product under test. Without this it is simply too easy for research to produce less than meaningful results. Therefore, for this research it is first important to answer these few simple questions. What are infusion pumps? What security research has already been performed?

If we consider the Background section earlier, it becomes apparent there is still a large amount of critical research to be performed in this space. Infusion pumps are a prominent and continuously developing area within the medical device space, where previous research has only scratched the surface. Due to the potential critical impact and the state of medical device security, many previous projects didn’t need to dig very deep to find security issues or concerns. The infusion pump industry has numerous devices which have not been researched publicly at all, and even more that only received a cursory analysis from the information security community. For these reasons, we decided to have an in-depth look at one of the largest infusion pumps vendors, B. Braun, and specifically focus on one of their devices used worldwide to analyze it at a depth never seen before. Tackling every aspect of this pump, we wanted to answer the basic question: In a realistic scenario, leveraging original security vulnerabilities, could a malicious attacker impact human life?

For this research project our system consisted of three main components– a B. Braun Infusomat Large Volume Pump Model 871305U (the actual infusion pump), a SpaceStation Model 8713142U (a docking station holding up to 4 pumps) and a software component called SpaceCom version 012U000050. These models and the corresponding software for the B. Braun Infusomat system were released in 2017. In industries such as consumer electronics, this would be considered obsolete and therefore less relevant to research. However, as discussed above, in the medical field this is simply not the case. Since older devices are still widely used and perhaps originally developed with a less emphasis on security, it increases the importance of investigating them. For due diligence, we consulted and confirmed with our industry partners that this specific model was still actively being used in hospital systems across the country.

SpaceCom is an embedded Linux system that can run either on the pump from within its smart-battery pack or from inside the SpaceStation. However, when the pump is plugged into the SpaceStation, the pump’s SpaceCom gets disabled. We performed most of our research with the pump attached to the SpaceStation as we found this was the most common use case. If a SpaceStation was compromised, it could potentially affect multiple pumps at once. SpaceCom acts as the external communication module for the system and is separated from the pump’s internal operations, regardless of where it is running from.

If we consider the pump attached to the SpaceStation as one system, it has three separate operating systems running on three distinct chipsets. SpaceCom running on the SpaceStation runs a standard version of Linux on a PowerPC chipset. The WIFI module for the SpaceStation also runs a standard version of Linux on an ARM chipset and communicates over a PCI bus with SpaceCom. Lastly, the pump runs its own custom Real Time Operating System (RTOS) and firmware on a M32C microcontroller. An additional microcontroller is used to monitor the M32C microcontroller, but this goes beyond the scope of our research. Due to this modular and isolated design, the Spacecom communication module and the pump need a dedicated path for exchanging data. This is resolved via a CAN bus, shared throughout the SpaceStation, where it allows pumps and accessories to communicate with each other. This is what SpaceCom and any pump docked into the Space Station rely on for their exchange. An architecture diagram below helps demonstrates the system layout and design when a pump is present in the docking station.

Figure 2: System Architecture

SpaceCom contains many different pieces of propriety software and applications to support the many functions of the larger B. Braun and medical facility ecosystem. Our team spent time analyzing each one in great detail; however, for the purpose of this paper we will only touch on key components which are important to the most critical findings mention in the opening summary.

An important function of SpaceCom is to be able to update the drug library and pump configuration stored on the pump. The drug library contains information such as ward and department, a list of pre-configured drugs with their default concentrations, information messages to be printed on the screen when selected, and more importantly, soft, and hard limits to prevent medication error. One of the biggest selling points of the smart infusion pumps is their ability to prevent incorrect dosing of drugs, which is partly done through the limits in the drug library. Another risk the drug library helps mitigate is human error. By having the most common dosage and infusion lengths preprogrammed into the pump, it eliminates errors associated with rate calculations, and drop counting previously mentioned, associated with manual infusion therapy.

The pump RTOS contains a database of over 1500 key/value pairs used during operation. This data consists of everything from status about current components, battery life, motor speed, alarms and values used for tube calibration. As such, this data would be considered extremely sensitive in the context of the pump’s operation and is not intended to have direct user interaction, nor is it presented to the user. A subset of the keys can be indirectly modified via a dedicated servicing software by certified technicians.

Although user access is the first step, root access will be needed in order to interact with the CAN bus to communicate with the actual pump. A good target and well-known process for privilege escalation is to find a binary owned by root with the setuid bit enabled. We could not find one ready to use; however, the web interface has an option to backup and export settings which relies on tarring a folder containing a handful of files and encrypting it with AES using a user-provided password. The backup archive can then be downloaded for later restore of the settings. When restoring this backup, root is the user doing the untarring in such a way that file permissions are being preserved from the provided tar file. Thus, if we can tamper with the archive, we might be able to create a privilege escalation scenario.

To use this to our advantage we need to embed a binary in the backup archive owned by root with the “setuid” bit set so we can use it to elevate privileges. Ironically, the code responsible for the import/export of settings is already doing most of the work for us. The “configExport” binary located on the filesystem is a wrapper to call setuid/setgid (and sanitize inputs) which then calls execve on the script “/configExport/configExport.sh.” We can use a hex editor to change which script the “configExport” binary is running and replace “configExport.sh” with an attacker-controlled script, while also patching out the input sanitizing. We could absolutely have compiled our own binary instead, but this approach saves us from a couple of hours of PPC cross-compiling fun.

The real work begins once root access is obtained. The challenge becomes how to affect change on the pump RTOS with root access on the SpaceCom communication module. One common approach would be to continue to look for vulnerabilities in the pump’s RTOS that would lead to code execution within its system. This method poses many challenges during black box testing and could lead to damaging our limited number of test devices.

Another approach which we have leveraged in past projects is hijacking the standard functionality of the device to further the attack. This can be more manageable, but it first requires a deep understanding of how the device works and the desired outcome. This also tests the device’s defense in depth and can prove to be very difficult depending on the security measures in place. In our case, this would force the question of how well-protected the area is surrounding the communication between the pump and SpaceCom.

As mentioned in the system description section above, the PCS binary is responsible for communicating with the pump’s system for two critical operations – updating the drug library and updating the pump config. These are key functions that would likely be of interest to an attacker. There are several different approaches which could be taken by an attacker to interact with these key operations, especially given root access. Considering the various alternatives, we chose to leverage our root access on SpaceCom to inject code into PCS’s memory and use existing functions and objects to communicate with the pump’s internal system.

Our chosen path required a deep understanding of the data structures and functions used to facilitate this communication. The key is to find the perfect place in a larger operation call stack where we can modify or inject the data we want, while still utilizing lower-level functions to avoid the need to unnecessarily create objects and data from scratch. To illustrate this point, consider if we want to send a simple signal to power off the pump from within PCS’s memory space. The fact that all data sent from SpaceCom to the pump’s RTOS is done through CAN messages, with root access meant that we could send CAN messages directly on the CAN bus. This would require an extensive knowledge and breakdown of the CAN message structure as the underlying protocol is designed by B. Braun and would have to be reverse engineered. Although possible, it is very difficult, especially with CAN’s data frame field having a lack of strict specifications. Inside PCS there is a call chain which builds this message. If we were to inject and utilize functions very low in the call chain, such as the trySend function which sends a CAN message (as seen in figure 4) , we would need to understand all of its arguments and the data format it uses. We’d essentially have the same problem as before.

Figure 4: trySend function

If we look higher in the call stack for a function that performs the operation we are interested in, switching off the device, we can instead let the rest of the call chain do the heavy lifting for us. Notice in Figure 5 below there is a function for just this purpose, which only requires one parameter to be passed.

Figure 5: switchOffDevice

Leveraging this concept, we are able to use the functions within PCS in a manner similar to an API to perform read and write operations to the pump’s database and force a change.

If we want to send and write data such as the drug library and pump config, we first need to understand the format of the data, how it is processed and any security measures in place which need to be accounted for. Our team spent extensive time reversing both the drug library and pump configuration data. A portion of the pump configuration is referred to as calibration and disposable data. Both can be modified through our attack chain; however, for this paper we will just touch on the more critical of the two the calibration and disposable data.

The calibration and disposable data are usually seen in the form of files that are living in SpaceCom. At a more granular level, they are a collection of key/value pairs that are meant to be read or written to the pump’s database. Each file can also be a large blob of data living on the pump flash. The physical location of each key within this blob is hardcoded in the pump and sometimes in PCS. This representation is relevant when it comes to computing various CRCs that operate on blobs of data rather than key pairs. These checksums are used heavily throughout the pump’s infrastructure with critical data to ensure the integrity of the data. This goes to ensure the safety of patients by ensuring data can’t be accidently modified or corrupted. Figure 6 shows an example of disposable data as contained in files on SpaceCom.

Figure 6: Disposable Data

Looking at the variable names inside the disposable data file and relevant code in the pump firmware led us to one key/value pair that specifies the “head volume” of the tube, which can be seen in the figure above. After extensive analysis, we determined that “head volume” is the parameter dictating the amount of medication being delivered per cycle to the patient. We determined that if this value was to be changed, it could be potentially harmful. We detail this analysis in section “Unique Consideration for Infusion Pump Hacking” below.

With a target key/value pair in mind, the next step would be to understand how to calculate the CRCs. Since the system is constantly checking the integrity of the data, if an attacker wanted to modify any value, they would also need to modify the CRCs which validate the changed data. Through reverse engineering we determined the CRC was a custom implementation of a CRC16, where the initial value is 0xFFFF and relies on a hardcoded polynomial table. We were able to extract this algorithm and write custom python scripts to compute the CRC needed for the disposable data.

If we review our attack chain, we can gain user-level access to the device without authentication or authorization. We can then escalate our privileges to root and leverage the existing functionality of the PCS binary to make modifications to the pump’s disposable data. Conceptually, the process is complete; however, we can do some additional housekeeping in order to make our attack chain slightly more realistic and efficient.

Since the proprietary protocol for the PCS binary is unauthenticated, there are certain configuration options which can be modified for an attacker to make their job even easier. One of these configuration options tells the pump which server is “trusted” to receive operational data from (such as the drug library). An attacker can send a command to SpaceCom which clears the current trusted server configuration and rewrites it to an attacker-controlled server. This is not required for this attack when leveraging the format string and privilege escalation path outlined above; however, it does provide alternative methods and simplifies the attack process.

Lastly, the pump has an audible and visual notification when any configuration or drug information has been modified on the pump. Once again in the spirit of a realistic attack, a malicious attacker is going to want to be as stealthy as possible. To accomplish this, it was worth determining a method in which to clear these notifications. This process turned out to be as simple as restarting the pump after our modifications were complete. The reboot operation happens in a matter of seconds, so by using this technique, all alerts to the end user were quickly cleared. The complete attack process can be seen outlined in the diagram below.

Figure 7: Complete Attack Chain

Although this attack chain presents a complete method to modify critical pump data, it is important to recognize the conditions required for this attack to be successful. These pumps are designed to be network connected to a local internal network. Therefore, under normal operating conditions an attacker would need to have found a method to gain access to the local network. Could this attack take place over the internet? Technically speaking, yes; however, it would be very unlikely to see a setup where a pump is directly internet-connected.

In addition to being on the local network, the pump does have safeguards in place to ensure no modifications can occur while the pump is operational. From what we discovered during our research, if the pump is actively administering medication, it ignores any request on the CAN bus to modify library or configuration data. This means the attack can only be successful when a pump is idle or in standby mode in between infusions.

The prerequisites for this attack are minimal and are not enough to mitigate the overall threat. In today’s world there are a wide range of documented and utilized methods for attackers to gain access to local networks. If we also consider that hospital or medical facilities are generally public places with little to no barriers to entry, it is easy to see how someone malicious can go unnoticed and obtain network access. Pumps are also not always actively administering mediation. Even in the busiest of hospitals there is downtime between patients or times when pumps are simply not in use.

With the ability to modify disposable and configuration data on the pump, there are a wide range of possibilities for which an attacker could choose to have an impact. An attacker could simply put the device in an unusable state or write arbitrary messages on the screen. We chose to focus on the disposable data, specifically the key/value pair labeled “TUBE_HEADVOLUME_A” since we determined it would demonstrate the greatest impact, bringing harm to a patient. In the below video you will first see the pump under normal operation. After demonstrating the system working as intended, we modify the configuration remotely using the attack chain explained above and then illustrate its effect on the pump when administering medication.



An interesting characteristic of this project is that its impact and consequences are inherently grounded in the physical world. Where common software hacks end with the ability to get root access or kernel privileges, in this project, the way the device is used by medical staff and how it can affect patient safety is crucial to the outcome. The next few sections will focus on various aspects of the project that fall under this umbrella.

As described previously, our attack relies on modifying the disposable data that governs the way the pump is used to deliver medication. But why and how did we decide to go investigate this? An interesting side-effect of the pump being built to be safe is that most of the inputs and outputs it receives from the CAN bus are extensively checked against out-of-range access. From an attacker’s perspective who has already compromised SpaceCom, this would usually be the prime target for memory corruption bugs. Fuzzing and emulating the M32C architecture is cost-heavy in terms of upfront work, so instead, we started looking for a path of least resistance and searched for blind spots in the secure design.

In our case, we wanted to be able to affect the amount of drug being dispensed, preferably without having something on screen as that would indicate a malfunction or abnormality. Our original plan was to tamper with the device drug library, but it turns out that data we could alter would be displayed on screen, which could raise concern as medical staff verify the prescribed drug and rate against the order before, and immediately after starting the infusion. This would not be ideal for an attacker, so we kept investigating. The other files we could modify were the calibration data and the disposable data. These files are interesting as they describe internal parameters; the calibration one specifies the physical parameters of the device itself, while the disposable one is for the specifics regarding the tubing going through the pump. Anyone familiar with precision tools know how important a good calibration is. If the calibration is off it will lead to improper operations or results. From an operational standpoint this makes sense, but from an attacker perspective this has a strong likelihood of fitting the bill for the attack we had in mind: modifying an internal value so the pump thinks it is dispensing the right amount of drug, while it is actually incorrect in its calculations.

Looking at the variable names inside the disposable file and relevant code in the pump firmware led us to one that specifies the “head volume” of the tube. From our understanding, each time the pump pumps, it compresses the IV tubing thereby pushing a small quantity of drug towards the patient. Overall, there are many physical parameters that would govern this volume –the internal tube diameter, the length of the compressed region, how much the tube is being compressed, etc.—but in the end, it seemed that all these values were summed up in one variable. Cutting this value in half would make the pump believe it is pushing half the actual amount, and therefore would have to pump twice as fast to deliver it. We tried our hypothesis, and by doing so, the amount of drug dispensed doubled while the pump assumed everything was normal.

Let’s now take a step back and consider some generic shortcomings that became apparent while looking at the infusion pump ecosystem. We believe these problems are not specific to a brand or a product but rather may be found across the entire medical field. This is because throughout the years, this vertical has only received a limited amount of attention from both malicious actors and the cybersecurity industry.  With the increased rate of cyber threats and the constant additions of new smart devices in private networks, new attack surfaces are being exposed and the hardening of many systems may turn into low hanging fruits for the ones lagging. The slower life cycle of smart medical devices means that best security practices and mitigations take longer to be adopted and deployed in the field. Awareness of this may help healthcare organizations, and their supporting IT administration have a more critical eye on the technology deployed in their environments while medical device vendors should remain vigilant of their “legacy” technologies and continually reassess the risk profile associated with legacy products in the current cybersecurity landscape.

Consumer products, both hardware and software are often nimbler than their counterparts in the medical industry. Your web-browser or operating system on your personal computer will auto-update immediately after a patch is released which come on a regular basis. This is radically different for medical devices which are often directly linked to patient safety and therefore need to undergo a more rigorous vetting process before applying updates. This often leads to the need to immobilize devices during updates, perform follow up tests and recalibrations. It is often very expensive and challenging for medical facilities to update products, resulting in deployed devices with firmware that is several years old. Because of this, “table stakes” security measures may never be fully adopted, and corresponding vulnerabilities may have a larger impact than in other industries.

When looking at the general architecture of the pump, it is obvious that it was designed with safety in mind. For instance, it relies on an application processor for the main processing but also has a control processor that makes sure nothing unexpected occurs by monitoring sensors output along with other components. Everything is CRC checked multiple times to flag memory corruption and every range is bounds-checked. All of this suggests that the design was intended to mitigate hardware and software faults, data accidentally being corrupted over the wire, and the flash module degrading which aligns with a high priority on safety.

However, it looks like preventing malicious intent was not given as much attention during the design process. Sometimes the difference between safety and security might be a little blurry. Preventing accidental memory corruption and out of bounds access due to faulty hardware will also make exploitation harder, yet an attacker will always attempt to escape these mitigations. Along the same lines, logic bugs that would be extremely unlikely to occur by chance might be the “keys to the kingdom” for an attacker. Internal audits and offensive security exercises can highlight the attacker mindset and bring valuable insights as how to harden existing safeguards to protect against intentional threats.

Originally, the CAN bus was reserved for communication between trusted components such as a Servicing PC used for maintenance or for connecting multiples devices within an older model of the Space Station that did not have SpaceCom built in. The latter would come as an optional module that could be plugged into the Space Station to offer external connectivity. Hence, the CAN bus was used for “internal” communication between trusted components and an external module, the SpaceCom, could be added for data reporting over the network. Over the following decade, technology improved and miniaturized to the point where everything got merged, so that even a battery module could provide WIFI connectivity and the SpaceCom functionalities. This opened new possibilities, such as having the built-in SpaceCom module provide similar capabilities as the servicing PC. From a user perspective this is great as it simplifies operations, but from a security perspective, this created a situation where a “trusted” internal network suddenly became bridged to an external network that could even be accessed wirelessly. What might have been an acceptable risk, where only a few proprietary devices with physical access could perform privileged operations, became much more questionable when a WIFI-connected Linux device started to offer the same capabilities.

This kind of problem has been faced by nearly every industry vertical that evolved from reliance on trusted physical networks which suddenly got connected to the internet or other untrusted networks. Smart connected devices are a double-edged sword: in the same way they offer greater flexibility and synergy between systems, they can also lead to emergent security issues that need to be considered holistically.

When developing custom protocols and ad-hoc systems it’s natural to incur technical debt. This is even more true when the life cycle of a device is many years and when it is complicated and expensive to deploy patches and upgrades, leading to a heterogeneous customer base and multiple hardware revisions to support. This can cause situations where more obscure features are not looked at for years and their ownership might be lost or perfunctory. An example of this is the format string vulnerability affecting the json-dbus module. Its usage is obscure, and it was forked from an open-source project many years ago. The original repository fixed bugs that were security bugs but were not flagged as such which led them to fly under the radar for multiple years. Likely, at the time it was forked, the code served its purpose and was never revisited afterwards, leaving the security bug unnoticed. The same can be said for custom-designed protocols and file formats. It may be difficult to evolve them in line with the improvement of best security practices while avoiding breaking “legacy” deployments. In this scenario, mitigations might be the way to go; making sure the systems are isolated, unnecessary features can be disabled and their privilege and access limited to what’s needed. Future-proofing a system is a difficult challenge. If anything, transparency on how the system functions and the components it relies on, coupled with regular audits (code source review or black box audit) can help prevent components from falling in the cracks where they’re not checked against best practices for many years.

This concludes a research project which took two senior researchers a significant amount of time to showcase a life-threatening risk of a medical device being taken over by a remote attacker. For the time being, ransomware attacks are a more likely threat in the medical sector, but eventually these networks will be hardened against this type of attacks and malicious actors will look for other lower-hanging fruits. Given the lifespan of medical devices and the difficulties surrounding their updates, it is important to start planning now for tomorrow’s threats. We hope this research will help bring awareness to an area that has been a blind spot for far too long. Dr. Nordeck affirms the importance of this research stating: “The ability to manipulate medical equipment in a way that is potentially harmful to patients, without end-user detection, is effectively weaponizing the device and something only previously conceived by Hollywood yet, McAfee’s ATR team has confirmed is plausible. Device manufactures clearly aim to produce safe and secure products as evidenced by built-in safeguards. However, flaws may exist which allow the device to succumb to a ransom attack or potentially cause harm. Therefore, manufactures should collaborate with security professionals to independently test their products to detect and correct potential threats and thereby preserve patient safety and device security.”

Performing regular security audits, making it easier for medical professionals to keep their devices up to date and offering solid mitigations when this is not possible should really be on every medical vendor’s list of priorities. Medical professionals, policy makers and even the general public should also hold accountable the medical vendors and have them clearly articulate the risk profile of the devices they sell and demand better ways to keep their device secure. We recognize even with this mindset and a holistic approach to security, there will always be flaws that cannot be predetermined. In these cases, vendors should encourage and even seek out industry partners, embrace responsible disclosure and communicate broadly with researchers, stakeholders and customers alike.

From a security research perspective, it is crucial to understand how a device works at a holistic system level, and how each component interacts with each other, which components they can talk to, and so on. For manufacturers, it is important to read between the lines; something may not be in a design document or in the specifications, but sometimes emergent properties will occur as a side-effect of other design decisions.

An offensive project like ours is really meant to highlight structural weaknesses and point out risks. Now, defensive work is necessary to address these concerns. For instance, manufacturers should leverage cheaper and more powerful microcontrollers to implement proper authentication mechanisms. However, it is even more important to study and address the challenges hospitals face when it comes to keeping their devices up to date. This should come as both technical solutions from the vendors and advocacy to promote secure practices and raise awareness on the underlying risks associated with critical devices having outdated software. The FDA tried to lead the way in 2018 with its CyberMed Safety (Expert) Analysis Board (CYMSAB), but so far little progress has been made. The work the German BSI did with the ManiMed project is also extremely encouraging. We see this as an area of cybersecurity with lots of potential and need for attention and look forward to the information security industry taking on this challenge to make this critical sector always more secure.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. As per McAfee’s vulnerability public disclosure policy, McAfee’s ATR team informed and worked directly with the B.Braun team. This partnership resulted in the vendor working towards effective mitigations of the vulnerabilities detailed in this blog. We strongly recommend any businesses using the B.Braun Infusomat devices to update as soon as possible in line with your patch policy and testing strategy.