Category Archives: News

News

The Hidden Risks of Internet of Bodies (IoB): Cybersecurity in Healthcare Devices

Read Time:6 Minute, 50 Second

The content of this post is solely the responsibility of the author.  LevelBlue does not adopt or endorse any of the views, positions, or information provided by the author in this article. 

The Internet of Bodies, or IoB, represents a groundbreaking shift in the healthcare industry, connecting vital health management devices like pacemakers, insulin pumps, and health monitors to the Internet.

While these advancements come with many remarkable benefits, they also expose these essential devices to new cybersecurity vulnerabilities. To help prepare for this remarkable shift, this article addresses the potential risks of IoB devices, highlighting the important intersection and interplay of healthcare and cybersecurity.

An Introduction to the Internet of Bodies

The Internet of Bodies, also known as the IoB, represents a significant leap in healthcare technology as we know it. It integrates connected devices that monitor and interact with the human body.

Its relevance, however, is accentuated by its potential to revolutionize patient care, particularly through remote monitoring and timely medical interventions.

Examples of IoB devices include pacemakers that transmit heart activity data to healthcare providers, insulin pumps that adjust dosage based on real-time glucose levels, and smart health monitors that track vital signs and alert users and doctors to irregularities.

These innovations are important in managing chronic conditions, providing real-time data that enhances patient outcomes and reduces hospital readmissions.

The topic of IoB is particularly timely as advancements in technology and data analytics continue to evolve, promising to improve healthcare delivery and patient experiences significantly. However, it also highlights important issues related to data privacy and security, requiring careful consideration of regulatory and ethical standards to protect patient information.

The Benefits of Utilizing IoB Devices in Healthcare

Utilizing IoB devices in healthcare brings numerous benefits, foremost among them being improved patient monitoring and personalized treatment. These devices help facilitate continuous and personalized patient care.

Improved patient monitoring and personalized treatment are among the primary advantages of IoB devices. These technologies enable real-time tracking of vitals and health metrics so that healthcare providers can customize treatments based on up-to-date information.

For instance, smartwatches used by Kaiser Permanente allow heart attack patients to share their health data continuously, leading to better monitoring and higher completion rates of rehabilitation programs​​.

IoB devices also increase efficiency and accuracy in medical interventions. An example of this are digital pills equipped with sensors that provide precise medication management by transmitting data about ingestion to healthcare providers. These devices help reduce medication errors and improve adherence to prescribed treatment plans​​.

The enhanced data collection and analysis that comes as a result of IoB devices contribute to better health outcomes. The vast amounts of data generated help better understand health patterns and predict potential issues.

As an example, smart thermometers used in Shanghai’s Public Health Clinical Center during the COVID-19 pandemic allowed for efficient monitoring and quick intervention by analyzing temperature data trends.​​​​.

Potential Cybersecurity Vulnerabilities of The IoB

While offering numerous benefits, IoB devices also present the potential to have significant cybersecurity vulnerabilities. After all, these devices are susceptible to various cybersecurity threats that could have dire consequences for patient safety and privacy.

One major threat facing healthcare organizations of all sizes and their IoB devices is the hacking of medical devices. For example, devices can be accessed remotely by malicious actors who might alter their settings, potentially leading to fatal outcomes.

The potential exploitation of these vulnerabilities can occur in multiple ways. For instance, hackers could intercept and manipulate data transmitted by these devices, compromising the integrity of medical treatments and patient records.

As always, connectivity itself is the main culprit. To make things even worse, the main attack vector isn’t a WiFi-equipped X-ray machine or a pacemaker, but the infrastructure of the healthcare provider or manufacturer. If they have a digital asset management system or an internal communication app in place, hackers would target that instead as a means of directly accessing IoB device networks.

Denial-of-service or DoS attacks could disrupt the normal functioning of these devices, leading to treatment delays and jeopardizing patient health. The theft of sensitive health data could also result in detrimental privacy breaches and unauthorized access to personal information.

Addressing each of these respective challenges requires having strong cybersecurity measures in place. Device manufacturers and healthcare providers must prioritize security from the design phase through the entire product lifecycle.

