If you work in the healthcare industry, you may have heard about a family of vulnerabilities called “SweynTooth.” Researchers from Singapore first discovered the vulnerabilities in 2019. After waiting 90 days to announce them, which is part of the responsible disclosure process, they published a technical paper. If you are not familiar with the SweynTooth family, you should still be aware of it considering the flaws could enable attackers to compromise some medical internet of things (IoT) devices that are being used in hospitals today (i.e., blood glucose meters, inhalers and certain pacemakers).

While the affected devices use Bluetooth Low Energy, the SweynTooth vulnerabilities do not stem from the Bluetooth chips themselves. They arise from flaws in the software development kit used during the manufacturing phase. Software development kits guide engineers as they build devices. For example, the kits explain how to integrate chips into the device. In the case of SweynTooth, the vulnerabilities are in the software libraries that come with the kit.

Hospitals and their patients are the main SweynTooth victims. Neither party has visibility into if vulnerabilities were introduced during the manufacturing process. Fortunately, in this case, the vulnerabilities are fixable, and in most circumstances are not life-threatening.

A Deeper Look at SweynTooth

To learn more about the potential impact of SweynTooth and what hospitals should be doing to prevent a compromise, I spoke with our X-Force Red Hacking Chief Technology Officer Steve Ocepek and physician and Director of Cybersecurity Advisory Services at The AbedGraham Group, Dr. Saif Abed. Steve and Dr. Abed analyzed the vulnerabilities to gain a better understanding of how they work and the damage they could potentially cause.

Abby: Thank you for joining me today, Steve and Dr. Abed. First and foremost, how worried should hospitals and patients be about the SweynTooth family?

Steve: Abby, in X-Force Red, we often analyze these vulnerabilities from an attacker’s perspective. One of the more problematic outcomes, as detailed by the researchers, is a security bypass condition. Only one documented vulnerability describes this condition, but it could allow attackers to bypass the secure pairing, which is when you pair a device with an application on your phone, and a set of “challenge” questions pop up to verify the user is really you. Because of these vulnerabilities, attackers could pair their mobile application with an affected medical IoT device and bypass the challenge questions. They could then deadlock the device, control it or get data from it. From an attacker’s perspective, this seems very problematic, but working with AbedGraham helps us to see the bigger picture in terms of clinical risk.

Abby: That is where AbedGraham’s COFR Approach™ comes into play, right? Per my past blog post, to decipher how much damage a vulnerability could cause, hospitals need to consider the clinical, organizational, financial and regulatory impact. Correct, Dr. Abed?

Dr. Abed: Yes, Abby. In this case, we mainly want to focus on the clinical, organizational and technical impacts. How would a device compromise affect patients and the hospital’s processes and people around them? And, how would a compromise affect the device and the rest of the infrastructure connected to it? For SweynTooth, my biggest concern is if an attacker were to make the device unavailable or affect its integrity in terms of how it behaves. For a blood glucose meter or an inhaler, a compromised device should, in most cases, be easy to replace. It should not be a life or death situation. A pacemaker, on the other hand, can be catastrophic, although you have to consider the likelihood of an attacker targeting it.

Abby: How likely would it be for an attacker to exploit these vulnerabilities?

Steve: From the technical side, we have not seen any weaponization of the vulnerabilities other than the sample exploit code that was shared. It is not complex to exploit the vulnerabilities; however, you would have to physically be within a short distance from the device or have a well-tuned antenna and amplifier that’s pointed at the device from afar. Arguably, if attackers are that close to a device, there are many other ways they could cause harm.

Dr. Abed: Based on Steve’s analysis, the context of where the vulnerabilities could enable an attacker to kill someone is highly unrealistic. In most cases, it will not be a life or death scenario. Although, if you are a healthcare provider and you are buying devices or prescribing them to patients, then you should still care. You are buying solutions which may have intrinsic vulnerabilities that could affect their utility, and in rare instances, may have a detrimental impact to the health of your patients. However, should the general public be concerned that their devices will kill them? No.

Abby: So, what should hospitals be doing to minimize the risk of a compromise?

Steve: First, update your devices. Some of the SweynTooth vulnerabilities have patches. Those can be applied when updating the device (patch information is here). This is also an opportunity to hold manufacturers accountable and find out how seriously they are taking security. What is their position on security as a manufacturer? There needs to be a two-way conversation between healthcare providers and device manufacturers. Talk to the manufacturer to get a clear answer. Each affected device should be patched. Some vendors will proactively notify healthcare providers and send out patches with step-by-step directions on how to make changes. Others will ignore the vulnerabilities entirely. Would you want to do business with that latter group? It’s time to assess your vendors and determine if they are responsible partners.

Dr. Abed: More and more devices are becoming IoT devices, and that means we are going to detect more vulnerabilities. This is just the first wave. Right now, from what we see, this is not a killer, so we have to avoid “fear, uncertainty and death” hype. However, over time it is inevitable there will be vulnerabilities in other types of devices that may carry a more detrimental impact. SweynTooth is a warning of what will come in the future. For manufacturers, many companies have chief information security officers (CISOs). Those security leaders should be making sure their risk analysis processes are in place. You cannot just consider the technical and clinical risk in isolation from each other. You need a process to combine the two. You have to implement a risk analysis methodology that is current and captures the view of the technical and clinical risk so you can justify what to patch first.

Abby: Thank you Dr. Abed and Steve for joining me today. If you are a healthcare provider, you may want to consider implementing a vulnerability management program to help you find and identify devices connecting to the network and the vulnerabilities exposing them and implement a risk-based remediation strategy.

X-Force Red is working closely with The AbedGraham Group, using their clinical security analytics platform, [CCOM2], to provide hospitals a continuous vulnerability management program for medical IoT devices.

Download the recently published IBM Security white paper on medical IoT risk.

More from Software Vulnerabilities

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

MSMQ QueueJumper (RCE Vulnerability): An in-depth technical analysis

13 min read - The security updates released by Microsoft on April 11, 2023, addressed over 90 individual vulnerabilities. Of particular note was CVE-2023-21554, dubbed QueueJumper, a remote code execution vulnerability affecting the Microsoft Message Queueing (MSMQ) service. MSMQ is an optional Windows component that enables applications to exchange messages via message queues that are reachable both locally and remotely. This analysis was performed in collaboration with the Randori and X-Force Adversary Services teams, by Valentina Palmiotti, Fabius Watson, and Aaron Portnoy. Research motivations…

X-Force prevents zero day from going anywhere

8 min read - This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today