Just Because You Don’t Use Log4j or Spring Beans Doesn’t Mean Your…

By now, you’re probably all aware of the recent Log4j and Spring Framework vulnerabilities.

As a recap, the Log4j vulnerability – made public on December 10, 2021 – was the result of an exploitable logging feature that, if successfully exploited, could allow attackers to perform an RCE (Remote Code Execution) and compromise the affected server.

The Spring Framework vulnerability – made public on March 29, 2021 – was caused by unforeseen access to Tomcat’s ClassLoader as a result of the new Module feature added in Java 9. The access could potentially allow an attacker to write a malicious JSP file accessible via the application server.

Just because your organization is not using a vulnerable version of Log4j or Spring does not mean that you are not using a Java component or development framework that relies on Log4j or Spring Beans. For example, Apache Struts2, ElasticSearch, Apache Kafka, among others, call on Log4j.

Our co-founder and CTO, Chris Wysopal explained:

“There might be applications that you have good visibility into and you find rather quickly, but it is challenging to find all your Java applications. The other challenge is, of course, vendor applications that are written in Java. You know, we saw this withHeartbleedmany years ago — which kind of kicked off the whole third-party risk — that a lot of vendor applications were written with the OpenSSL library and you had to wait for your vendor to patch that. And the same thing could happen here. “A lot of appliances, a lot of packaged software using Java, so I would expect people to be asking their vendors when they’re going to be patched.”

Wysopal’s solution? “Software will not become more secure until open-source software becomes more secure,” he said. You could add SBOMs to open-source libraries, but you really should not rely on an open-source team to track the vulnerabilities. Your organization needs to have its own tools and processes in place.

Open-source libraries are being increasingly leveraged as a way to speed up development. In fact, our recent State of Software Security (SOSS) report unveiled that 97 percent of the typical Java application is made up of open-source code. And 77 percent of flaws in third-party libraries remain unfixed after three months.

That said, our SOSS report also found that there has been a noticeable improvement in time to remediation for third-party flaws. Back in 2017, it would take over three years to get to the 50 percent (half-life) closed point, and now it takes just over a year.

It’s great to see that many organizations are starting to realize the importance of finding and fixing open-source flaws. But there’s still a long way to go.

In terms of open-source library developers, we need to be giving them free scanning tools and more recognition to individuals who uncover bugs.

For organizations, Wysopal suggests putting a process in place for selecting open-source libraries to ensure that the libraries you select are free from vulnerabilities. He also suggests investing in scanning tools like software composition analysis (SCA) to catch open-source flaws in your applications before moving them to production.

Veracode SCA uncovers third-party flaws introduced directly by a developer or indirectly. Our tool then quickly and effectively addresses open-source risk by accurately highlighting where you have open-source vulnerabilities and if they are in your application’s execution path.

Once you have an SCA tool in place, you should add a policy regarding what level of risk is deemed “not acceptable” in production and prioritize those fixes. Flaws with lower criticality should still be addressed, but only after highly critical flaws are remedied.

Log4j and Spring Framework are not the only vulnerabilities of concern. It’s important to be proactive as opposed to reactive. Learn more about our open-source capabilities by scheduling a demo.

Source

By now, you’re probably all aware of the recent Log4j and Spring Framework vulnerabilities.

As a recap, the Log4j vulnerability – made public on December 10, 2021 – was the result of an exploitable logging feature that, if successfully exploited, could allow attackers to perform an RCE (Remote Code Execution) and compromise the affected server.

The Spring Framework vulnerability – made public on March 29, 2021 – was caused by unforeseen access to Tomcat’s ClassLoader as a result of the new Module feature added in Java 9. The access could potentially allow an attacker to write a malicious JSP file accessible via the application server.

Just because your organization is not using a vulnerable version of Log4j or Spring does not mean that you are not using a Java component or development framework that relies on Log4j or Spring Beans. For example, Apache Struts2, ElasticSearch, Apache Kafka, among others, call on Log4j.

Our co-founder and CTO, Chris Wysopal explained:

“There might be applications that you have good visibility into and you find rather quickly, but it is challenging to find all your Java applications. The other challenge is, of course, vendor applications that are written in Java. You know, we saw this withHeartbleedmany years ago — which kind of kicked off the whole third-party risk — that a lot of vendor applications were written with the OpenSSL library and you had to wait for your vendor to patch that. And the same thing could happen here. “A lot of appliances, a lot of packaged software using Java, so I would expect people to be asking their vendors when they’re going to be patched.”

Wysopal’s solution? “Software will not become more secure until open-source software becomes more secure,” he said. You could add SBOMs to open-source libraries, but you really should not rely on an open-source team to track the vulnerabilities. Your organization needs to have its own tools and processes in place.

Open-source libraries are being increasingly leveraged as a way to speed up development. In fact, our recent State of Software Security (SOSS) report unveiled that 97 percent of the typical Java application is made up of open-source code. And 77 percent of flaws in third-party libraries remain unfixed after three months.

That said, our SOSS report also found that there has been a noticeable improvement in time to remediation for third-party flaws. Back in 2017, it would take over three years to get to the 50 percent (half-life) closed point, and now it takes just over a year.

It’s great to see that many organizations are starting to realize the importance of finding and fixing open-source flaws. But there’s still a long way to go.

In terms of open-source library developers, we need to be giving them free scanning tools and more recognition to individuals who uncover bugs.

For organizations, Wysopal suggests putting a process in place for selecting open-source libraries to ensure that the libraries you select are free from vulnerabilities. He also suggests investing in scanning tools like software composition analysis (SCA) to catch open-source flaws in your applications before moving them to production.

Veracode SCA uncovers third-party flaws introduced directly by a developer or indirectly. Our tool then quickly and effectively addresses open-source risk by accurately highlighting where you have open-source vulnerabilities and if they are in your application’s execution path.

Once you have an SCA tool in place, you should add a policy regarding what level of risk is deemed “not acceptable” in production and prioritize those fixes. Flaws with lower criticality should still be addressed, but only after highly critical flaws are remedied.

Log4j and Spring Framework are not the only vulnerabilities of concern. It’s important to be proactive as opposed to reactive. Learn more about our open-source capabilities by scheduling a demo.

Source

More from author

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Related posts

Advertismentspot_img

Latest posts

Apple patches zero-day kernel hole and much more – update now! – Naked Security

Apple's latest security updates have arrived. All still-supported flavors of macOS (Monterey, Big Sur and Catalina), as well as all current mobile devices (iPhones, iPads,...

Half of global CISOs feel their organization is unprepared to deal with cyberattacks

Human error is considered by IT executives to be the biggest vulnerability for organizations...

What IT leaders from BlackBerry, CN and Microsoft Canada and more predict for the future of InfoSec

In his decades-long career in cybersecurity and threat detection, John McClurg has engaged in the "perpetual dance" with adversaries large and small. "As the years...

Want to stay up to date with the latest news?

We would love to hear from you! Please fill in your details and we will stay in touch. It's that simple!