On top of this, implementing stringent encryption protocols, regularly updating software, and conducting thorough security audits are essential steps in mitigating these risks and ensuring the safety of IoB devices and the sensitive data they handle.

The Impact of Attacks on Patient Safety and Privacy

Cyberattacks on IoB devices can have profound consequences for patient safety and privacy in your organization.

Compromised IoB devices can directly threaten patient health by altering the functions of essential medical devices. For instance, hacking into these devices can disrupt their operation, potentially leading to life-threatening situations like incorrect dosage delivery or heart rate irregularities.

The risks to personal health data are significant as well. IoB devices collect vast amounts of sensitive information, which, if breached, can lead to severe privacy violations. Stolen health data can be exploited for identity theft, insurance fraud, or unauthorized access to medical records.

The psychological impact on patients is also substantial, as they might lose trust in the healthcare system and experience increased anxiety and stress over their compromised data security.

Current IoB Security Measures and Their Limitations

Current security measures for IoB devices include encryption protocols, multi-factor authentication, and real-time threat detection. Each of these measures aims to protect the data transmitted between IoB devices and central systems, securing the integrity and confidentiality of sensitive health information.

However, these security protocols have limitations. Despite the implementation of encryption, many IoB devices still lack adequate protection due to weak authentication practices, unpatched vulnerabilities, and the absence of industry-wide security standards.

What’s more, many of these manufacturers, on both the software and the hardware side, don’t even follow security-by-design principles when launching products, which the end user isn’t even remotely aware of. These shortcomings can make IoB devices susceptible to cyberattacks, such as DoS attacks and data breaches.

For instance, weak default passwords and lack of multi-factor authentication can leave devices exposed to unauthorized access and exploitation.

Examples of security breaches illustrate these vulnerabilities. Notably, implantable cardiac devices from St. Jude Medical were found to have essential security flaws that could be exploited to drain the battery or administer incorrect shocks. Similarly, ransomware attacks on healthcare facilities have disrupted patient care, leading to delayed treatments and increased mortality rates.

While we clamor about HIPAA and health data privacy in general, the dream of hosting IoB-harnessed data on local devices is still far-fetched. The average tech-conscious user would love to download their own vitals for the data, store them in Sharepoint or Google Drive as a backup, and have them on a local server.

But, what even the savviest users don’t realize is that the average user cannot ensure HIPAA-like data protections are in place.

Strategies for Enhancing IoB Cybersecurity

To help improve IoB cybersecurity across the board, manufacturers must adopt stringent encryption standards and secure authentication methods. Keeping devices secure involves performing regular software updates and conducting thorough security testing in routine intervals.

Healthcare providers should perform routine security assessments of IoB devices and ensure their staff is trained in cybersecurity best practices. Meanwhile, patients can help contribute by using strong, unique passwords where applicable and keeping their IoB devices updated with the latest firmware.

Keeping Your IoB Devices Safe and Protected

The integration of IoB devices in healthcare holds immense potential for improving patient care through advanced monitoring capabilities and more personalized treatment options. However, this progress brings with it significant cybersecurity challenges that organizations must address.

Maintaining the security of these devices requires a coordinated effort from manufacturers, healthcare providers, and patients alike. As we continue to embrace the future of IoB, maintaining a strong focus on cybersecurity will be essential to realizing its full potential while protecting those who rely on these life-enhancing technologies.

Read More

News

Local Networks Go Global When Domain Names Collide

Read Time:8 Minute, 56 Second

The proliferation of new top-level domains (TLDs) has exacerbated a well-known security weakness: Many organizations set up their internal Microsoft authentication systems years ago using domain names in TLDs that didn’t exist at the time. Meaning, they are continuously sending their Windows usernames and passwords to domain names they do not control and which are freely available for anyone to register. Here’s a look at one security researcher’s efforts to map and shrink the size of this insidious problem.

At issue is a well-known security and privacy threat called “namespace collision,” a situation where domain names intended to be used exclusively on an internal company network end up overlapping with domains that can resolve normally on the open Internet.

