[
https://issues.apache.org/jira/browse/SHIRO-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277862#comment-15277862
]
Andreas Kohn commented on SHIRO-550:
------------------------------------
[~richard.bradley]:
{quote}
Andreas Kohn – you have recent commits in
https://git-wip-us.apache.org/repos/asf?p=shiro.git , but it sounds from your
comments above that you are not a Shiro maintainer?
{quote}
Correct. I'm not a Shiro maintainer, but I'm using a fork of Shiro in our
application. The reason for that is actually very related to this issue: No
feedback on filed issues. Thanks to [~bdemers] though, it seems there is some
movement again :)
> 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)
