We touched on a similar issue last week in Zabbix where the ability to access the setup process after it was complete could lead to compromising the system. In this situation no extra trickery was necessary as it appears to have been a bad conditional allowing reentry to the setup functionality.
if (string.IsNullOrEmpty(text) && Dynamicweb.Content.Management.Setup.SetupCompleted())
{
base.Response.Redirect("/Admin");
}
The above code probably meant to use || instead of &&, creating the condition of, if text is empty or SetupCompleted() redirect to /Admin. Instead as the && is used, it only redirects when both conditions are true, if an attacker provides an action, it won’t redirect and will go to the HandleAction method of the setup.
HandleAction provides the usual suite of setup functionality like copying files to the system, setting database configuration information, and creating administrative users.
I want to say the root of this issue is from trying to determine by name whether an identifier is a commit hash or a branch name. While git allows the creation of branches consisting of 40 hex characters, GitHub will reject the branch. GitHub however, does not reject branch names that copy short-hashes.
Using a047be8 as an example. If that was both a short-hash for a commit, and a branch name, github.com/someone/some-repo/tree/a047be8 would resolve to the branch a047be8. If that branch were ever deleted then it would resolve to commit. This edge case can lead to an interesting bug.
- Create a branch with a name consisting only of hex characters
- Create a pull-request from another branch to this new branch
- Delete the original branch, causing the PR to be closed
- Create a commit with a short hash matching the branch name (https://github.com/not-an-aardvark/lucky-commit)
- Reopen the PR
Even though the PR is against a non-existent branch, it will resolve to the commit hash instead. Why does this matter? If that commit has a GitHub Action’s workflow, then when the PR is reopened the workflow at the base of the branch of the PR will be run, since that now resolves to the commit, the attackers workflow can be run with access to the GITHUB_TOKEN for the victim repository.
A lot of steps and user interaction involved with this attack, but its a cool edge case.
Multiple bugs in Carbon Black and vRealize Operations Manager, authentication bypassing through proxy trickery, server-side request forgery, credential leaking, and ultimately RCE.
VMWare Carbon Black - Authentication Bypass
Two core issues leading to an authentication bypass, first being that the SERVICE_USER role is overly permissive. Any service could generate a JWT that had all permissions, regardless of what the service actually needed. This was exposed on an internal endpoint /acs/api/v1/service-token/{serviceName}. Getting access to this internal endpoint was the more interesting issue.
This endpoint under normal circumstances could not be reached from external sources, the front end Envoy proxy that handling incoming requests would route /acs/ routes to the correct place, but there was a particular rule in place rewriting requests matching /acs/api/v1/service-token/ so it wouldn’t be found. The problem is that Envoy by default would not normalize URLs, whereas the receiving Tomcat server would. So by encoding one of the characters in the path, they could craft a url that would get routed for /acs/ but not match the service-token rule: /acs/api/v1/%72ervice-token/.... Granting them a SERVICE_USER token.
VMware vRealize Operations Manager
Server-Side Request Forgery
Pretty standard SSRF here, the casa/nodes/thumbprints endpoint would take an array of addresses, and respond with the page contents. With no checks it could be directed to internal endpoints such as 127.0.01/casa/private/security/passwordsync to reveal administrative password hashes.
Credentials Leak
Using the same SSRF, by making a request to an attacker controlled server, the Authorization header would include a super-user’s credentials that could be replayed against other endpoints.
Password Reset
The password reset endpoint at PUT /casa.os/slice/user only required a username and new password, no additional verification to ensure you know the current password (likely by design to allow administrators to change user credentials). This could be abused to change the admin account and login over SSH for RCE.
Path Traversal
A straight forward path traversal using the /casa/private/config/slice/ha/certificate API one could directly upload a .jsp webshell and include path traversal in the name to write it into the webroot if they know the location.