A few months ago, I was fiddling around with some Intuit applications as I had made a commitment to better track my finances. To my surprise, when I tried to make an account, I was receiving an error that there was already an account with my email address. This seemed odd so I tried resetting the password. It was typical, enter your email and get your password reset but when I entered my email for the reset, I received a notification that the reset email was sent to some email address I had never seen. This was even odder. So, like any good security researcher or paranoid finance person, I began to investigate.
After few hours of going back and forth with multiple customer service employees and my own investigation, I concluded it was a weird logic error in the Intuit account recovery process. I think the issue is most likely a result of the way in which Intuit migrated accounts from multiple acquired companies/services into their new single account system.
Recreating the error
So, let's get into it and I’ll show you what it looks like.
First things first, let’s create a few throwaway email addresses so we can make some new accounts in Intuit.
We’ll call them Batman and Spiderman. (I know that’s mixing the DC and Marvel universes but go with me here.)
Next, let's have Batman mess with Spiderman by changing his Intuit account’s username to the Spiderman’s email address. He can do this because the form just accepts that edit without properly checking for existing accounts. We’ll explain a little more in the conclusion.
Spiderman has no idea this has happened because it’s technically not his account.
Springing the trap
Now, let's say Spiderman has taken one too many Green Goblin pumpkin bombs to the head and loses his memory, forgetting his password (which does seem to happen quite often to Spiderman).
Spiderman tries to trigger a password reset using his email address, but things don’t go exactly as he plans.
When Spiderman tries to reset his password using his email address as his username (spiderman@aaathats3as.com), the system matches that username to Batman’s account and sends the email to Batman’s email address instead. Spiderman is now locked out of his account.
What’s going on?
This happens because of a logic error. The script for matching accounts searches through the username field before searching through the email address field. And since you can enter an email address in the username field, it will always match that first.
In this case, Spiderman cannot reset his password unless he calls support or if he has entered other personal information into his account that can be used to recover the account.
I’m sure everyone knows that one person who can never remember their passwords and doesn’t want or know to use a password manager. These users often are the ones that manage their account logins by just resetting their passwords every time they need to access the service. I would expect these users to be especially susceptible to this issue and it would be easy for users to take advantage of this.
Remediation of the issue should be straightforward. Instead of having one box that searches phone number, email, or user ID, Intuit could add individual boxes to search those specific fields. They could even add this as a second step if someone were to try the above method and it matches to the wrong account.
So, is this bad?
It depends.
Overall, the chances of this happening by accident are slim. But when you consider the type of information Intuit holds for its users (e.g., financial data, tax returns, budget information), losing access to this information in any way should be considered a high severity problem.
Taking advantage of the logic error for an attack does appear to be very specific, which would lower the severity of the issue. However, we left it up to Intuit to decide.
Reporting the error
Intuit does not have a bug bounty program, but I still contacted them to report the issue in the hopes that it would be resolved.
When contacted, Intuit provided the following response:
“Thank you for your patience while our security team investigated the issue you reported. Based on our understanding of the information you provided, our research suggests that this is not currently an active vulnerability.
After discussing the reported issue with our development team, it was determined that this is a known issue that is considered accepted risk.
The development team had faced multiple challenges with the various methods of ID and considered various solutions. However, each one came with tradeoffs that resulted in side effects. The current solution was determined to be the most ideal option that affected the least amount of users and would cause minimal impact to our customers.”
So, as of now, this continues to be an issue. Feel free to replicate these steps if you would like to confirm this for yourself.
Why would you do this?
Spending time to get to the bottom of a login glitch may seem like a waste of a good couple of hours to some. To those of us whose job it is to find vulnerabilities in web applications and networks, it’s called “research.”
If you pay close attention to how different websites and applications process their authentication, especially account recovery, you’ll learn a lot about how their back-end systems are set up. And, while not every glitch leads to a vulnerability, you will find surprising entry points if you knock on enough doors.
Software developers can endeavor to build hacker (and user) proof applications from the start, but you can only be sure of their success by employing penetration assessments. And you must be persistent and relentless because your adversaries will be also.