What Happens When Security Configurations Do Not Work As Intended

So, what happens when a company sets up security configurations then makes it hard to report an issue? Well, you are about to find out.

Changing Email Addresses Turned Nightmare

One day, I decided to switch email providers and, in turn, needed to go through accounts and update the email they had on file. This is when I came across my Udemy account and discovered a massive security misconfiguration that led to an account takeover since the change email field required to trust that the multi-factor authentication (MFA) was implemented correctly. The basis is that Udemy requires MFA to be enabled on the account to change the user's email address.

This sounds great in theory, protecting users with known bad or reused credentials from having their account stolen by a threat actor. A very valid way that attackers are gaining access to accounts is an attack called Credential Stuffing, where an attacker takes a list of compromised users from one breach and then sprays the credentials to thousands of other sites to see where credentials were re-used. For a frame of reference, think of the 23andMe breach, where millions of user's records were stolen and sold. The attacker gained entry through credential stuffing.

The MFA Fiasco to Account Takeover

Now comes the fun. I enabled MFA on my account and was presented with a message that I would be logged out and would need to log back in.

This sounds great once again, but I was not logged out and was not asked to confirm I had access to the email that owned the account. You can start to see where this is leading...

I then went back to my account management page without logging back in and proceeded to change my email address. I figured since MFA was required to change my email, it would prompt for the code at that point. I was sadly mistaken...
This led to me making the discovery that a threat actor could steal accounts by having local access (e.g., someone trying to use Udemy from a public library) to already compromised accounts due to credential stuffing attacks.

Vulnerability Scoring CVSS 3.1

In the end, I came up with a base CVSS 3.1 score of 6.5

• Based on the Vulnerable Component:
  • Attack Vector (AV): Network - Accessible through the Internet.
  • Attack Complexity (AC): Low - No special access, and through credential stuffing, an attacker can expect repeatable results (Detailed below, but I had a sample of a list from a seller with a little under 10,000 stuffed credentials).
  • Privileges Requires (PR): None - A basic user account is required, not an administrative one.Per HackerOne's policy this is set to None due to anyone can create an account. Detailed Platform Standards
  • User Interaction (UI): None - Only the attacker is required to interact in any way.
  • Scope (S): Unchanged - Both the Vulnerable Component and Impacted Component are managed by the same security authority, web application.
• Based on the Impacted Component to show, well Impact:
  • Confidentiality (C): None - While access to restricted information (paid course lectures or subscription plans) is granted when an account is taken over. However, the account is already compromised through other means and not directly related to the MFA vulnerability
  • Integrity (I): Low - The ownership of the account is modified, but the attacker gains little access to make additional modifications. This is due to the reliance the developers placed that MFA must be enabled in order to change account ownership. Trust matters, and the developers agreed by requiring MFA in place to change ownership.
  • Availability (A): Low - The legitimate users can no longer access their account and are denied persistent access until support staff steps in to recover the account.

Udemy disputed this score based on the reasoning provided below:

However, as you can see I address each one above on why that isn't the case. Such as PR needing to have administrative access to utilize the vulnerability, which goes against thier own policies or the fact that the specification states that "some restricted information is obtained." While, my intent is not to get into the debate over score for this vulnerability, I would like to note that for Integrity, they clearly state "the email address gets changed and user looses access to account" then try to claim that there is no loss of availability. The legitimate user losses access to their account, but it is not a wide spread all users lose access, so this wouldn't be High, but it also wouldn't be None.

The Pain of the Reporting Process

Now, you may be asking at this point, what did you do to report this responsibly before writing this blog? I tried several avenues. First, I went to Udemy and discovered they only take reports like this through HackerOne. This made me cringe because I have talked to a few people who reported vulnerabilities through HackerOne to have them shot down and labeled informative for some obscure reason. I then researched and found Udemy's CTO and CEO emails and reached out directly, hoping to gather additional visibility for how the reporting process was handled, but I never heard back. Some movement on the HackerOne side started after I waited for 30 days, and no objections were made on either side. I told them I would go public with what was found. If the report ever goes public, I will report back with links to the HackerOne report. It is a long one, printed out it is currently about 37-40 pages long.

This interaction led to me finally getting to discuss the vulnerability with a Udemy representative and the HackerOne mediation team, basically they also went off opinions after trying to say that they based their score off the CVSS 3.0, I was basing mine on 3.1, but after getting deep into the definitions of the specification they still went off their opinions and feelings, which I will write another blog about because it would be too much information for a vulnerability disclosure post. I feel I have already gone over what I should have for the vulnerability post.

Responsibility

I did not write this blog to accuse HackerOne of wrongdoings or attack them directly. I, however, hope they make it public for everyone to read because while I was invested in the process and wanting to do the right thing, they either ignored facts and went with their feelings, ignored questions altogether for how many credentials would be required before they would take this seriously. I had already contacted someone from a hacker forum that sells known reused credentials. I had a proof text with a little under 10,000 users using credentials from other breaches (aka Credential Stuffing attacks). While I was performing his action for another reason and would never pay a criminal for stolen data, it made sense to ask for Udemy's web address to show impact.

I also waited over a year after initial discovery and over ten months after intial request to disclose. Based on HackerOne policy, I am publicly disclosing based on the Last Resort section in their Disclosure Guidelines

A Show With No Tell - PoC Video