In our organisation's internal security audit another vulnerability which enables logged in user to gain admin permissions was found. This vulnerability is non-deterministic in nature (ie. there are no exact steps to reproduce it 100% of the time) so it is a bit hard to describe but I will do my best with the information I got:
The userrepo plugin creates the repository with (temporarily) elevated permissions. In some rare conditions it is possible that the permissions are not restored to the original level and as a result, the user session continues with administrator privileges.
The SCM Manager application logs show a lot of repository creation activities and Java errors during the issue:
10:58:26.926 [TP-Processor28] INFO sonia.scm.web.security.DefaultAdministrationContext - user testuser executes sonia.scm.userrepo.CreateUserRepositoryAction as admin 10:58:26.926 [TP-Processor28] INFO sonia.scm.repository.DefaultRepositoryManager - create repository Testing2 of type git 10:58:26.946 [TP-Processor28] ERROR sonia.scm.userrepo.UserRepositoryResource - could not create new repository java.lang.RuntimeException: sonia.scm.repository.RepositoryAllreadyExistExeption
We think this may be a some kind of threading issue and that's why it is not always reproducible. It may require that several threads try to create the same repository at the same time. In the normal user flow of things, this would never happen, but using a vulnerability scanner with multiple concurrent scanning threads does just that.
Additionally, it may require that the creation thread crashes. The SCM Java code in DefaultAdministrationContext.java uses a try-finally block to handle the privileged run and the finally block downgrades the privileges. However, if the thread created in the try block dies, the finally block is never executed.
Steps you could try to reproduce this:
- Obtain, install and execute OWASP ZAP 2.0
- Start browser and configure it to route all traffic via the ZAP local proxy.
- Log in to SCM Manager as non-privileged user (we have LDAP users, YMMV).
- Create a repository so that the creation plugin URL is caught by ZAP.
- Configure ZAP Analyse -> Scan policy to scan only
- LDAP injection
- all SQL injections Disable the rest.
- Ensure you have at least 3 concurrent threads (5 is the best bet) per host in Tools->Options->Active Scan.
Right click on the SCM site host name on the ZAP Sites tab. Select Attack -> Active scan site in the context menu.
When the active scan has finished, refresh your SCM front page and you will hopefully find yourself logged in as scmadmin. Since the creation tests are run somewhere in the middle of the test run, you can test your userid status by refreshing the SCM front page even in the middle of the scans.
This works about 50% of the time. If it does not work the first time, log out and log in again. Ensure that your new session id is selected active in the Http Sessions -tab. Rerun the Active scan and it hopefully works.