Uploaded image for project: 'Shiro'
  1. Shiro
  2. SHIRO-550

Randomize default remember me cipher

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.4
    • Fix Version/s: 1.2.5
    • Component/s: RememberMe
    • Labels:
      None

      Description

      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 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.

        Issue Links

          Activity

          Hide
          ankon Andreas Kohn added a comment -

          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.

          Show
          ankon Andreas Kohn added a comment - 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.
          Show
          ankon Andreas Kohn added a comment - Went ahead with that in https://github.com/Collaborne/shiro/commit/71114398cadb47e49384638df0a4b79fb3120f8a
          Hide
          mbechler Moritz Bechler added a comment -

          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)
          Show
          mbechler Moritz Bechler added a comment - 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)
          Hide
          richard.bradley Richard Bradley added a comment -

          > This is really really serious, should get a CVE and a security fix released ASAP.

          +1
          I understand that Open Source projects may or may not be actively maintained, and that you use them at your own risk, but It seems to me to be simply irresponsible to be distributing Apache Shiro when it has a known RCE attack in its default configuration.
          It seems to me that Shiro is not safe to use (in its default configuration) while this bug is open and a deprecation warning should be put on the Shiro homepage until this can be fixed.
          I don't see this on Metasploit yet, but is that what is needed for this to get any attention?

          > 5 months and no fix.

          The underlying bug, SHIRO-441, that the RememberMe key is hardcoded and publicly available (and enabled by default) has been open since May 2013, so I'd say this has been open for 3 years.

          I've tried to cross-reference the recent committers in git with the mailing list to see who is responsible for Shiro.

          Brian Demers – do you have commit rights? Are you a Shiro maintainer? Do you agree that this needs attention ASAP and that all Shiro users need to be alerted that their webapps have an easy RCE attack hole wide open?
          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?

          I'll email the dev list as well

          Show
          richard.bradley Richard Bradley added a comment - > This is really really serious, should get a CVE and a security fix released ASAP. +1 I understand that Open Source projects may or may not be actively maintained, and that you use them at your own risk, but It seems to me to be simply irresponsible to be distributing Apache Shiro when it has a known RCE attack in its default configuration. It seems to me that Shiro is not safe to use (in its default configuration) while this bug is open and a deprecation warning should be put on the Shiro homepage until this can be fixed. I don't see this on Metasploit yet, but is that what is needed for this to get any attention? > 5 months and no fix. The underlying bug, SHIRO-441 , that the RememberMe key is hardcoded and publicly available (and enabled by default) has been open since May 2013, so I'd say this has been open for 3 years. I've tried to cross-reference the recent committers in git with the mailing list to see who is responsible for Shiro. Brian Demers – do you have commit rights? Are you a Shiro maintainer? Do you agree that this needs attention ASAP and that all Shiro users need to be alerted that their webapps have an easy RCE attack hole wide open? 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? I'll email the dev list as well
          Hide
          bdemers Brian Demers added a comment -

          I have a fix locally, I'll submit it soon

          Show
          bdemers Brian Demers added a comment - I have a fix locally, I'll submit it soon
          Hide
          mbechler Moritz Bechler added a comment -

          Went ahead and notified a few people listed as references on the project page where I could easily identify (almost certainly) vulnerable instances.

          Show
          mbechler Moritz Bechler added a comment - Went ahead and notified a few people listed as references on the project page where I could easily identify (almost certainly) vulnerable instances.
          Hide
          ankon Andreas Kohn added a comment -

          Richard Bradley:

          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?

          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 Brian Demers though, it seems there is some movement again

          Show
          ankon Andreas Kohn added a comment - Richard Bradley : 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? 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 Brian Demers though, it seems there is some movement again
          Hide
          richard.bradley Richard Bradley added a comment -

          Thanks, Andreas.
          My email didn't seem to make it through to the shiro-dev mailing list. I have re-sent it.

          Brian, do you think it is worthwhile doing any of:
          1. Creating a CVE for this issue
          2. Notifying users of Apache SHIRO about the issue
          3. Suspending downloads of the current vulnerable-by-default version, until a fix can be released?

          Show
          richard.bradley Richard Bradley added a comment - Thanks, Andreas. My email didn't seem to make it through to the shiro-dev mailing list. I have re-sent it. Brian, do you think it is worthwhile doing any of: 1. Creating a CVE for this issue 2. Notifying users of Apache SHIRO about the issue 3. Suspending downloads of the current vulnerable-by-default version, until a fix can be released?

            People

            • Assignee:
              Unassigned
              Reporter:
              tstibbs Tim Stibbs
            • Votes:
              1 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development