CODEWITHSUNDEEP
spring-securityspring-remoting
btburt
btburt

Reputation: 61

Spring HttpInvoker vulnerable to recent deserialization exploit before authentication?

The recent Foxglove Security article on Java deserialization attacks with links to example code for targeting major app servers, as well as Spring and Groovy apps, is raising lots of consternation. The article states that these exploits bypass authentication because the object payload is deserialized before authentication checks are done. It doesn't specifically name or discuss Spring HttpInvoker, though, and I haven't been able to find a clear statement on this elsewhere.

For remote services exposed via Spring HttpInvoker, using Spring Security with Basic authentication, would the authentication check be performed before the (potentially malicious) object payload is deserialized? Or does the article's assertion that "authentication won't protect you from this attack" apply to HttpInvoker services as well?

Upvotes: 2

Views: 2789

Answers (2)

Robert Beltran
Robert Beltran

Reputation: 494

I'd google for the ysoserial payload generator. Create payloads with each option and then curl it to your endpoint with the correct content type set. We did that here at my work and were amazed that we could execute code remotely on our dev servers.

Upvotes: 0

btburt
btburt

Reputation: 61

Decided to test this out on my own. To test the sequence of events in processing an inbound HTTP Invoker service call, I set up a simple little Spring Boot starter app as follows:

  • One HelloWorld service exposing one simple hello() method that takes a custom HelloDto object as an input parameter.
  • Custom serialization logic in HelloDto to log both serialization and deserialization.
  • Spring Security Basic authentication used to protect the service.

I cranked logging up to Debug level for Spring Security and Spring Remoting, then invoked the HelloWorldService remotely via a simple JUnit test client. I confirmed via the console log that Spring Security is both authenticating and authorizing the caller before the deserialization occurs.

As I thought through the sequence of events, this makes sense. Spring Security is implemented as a filter chain whereas the HTTP Invoker logic is handled by a DispatcherServlet that would logically get control after the filters have executed up-front.

If any of the Spring gurus can confirm that this is an accurate interpretation (or especially if there are any obscure "edge cases" where deserialization could still bite us before the caller is authenticated), that would be much appreciated.

Upvotes: 4

Related Questions