Gitpod is a service from Gitlab that allows for spinning up fresh, automated dev environments for each task in the cloud. You can login to Gitpod with your GitLab, GitHub, or Bitbucket account and then use a pretty full-blown, web-based development environment to work on your code, run tests, or even spin up services and expose them from your Gitpod instance to the internet.
Gitpod holds an OAuth token with full API access to all of the major Git hosting providers. Because of this, the author decided to take a look at the platform.
The product spins up a random workspace name. Once it has booted, all ports of tasks happen from exposed ports to many other things. The web-based IDE uses websockets to communicate with gitpod.io. Using a Cross-Origin WebSocket attack, it is possible to call the API on behalf of the other user. They made the call from another custom domain, which is why it's cross origin instead of cross site>.
The next attack allowed to login as any account. On Gitpod, a user can add custom integrations. When using a self-hosted Gitlab, it makes sense that you would want to be able to use Gitpod on a self-hosted instance. The author had a big what if moment: " What if I could use a self-hosted instance to log into Gitpod?"
In the end, an attacker could set the redirect_uri and client_id values to match those of the self-hosted instance. Because this was technically an OAuth provider, the service blindly accepted the request back. As a result, you can login as any user on the Gitpod.
The fix for the previous bug was to validate that the pod user matched the domain of the iDP. This host check can be found at
here on Github.
Feature rich applications leave room for complicated business logic attacks. Both of these attacks only made sense within the context of the application, requiring a good understanding of the website.