Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
Date: Fri, 6 May 2016 11:03:12 +0000 (UTC)
From: "Moritz Bechler (JIRA)" <jira@apache.org>
To: dev@shiro.apache.org
Message-ID: <JIRA.12914414.1447928138000.127551.1462532592832@Atlassian.JIRA>
In-Reply-To: <JIRA.12914414.1447928138000@Atlassian.JIRA>
References: <JIRA.12914414.1447928138000@Atlassian.JIRA> <JIRA.12914414.1447928138667@arcas>
Subject: [jira] [Commented] (SHIRO-550) Pre-authentication deserialization
 vulnerability
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 06 May 2016 11:03:14 -0000


    [ https://issues.apache.org/jira/browse/SHIRO-550?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D15273=
916#comment-15273916 ]=20

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 th=
e current default behavior allows the client to send whatever principals he=
 likes)


> 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 deseriali=
zation 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-applic=
ation-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, whe=
n it receives a request from an unauthenticated user, it looks for their re=
membered 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 acc=
ess to the source code knows what the default encryption key is. So, an att=
acker can create a malicious object, serialize it, encode it, then send it =
as a cookie. Shiro will then decode and deserialize, meaning that your mali=
cious object is now live on the server. With careful construction of the ob=
jects, 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 [ysoseri=
al commons-collections4 exploit|https://github.com/frohoff/ysoserial/blob/m=
aster/src/main/java/ysoserial/payloads/CommonsCollections2.java] and http c=
lient. 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=E2=80=99s no way for the user to as=
k 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)