How to Detect Heartbleed Vulnerabilities & Attacks
Watch to learn how to check for Heartbleed vulnerabilities and detect Heartbleed attack attempts, quickly and easily. Heartbleed is not an exploit you want to ignore as an IT professional. It exposes passwords and cryptographic keys, and requires not only that you patch OpenSSL for each of the services using the OpenSSL library, but also that you replace the private keys and certificates so that attackers won’t be able to use any of the data compromised by the vulnerability. Read more
We’re going to jump into the AlienVault interface and spend some time here, and actually show you how you can use the components built into the AlienVault platform, specifically asset discovery, vulnerability assessment, and network intrusion detection to effectively manage the risk associated with the heartbleed bug. So… in fact before we get into that, just a couple of things – I basically have a web server here that I’m running. You can see that it actually does have SSL-based support for running encrypted sessions through the web server. So this is actually relying on OpenSSL, and this is in fact a vulnerable version of OpenSSL that’s running on this web server. So we’ll actually be able to run some attacks and exploit the system just so that you can see kind of what that looks like.
So, again, there’s a couple of key capabilities inside of the AlienVault platform that you can leverage in order to really help you manage this risk, and one piece of that is asset discovery. So basically, the AlienVault system has a number of mechanisms in it that allow it to root and sort of scan your network and identify where the systems are that are running different types of services, for example a web server that might be running, or open on port 443, which is the typical port that SSL-based encrypted sessions operate over. So you can use the asset discovery, for example, if you can point your scan that you want to run to a specific network segment, you can identify that environment and say “Okay, I want to run this scan here and go find all of the systems, and all of the different services that are present there.” And we take a little while for me to actually do that, so I’m not going to do it here, because it’s actually already been done for this environment, but when you get that information back, there’s a lot of interesting things you can do with it.
So for example, now that we’ve got the asset inventory populated with all of this information, we can, you know, basically filter it down using a couple of different filtering capabilities over here. So we can search for specific host names or IPs here, you can say, you know, “Shoe me events…” or “Show me assets that have vulnerabilities, or that have events, or have alarms”. But we also have a couple of other filtering capabilities, for example ports and services. So I can say “You know what? I want to see any asset that has port 443, you know, whether it’s identified as an SSL service or not, I want to see those assets.” So I’m going to apply that filter – again, this is the port that SSL services typically run over, so any asset that has port 443 open is potentially vulnerable to the heartbleed bug. So that’s basically what I just found by applying that filter, is all of the assets in my environment that I at least know have that particular service open.
And once I have this filter set, I can actually save all of these assets to a group. So I’m going to save this group – I’m actually going to call this “SSL Servers.” I don’t necessarily know if they’re OpenSSL based servers, or if they’re actually vulnerable to a heartbleed, I just know that these are servers that I want to pay special attention to basically. So I’m going to save that group, and now that I have this group saved, you can see that, you know, through the list here, there are a number of different systems that do have SSL services running. And in fact, there are multiple ports that have SSL services running, as opposed to just the traditional port 443. So that’s good information to know. From here we can, you know, use or leverage this group in a couple of really interesting ways.
So for example, while we’re doing vulnerability scanning, if we set up a new vulnerability scan, we can basically tell it “You know what? I want this vulnerability scan to run immediately.” I’m going to do an OpenSSL scan, and that’s just kind of an arbitrary name that I applied to track when the scan job is running and when it’s finished, and I’m going to drill down into these asset groups, and it’s specifically my SSL servers that I want to run the scan against, right. So, being able to easily identify those assets that are potentially vulnerable, and then focusing your scanning efforts here is a really nice tactic to get, you know, kind of, you know, pinpoint accurate around identifying the potential risk in the environment. So, again, this is a scenario where the scan will take a while. I’m not going to waste everybody’s time by sitting here and watching this scan run, but we can go in and look at some specific vulnerability reports that have already been completed, and actually see if we can identify some systems that might be vulnerable.
So I’m going to do a free text search here and see if I can find a system that has a heartbeat vulnerability on it. And in fact, there is, so this OpenSSL vulnerability, from a technical standpoint, is typically referred to as an OpenSSL heartbeat vulnerability. So that’s one of the ways you’ll be able to find it. We’ll actually drill down into this report here, and we can just do a quick search in fact to find, yep. So here it is. This is an OpenSSL TLS heartbeat extension information disclosure vulnerability that’s been identified on this particular system. So we basically, at this point, we know that we’ve found a system inside of our environment that has this exposure. So we started with identifying all of the assets that are potentially OpenSSL based systems, or using the OpenSSL libraries to provide SSL services, and then we ran a vulnerability scan against those assets and found specifically a system that is running a vulnerable version of OpenSSL, so that’s what we detected here. So that’s really good information for us to be able to now respond and go back and patch this asset. And like I said, the OpenSSL team has essentially released a patch that we can apply to this system in order to eliminate this risk from our network. So lots of very effective, you know, sort of proactive security efforts we can apply as a result of having these tools at our disposal.
Now the next level of this is actually, you know, monitoring the network to see… while I know I have this vulnerability present, assuming it’s on a production server and I can’t go patch it without going through some kind of change request process or whatever, you know, I need to know: is this particular vulnerability being exploited? And if it is, you know, how often is it happening? How bad is it? You know, I need to be able to monitor for that type of activity. So the alarms interface is really going to allow us to do that, thanks to the network intrusion detection system that AlienVault has built into the platform, which has a capability of detecting, you know, A., the attack, B., the response to the attack, and then actually correlating that information in order to generate an alarm that will surface here and get your attention, indicating that, you know, there was a significant problem that happened that you need to respond to.
So having, you know, the detection capabilities here, and knowing that we’re going to be able to dig into that, that’s great, and before we do, let’s take a look at running this exploit. Let’s actually take a crack at it. So this little script that I have here is basically just a python script, and it’s really, really simple. It’s just going to send out… establish an SSL connection essentially, and then once the connection is established, it’s going to send a heartbeat request with basically a malformed request as part of that. And then, you know, the intent is to get that system to respond with all of that data that’s stored in its memory that it shouldn’t be responding with. It’s tough to change the IP here, it’s actually about 76 is the host that’s running my web server when I attack somebody else on my network here, so.
Anyways, just hitting Enter on the script, you can see that it came back and dumped a ton of data. So basically this is all of that… the 64 kilobytes worth of information that’s in the system’s memory – maybe it’s interesting information, maybe it’s not, but at this moment, you know, “Okay, this system is actually vulnerable, and I can start to, you know, really extract information out of this host.” And you can see how easy it was for this attack to run – I just executed a simple script and it went out and did a connect and established the session. Once that session was set up, it said “Okay, I’m going to send a heartbeat request”, and the heartbeat response was sent back from the server. This is this big dump of data.
Now the thing is, I can run this script over and over again. It’s trivial, right. I can just keep doing this. And as I keep running this script and pushing it through the system, basically what I’m going to get is I’m going to continue to get different dumps of the memory as users are working with the server, as they’re browsing to different pages on the web server for example, they’re doing different things. So just to show you here, you know, I might be able to click around on a few things inside of this website that’s running on this particular server. You can see that I’m in an https session, a little lock is there, meaning it’s secure, so we’re good, right. And I’m, like, clicking around and looking at various stuff, and all the while an attacker is out there basically getting that system to dump its data back to him, and, you know, possibly being able to get information about my browsing session and see, you know, what I’m doing as a result.
And you can see here that that information that’s being dumped to me has changed now. So before we were just seeing kind of some random characters. This time I’m actually seeing some language, “en”, so English US, “Accept-encoding: gzip, deflate..Referer:” There’s basically a URL, a specific URL that indicates kind of where I was browsing. Not terribly interesting information in this case, or terribly sensitive information in this case, but the point is that the system is dumping its memory content back to me. And this is a matter of time before, as an attacker, I hit on something that is really sensitive, valuable data. And obviously, while I’m kind of working through this website, there’s really not anything here of particular interest. I haven’t entered any user password credentials; I haven’t entered any credit card information to process a credit card transaction, right. If I was doing all of those things, that’s the information that would be in the server’s memory, and therefore, you know, it’s very likely that that’s the information that’s going to get dumped back out through, you know, carrying out this exploit.
So like I said, having some kind of script that just executed this command over and over and over again against a remote server, at the end of the day, the attacker’s going to have a huge treasure trove of data of all kinds of, you know, malicious, or with all kinds of information in it that they can use to carry out whatever their malicious intent is. So that is, basically, the attack actually playing out. Now, on the detection side, we’ve got our alarms interface over here that’s got, you know, a number of different issues that have been identified. These are all kind of this big collection of data down here is environmental awareness stuff. You can see that’s basically the bottom category. As you move up the stack through the different categories, you can kind of recognize the severity of the activity that’s detected is increasing, right. And this category here, which is exploitation and installation, is actually the category where we’re going to identify these heartbeat exploit attempts.
And so if you mouse over the bubbles, those are basically indications of, you know, these attacks that are occurring, and you don’t necessarily need to know that “Oh, well I’ve got to be looking in the exploitation category for this heartbeat stuff, or for, you know, exploits against the heartbleed bug.” It’s really not that significant that you have that understanding. What is significant is that you understand that, you know, anything that falls into the exploitation and installation category is pretty severe, and probably, you know, needs your attention, you need to spend some time looking into it. Especially anything that comes into the “System Compromise” category is going to be a significant that needs your attention, right. And so as you’re going through the process of looking into these, you’ll find out that, you know, in fact, while this is just… and we saw some file sharing software in your environment, this one is, you know, more significant, where we’ve seen an actual service exploit we can drill down into. And you just click on that bubble, and it basically condenses the view down to just the activity that was associated with that specific bubble.
We can drill down into this alarm and show you essentially the activity that was detected through the network intrusion detection system. So again, what we’re seeing here is an attack where there was a malformed heartbeat request, and that by itself is an indicator that “Hey, somebody’s trying to exploit this vulnerability, or potentially exploit a vulnerability on your network.” But the attack by itself isn’t necessarily a significant cause for concern. What is a significant cause for concern is when you see a response to that attack indicating that the system actually dumped its memory contents back to the attacker. And so this is where the correlation aspect comes in. Not only did the network intrusion detection system detect the attack, but it also detected the response to the attack, and therefore our correlation engine identified that “Hey, the attacker, when that request was issued, was actually the destination when the response was issued”. And so that is basically the confirmation that we need to see that this attack was carried out successfully. And that’s why we generated this alarm that was identified as a service exploit, specifically OpenSSL heartbeat method was employed in order to carry out this attack. So that’s the information that we leveraged in order to really help you understand that this attack was successful.
So clicking on that actual event, you just drill down into the intrusion detection data, and what we can show you from here is basically the payload that the network intrusion detection system picked up off the wire, this is a detailed description of the actual signature that’s employed in order to detect this type of attack. And down here at the bottom, you actually have a Pcap-style viewer that you can use to drill down into the various packet headers – you can see we’ve got, like, a layer for TCP header here as part of the packet; we’ve also got the SSL layer here, or header, and if you expand that, it actually shows you, in fact this is a heartbeat request, right. So we’re recognizing that this is a TLS heartbeat request inside of the SSL session, and in addition to that, we’re recognizing that it was actually a malformed packet that was included inside of that particular request. And this is, in fact, the element of the attack that is significant, right. So that’s what we’re triggering on in order to recognize this activity.
Now, seeing that, and again, recognizing that, you know, that doesn’t necessarily mean that the attack was successful, we’re looking for this response as well – and the network intrusion detection system, again, was able to identify this particular response, and actually what you’re seeing here is that payload off of the wire where the system identified “Okay, the server responded to this attack attempt, and this is the actual payload that got, or the memory contents, that got dumped back to the attacker when the vulnerable system responded.” And again, you can see, you know, the signature detecting that response, the specific packet headers associated with the response, etc. And so that’s kind of all of the detail from an analysis perspective, being able to see that this attack actually occurred, and the information associated with it.
And so because this information is essentially confirming for us that the attack was successful, that allows us to assess the risk level at a four, which is relatively high in the case of AlienVault alarms. If you’re in the four or five range, we consider that relatively high-risk. Obviously the risk can go all the way up to a ten, but a lot of alarms are, you know, risk level one or two, so something that’s a four, that’s pretty high-risk, and that’s really what we’ve been able to establish for you here, is that this is a significant issue that needs your attention, right. And at the very least, you know, it’s time to go look into that particular system, and figure out, you know “What do we need to do to mitigate this vulnerability and stop this from happening?” So full on incident response mode at that point, right.
So that is essentially the AlienVault USM platform identifying assets, checking the vulnerabilities, and then detecting attacks associated with the heartbleed bug.