A recent series of vulnerability announcements has made headlines by drawing attention to serious security issues in remote management hardware shipped with many brands of servers. There’s plenty of food for thought here: What is the problem? How bad is it? What do we do about it? Unfortunately, the security world thrives on anxiety. Security researchers, naturally, want to play up the severity of their findings, and security sales organizations want to use fear of newly-discovered vulnerabilities as a tool to move products.

So let’s take a look at the situation, and try to separate good actionable advice from hype.

First and foremost, when people talk about “a new vulnerability,” generally speaking the vulnerability itself isn’t new– someone has just recently found out about it, but the vulnerability itself has been there all along. Not only that, but we’ve been living our lives in relative peace: the discovery of a vulnerability in and of itself is not reason to panic. We first have to find out how severe the vulnerability is, and we also have to find out how likely it is to be exploited.

In the context of these current vulnerability announcements, there is definite cause for concern: vulnerable systems are widespread, they can be exploited remotely, and the exploitation itself seems relatively simple. This means that we likely have only a short window of time before attacks become widespread.

But there is good news. Defending against the most worrisome style of attack (exploitation of vulnerable systems over the Internet) is relatively easy: just don’t expose the vulnerable interface to the Internet, and that attack vector is cut off.

While blocking things at the firewall is a great first step, by itself it is insufficient, because inevitably various malware will adopt this means of attack, and we will start to see exploitation of internal networks as well.

With this in mind, CDW recommends the following strategy:

  1. Take stock of your current servers: do you have BMC interfaces that speak the IPMI  protocol?
  2. How sure are you? Our security assessment can perform scanning to help you identify potentially vulnerable systems you may have missed. This scanning should at a minimum cover your Internet-facing systems, but a thorough approach would encompass your internal network as well.
  3. If you have potentially vulnerable systems on your network, block access to the interfaces at the firewall.
  4. At the same time, also change the default passwords for the management interfaces to something nice and strong. If it helps, in the course of our scans, we can also test your systems for default passwords.
  5. Check with your vendors to see if they have additional workarounds you can employ; in many cases, it will be possible to disable week cryptography, in others it may be possible to update the BMC firmware.
  6. Segregate network management traffic to its own dedicated management network. Moving network management traffic out of band helps both performance and security, and makes sure that potentially vulnerable server management interfaces aren’t exposed to unwanted traffic.

If you have questions about whether your servers are vulnerable (regardless of whether you bought them from us or someone else), call us: we can help scan for vulnerable systems, so that you can take the necessary steps to nip this issue in the bud, before it becomes a problem.

Any other tips you think should be included in this type of vulnerability attack? Leave them in the comments below.

2 thoughts on “IPMI Vulnerabilities: Don’t Panic, but Do Take Action

  • Peyton Engel says:

    Hi Luan. Yes, there are tools that can help you with this. Most network vulnerability scanners should include checks for these weaknesses. The first two links in the article give some details as well (for example, checking UDP port 623).

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.