When the Security Researchers Come Knocking, Don’t Shoot the Messenger

Our own Jonathan Butts and Billy Rios were interviewed this month on the CBS Morning News about their research showing that medical devices like pacemakers and insulin pumps can be hacked by… basically anybody.  These devices all contain embedded controllers, but unlike most modern computer technologies, they haven’t been designed with security in mind.

“We’ve yet to find a device that we’ve looked at that we haven’t been able to hack”, said Jonathan.

Billy also speaks to the one-way nature of medical equipment exploits, noting that it’s not just a matter of issuing a new credit card or changing a password when bad guys take advantage of the flaw. Victims of these kinds of attacks can end up dead.

You can see the full interview here:

http://www.cbsnews.com/video/how-medical-devices-like-pacemakers-insulin-pumps-can-be-hacked/

The Washington Post did a story on the same subject, featuring Billy and Jonathan back in October.

Poor security design is clearly widespread throughout the medical device industry.  As readers of our blog know, devices with embedded controllers are found in the electrical power industry, oil & gas, manufacturing, aerospace, defense, and a host of other critical infrastructure sectors. And many of those devices have had serious security vulnerabilities exposed in the past decade. But what makes this story concerning is that the medical industry seems especially behind in its approach to vulnerability management.

Billy and Jonathan uncovered the vulnerabilities associated with a Medtronic pacemaker way back in January last year. They then disclosed their findings in a detailed report to the vendor. Unfortunately, Medtronics denied that action was necessary and did nothing to address the problem or warn users.  It took a live, very public demonstration at Black Hat USA 2018 to capture the attention of the FDA and the vendor.

That isn’t the way responsible vulnerability disclosure is supposed to work. When researchers discover a vulnerability and privately share it with the vendor (and/or appropriate government agencies), the vendor needs to take that vulnerability seriously. That way the users of its products get a chance to patch before the dark side of the cyber world starts to exploit the weakness. Requiring researchers to broadcast the news to the world to get action is simply terrible security practice.

As a former CTO of a large industrial device manufacturer, I have faced my share of researchers bringing news of vulnerabilities in my company’s products. Some of the vulnerabilities proved to be very serious, while others simply a misunderstanding of how the product would be deployed in the field. Regardless, we took every vulnerability report seriously, immediately engaging the researchers so we could learn as much as possible about their testing techniques and findings. Sometimes, when we thought the researcher was onto a particularly serious or complex problem, we flew them into our development center so we could start addressing the issues as quickly and completely as possible.

The bottom line is that device manufacturers need to start seeing security researchers as partners, not annoyances. When a researcher finds a vulnerability, they are basically doing free QA testing that the quality and security teams should have done before the product ever shipped. It’s time that companies like Medtronic started working with security researchers, not fighting them. Instead, we should all be fighting the bad guys together.  It is the only way our critical systems will become more secure.

Follow Us:

Twitter
  LinkedIn

Who Infected Schneider Electrics’ Thumbdrive?

Infected USB Drive

On 24 August 2018 Schneider Electric issued a security notification alerting users that the Communications and Battery Monitoring devices for their Conext Solar Energy Monitoring Systems  were shipped with malware-infected USB drives.

First of all, kudos to Schneider Electric for alerting their customers and providing information on how to remedy the situation. According to Schneider, the infected files would not affect the devices themselves. Schneider also noted that the particular malware was easy to detect and remove by common virus scanning programs.

Provided that all of Schneider’s customers read these alerts, this should remain a minor security incident. Unfortunately, this is a big assumption. Due to the complexities of modern distribution channels, I’m pretty certain no one in the world knows if the Schneider notice is getting to the people who actually use the Conext product. It could be getting stuck on some purchasing manager’s desk, never to be forwarded to the technicians in the field. Or it could be languishing in the inbox of an engineering firm that is no longer working at the location where the Conext product is deployed. If ZDNet and CyberScoop had not reported on the story, it may have stayed off everyone’s radar.   Clearly, both vendors and asset owners need better ways of sharing urgent security information.

The Conext Battery Monitor from Schneider Electric
The Conext Battery Monitor
Source: Schneider Electric

But what is especially interesting is that the thumb drives were not infected at Schneider’s facilities.  They were infected via a third-party supplier during the manufacturing process. Like ALL major ICS vendors, the supply chain for Schneider hardware, software (and even the media upon which it is shipped) is exposed to many hands.

This situation highlights an alarming reality in the ICS world. Just because a digital file comes from a trusted vendor doesn’t mean you can trust all the other companies that touched that file.

