Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Release Branch 4.0, Release Branch 09.04, SVN trunk
    • Fix Version/s: None
    • Component/s: framework
    • Labels:
      None

      Description

      This issue was first brought up here: https://sourceforge.net/forum/message.php?msg_id=7496877

      Basically, any user with PARTYMGR_CREATE/UPDATE permissions can set the password of another user. This creates opportunity for Malfeasance. For example, a customer service rep could set the password of the admin user.

      A simple solution would be to create a new security permission PARTYMGR_PASSWD and require that permission for setting or changing password of a different user, instead of using PARTYMGR_UPDATE. PARTYMGR_PASSWD could then be associated with the administrative user.

      An alternative is to use the SECURITY_UPDATE permission instead of PARTYMGR_UPDATE or a new PARTYMGR_PASSWD permission.

        Issue Links

          Activity

          Hide
          Michele Orru added a comment -

          As I've specified in in SF thread, and as Si correctly pointed to me, this is a logic flaw: SecurityPermissions can be as granular as we want, but basically what is happening here is that 90% of the users will use the permissions that are already in the ofbiz seed data.

          Then, if we combine this flaw with the many XSRF exploitables points that are present in ofbiz, we can use an attack vector like the following:

          document.body.innerHTML += '<form id="maliciousform" action="http://localhost:8080/partymgr/control/updatePassword" method="post"><input type="hidden" name="userLoginId" value="euronymous666"><input type="hidden" name="partyId" value="10010"><input type="hidden" name="currentPassword" value="blabla"><input type="hidden" name="newPassword" value="passwordwedontknow"><input type="hidden" name="newPasswordVerify" value="hardpasswd"><input type="hidden" name="passwordHint" value=""></form>';
          document.getElementById("maliciousform").submit();

          If this code (embedded in a properly formatted page) will be executed by *any user with PARTYMGR_UPDATE privileges in the application, then even the admin password can be changed.

          A simple example is an e-commerce website based on the ofbiz trunk code: the website have a "MyAccount" page for customers, where they can modify their profiles. Almost all the time, for lack-of-time, or for requirements, the services/permissions that will be used will be the same of ofbiz. Thus, when creating a SecurityGroup for such "CUSTOMER" users, we will use a PARTYMGR_UPDATE permission, to let the users update their profiles (and for instance to prevent access to partymgr application, without giving them PARTYMGR_VIEW permission).

          In this hypothetical situation (but not so far from reality), if the user can embed JS code in some parts of the application, the game is over: we change the ADMIN password, and we have full control of the application.

          I've already committed a patch in opentaps trunk.

          :::Michele Orru':::
          Network& Security Manager, IntegratingWeb.com
          http://www.integratingweb.com

          Show
          Michele Orru added a comment - As I've specified in in SF thread, and as Si correctly pointed to me, this is a logic flaw: SecurityPermissions can be as granular as we want, but basically what is happening here is that 90% of the users will use the permissions that are already in the ofbiz seed data. Then, if we combine this flaw with the many XSRF exploitables points that are present in ofbiz, we can use an attack vector like the following: document.body.innerHTML += '<form id="maliciousform" action="http://localhost:8080/partymgr/control/updatePassword" method="post"><input type="hidden" name="userLoginId" value="euronymous666"><input type="hidden" name="partyId" value="10010"><input type="hidden" name="currentPassword" value="blabla"><input type="hidden" name="newPassword" value="passwordwedontknow"><input type="hidden" name="newPasswordVerify" value="hardpasswd"><input type="hidden" name="passwordHint" value=""></form>'; document.getElementById("maliciousform").submit(); If this code (embedded in a properly formatted page) will be executed by *any user with PARTYMGR_UPDATE privileges in the application, then even the admin password can be changed. A simple example is an e-commerce website based on the ofbiz trunk code: the website have a "MyAccount" page for customers, where they can modify their profiles. Almost all the time, for lack-of-time, or for requirements, the services/permissions that will be used will be the same of ofbiz. Thus, when creating a SecurityGroup for such "CUSTOMER" users, we will use a PARTYMGR_UPDATE permission, to let the users update their profiles (and for instance to prevent access to partymgr application, without giving them PARTYMGR_VIEW permission). In this hypothetical situation (but not so far from reality), if the user can embed JS code in some parts of the application, the game is over: we change the ADMIN password, and we have full control of the application. I've already committed a patch in opentaps trunk. :::Michele Orru'::: Network& Security Manager, IntegratingWeb.com http://www.integratingweb.com
          Hide
          Scott Gray added a comment -

          If I'm not wrong the logged in user would also have to have the PARTYMGR_VIEW permission in order to be able to submit the form to the partymgr app. With that in mind how valid is this issue?

          Show
          Scott Gray added a comment - If I'm not wrong the logged in user would also have to have the PARTYMGR_VIEW permission in order to be able to submit the form to the partymgr app. With that in mind how valid is this issue?
          Hide
          Si Chen added a comment -

          Somebody can use a CSR's credentials to try to reset a password, such as for an administrative user, either by a scripted attack or URL hacking. Or, if that part of the system is made available to Web services, that's another way to access the backend of the system without having to use the form in your party manager. For how a simple fix is required to address this issue, it would make sense to do it to prevent this kind of risk.

          Show
          Si Chen added a comment - Somebody can use a CSR's credentials to try to reset a password, such as for an administrative user, either by a scripted attack or URL hacking. Or, if that part of the system is made available to Web services, that's another way to access the backend of the system without having to use the form in your party manager. For how a simple fix is required to address this issue, it would make sense to do it to prevent this kind of risk.
          Hide
          Si Chen added a comment -

          A couple of other security enhancements which I think should be made:

          1. the user's password should be checked, even if he is changing his own password

          2. the admin user's password should be checked as well before he is allowed to change any passwords

          Otherwise, there is the risk of a low-tech "coffee break attack": the user or the admin user steps out for a five-minute coffee break, and somebody comes in, sits down at his terminal, and starts changing passwords

          Show
          Si Chen added a comment - A couple of other security enhancements which I think should be made: 1. the user's password should be checked, even if he is changing his own password 2. the admin user's password should be checked as well before he is allowed to change any passwords Otherwise, there is the risk of a low-tech "coffee break attack": the user or the admin user steps out for a five-minute coffee break, and somebody comes in, sits down at his terminal, and starts changing passwords
          Hide
          Si Chen added a comment -

          Jacques,

          Why has this been reclassified as a "subtask" instead of "bug"?

          Show
          Si Chen added a comment - Jacques, Why has this been reclassified as a "subtask" instead of "bug"?
          Hide
          Jacques Le Roux added a comment -

          Hi Si,

          The only goal is to group security related issues together : easier to follow progress on.

          Show
          Jacques Le Roux added a comment - Hi Si, The only goal is to group security related issues together : easier to follow progress on.
          Hide
          Jacques Le Roux added a comment -

          I think Michele and Si are right on this. It's as simple as "More security is better than less".
          Michele did a good work explaining this here
          On the other hand too bad no code was provided to OFBiz, is there anything blocking Michele?

          Show
          Jacques Le Roux added a comment - I think Michele and Si are right on this. It's as simple as "More security is better than less". Michele did a good work explaining this here On the other hand too bad no code was provided to OFBiz, is there anything blocking Michele?
          Hide
          Michele Orru added a comment -

          Hi Jacques,

          I'm too much busy on multiple different works, but I will took a look at the latest Ofbiz trunk
          and come back with a patch.

          Did I have access to your SVN?

          :::Michele Orru':::
          Network& Security Manager, IntegratingWeb.com
          http://www.integratingweb.com

          Show
          Michele Orru added a comment - Hi Jacques, I'm too much busy on multiple different works, but I will took a look at the latest Ofbiz trunk and come back with a patch. Did I have access to your SVN? :::Michele Orru'::: Network& Security Manager, IntegratingWeb.com http://www.integratingweb.com
          Hide
          Jacques Le Roux added a comment -

          Hi Michele,

          You have an access to read for sure. For a patch you don't need write access. Simply attach it here, don't forget to check the ASF Granted License.

          http://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Source+Repository+and+Access

          Thanks!

          Show
          Jacques Le Roux added a comment - Hi Michele, You have an access to read for sure. For a patch you don't need write access. Simply attach it here, don't forget to check the ASF Granted License. http://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Source+Repository+and+Access Thanks!
          Hide
          Jacques Le Roux added a comment -

          Ping

          Show
          Jacques Le Roux added a comment - Ping

            People

            • Assignee:
              Unassigned
              Reporter:
              Si Chen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development