The hidden dangers of numerical IDs

Web applications have so many different objects, and it’s important to be able to uniquely identify all of these through the use of primary keys. We typically consider numerical IDs to be a good identifier; for example, we could use unique 10-digit number for each user. However, using deterministic IDs can often result in a common vulnerability insecure direct object references (IDOR). In this type of vulnerability, the web app fails to check if the attacker (let’s say user 1111) should be able to view/edit the resources of a victim (let’s say user 2222).

Usually, these vulnerabilities are not in extremely obvious places; most apps try to take IDORs into account, and you probably won’t be able to delete another user’s account from yours using IDORs. But, in places that can be overlooked, or might seem unnecessary to have an access check, there can lie hidden dangers. This is exactly what happen to GitLab when HackerOne user saltyyolk found a critical IDOR bug, resulting in a $20,000 bug bounty.

I will be going over saltyyolk’s summary and report provided at HackerOne. Please read the original summary for an in-depth technical analysis.

GitLab is a DevOps platform that is very similar to GitHub, but it tends to be more geared for enterprise use. In GitLab, users have the ability to create projects, but in the case users already have an existing project, they also can import one.

In this feature, users most likely would be importing an exported version of a different GitLab project. Within this export, there is a project.json file that provides the project data. In this JSON file, there is an array of values called issues which contained all the IDs of GitLab Issues, which serve as an important piece of GitLab’s project planning, related to the project.

In saltyyoke’s exploit, the issues array was left blank, and the issue_ids array was added with IDs of issues that the attacker would want to steal. Because the IDs were numerical, one would theoretically be able to steal all the issues they could want. Note: the original PoC created by saltyyoke can be found here at GitLab.

saltyyolk also noticed that this exploit was not limited to only the Issues feature, but also to other GitLab features such as boards, merge requests, and more. These “foreign key” were not excluded during the import, and therefore affected the resulting process of importation. As a result, the user could import different issues that didn’t belong to them simply by referencing their IDs.

Essentially, the error here is that the GitLab import process could simply importing the IDs of issues into the newly created project of the attacker without having any validation that those issues belonged to the attacker.

This causes a significant breach of privacy for users since very sensitive project information could be leaked, such as cluster IDs and secret CI keys. So, on a surface level, this is similar to having private information stolen, which is bad enough. However, saltyyolk further highlighted that this stolen information could be used to sabotage critical infrastructure for victim teams, such as messing with build/deploy pipelines or making content inaccessible for other users. This double impact of this IDOR would be catastrophic for GitLab, which is why it was given a critical rating as well as the $20,000 bounty.

Congrats again to saltyyolk on this amazing find that potentially saved millions of users having their data stolen, along with your well-deserved $20,000 bounty! A reminder (and encouragement) that bugs do not have to be sophisticated to cause great damage.

Thanks for reading through and please leave any constructive feedback, suggestions, or questions below! If you enjoyed, please consider following me on Medium. Contact me at [email protected], follow me on twitter, and connect with me on LinkedIn!