The maintainers behind the popular open-source library Spring recently posted a patch to address a CVE that – if exploited – could grant local resource access to an attacker∗.
After the Log4j incident, all users of that library – or any other application or platform that includes the Spring library – should immediately update to a patched version. The lessons learned from the Log4j incident grant insight into the possible impact of this type of vulnerability, and we should all learn from them:
Underlying open-source libraries can be part of many different third-party applications deployed within an organization. Spring is a popular library for Java-based or Java-integrated platforms due to the wide variety of features it enables for a web application and/or platform. This means that there is a high likelihood that applications already being used by the organization have Spring integrated into them and therefore are subject to exploitation of this vulnerability.
Communicating with your vendors now to determine if they utilize Spring in any form is a vital step toward preparing for the inevitable exploits we will see in the coming days and weeks.
Home-grown applications must be updated/patched quickly; take the downtime now. VMware (the maintainer of Spring) has been transparent about the vulnerability and quick to supply working patches for all supported versions of the library. There is a possibility that legacy applications are using now-unsupported versions of Spring, and may require coding work to allow those apps to use the more recent (and currently supported) versions of the library.
Where a current library version is being used, patches must be applied immediately – even if this requires downtime to perform the patching operation. The slower patching timelines seen for Log4j when that library was part of business-critical applications led to weeks of successful attacks as automated scanning discovered app after app that had not been fully updated due to waiting for change control windows and/or budget for code changes.
Direct attacks are not the only goal of threat actors. With Log4j, while the initial wave of attacks was most definitely attempting to breach and manipulate resources on the servers hosting the library itself, secondary waves mere days later utilized the vulnerability as the first part of a multi-stage attack that included lateral movement and ransomware techniques∗∗
Failure to identify and patch all instances (first- and third-party) of Spring could lead to the same pattern of attacks, and the same fallout from their success.
Spring, and its popularity, are creating an equal level of threat against first- and third-party web applications and organizational infrastructure. Let’s learn the lessons of Log4j and get out ahead of the situation before the problem makes the news.
Start simulating the latest cyberattacks today with a 14-day free trial of Cymulate’s Extended Security Posture Management platform.