Spring4Shell, Log4j and a few good tips for staying secure

By Idan Sofer May 5th, 2022

Well it is now safe to say that the season of Java vulnerability exploits is upon us. In the wake of massive zero day attack vectors such as Log4Shell (discovered Dec 2022) and his younger sibling Spring4Shell (discovered Mar 2022), it is becoming clear that Java based Zero Day attacks are here to stay. Java vulnerabilities usually exploit loop holes in widely used Java libraries, to expose an application to remote code execution (RCE). From here the back door is open to various threats that can potentially bring down an entire organization.

So here are a few top line facts about the log4j and Spring4Shell, you may find interesting:

Log4Shell/log4j/log4j 2

Log4Shell is a critical vulnerability (CVE-2021-44228, CVSSv3 10.0) which affects several versions of Apache Log4j 2. It was introduced publicly by the project’s GitHub on December 9, 2021.

The vulnerability allows for unauthenticated remote code execution. Log4j 2 is an open source Java library developed by the Apache Foundation and is widely used in enterprise applications and cloud services.

The vulnerability, designated as CVE-2021-44228 is commonly referred to as “Log4j”, it allows attackers to take over vulnerable and sensitive resources spanning across and entire ecosystem. To perform remote code execution, an attacker simply sends a malicious request that contains a formatted string that is then picked up by the log4j library.

According to CVE log4shell exposed various vulnerabilities that could deeply impact a business or organization:

1. CVE-2021-45046 log4shell made it possible for attackers to craft malicious input data that could cause an information leak or remote code execution.
2. CVE-2021-44228 log4shell allowed attackers to execute random code using the message lookup functionality.
3. CVE-2021-45105 log4shell left the door open for an attacker to initiate a denial-of-service attack by causing an infinite recursion loop on self-referential lookups.
4. CVE-2021-44832 log4shell gave attackers control of the target LDAP server could launch a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI.

Spring4Shell/SpringShell

Spring4Shell is a newly discovered critical vulnerability in the Java Spring Framework. Because of Spring’s wide adoption, many organizations and businesses might potentially be heavily impacted.

Spring is an open source framework; 60% of developers use Spring for their Java applications.

Spring4Shell exploits remote code execution (RCE) to execute code and/or extract data. Remote code execution allows an attacker to access application data, and penetrate infrastructure and cloud assets. It may also allow an attacker to access management resources to circumvent permissions and security rules.

Unfortunately Spring4Shell is no longer theoretical:

• In the first weekend since the vulnerability was found Check Point Research spotted ~37K attempts to allocate the Spring4Shell vulnerability
• During the first 4 days 16% of the organizations worldwide were impacted by exploitation attempts
• Software vendors are the most impacted industry where 28% of the organization were impacted
• The most impacted region seen is Europe, with an impact of 20%

Spring Framework has released a new version to fix this vulnerability. Affected users can download it from the following link:

https://github.com/spring-projects/spring-framework/tags 

Spring4Shell is one of three vulnerabilities published on March 30:

1. Spring Core RCE (critical): CVE-2022-22965 a.k.a. Spring4Shell or SpringShell
   Affected library: org.springframework:spring-bean
2. Information exposure in Spring Cloud Function: CVE-2022-22963
   Affected library: org.springframework.cloud:spring-cloud-function-context
3. Denial of service in Spring Expressions: CVE-2022-22950
   Affected library: org.springframework:spring-expression

One more thing that should be mentioned in this context, is that unfortunately, in these cases, by the time you fix them, you’re already too late:

According to IBM’s 2021 Cost of Data Breach Report, the average total cost of a data breach sits at 4.24 million dollars.

The worst part of this is that it takes an average of 287 days to identify and contain a breach.

The good news? There are ways to prevent them and in some cases even detect them before they are able to cause any serious damage… So to put your mind at ease – we’ve compiled a quick list of the (wait for it…)

10 most common Java vulnerabilities your team should be looking out for:

1. Code Injections

Every application susceptive to input is potentially vulnerable to code injections. This occurs when an attacker identifies a vulnerability which allows him to insert malicious code through the input and trigger various actions and/or return data.

Code injections are very common, and are actually pretty easy to execute. In 2010, a Japanese developer noticed that you could send HTML as tweets. Exploiting a vulnerability to inject JavaScript inside the HTML, he triggered a Twitter worm.

What did this little piece of code do?

Every time a user would hover over a specific pixel planted with the HTML, they would instantly retweet the worm. So when one of their followers was scrolling through, they might just retweet that little worm. This led to over 3000 retweets within a mere few minutes.

Though Twitter doesn’t exclusively use Java in its stack, a cautionary event can be applied to protect your inputs. The most common method is to apply input validation including output sanitizing and escaping. This means that attempts at sending HTML code will be parsed or rejected, depending on your application design.

2. Command Injections

An OS command injection better known as a Shell injection, allows attackers to execute shell commands on an application server.

PHP is relatively an easy target for command injections because it calls a sh/bash/cmd by default.

Java, contains limited protocols using a fork() of the given command to create child processes and pass given arguments. However, this is not full proof measures to prevent an injection.

Legacy products can also act as an ideal entry ways for shell command injections, since the code is usually less visible and may contain patches and outdated practices.

As a prevention measure, you might need to issue a command line to your server – like sending a confirmation email. Rather than using Runtime.exec() to tap into a server, it’s better to use the available Java API located at javax.mail.*

3. Connection String Injection

Connection strings are a set of definitions used to connect an application to a data source. Including, among others: relational databases, LDAP directories or individual files. Connection string attacks happen when a bad actor gains access by injecting parameters into the connect strings using semicolons as separators.

