Skip to content

Instantly share code, notes, and snippets.

@kidd0123
Last active March 31, 2022 23:23
Show Gist options
  • Save kidd0123/c89ff8bd21454a2da2c429fd8cc228b2 to your computer and use it in GitHub Desktop.
Save kidd0123/c89ff8bd21454a2da2c429fd8cc228b2 to your computer and use it in GitHub Desktop.
Understanding spring4Shell Severity

I have done a bit more research on the vulnerability itself and want to share the details in writing to better help my own understanding of the vulerability - before you read further two things

  • My java knowledge is extremely dated.
  • Everything I mention here is already explained in other blogs but its more of a summation and simplification.

When you use spring-boot to build a web application you can take the request parameters (POST) and convert that into an object for easy access. (Java being an Object oriented programming language it makes sense to do this)

Java doesn’t natively support json so they can Jackson or other ways (a library to convert things to json). But it also gives the ability to convert it into a regular java object. These are called POJO ( abbr for plain old java code)

You can do this in spring-boot using @RequestMapping annotation See this example from lunasec blog post.

public class Greeting {
    private long id;

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }
}

@Controller
public class HelloController {
    @PostMapping("/greeting")
    public String greetingSubmit(@ModelAttribute Greeting greeting, Model model) {
        return "hello";
    }
}

so lets say you have a request to a post endpoint localhost:8080/testEndpoint=input. You can pass an arbitrary classname that exists and accepts parameters instead of testEndpoint to overwrite. The vulerability here is this ability to pass a class name that allows the overwrite. In tomcat they found an older technique of list of classes that has these parameters available to craft the exploit. The blog post: https://hacksum.net/2014/04/28/cve-2014-0094-apache-struts-security-bypass-vulnerability/ has a long list of classes available on tomcat. (its interesting to note that this technique of overwriting classes is also used in Apache Struts vulnerability which is pretty old)

# Tomcat 6 :
class.classLoader.searchExternalFirst
class.classLoader.clearReferencesLogFactoryRelease
class.classLoader.jarPath
class.classLoader.antiJARLocking
class.classLoader.clearReferencesStopThreads
class.classLoader.clearReferencesStopTimerThreads
class.classLoader.clearReferencesThread.classLoader.clearReferencesThread
.
.classLoader.defaultAssertionStatus
class.classLoader.resources.dirContext.docBase
…
 # Tomcat 8:
class.classLoader.resources.context.parent.pipeline.basic.domain
class.classLoader.resources.context.parent.pipeline.first.encoding
class.classLoader.resources.context.parent.pipeline.first.directory
class.classLoader.resources.context.parent.pipeline.first.checkExists
class.classLoader.resources.context.parent.pipeline.first.prefix
class.classLoader.resources .context.parent.pipeline.first.rotatable
class.classLoader.resources.context.parent.pipeline.first.renameOnRotate
class.classLoader.resources.context.parent.pipeline.first.buffered
class.classLoader.resources.context.parent. pipeline.first.suffix
class.classLoader.resources.context.parent.pipeline.first.fileDateFormat
class.classLoader.resources.context.parent.pipeline.first.locale
class.classLoader.resources.context.parent.pipeline.first.requestAttributesEnabled
class.classLoader.resources.context.parent.pipeline.first.pattern
class.classLoader.resources.context.parent.pipeline.first.condition
class.classLoader.resources.context.parent.pipeline.first.conditionUnless
class.classLoader.resources .context.parent.pipeline.first.conditionIf
class.classLoader.resources.context.parent.pipeline.first.enabled
class.classLoader.resources.context.parent.pipeline.first.asyncSupported
...

One of the main reasons why a lot of java devs don’t consider this as a serious issue and bring the point noted here: https://github.com/tweedge/springcore-0day-en#check-yourself

All this smells of "How can I make an app that's exploitable" vs. "How can I exploit this thing that exists?"

See this SO question for example. Its very unlikely to write a production app where you do not explicitly write the translations. https://stackoverflow.com/questions/31986357/spring-mvc-parameter-binding

Tl;dr; This is not log4j and I will sleep peacefully.

Resources:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment