Posted on 2024-04-30 by Matt Strahan in Business Security
I was working on a penetration test for a gym company a while ago and found a vulnerability. When looking at the profile I found you could change the number in the URL and view other profiles. “Unfortunately” you couldn’t change the other user’s password, but wait! There’s a forgotten password function and I’m able to change the user’s email address! How about I just change the email address, submit the forgotten password page, and then…great I’ve got access to the account!
For the pentesters who are reading this, this is not a particularly interesting story. It’s just the exploitation of a stock standard IDOR vulnerability using a pretty well known technique. They’d put the recommendation to require the user’s password for changing email address and oh don’t forget to fix the IDOR.
But for some reason this story was rolling around in my head not long ago and it made me think. For this company the email address ended up being just another way of authenticate. In terms of authentication it was equivalent to just having the username and password. In other words, you could have either a username and password to access the account or access to the email.
We all kind of know this when we think it through, but did the company treat email this way? Did they treat access to email as a method of authentication in the same way as a password?
This blog post is based off a talk I did for Comfycon. See the recording of this talk below:
Forgetting that forgotten password is still just authentication
What if I, for instance, went to one of their branches and went across to the receptionist, and said…
“Hey, I really love getting your newsletters! I mark off every day of the month until your newsletter arrives. It’s got so many useful tips and tricks. I haven’t been getting them lately, though. Have you put in my new email address?”
Would she say no? What would she ask for to verify it’s me, if anything? What else could I “login” with? What do I really need to authenticate?
This is not just theoretical. One example of this that I like is from XBox Live where people found genuine loopholes in the help desk authentication. They would call up the help desk with a gamer tag and ask for a piece of information, maybe validate the phone number that’s attached to it. Then they’d hang up the phone and call up again, this time maybe looking for the address. Each time they’d get more information and eventually they’d get enough information to go through the forgotten password process.
The XBox Live hack wasn’t social engineering, it was a genuine hack of the help desk processes. Everyone on the help desk was just following their processes, it was just that there was a legitimate hacking vulnerability in their help desk system.
The issue is one of scale
I’m going to get morbid for just a second. How big a user base do you need before you can expect that one of your users will die each day? This is a pretty basic probability problem. We live for about 27 thousand days. Most user bases skew a little bit younger than the general population, so let’s call it a user base of 100 thousand people before you can expect that one of your users will die, on average, each day.
How big a user base do you need until you have daily phone thefts or users losing their passwords or changing emails daily? On a happier note, how big a user base do you need before one of your users gets married and changes their name daily? These are unusual, potentially once-a-lifetime events on an individual basis but given enough people they are just regular occurrences.
- People lose their passwords
- People change email addresses
- People go on holiday
- People get their accounts hacked
- People get their phones stolen
- People lose their jobs and get new jobs
- People change their names and get married
- People die or become permanently incapacitated
With even a moderately sized user base all of these scenarios aren’t unusual but should be expected on a daily basis. That means that another such request isn’t particularly unusual. The organisation should be able to take them all in their stride and, ideally, have processes for all of these scenarios.
When thinking of authentication, then, these “unusual events” should be thought of as just another authentication process, as valid as using a username and password to log in.
Down the rabbit hole I went
Once you start considering all the channels for changing or updating authentication factors within an organisation’s support structure you have to start again and again asking yourself questions for each factor of authentication around this:
- How and when is it provided?
- How can it be changed?
- What happens when it’s lost or stolen?
- Can it be substituted, disabled, removed, or closed?
- Can ownership be transferred?
- What is required on other communications channels?
- What happens when someone dies or has power of attorney?
- What about law enforcement/subpoena requests?
When you’re attacking a system, you want to be able to identify the path of least resistance. Sometimes that’s not through the front door but through the window. That could be by exploiting these more esoteric authentication processes.
When you’re defending, you have to make sure that you know all the factors of authentication you might have - primary, secondary, tertiary, N-ary - all of them.
Visually representing authentication requirements
I’ve got to be honest here. This was a problem I thought was somebody would have already solved, but I couldn’t find anything. Maybe my Googling/Duck Duck Going powers just aren’t up to scratch. The best I could find was flow charts that showed the “how” but not so much the “what”. ChatGPT was no help - the diagram it tried to give me looked like a bunch of MBA grads took acid then reached for some crayons.
This meant I had to try and make something up myself. For my shot at this I ended up choosing a slight variation on logic diagrams.
This example is for the gym above and it’s just one step away from being as simple as can be, but in practice we can rather easily go further. Let’s bring our questions from before and create some hypothetical examples of where authentication may be able to be bypassed.
How and when can the username be provided?
If I ask for my username from the helpdesk or reception, what will they ask for before they give it to me? Could they just ask for a name or an email? Do they need anything else?
How can the registered email be changed?
Could we just, for instance, call up and ask nicely to change our email address? Is that all it takes?
What happens when the phone is lost/stolen?
Can you register a new device for a user? Are there recovery codes? Is access to email another factor?
I found when mapping out some examples that registered email can be used to change practically anything with a lot of systems.
Are there alternate comms channels?
If there is a help desk, what is required to authenticate there? Maybe there’s a whole other way of “logging in” to the account
Showing the bigger diagram
For each of the factors we should be asking those questions from before. What would be involved in getting access to this factor? What might some of the replacements for this factor be? Would this level of evidence be enough?
In particular, it might be worth going from the opposite direction. Where would a drivers license or passport, for instance, fit into this picture? Put yourself in the shoes of a receptinist or help desk specialist - what would you yourself require if someone were to ask for access to one of the defined factors of authentication?
Once this is all worked out it can show some surprising complexity.
Employee and contractor accounts
I’ve mostly spoken about authentication requirements for customers and users so far, but companies have similar issues identifying and authenticating their own employees, contractors they work with, clients, and suppliers. For a larger organisation, authenticating an employee or contractor for an internal account can be difficult. Not everyone knows each other so how do you make sure that they are who they say they are?
I’m not going to go deep into this as this blog post is already getting pretty long, but, just for an example, issuing the credentials for a new contractor account can be challenging. The requester most likely doesn’t work in the IT helpdesk and so needs some way of connecting the new contractor up with their account. Sometimes that could be something like “please call the IT desk to get your temporary password”, a pretty common solution that I’ve seen a bunch of times:
In this case, the authentication requirement is almost one of timing. If you’re on the red team and wanted to bounce around accounts, could you, for instance, get a list of new contractors and call the help desk pretending to be them?
Takeaways
What’s really required for authentication? In going down this rabbit hole there are some takeaways that stuck out:
- It’s worth knowing what, not just how to authenticate.
- It’s worth exploring what is used to authenticate when conditions aren’t normal, because abnormal is normal with enough scale.
- It’s worth writing this down – everyone needs to be consistent with what they require and you might see some holes.
Mapping out authentication can show surprising complexity - authentication is never just a username and password.
About the author
Matthew Strahan is Co-Founder and Managing Director at Volkis. He has over a decade of dedicated cyber security experience, including penetration testing, governance, compliance, incident response, technical security and risk management. You can catch him on Twitter and LinkedIn.
If you need help with your security,
get in touch with Volkis.
Follow us on Twitter and
LinkedIn