Windows computers on a private corporate network validate other things on that network using a Microsoft innovation called Active Directory, which is the umbrella term for a broad range of identity-related services in Windows environments. A core part of the way these things find each other involves a Windows feature called “DNS name devolution,” a kind of network shorthand that makes it easier to find other computers or servers without having to specify a full, legitimate domain name for those resources.

Consider the hypothetical private network internalnetwork.example.com: When an employee on this network wishes to access a shared drive called “drive1,” there’s no need to type “drive1.internalnetwork.example.com” into Windows Explorer; entering “\drive1” alone will suffice, and Windows takes care of the rest.

But problems can arise when an organization has built their Active Directory network on top of a domain they don’t own or control. While that may sound like a bonkers way to design a corporate authentication system, keep in mind that many organizations built their networks long before the introduction of hundreds of new top-level domains (TLDs), like .network, .inc, and .llc.

For example, a company in 1995 builds their Microsoft Active Directory service around the domain company.llc, perhaps reasoning that since .llc wasn’t even a routable TLD, the domain would simply fail to resolve if the organization’s Windows computers were ever used outside of its local network.

Alas, in 2018, the .llc TLD was born and began selling domains. From then on, anyone who registered company.llc would be able to passively intercept that organization’s Microsoft Windows credentials, or actively modify those connections in some way — such as redirecting them somewhere malicious.

Philippe Caturegli, founder of the security consultancy Seralys, is one of several researchers seeking to chart the size of the namespace collision problem. As a professional penetration tester, Caturegli has long exploited these collisions to attack specific targets that were paying to have their cyber defenses probed. But over the past year, Caturegli has been gradually mapping this vulnerability across the Internet by looking for clues that appear in self-signed security certificates (e.g. SSL/TLS certs).

Caturegli has been scanning the open Internet for self-signed certificates referencing domains in a variety of TLDs likely to appeal to businesses, including .ad, .associates, .center, .cloud, .consulting, .dev, .digital, .domains, .email, .global, .gmbh, .group, .holdings, .host, .inc, .institute, .international, .it, .llc, .ltd, .management, .ms, .name, .network, .security, .services, .site, .srl, .support, .systems, .tech, .university, .win and .zone, among others.

Seralys found certificates referencing more than 9,000 distinct domains across those TLDs. Their analysis determined many TLDs had far more exposed domains than others, and that about 20 percent of the domains they found ending .ad, .cloud and .group remain unregistered.

“The scale of the issue seems bigger than I initially anticipated,” Caturegli said in an interview with KrebsOnSecurity. “And while doing my research, I have also identified government entities (foreign and domestic), critical infrastructures, etc. that have such misconfigured assets.”

REAL-TIME CRIME

Some of the above-listed TLDs are not new and correspond to country-code TLDs, like .it for Italy, and .ad, the country-code TLD for the tiny nation of Andorra. Caturegli said many organizations no doubt viewed a domain ending in .ad as a convenient shorthand for an internal Active Directory setup, while being unaware or unworried that someone could actually register such a domain and intercept all of their Windows credentials and any unencrypted traffic.

When Caturegli discovered an encryption certificate being actively used for the domain memrtcc.ad, the domain was still available for registration. He then learned the .ad registry requires prospective customers to show a valid trademark for a domain before it can be registered.

Undeterred, Caturegli found a domain registrar that would sell him the domain for $160, and handle the trademark registration for another $500 (on subsequent .ad registrations, he located a company in Andorra that could process the trademark application for half that amount).

Caturegli said that immediately after setting up a DNS server for memrtcc.ad, he began receiving a flood of communications from hundreds of Microsoft Windows computers trying to authenticate to the domain. Each request contained a username and a hashed Windows password, and upon searching the usernames online Caturegli concluded they all belonged to police officers in Memphis, Tenn.

“It looks like all of the police cars there have a laptop in the cars, and they’re all attached to this memrtcc.ad domain that I now own,” Caturegli said, noting wryly that “memrtcc” stands for “Memphis Real-Time Crime Center.”

Caturegli said setting up an email server record for memrtcc.ad caused him to begin receiving automated messages from the police department’s IT help desk, including trouble tickets regarding the city’s Okta authentication system.

