25 Jan Hard lessons you can learn from the Log4j catastrophe
Our friends of Rohde & Schwarz address the lessons we can take away from the Log4j default, and reflect more generally onthe problem of compromised software components, that can be an unwanted entry door in information systems. The good news is that the European Cybersecurity industry has the solutions to protect your data!
Is there a way to prevent, detect and protect yourself when the next Log4j hits?
Well, it is possible and we will show you how to do it in this article. Being proactive is definitely one way to stop Log4j and its variants. But there are more and we will get to it.
Log4j has been lurking in the news headlines since its discovery in December 2021. It seems to be more ominous than any other case of late due to its immense usage in Java solutions. Any Java web application using Log4j is vulnerable and can be hacked. This presents a giant opportunity for exploitation to hackers everywhere as they can now perform a remote code execution (RCE) attack on any target computer.
In fact, there have been massive attempts to exploit the Log4j vulnerability in the wild. By easily exploiting the java naming and directory interface (JNDI) lookups feature exposed by Log4j in log messages, hackers can hack into your application, run any code they want, steal your sensitive data and take full control of your system. So you can imagine why companies, governments and individuals all around the globe are under such huge pressure. It is due to the extensive impact and seriousness of this vulnerability.
A real incident that tends to impart some significant lessons to us all. Let’s have a look in depth.
A wakeup call for less mature organizations
One of the main things we have learnt from Log4j is that you need to be always prepared to deal with zero day attacks. Keep monitoring your environment, logging and reporting any issues to check if you are being attacked. You need to have a proper process outlined for vulnerability assessment in the company. Such processes will tell you what the existing risks are, their criticality, which are the vulnerable components and products, if they are exploitable etc. You need alert logs and access logs that will help you look back and grasp any tentative exploitation. You can equip your teams with security orchestration, automation and response (SOAR) technologies that extract information related to threats from logs. Security information and event management (SIEM) tools can also be helpful to identify exploitation activities in real-time.
Scaling your response to zero-day attacks
Big organizations like google cloud platform (GCP) were prepared and so able to manage the risk well. They ensured that their customers upgraded to the newest available version of Log4j quickly. Any vulnerable images were prevented from being deployed in production. You also need to have the best crisis response actions in place, scale up patching of the affected systems, to reduce any further exposure. Zero-day attacks are inevitable in everyday life. They are potent and costly attack tools. When the worst happens, you should be able to invoke the best practices diligently. Only prepared companies will succeed in times of such disasters.
One of the main things we have learnt from Log4j is that you need to be always prepared to deal with zero day attacks. Keep monitoring your environment, logging and reporting any issues to check if you are being attacked. You need to have a proper process outlined for vulnerability assessment in the company.
Third-party components can lead to insecure code
Disasters happen more likely due to third party dependencies. For example, even if your company is not using Log4j directly, you might be dependent on another third-party library that uses it. In fact, most of the Java applications using Log4j use it indirectly. You need to keep all third-party products updated to their latest versions. We saw that the vulnerability has not affected the latest Log4j versions. Ask your software vendors if they are covering themselves from this flaw.
Many organizations focus on static application security testing (SAST) tools as a part of their DevSecOps implementation, but we see that early adopters are engaging more with software composition analysis (SCA) tools these days. Even less mature customers are realizing the need for SCA tools to report instances of CVEs like Log4j and know which applications are running such vulnerabilities.
Being cautious when choosing your open source libraries
Log4j is one of the open source logging libraries that helps Java developers keep track of their applications’ past behavior. Code in millions of internet facing devices worldwide use Log4j. However, open source code is out there for everyone to see and very few people actually maintain it. You need to pay heed to the community size. This incident does not necessarily tell that all open source software components that companies have embedded in their tools are hazardous. However, more security researchers should watch these open-source projects for any changes and search for possible vulnerabilities in their code sources, like the Log4j vulnerability. Do not hesitate to participate in an open source project (reporting bugs, proposing improvements, providing bug fixes, etc…)
Introducing a proactive approach to prevent zero day attacks
Vulnerabilities like the Log4j prompt you to develop a zero trust mindset, build cloud automation and rethink your entire application security posture. To contain such vulnerabilities effectively, you need an intelligent web application & API protection (WAAP) solution. However, do not rush into buying any such solution. Take the time to assess your options in the market.
At Rohde & Schwarz Cybersecurity, we have seen no evidence of exploitation among our 600+ customers. Here is why:
- Generic signatures prevent zero day events
We already had all the rules in place to block Log4j, which means we covered our clients already on every web facing applications. In fact, 88% of most zero day attacks are blocked by our web application and API protection (WAAP) solutions, without having to customize the rule set.
- Custom rules are the best defense!
While you should focus on generic signature-based protection, you need to react quickly if something is not included in it. For events like this, we are able to respond immediately to the issue with our WAAP Gateway and SaaS WAAP, generating the right custom rules, to ensure that no exploitation occurs. It is well known that writing custom rules can be difficult, giving rise to a high false positive rate. However, this has been one of our reputable characteristics in the market.
Check out the advisory Rohde&Schwarz Cybersecurity has issued for their customers for more insights:
Invest in next generation application security tools from a trusted vendor with the right custom rules that also prevent false positives. And you can enjoy your peace of mind.
Stéphane de Saint Albin, Président de Rohde & Schwarz Cybersecurity SAS – Vice-Président d’Hexatrust
www.rohde-schwarz.com/cybersecurity