Who knows which “third-party supplier’s facility” was involved in contaminating those USB drives?? Was it the USB manufacturer… or a duplication company… or even a graphics company who added some branding? Schneider Electric no doubt will be re-thinking that relationship, but the fact remains that they have to work with 3rd parties to get their products to market.

The worrisome question is, what other ICS vendors use that same third-party supplier? How widespread is the infection? It seems unlikely that Schneider Electric is this supplier’s only customer. Naming and shaming the supplier may be fraught with legal consequences (or perhaps they are still tracking down the specific vendor) so Schneider has remained silent for now on the source of the malware. That means all the other vendors out there and their customers may be exposed as well. Or not. We don’t know – and that is a problem.

One hopes that if other vendors have detected issues with their USB drives, they will follow Schneider Electric’s lead and issue prompt alerts. Some vendors are better than others at transparency and there will likely be some who choose to lay low instead to avoid bad publicity. It is a pity because vendors like Schneider are as much a victim in this scenario as the end users.

This is one of the reasons aDolus is developing a platform for ICS asset owners and vendors that offers an ecosystem of trust where they can verify software of, let’s call it “complicated origin” and ensure it hasn’t been tampered with BEFORE they install it. We’re also looking at ways vendors can get early warnings about security issues occurring at their client’s sites and not have to wait until hundreds or thousands of facilities have been infected.  

Interested in learning more about protecting yourself from compromised software? Let us know if you are an end user interested in validating ICS software or an ICS vendor interested in protecting your distribution mechanisms to ensure they are clean.

Follow Us:

Twitter
  LinkedIn

Building (or Losing) Trust in our Software Supply Chain

Back in 2014, when I was managing Tofino Security, I became very interested in the Dragonfly attacks against industrial control systems (ICS). I was particularly fascinated with the ways that the attackers exploited the trust between ICS suppliers and their customers. Frankly, this scared me because, as I will explain, I knew that all the firewalls, antivirus, whitelisting, and patching in the world would do little to protect us from this threat.

If you are not familiar with the Dragonfly attacks, they were launched against the pharmaceutical industry (and likely the energy industry) in 2013 and 2014. The attacks actually started in early 2013 with a spear phishing campaign against company executives. But the part that concerned me began later, starting in June 2013 and ending in April 2014.

 

During that period, the Dragonfly attackers penetrated the websites of three ICS vendors: vendors who supply hardware and software to the industrial market. Once the bad guys controlled these websites, they replaced the vendors’ legitimate software/firmware packages with new packages that had Trojan malware called Havex embedded in them (Attack Stage #1).

When the vendors’ customers went to these websites they would see that there was a new version of software for their ICS products. They would then download these infected packages, believing them to be valid updates (Attack Stage #2). And because one of the messages we give in the security world is to “keep your systems patched,” these users pushed out the evil updates to the control systems in their plants (Attack Stage #3).

Once these systems were infected, the Havex malware would call back to the hacker’s command and control center, informing the attackers that they had penetrated deep into a control system. The attackers then downloaded tools for ICS reconnaissance and manipulation into the infected ICS hardware (Attack Stage #4). These new attack tools focused on the protocols we all know well in the ICS world, such as Modbus, OPC, and Ethernet/IP.

As far as we know, the attackers were most interested in stealing industrial intellectual property — not destroying equipment or endangering lives. However, there was nothing that would have restricted the attackers to just information theft. Their tool sets were extremely flexible and could have easily included software that would manipulate or destroy a process.

The Dragonfly attacks were particularly insidious because they took advantage of the trust between suppliers and end users. The engineers and technicians in industrial plants inherently trust their suppliers to provide safe, secure, and reliable software. By downloading software and installing it, the Dragonfly victims were doing what they had been told would improve their plant’s security. In effect, these users were unwittingly helping the attackers bypass all the firewalls, circumvent any whitelisting or malware detection, and go directly to the critical control systems.

This is what I call “Exploiting the Supplier-User Trust Chain” — and I think it is one of the most serious security risks facing our world today. It is not only a problem for ICS-focused industries like energy or manufacturing, but also for any person or company that uses “smart “ devices… which is pretty well all of us. Aircraft, automobiles, and medical devices are all susceptible to this sort of attack.

So with the help of Billy Rios, Dr. Jonathan Butts , a great team of researchers, and the DHS Silicon Valley Initiatives Program, I’ve been working on finding a solution to the Chain-of-Trust challenge. aDolus and Security Trust Anchor (STA) are the result of 1000s of hours of our systematic investigation into the problem and its possible solutions. Join me on this blog over the next few months as I share what we have learned and where we still have to go to ensure trust in our software.

For more on Dragonfly:

Scroll to top