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
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 firstname.lastname@example.org or use our Contact form.
MOXFIVE provides the clarity and peace of mind needed for attack victims during the incident response process. Our platform approach enables victims of attacks to work with a Technical Advisor who provides the expertise and guidance needed in a time of crisis, and facilitates the delivery of all technical needs required, consistently and efficiently.Learn More
With experience on the front lines responding to incidents daily, MOXFIVE Technical Advisors have the unique ability to connect the dots between business, information technology, and security objectives to help you quickly identify the gaps and build a more resilient environment.