The Continued Risk of Log4j

The Log4j vulnerability turned into a fun fire drill for most companies/security teams. Fortunately, the impact from the vulnerability was less than most anticipated. However, due to companies having to scramble there are definitely strong take aways moving forward and as the vulnerability stays open within environments attacker will find a way to take advantage of it.

What does this mean for the future of cybersecurity?

This type of vulnerability puts the icing on the cake as far as what we have seen over the last couple of years in relation to vulnerabilities and patching (IE: Exchange, Solarwinds, VPN, etc.). Many leaders tend to think of vulnerabilities as flaws in a particular product or application, making impact assessments and patching exercises comparatively simple. This vulnerability changed the game because it underscores a fundamental challenge with the software supply chain because Log4j is used by dozens of the largest tech companies to build thousands of dissimilar software products. This made identifying impact challenging as there needed to be a discovery process and it wasn’t easy for any organization to know if they were impacted. At the end of the day, software is never going to be bullet proof and vulnerabilities will arise in any application.  

Log4j Continued usage

• Because Log4j is widely used by software developers, attackers can use this one vulnerability to compromise organizations that use thousands of downstream applications in the digital supply chain.  

Future Impact

• The most concerning impact is where attackers use this vulnerability to breach potentially thousands of otherwise uncompromised organizations.  
• While the widely publicized global patching effort and relative difficulty to successfully exploit this flaw will mitigate some concern, we expect many public facing systems to remain unpatched for years to come.  

• Because internal applications are often considered lower priority for patch management programs, attackers will likely use the Log4j vulnerability for lateral movement within already-compromised environments for the foreseeable future.  

How can we prevent something like this from taking place again?

Log4j was a rude awakening and has resurfaced and reinforced older ideas that focus on mitigating the challenges the software supply chain brings to the table. CISA has done a great job starting the process towards a stronger standard. One of ideas that is gaining traction is the Software Bill of Materials (SBOM) approach or simply put an “ingredients list.” This would be a list that organizations can reference to quickly understand what their exposure is based on the applications they use. This would reduce the “fog of war” and enable businesses to assess risk and impact faster as they will have a reference point. It would also expedite cleanup and make these unfortunate situations much more manageable. This is a great step forward as most companies had to make difficult business-impacting decisions quickly without understanding the scope of their potential exposure. The next step as mentioned by CISA with SBOMs would be to enable businesses to automatically assess if they are vulnerable so that they can begin remediation and cut down the exposure time. This of course won’t happen overnight but would be a great goal to strive for.

Best practices in reducing your blast radius and improving security posture

Businesses need to have the capability to quickly respond and take action on these types of vulnerabilities (i.e., asset management, vulnerability scanning, etc.) however they should assume compromise and take actions on reducing the blast radius (i.e., Endpoint Detection and Response (EDR), Managed Detection and Response (MDR), segmentation, zero trust architecture, etc.).  

Has this vulnerability been leveraged recently and is this going to become an issue in the future?

Yes, a recently discovered botnet targets Linux systems and uses exploits targeting the Log4j vulnerability. Due to vendors using the vulnerable Apache Log4j logging library this botnet will be successful.

In addition to hackers leveraging the vulnerability, the attack surface continues to expand which is rare to see with a known vulnerability. There are vulnerable Log4j packages that remain downloadable that are being used! In addition to that Qualys pulled data recently that showed 30% of the Log4j instances on the internet are still vulnerable.  

Even though Log4j wasn’t as impactful as the industry thought it would be, it doesn’t mean it won’t turn into a burning issue in the future. The cyber security landscape is different than most in the sense that attackers will continue to leverage low hanging fruit for most targets until they can’t, and they then need to change their tactics. It’s hours not weeks or months for them to pivot to a different vulnerability/tactic and the businesses that didn’t address it would then be the first target. The recently leaked conversations from Conti show how quickly the groups will pivot as needed.

If you have questions about the Log4j vulnerability or need help with a current incident, you can contact a MOXFIVE Technical Advisor at ask@moxfive.com or use our Contact form.