Skip to content

Category: Security

CVE-2023-34034: Spring Security Authorization Bypass

CVE-2023-34034 is another authorization bypass in Spring Security. Like CVE-2022-31692 it’s nasty because it allows completely unrestricted access to supposedly protected resources. Also like CVE-2022-31692 it requires very specific configuration to be vulnerable and is easily fixed.

This post demonstrates the vulnerability, the problem configuration and suggested fixes. A demonstration vulnerable application is on GitHub.

CVE-2022-42889 Text4Shell vulnerability in Apache Commons Text

CVE-2022-42889 Text4Shell is a vulnerability in the Apache Commons Text library. Like previous brand-name vulnerabilities Log4Shell and Spring4Shell, it’s a Remote Code Execution (RCE) vulnerability that allows a bad actor to run arbitrary code on the host machine. However it’s less likely to be exploitable as it requires a very specific use of the library to be vulnerable.

It affects Apache Commons Text 1.5 to 1.9 and was fixed in 1.10. However, as we’ll see later the application code can still be vulnerable to other attacks even in the fixed version.

Spring4Shell

The Spring4Shell (CVE-2022-22965) critical severity vulnerability in Spring Framework allows remote code execution (RCE). At time of writing, it can be exploited only in very specific scenarios. However, Spring have made a patch available (Spring Framework version 5.3.18 and 5.2.20) and I strongly advise you to take them, even if you’re not running the exploitable setup.

Spring Security delegating password encoder

The Spring Security PasswordEncoder interface exists to make it easy to safely encode passwords for storage in a database. Hashing the password using a secure algorithm with a heavy work factor will slow down an attacker even if they compromise the password database.

Since the interface was introduced, security recommendations have changed as CPUs / GPUs become more powerful and as vulnerabilities are discovered in legacy algorithms. The original StandardPasswordEncoder is now deprecated as the SHA-256 algorithm is considered insecure. Spring offers more secure implementations based on bcrypt, PBKDF2 and Argon2.

However, Spring no longer ties you to a single algorithm. The new DelegatingPasswordEncoder provides support for multiple PasswordEncoder implementations, many of which are available in Spring Boot applications with default configuration. This makes it possible to select an algorithm at run time and to have a database containing password hashes with different algorithms.

Securing a Zookeeper ensemble

In the previous post, we looked at how to build a three cluster Zookeeper ensemble. However, the ensemble was not secured in any way. This would allow unauthorised clients to query Zookeeper and to push data to znodes. It also allows unauthorised Zookeeper instances to join the ensemble and potentially even instruct the cluster to shut down.

Even in secured networks, it’s a good idea to use some of the security features available in Zookeeper. In this post we’ll look at two security mechanisms: mutual TLS (mTLS) and SASL authentication. We’ll set up these security features on the server-server communication (leader election protocols) and client-server communication (Kafta to Zookeeper).

Thymeleaf and Spring Security

Thymeleaf is a popular templating engine, particularly with Spring projects. Spring Boot has chosen Thymeleaf as the view technology of choice, largely replacing the need for JSP. With old JSPs, custom tag libraries provided integration with various technologies, including Spring Security. A similar library exists to integrate Thymeleaf and Spring Security – the Thymeleaf Spring Security Integration module.

Hashing and Salting passwords with Spring Security PasswordEncoder

A standard Spring Security configuration uses username / password based authentication. This always presents a tricky problem: how to securely store a user’s password in such a way that it can’t be read by anyone with access to our database. It’s naive to assume that our password database is 100% secure, just ask Adobe, Sony, Ashley Madison, and every other large organization that has had their database breached. Even if the database isn’t ‘breached’ or ‘leaked’, legitimate database admins or sys admins still have access to user passwords. A database containing user passwords is a liability that we’d rather not have.

The standard solution to this problem is store store a hash of the password rather than the plain text or even encrypted text. I don’t want to focus on why this is good or how it works as many others have done this already. I’ve found no better discussion of this (and password management in general) than Troy Hunt’s post on Everything you ever wanted to know about building a secure password reset feature.

Getting the details right when implementing password storage is critical. Some hash algorithms are vulnerable or just not suited to password hashing. If the salt is too short or predictable, it may be possible to retrieve the password from the hash. Any number of subtle bugs in coding could result in a password database that is vulnerable in one way or another. Fortunately, Spring Security includes password hashing out of the box. What’s more, since version 3.1, Spring Security automatically takes care of salting too.

User Impersonation with Spring Security SwitchUserFilter

A common requirement for secured applications is that admin / super users are able to login as any other user. For example, it may be helpful for a customer support analyst to access a system as if they were a real specific customer. The obvious way to do this is for the admin user to ask for the customer’s password or look it up in the password database. This is usually an unacceptable security compromise – no one should know a customer’s password except for the customer. And if the password database is implemented correctly it should be technically impossible for anyone – not even a system admin or DBA – to discover a user’s password.

An alternative solution is to allow admin users to login with their own unique username and password but allow them to then impersonate any other user. After the admin user has logged in, they can enter the username of another user and then view the application as if they were logged in as that user. Implementing user impersonation in this way also has the advantage that the system knows who has really logged in. If the system has an audit log, we can audit actions against the real admin user, rather than the impersonated user.