It would be difficult to find someone involved in the security industry today who has not heard about the Heartbleed vulnerability, first disclosed earlier this week. This flaw in OpenSSL, which affects most of the Internet, is one of the most serious publicly disclosed vulnerabilities in recent times, not only because of how common OpenSSL usage is, but also because of the scope of the vulnerability itself. Servers vulnerable to the Heartbleed buffer overflow expose their own raw memory contents to attackers, allowing someone to snoop in on all kinds of data, including user names, emails, passwords, addresses, Social Security numbers, companies’ confidential data — the sky’s the limit. Essentially, if it is data that has recently passed through OpenSSL memory buffers on the server, it is vulnerable to attackers.

SEE ALSO: What to Do to Protect against Heartbleed OpenSSL Vulnerability

Furthermore, properly fixing the vulnerability is not even as simple as patching OpenSSL itself because if the host has been exposed to attackers, one must also regenerate their security certificate, which may be compromised and can no longer be trusted. Generating and replacing certificates for all servers can be an extremely expensive and time-consuming procedure for companies that have many SSL end points. Likewise, these previously used (and assumed compromised) certificates also have to be revoked.

How does one decide which servers to patch and certificates to remediate first?

There has been commentary that this vulnerability exposes a “need for a new approach to security,” one where proper monitoring, intelligence and incident response are just as important as strong firewall rules, which raises an important point: When responding to an incident like Heartbleed, the solution is not usually as simple as pressing a button and having all machines in the enterprise patched and all new certificates generated and deployed. For most organizations, it will require lots of planning and effort. So the question arises: How does one decide which servers to patch and certificates to remediate first? Thankfully, IBM Security has you covered. Using the IBM Security QRadar suite of products, it is relatively straightforward to not only detect servers that are likely vulnerable to Heartbleed, but also to prioritize your remediation work flow, allowing you to target your most vulnerable and/or valuable assets first.

2014 Gartner Magic Quadrant for SIEM

The first step is identifying the machines and services that are vulnerable to Heartbleed. IBM Security QRadar Vulnerability Manager’s scanner module, which processes nightly signature updates, will have the ability to detect hosts vulnerable to Heartbleed, also known as vulnerability CVE-2014-0160. It is important to note that you don’t have to rescan your assets to know if they are vulnerable; they just have to have been scanned in the past. Figuring out which hosts are vulnerable is very straightforward and can be done with a simple search.

Now that we know which hosts are vulnerable, we need to decide which ones must be patched first. Is the host exposed to the Internet, or is it firewalled from the world? Is the host a piece of production infrastructure, or is it just a test machine? This is where IBM Security QRadar Risk Manager enters the picture, which, as one of its functions, allows you to write policies that influence the prioritization of vulnerabilities. These policies can take into account not only the host’s security posture, but also firewall and IPS rules, routing information and flow traffic.

Here we have written a policy test if the server is in our production PCI network and also tests if inbound connections from the Internet can reach the host on the exposed port. The policy will then increase the risk of this vulnerability by a factor of 100 percent via the monitor mode and bring it to the top of our remediation list for patching.

But we can go even further: As previously mentioned, servers that are vulnerable to Heartbleed and have been exposed to attackers in the past also need to regenerate and apply their certificates. This could be the most expensive process for the enterprise in this whole scenario, so we want to make sure that we prioritize this properly. Due to its integrations with the rest of the QRadar product family, IBM Security QRadar Vulnerability Manager has the additional ability to filter on hosts that have actual traffic on a port. If we want to know which hosts not only are susceptible to Heartbleed, but also have communicated on this port in the past, the software allows you to determine if a new certificate actually needs to be generated for this host or not.


This search shows that none of the machines that have the vulnerability have communicated using this port in the past 120 days. Therefore, we can rest assured that the likelihood of them having a compromised SSL certificate is low, and we can move them to the bottom of the priority list for new certificates.

As you can see, even with issues as severe and wide-reaching as Heartbleed, a proper application of security intelligence can not only reduce your exposure to the issue, but also save a lot of time and money while remediating. While we may not be able to predict when the next Heartbleed will be exposed, by using the right tools it is at least possible to create policies and procedures that can be used to reduce reaction times when these kinds of problems come to the fore.

 

More from Software Vulnerabilities

Analysis of a Remote Code Execution (RCE) Vulnerability in Cobalt Strike 4.7.1

Command & Control (C2) frameworks are a very sensitive component of Red Team operations. Often, a Red Team will be in a highly privileged position on a target’s network, and a compromise of the C2 framework could lead to a compromise of both the red team operator’s system and control over beacons established on a target’s systems. As such, vulnerabilities in C2 frameworks are high priority targets for threat actors and Counterintelligence (CI) operations. On September 20, 2022, HelpSystems published…

Controlling the Source: Abusing Source Code Management Systems

For full details on this research, see the X-Force Red whitepaper “Controlling the Source: Abusing Source Code Management Systems”. This material is also being presented at Black Hat USA 2022. Source Code Management (SCM) systems play a vital role within organizations and have been an afterthought in terms of defenses compared to other critical enterprise systems such as Active Directory. SCM systems are used in the majority of organizations to manage source code and integrate with other systems within the…

X-Force Research Update: Top 10 Cybersecurity Vulnerabilities of 2021

From 2020 to 2021, there was a 33% increase in the number of reported incidents caused by vulnerability exploitation, according to the 2022 X-Force Threat Intelligence Index. A large percentage of these exploited vulnerabilities were newly discovered; in fact, four out of the top five vulnerabilities in 2021 were newer vulnerabilities. Vulnerability exploitation was the second most common initial infection vector observed by IBM Security X-Force in 2021, falling closely behind phishing. Cybercriminals are finding new ways of bypassing security…

How Log4j Vulnerability Could Impact You

MITIGATION UPDATE: New vulnerability in 2.17 — CVE-2021-44832 Upgrade to 2.17.1 to mitigate this vulnerability Do NOT enable JNDI in any versions Follow: https://logging.apache.org/log4j/2.x/security.html If you hadn’t heard of Apache Log4j, chances are it’s on your radar now. In fact, you may have been using it for years. Log4j is a logging library. Imagine writing your daily activities into a notebook. That notebook is Log4j. Developers and programmers use it to take notes about what’s happening on applications and servers.…