shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moritz Bechler (JIRA)" <>
Subject [jira] [Commented] (SHIRO-550) Pre-authentication deserialization vulnerability
Date Fri, 06 May 2016 11:03:12 GMT


Moritz Bechler commented on SHIRO-550:

5 months and no fix.... This is really really serious, should get a CVE and a security fix
released ASAP.

Shiro even comes with a dependency on commons-beanutils (which transitively depends on commons-collections),
both of which contain exploitable gadgets so one must assume that almost every user of shiro
is exploitable.

Side note: the deserialization classloading is buggy with regards to array types - that breaks
some of the public gadgets - but I can assure you that this can be worked around.

I think both needs to be done:
- disable remember me by default.
- randomize the key (so that enabling it would not mean direct RCE, also the current default
behavior allows the client to send whatever principals he likes)

> Pre-authentication deserialization vulnerability
> ------------------------------------------------
>                 Key: SHIRO-550
>                 URL:
>             Project: Shiro
>          Issue Type: Bug
>          Components: RememberMe
>    Affects Versions: 1.2.4
>            Reporter: Tim Stibbs
> The way shiro is set up by default exposes a web application to deserialization attacks.
This is dangerous anyway, but particularly in light of the recent exploits using commons-collections
for more info).
> By default, shiro uses the {{CookieRememberMeManager}}. This serializes, encrypts and
encodes the users identity for later retrieval. Therefore, when it receives a request from
an unauthenticated user, it looks for their remembered identity by doing the following:
> * Retrieve the value of the {{rememberMe}} cookie
> * Base 64 decode
> * Decrypt using AES
> * Deserialize using java serialization ({{ObjectInputStream}}).
> However, the default encryption key is hardcoded, meaning anyone with access to the source
code knows what the default encryption key is. So, an attacker can create a malicious object,
serialize it, encode it, then send it as a cookie. Shiro will then decode and deserialize,
meaning that your malicious object is now live on the server. With careful construction of
the objects, they can be made to run some malicious code (see link above for more detail).
> Note this is not theoretical; I have a working exploit using the [ysoserial commons-collections4
and http client. I can provide my test code if required.
> I understand that this requires your shiro to be set up using the default remember me
settings, but in my case my application doesn't even make use of the remember me functionality
(there’s no way for the user to ask to be remembered), so I didn't even consider that I
needed to secure this part. Yet, my application still has this vulnerability.

This message was sent by Atlassian JIRA

View raw message