There are four parameters that an attacker would need to complete this type of penetration:

1. The data source
2. The initial catalog
3. The user id
4. The password

From here on the attacker is free to create his own brand of havoc…

Since some database providers have no limit cap and run on a ‘last one wins’ algorithm, an attacker can run multiple connection injection strings, with duplicate parameters effectively “tricking” the database to accept the combinations as valid.

As a result, the attacker ends up bypassing the standard authentication process without getting locked out. Once in, the malicious user can modify credentials manipulate or return data and execute malicious code.

4. LDAP Injection

An LDAP injection uses input validations to inject executable queries. LDAP ( Lightweight Directory Access Protocol) is an open, cross platform protocol, used for directory service authentication.

LDAP is a communication language which applications use to access directory servers which usually store PII and other sensitive information.

LDAP injections occur when unsanitary inputs are pushed from the application directly into an LDAP statement. The attacker can then use the LDAP filter syntax causing the server to execute malicious queries and LDAP statements.

The best practice in this case is to ensure that LDAP special characters – ( ) ! | & * are escaped or rejected upon validation.

5. Reflected XSS

A reflected XSS A.K.A reflected cross site scripting, is a penetration method by which an attacker adds malicious scripts which are activated through a web link that redirects the user to a different location. For instance, a reflected XSS can be seamlessly embedded into a web page as an input, link or button. The user may click on it and end up going to a 3rd party site and then redirected back to the original site. Whilst at the 3rd party, malicious activities such as cookie or session stealing may occur.

Although it’s hard to monitor reflected XSS, spam filters on links submitted can help reduce these threats.

6. Resource Injection

Resource injections occur when the resource identifiers used by an application are altered to perform malicious tasks. This might span from changing a port number or modifying a file name, all the way to gaining the ability to access additional sensitive resources.

For example, an attacker could gain access to a e-commerce site via connection string injection, or successfully steal users’ details via XSS. He can now modify or query details using resource injection. Your attacker is now able to cause real damage by completing transactions, modifying or stealing PII and collect additional information about your customer without their knowledge.

7. SQL Injection

SQL injection is the process of injecting SQL within data requests resulting in the backend application giving back confidential data or executing malicious scripting within the database.

This can result in a complete compromise on the host, access to data and breaches of privacy. Furthermore, SQL injection can lead to data loss or corruption, and might lock one out of his own database. When this happens, the injection has completed its take over

The easiest precaution is making sure that you validate on the server-side. Frontend inputs can be bypassed and the backend serves as a backstop to block unwanted characters, such as spaces and ‘ ‘ quote marks, to trickle through.

8. Second Order SQL Injection

Second order SQL injection is a twostep process. First, the attacker adds something to your application but doesn’t immediately execute it. They might be waiting for more data or waiting for a trigger activity.

This is where second order SQL injection differs from normal SQL injections.

The attacker injects code into the table row, which is deemed as a trusted source. That table row is then called, causing the attack to move from its dormant state to active execution.

Testing for second order SQL is harder because of its often covert nature.

For example, the malicious user signs up with the username ‘ or ‘hacker’=’hacker

This means that ‘ or ‘hacker’=’hacker gets stored in the database.

Then when you go to login, the user name completes the validation query, giving access to other users and their account details.

9. Stored XSS

Stored XSS, A.K.A persistent XSS attacks take place when script is injected into the content of a website or app. Unlike reflected XSS in which third party links are embedded, store XSS is far more dangerous in that it doesn’t require the user to interact with it.

Social media sites are particularly vulnerable to stored XSS attacks because of the platform’s nature. Users are encouraged to post and interact.

XSS is also commonly known as web worms, where the user ends up with the offending element and it executes on the browser. This attack can lead to stolen cookies, account information or some additional function through account impersonation.

XSS can be triggered in four places and is often done through JavaScript – @post.title, post.url, @post.id and @post.footer_attr

To prevent this, rejecting or escaping special characters likes < > and @ before parsing it can be useful.

10. XPath Injection

While JSON is the rising star for data structuring, XML documents are still popular and widely used. XPath is the syntax used for defining parts of an XML document. The idea behind XPath injections is similar to SQL injections.

The only difference between SQL injection and XPath is that XPath is in an XML format.

This permits the attacker to browse XML documents, gaining access to sensitive data such as username and password on other PII details.

In most cases, an XPath injection happens when a query is built on invalidated inputs. To prevent XPath injections it is recommended to use precompiled XPaths. Refrain from permitting full expressions from an unsecured source. If you must parametrize your XPath, use string only parameters to prevent your query from getting hijacked.

Usually, validating user inputs prior to consuming them is the simplest way to prevent potential threats. It’s easy to offload the task over to the frontend, but they are only the first line of defense that’s not always guaranteed to hold.

While Java can be frontend and backend simultaneously, it’s still good practice to check that whatever your user gives you is what you expect it to be. Setting up your validation parameters may be a matter of identifying and specifying what’s allowed, rather than trying to figure it out and eliminate everything else.

While Java is considered relatively safe, mainly because it’s a server side language, there are still multiple ways to attack and access it, so make sure to adhere to best practices and stay up to date and take a look at these 3 tips to get you started:

1. Major security vendors are already offering AI based early detection and remediation, this means you detect early signs of anomalous behavior and block it immediately before wide spread damage or leaks can be caused.
2. Your security people should always keep up to date with the latest threats and research
3. Adopting emerging practices such as secops, devsecops etc. and gaining full visibility, automation, prevention, detection and remediation (all in the price of one) throughout your organization and applications – making security an integral part of your development and services (without slowing you down).