Auth Bypass : A Story of LinkedIn's Sneaky Session Update Bypass

Hello friends! Toryy here!

I'm excited to share with you an Authentication Bypass that I discovered on LinkedIn. I'm particularly proud of it because of its unexpected and sneaky nature. Let's dive right in!

Overview

Just like Github, Facebook, and some other top organizations, LinkedIn utilizes another authentication layer asides from the regular user account "username+password + 2FA" that's needed to be completed on login. This extra authentication instead, surfaces when the user attempts to perform sensitive actions that holds more significance than others. They put the user in "Sudo mode"; elevating their privileges either for a specified period of time, the completion of the action, or until session token is expired (logout, token rotation).

LinkedIn (web) challenges the user in two ways. We know this through the response of a particular request that's initiated when you try to access the email ;

• challengeType : "Email Pin"
• challengeType : "SSP_BLOCKING_CHALLENGE"

SSP most likely stands for "Sign-in Security Prompt"

After numerous futile testing on the "Email Pin", I decided to test the other one. I believe many hunters missed this because they probably never encountered it in the first place. Was it hidden? well, not quite.

This SSP_BLOCKING_CHALLENGE only surfaces when the same account is signed in on the LinkedIn mobile app, and is assigned as the "challengeType " parameter value automatically in that event.

How does this type of Authentication Challenge work?

• it first prompts the user on the web browser to check their mobile app and affirm by tapping "Yes",

• it prompts the user on the mobile app to confirm if they are the one requesting access or not.

Vulnerability Details

In our context, I discovered a vulnerability in LinkedIn's session update mechanism. This vulnerability allows an attacker to bypass session revalidation and perform sensitive account actions even if the victim explicitly denies the request. Here are the details below:

1. Attacker attempts to add phone number/ email address on victim's session but gets prompted such as fig 1.1 demonstrates
2. Attacker turns on Request Interception on his proxy tool to intercept the incoming requests.
3. Victim receives a prompt on his signed in mobile such as in fig 1.2, reacts rationally and taps "No, it's not me"
4. This action (performed in the latter step by the victim) sends a particular POST request and is intercepted by the attacker. The attacker also intercepts the response to this request as shown in the image below

Note: the response contains an endpoint in the "Location" header and the path contains a directory named "paused', indicating the session update is unsuccessful and now on hold due to the victim's action

5. The Attacker now modifies the endpoint from

/checkpoint/challengesV2/inapp/paused/AQEB9gB3z8qezQAAAZWrepDTwxxxxxxxxxxxxxxx
?flavour=SETTINGS_CHANGE&challengeId=

to

/psettings/phone/add?challengeId=

/checkpoint/challengesV2/inapp/paused/AQEB9gB3z8qezQAAAZWrepDTwxxxxxxxxxxxxxxx
?flavour=SETTINGS_CHANGE&challengeId=

to

/psettings/phone/add?challengeId=

6. Forwarding this response, Attacker's privilege is successfully elevated and the browser navigates to the phone number page,

from here on, the Attacker can now add arbitrary email addresses, phone numbers to achieve an account takeover, or perform other sensitive actions.

This finding once again demonstrates the value of delving deeper, which can sometimes be fruitful, or perhaps most of the time. The points where two different services or platforms (web and mobile in this case) connect, deserve a bit more attention than the others for logic, authentication and authorization checks. Carefully trace every request initiated by an action performed, determining how each one finds its place in their minor or major engineering goal(s).

Also, all the glory to Jesus.

If you are reading this, remember to put God first in all that you do, and I wish you all the best.

Let me know if you have any questions in the comments. You can also contact me through:

Toryy?? (@torious100) on X Christian #GenI | Bug Bounty Hunter |Cybersecurity

Ayodeji Adebayo - HackerOne | LinkedIn As an Application Security Engineer and dedicated Bug Bounty Hunter, I excel in offensive... · Experience: HackerOne ·…