In December, information security researchers discovered a serious vulnerability in the popular open-source logging library, Log4j. If exploited, this vulnerability, known as Log4Shell, could allow malicious attackers to execute code remotely on any targeted computer. Millions of computers use Log4j. According to one study, 93% of all cloud environments are affected by the vulnerability.
Though it was detected late in 2021, the Log4j vulnerability continues to reverberate around the technology world into 2022. Late in January, attackers targeted the SolarWinds Serv-U file sharing service using Log4j. Malicious actors also targeted VMware Horizon servers using Log4j vulnerabilities. Log4j vulnerabilities are expected to linger for the next three to five years.
At OpsRamp, we moved swiftly to assess and remediate our Log4j vulnerabilities, protecting our customers and partners from Log4Shell within a day of finding out about it. Here are the steps we took to remediate our own vulnerabilities and protect customers going forward.
Identifying the Vulnerabilities
The first step was to identify where OpsRamp uses Log4j for logging. We executed a Python script on all of our own infrastructure to find Log4j dependencies. The biggest vulnerability was in the OpsRamp Cloud servers. Our Classic Gateway and Windows Gateway both use Log4j internally but only in modules that are not exposed to outside communications. We found no Log4j dependencies in our agent, cluster gateway, apps and adaptors, or synthetic collectors.
Taking Action
On December 9, the Apache Software Foundation disclosed the Log4j vulnerability on the project’s GitHub. On December 10, we applied the recommended fix, upgrading our Log4j instances to the 2.16 version, which removes the compromised functionality. This upgrade was carried out across all OpsRamp Cloud servers in all geographies. No further action was required of our customers and partners.
Though the threat to our Classic Gateway and Windows Gateway was very low, we nonetheless made a fix available to customers to remove even this slight threat. Both gateways sit behind customer firewalls, which reduces the threat, but also requires customers and partners to make the fix themselves.
On December 13, we made an initial mitigation patch available to customers for the Classic Gateway. A week later, on December 20, we delivered a permanent fix for the Classic Gateway. Meanwhile, we delivered a mitigation patch for the Windows Gateway on December 14.
How OpsRamp Helped Customers to Remediate Log4j
With its powerful built-in automation and remediation capabilities, OpsRamp helped its customers to detect and remediate Log4j vulnerabilities without any human intervention.
By following the three steps below, customers can create custom scripts with OpsRamp’s Process Definition feature to find and remediate or take other custom actions on vulnerabilities.
Step 1: Script Deployment for Finding Log4j
Step 2&3: Searching for Log4j vulnerabilities and executing the auto remediation steps on the servers using process definitions and script capability
Going Forward
We did not find any Log4j attacks in our cloud servers or our customers’ gateways and have remediated any potential vulnerabilities. We’ve also made our Python script that detects Log4j instances available to our customers to use in their own internal and cloud infrastructure that we monitor. Our Shared Services team stands ready to assist customers to root out any other Log4j vulnerabilities they may discover.
Next Steps:
- Read the Blog: Security FAQ: How OpsRamp is Responding to Recent Cybersecurity Attacks
- Read the Blog: Patch Management Lessons for the Next Big Enterprise Security Breach
- Read the Whitepaper: The OpsRamp Platform: Security and Compliance