Mike Barlow, information security manager for the City of Memphis, confirmed the Memphis Police’s systems were sharing their Microsoft Windows credentials with the domain, and that the city was working with Caturegli to have the domain transferred to them.

“We are working with the Memphis Police Department to at least somewhat mitigate the issue in the meantime,” Barlow said.

Domain administrators have long been encouraged to use .local for internal domain names, because this TLD is reserved for use by local networks and cannot be routed over the open Internet. However, Caturegli said many organizations seem to have missed that memo and gotten things backwards — setting up their internal Active Directory structure around the perfectly routable domain local.ad.

Caturegli said he knows this because he “defensively” registered local.ad, which he said is currently used by multiple large organizations for Active Directory setups — including a European mobile phone provider, and the City of Newcastle in the United Kingdom.

ONE WPAD TO RULE THEM ALL

Caturegli said he has now defensively registered a number of domains ending in .ad, such internal.ad and schema.ad. But perhaps the most dangerous domain in his stable is wpad.ad. WPAD stands for Web Proxy Auto-Discovery Protocol, which is an ancient, on-by-default feature built into every version of Microsoft Windows that was designed to make it simpler for Windows computers to automatically find and download any proxy settings required by the local network.

Trouble is, any organization that chose a .ad domain they don’t own for their Active Directory setup will have a whole bunch of Microsoft systems constantly trying to reach out to wpad.ad if those machines have proxy automated detection enabled.

Security researchers have been beating up on WPAD for more than two decades now, warning time and again how it can be abused for nefarious ends. At this year’s DEF CON security conference in Las Vegas, for example, a researcher showed what happened after they registered the domain wpad.dk: Immediately after switching on the domain, they received a flood of WPAD requests from Microsoft Windows systems in Denmark that had namespace collisions in their Active Directory environments.

Image: Defcon.org.

For his part, Caturegli set up a server to resolve and record the Internet address of any Microsoft Sharepoint systems trying to reach wpad.ad, and saw that over one week it received more than 140,000 hits from Sharepoint hosts around the world attempting to connect.

The fundamental problem with WPAD is the same with Active Directory: Both are technologies originally designed to be used in closed, static, trusted office environments, and neither was built with today’s mobile devices or workforce in mind.

Probably one big reason organizations with potential namespace collision problems don’t fix them is that rebuilding one’s Active Directory infrastructure around a new domain name can be incredibly disruptive, costly, and risky, while the potential threat is considered comparatively low.

But Caturegli said ransomware gangs and other cybercrime groups could siphon huge volumes of Microsoft Windows credentials from quite a few companies with just a small up-front investment.

“It’s an easy way to gain that initial access without even having to launch an actual attack,” he said. “You just wait for the misconfigured workstation to connect to you and send you their credentials.”

If we ever learn that cybercrime groups are using namespace collisions to launch ransomware attacks, nobody can say they weren’t warned. Mike O’Connor, an early domain name investor who registered a number of choice domains such as bar.com, place.com and television.com, warned loudly and often back in 2013 that then-pending plans to add more than 1,000 new TLDs would massively expand the number of namespace collisions. O’Connor was so concerned about the problem that he offered $50,000, $25,000 and $10,000 prizes for researchers who could propose the best solutions for mitigating it.

Mr. O’Connor’s most famous domain is corp.com, because for several decades he watched in horror as hundreds of thousands of Microsoft PCs continuously blasted his domain with credentials from organizations that had set up their Active Directory environment around the domain corp.com.

It turned out that Microsoft had actually used corp.com as an example of how one might set up Active Directory in some editions of Windows NT. Worse, some of the traffic going to corp.com was coming from Microsoft’s internal networks, indicating some part of Microsoft’s own internal infrastructure was misconfigured. When O’Connor said he was ready to sell corp.com to the highest bidder in 2020, Microsoft agreed to buy the domain for an undisclosed amount.

“I kind of imagine this problem to be something like a town [that] knowingly built a water supply out of lead pipes, or vendors of those projects who knew but didn’t tell their customers,” O’Connor told KrebsOnSecurity. “This is not an inadvertent thing like Y2K where everybody was surprised by what happened. People knew and didn’t care.”

Read More