Log4Shell, the vulnerabilities and the panic that ensued – What have we learned?
Log4Shell, the vulnerabilities and the panic that ensued - What have we learned?
What are the Log4Shell vulnerabilities?
At the end of 2021, a year already full of 0-days and emergency patching, security researchers discovered a number of vulnerabilities in the open-source Java package Log4j which is utilised in a wide array of Java based applications for logging.
The vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-4104) allowed attackers to download and execute malicious code and in many cases trigger ransomware infections, gain privileged and persistent access to infrastructure and steal sensitive information.
Why did it take so long to fix?
The first workaround recommendations were not effective and did not actually prevent the vulnerability from being exploited, along with initial iterations of patches also proving ineffective, and this was just for the package itself, not for third party software that bundles Log4j with it.
Even now, many organisations continue to struggle to quickly issue patches to their product suites due to the issues stated above, but also based on whether the JNDI lookup functionality that was disabled in the workaround impacted their products, in some cases lack of security knowledge and also the chain reaction of waiting for the original package owners to patch, then to perform their own assessments and approval processes.
Do we have this deployed in our networks and applications?
For many organisations this was an extremely difficult question to answer!
Due to lack of visibility when it comes to software asset management, lists of installed software not capturing the package as it was part of other applications and sometimes complete lack of any vulnerability management capability a lot of organisations could not quickly and confidently confirm whether Log4Shell impacted them, let alone begin to address the vulnerabilities.
What can we do to stop this from happening again?
Visibility is absolutely essential when identifying security risks and speed of that visibility is just as important.
Being able to readily identify software deployed within your organisation provides you with impact and scope and allows for effective action in vulnerability remediation.
Being able to scan your systems on a regular and ad-hoc basis allows you to not only quickly identify key vulnerable systems, but also gives you the ability scrutinize your patching efforts and qualify whether your systems are protected.
Missing out key systems from patches or deploying ineffective workarounds could be the difference between you being compromised or not.
How can Zepko help with this?
If you would like to discuss Log4Shell/Log4j in greater detail and would like to find out more about some real-world scenarios and process and technology driven solutions, please contact us.
You will be happy to hear Zepko provide a multitude of services that will help protect your organisation against these issues.
Here is an example SOC service purpose built to protected against this threat – Uranus – DLP, VM, SIEM, MDR, IDS
Specifically, our services would help in the following ways:
We have seen across our customer base that even 6 months on, attackers scan for this vulnerability on network perimeters more than anything else which is why having IPS deployed is so important. Not only will the IPS rules prevent attackers from scanning for the vulnerability, it also blocks known exploit types. IPS block rules were deployed to prevent Log4Shell exploits before patching was possible ensuring a quick and effective layer of protection was in place.
Our vulnerability management service allowed our customers to quickly identify systems exposed to Log4Shell vulnerabilities across their networks and also re-trigger scans after patching to ensure that the vulnerability was completely remediated.
Not only did EDR/MDR provide our customers with the ability to prevent exploit attempts on endpoints, it also allowed for quick access to lists of exact files and locations on those hosts to identify third party applications and archived files vulnerable to Log4Shell.
In the case of a successful exploit, Data Loss Prevention will help prevent sensitive information from being exfiltrated from your networks and provide a clear indication of the scope of any files accessed.
Combining the solutions listed above with our SOC and SIEM service along with the knowledge of our security experts, we were able to quickly protect our customers against the Log4Shell vulnerabilities, provide effective vulnerability remediation guidance, provide visibility into exploit attempts and maintain assurance for our customers that they are well protected.