Just what can be accomplished when webhooks are allowed to access internal services, Cider Security takes a look specifically at abusing GitHub and GitLab webhooks to access internally hosted Jenkin instances.

The core idea is pretty simple, a lot of companies running Jenkins want their source-code management (SCM) service like GitHub or GitLab to be able to kickoff contiuous integration pipelines on their CI service like Jenkins. To enable this they may have a blanket allow statement for the SCM IPS to access Jenkins. This whitelisting may not be limited just to kicking off specific events however. So this posts what could be done if the webhooks could access any of the Jenkins endpoints.

They found a few things out.

1. GitLab will follow redirects, but GitHub will not. While webhooks will be POSTs, a 302 redirect will strip the body and make a GET request. This can be used to access GET endpoints on Jenkins with GitLab redirects. Though as each request is stateless abusing this is more complicated to access authenticated GET endpoints.
2. Jenkins will access parameters as part of the URL or the POST body. So while you cannot control much of the webhook body, you can provide all the necessary parameters through the URL.

These allows them to craft three chains against Jenkins:

1. Authentication brute-force. This could be performed using both GitHub and GitLab webhooks. Effectively just crafting a POST request with the username/password in the URL. Both services allow you to see the response so seeing whether or not the request gets redirected to the Jenkin’s mainpage indicates whether or not the login was successful. While this is theoritically possible, I do question the practicality of it, given the speed of the attempts.
2. Access to authenticated GET endpoints. This only worked with GitLab webhooks, but the login request also accepted a from parameter. The login request would be redirected to this endpoint upon successful login. By setting this to (for example) a pipeline’s /consoleText endpoint the console output of a pipeline could be accessed.
3. The last chain is a remote-code execution abusing a 2019 vulnerability that could result in RCE from a single GET request. This vulnerability was discovered and documented by Orange Tsai