[
https://issues.apache.org/jira/browse/SHIRO-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Demers updated SHIRO-550:
-------------------------------
Fix Version/s: (was: 2.0.0)
> Randomize default remember me cipher
> ------------------------------------
>
> Key: SHIRO-550
> URL: https://issues.apache.org/jira/browse/SHIRO-550
> Project: Shiro
> Issue Type: Bug
> Components: RememberMe
> Affects Versions: 1.2.4
> Reporter: Tim Stibbs
> Fix For: 1.2.5
>
>
> 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 (see
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
> 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
> exploit|https://github.com/frohoff/ysoserial/blob/master/src/main/java/ysoserial/payloads/CommonsCollections2.java]
> 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
(v6.3.4#6332)
