There’s nothing that makes you feel older than realizing how much of your life you have dedicated to a single topic. At what point do you consider yourself an expert? After more than 17 years in vulnerability management, I’m starting to come around to the idea that I might be an expert in the field. Although, the main reason I feel that way is because, at this point, I’ve seen pretty much everything.
One of those things that I’ve seen time and time again is the argument around Patch Management vs. Vulnerability Management. We could delve deeper into discussions around management vs. assessment, but let’s ignore that one for now. With patch management, the process is simply a matter of seeing if the patch is installed. Within the vulnerability management space, particularly with authenticated scans, the process appears identical. However, there are secondary steps that must go into determining vulnerability state, including any post patch mitigations.
The idea of post patch mitigations is one of the biggest “gotchas” for our customers, particularly customers that utilize patch management software. This, combined with patches that don’t apply, accounts for a lot of the conversations that I have. Microsoft is famous for the text, “To be fully protected from this vulnerability, customers must do the following…” Yet, for some reason, many people are still unaware of these additional steps. Others have complete confidence that if a patch says it installed successfully, that it must have truly installed successfully. Interestingly, a patch’s “successful” installation is not an indication of vulnerability resolution. This is probably one of the points that I spend the most time educating customers about.
There’s an even more interesting issue, however, that I want to discuss today. Vulnerabilities that are never fixed, but stop being discussed. For years, this was a battle that we fought with Oracle Database Express. It was such an issue, that it became a major research project for us, resulting in a blog post and multiple conference presentations. Today, however, I want to talk about CVE-2010-1549 – “Unspecified vulnerability in the Agent in HP LoadRunner before 9.50 and HP Performance Center before 9.50 allows remote attackers to execute arbitrary code via unknown vectors.”
Some tools likely stopped checking for this when LoadRunner went past version 9.50. Others might have dug a bit deeper and found out that the mitigation for this didn’t become the default until version 12.50. At Tripwire, we developed a direct condition test for this. That is to say, we test for the vulnerability by interacting with the vulnerable product rather than inferring the vulnerability based on other related data. Since this is a direct condition test, we didn’t feel the need to mask it to specific versions of LoadRunner. Which means that every year, we see an instance or two of this vulnerability raised by our customers as a false positive.
Over the years, we’ve heard multiple reasons why people think it is a false positive:
- “This is a 2010 CVE, there’s no way our software is vulnerable a decade later.”
- “HP sold LoadRunner to MicroFocus… this is an HP vulnerability.”
- “The NVD description says that this impacts LoadRunner before 9.50, we’re running a newer version.”
- “The documentation says that this vulnerability is mitigated by default after 12.50, we’re running a newer version.”
I’m sure that there are other justifications that we’ve heard as well, but these are the most common ones.
Recently, this vulnerability bubbled up again with a customer involved in a major project and they wanted to know more about the reason it was being detected. I ended up deploying MicroFocus LoadRunner 2023, the most recent version, and testing our content on a default install. The vulnerability instantly matched. Next, I grabbed exploit code and ran the actual exploit, setup to run calc.exe on the device, against the server. The calculator immediately opened. So, the vulnerability still exists.
There was a problem though. I couldn’t find any documentation about the vulnerability on the MicroFocus website. Many of the HP pages addressing the vulnerability no longer existed and the settings that were mentioned on the pages I found did not exist. After searching the MicroFocus documentation for keywords, I found a command line setting that sounded like it might help. I ran the command and tested the vulnerability again. Sure enough, it was mitigated. When I disabled the setting, the system was instantly vulnerable again.
I was able to get on a call with our customer and quickly walk them through a demonstration of this attack and show why Tripwire IP360 identified the system as vulnerable. The customer was happy because they had confirmation that we were correct, and I was happy because I was able to demonstrate exactly what had happened. At the same time, nobody was happy because there was limited documentation around mitigating this vulnerability. The only reference material still online said to enable the “Secure Channel” feature. For those of you running LoadRunner, here is the setting we used to mitigate the vulnerability.
On modern versions of LoadRunner, this setting can be configured using the lr_agent_setings binary, which can be found within the LoadRunner install folder, in the bin directory. In order to mitigate this vulnerability, the check_client_cert setting must be enabled.
Enable check_client_cert: lr_agent_settings -check_client_cert 1 Restart agent: lr_agent_settings -restart_agent
Should the mitigation need to be reverted, it can be done with the following commands:
Disable check_client_cert: lr_agent_settings -check_client_cert 0 Restart agent: lr_agent_settings -restart_agent
For me, this was a good reminder of why patch management and vulnerability management are different. It was also a good reminder of why we don’t retire older vulnerability content. It’s not every day that you expect to see a critical (and easy to exploit) unauthenticated remote code execution pop-up on modern networks, but this one could be devastating to organizations without a mature vulnerability management program.
Tripwire IP360 gives users complete visibility into their networks, both on-premises and in the cloud, including all devices and their associated operating systems, applications, and vulnerabilities. Learn more about how Tripwire IP360 could secure your organization here: https://www.tripwire.com/products/tripwire-ip360
Mastering Security Configuration Management
Master Security Configuration Management with Tripwire's guide on best practices. This resource explores SCM's role in modern cybersecurity, reducing the attack surface, and achieving compliance with regulations. Gain practical insights for using SCM effectively in various environments.
