Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - SANS Internet Storm Center InfoSec Handlers Diary Blog

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Java Springtime Confusion: What Vulnerability are We Talking About

Published: 2022-03-30
Last Updated: 2022-03-30 21:50:20 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

Today, I spent a lot of time working through different issues regarding Java. "Spring4Shell" was one name that has been assigned to at least one of the vulnerabilities. In this post, I am trying to clean up some of the issues around the different vulnerabilities and Java frameworks.

First of all, we are talking about two different frameworks here:

Spring Core: This is the very widely used "Spring" framework. It is open-source and very popular for enterprise applications.
Spring Cloud: As the name implies, the Spring Cloud framework helps create cloud applications. 
Spring Expression Language (SpEL): A language used to configure Spring integration components.

All of this is part of the overall Spring Framework [1]. The company VMWare supports Spring.

So what vulnerabilities are we talking about? Let's start with the "easy" one that has a CVE number and is acknowledged by the Spring project:

CVE-2022-22963 [2]

This vulnerability in Spring Cloud was made public on March 29th. It fixes a vulnerability in the routing functionality. The original announcement assigns it a CVSS score of 5.4. But the score may not be correct. The advisory only mentions that an attacker may get access to other local resources. But remote code execution exploits have been published.

The exploit takes advantage of a crafted SpEL message that is passed in the header. Serverless functions written in Java may be vulnerable, but that would depend on them being exposed to the header.

A typical exploit will include a header like [3]: T(java.lang.Runtime).getRuntime().exec("{cmd}")'

Unnamed Vulnerability/Spring4Shell

This is the issue that started a lot of the speculation earlier. It was first raised in some tweets on March 29th, which were later deleted, and a blog post [4]. It was first described as a deserialization vulnerability and associated with a particular patch committed to Spring [5].

For this vulnerability, our handler Bojan was able to get one of the publicly available exploits to work. But there are likely many different ways to exploit this vulnerability. The exploit requires several requests to achieve code execution. First, it reconfigured logging, limiting logging to a particular header, and logging the content of the header to a specific file. Finally, the code is sent to be written to the file, and lastly, the code is executed. There may be a number of different ways how this can be exploited.

What Should You Do?

Don't panic :). Next, keep your eye out for patches, and apply them as they become available. A patch for the second issue has been committed to git, but no official new version has been released, and this issue has not yet been acknowledged as a vulnerability in Spring. You may configure web application firewalls to block the header triggering the first issue. The second issue is a bit more tricky. But watching for unusual custom headers is likely helpful. It also requires write permissions for the server inside the document root, which is a bad idea for many reasons and should be avoided.

Lunasec published an excellent post with more details here:



Johannes B. Ullrich, Ph.D. , Dean of Research,

0 comment(s)

Possible new Java Spring Framework Vulnerability (Updated: not a Spring problem)

Published: 2022-03-30
Last Updated: 2022-03-30 14:26:57 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

Last night, news broke that the Java Spring framework may release an update fixing a significant security vulnerability. The project added a patch to the Spring framework GitHub repository that appears to fix a deserialization vulnerability [1]. 

A blog post published around that time includes some additional details [2]. However, the comment by Sam Brannon released with the git commit (scroll down to the end of the page for [1]) does explain the patch:

The purpose of this commit is to inform anyone who had previously been using SerializationUtils#deserialize that it is dangerous to deserialize objects from untrusted sources.

The core Spring Framework does not use SerializationUtils to deserialize objects from untrusted sources.
There is no CVE and no official announcement from Spring at this time. But it may be a good idea to find your Log4j notes as your response will likely be similar.

Do not confuse this vulnerability with CVE-2022-22963 (I have already seen some posts mixing up the two). CVE-2022-22963 is a vulnerability in Spring Cloud Function, not in the spring framework. It was patched yesterday and appeared already to be probed based on our honeypot. For example, we do see requests like this:

THIS IS CVE-2022-22963, NOT spring4shell

POST /console/images/%252e%252e%252fconsole.portal HTTP/1.1
Host: a.b.c.d:7001
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Connection: close
Content-Length: 147
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip





Johannes B. Ullrich, Ph.D. , Dean of Research,

2 comment(s)

Quickie: Parsing XLSB Documents

Published: 2022-03-30
Last Updated: 2022-03-30 07:32:47 UTC
by Didier Stevens (Version: 1)
0 comment(s)

Inspired by Xavier's diary entry "XLSB Files: Because Binary is Stealthier Than XML", I took a look at Microsoft's XLSB specification.

This confirmed my hopes: the binary format of XLSB files is a sequence of TLV records, just like BIFF. At least for sheets and shared string tables, I haven't looked at the other file formats yet.

The type and length of each TLV record is a variable length integer: from 1 to 2 bytes (type) and from 1 to 4 bytes (length). It's stored in little-endian format, and the least significant bytes have all their most significant bit set. The most significant byte has its most significant bit cleared. 7 least significant bits are used to encode the integer value. This implies that the highest value for a type integer is number 16383.

I wrote a simple parser, it is still in beta:

Didier Stevens
Senior handler
Microsoft MVP

Keywords: maldoc xlsb
0 comment(s)
ISC Stormcast For Wednesday, March 30th, 2022
Diary Archives