[
https://issues.apache.org/jira/browse/SHIRO-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013781#comment-15013781
]
Andreas Kohn commented on SHIRO-550:
------------------------------------
I'm in a similar situation: our application doesn't need/use/want remember-me
functionality.
For me to fix the problem at its core it seems I just need to ensure that we're
using a different serializer, and/or that the security manager is configured
with a dummy RememberMeManager.
For Shiro in general it seems these steps would be sensible:
1. Change the DefaultWebSecurityManager constructor to not set the
CookieRememberMeManager, and
2. Change shiro.ini to explicitly spell out what needs to be done to enable
remember-me functionality (set the manager, and configure the serializer).
Additionally it would also be good to just kill the hardcoded secret, and
replace it with some documentation on how to produce one.
> Pre-authentication deserialization vulnerability
> ------------------------------------------------
>
> 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
>
> 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)
