0 Click ATO with the Sandwich Attack

Aug 11, 2023

RONI CARTA | LUPIN

sandwich, attack, takeover, account, exploit, bug bounty

I'd like to share with you an intriguing story from my journey in the field of bug bounty hunting. This story happened one night collaborating with my friend Snorlhax where we were testing a new application of one of our target.

Something that I particularly didn't like about this applicating was the lengthy process involved in creating a new account. So, I reached out to Snorlhax for one of his account credentials. He provided me with a link to the password reset feature so I could set up my own password. When I saw this link, I instantly knew we could hack this feature.

In this article we are going to talk about a technique called the "Sandwich Attack" and how we used it to get a 0 Click Account Take Over (ATO). In fact, I have had the pleasure of presenting this vulnerability at the HacktivityCon 2022 in Las Vegas and on the French Channel Underscore_

Let's start from the beginning. The password reset feature of an application is a security measure that helps a user in resetting their password if they forget it. Typically, this process involves an email being sent to the user with a reset token embedded in the URL. This reset token should be unique for every user and unguessable. But what if we could understand the algorithm generating this token, and forge one back for another user ?

The link Snorlhax gave me was interesting, as the token aspect was a UUID, or Unique Identifier. While UUIDs are common and sometimes even used as a password reset token, this one was different since it was a UUID Version 1. There are five versions of UUIDs, with V1 and V4 being the most common. V1 utilizes the timestamp and MAC address, while V4 employs random numbers for generation. Our main focus here is the V1 UUID provided to me by Snorlhax, and the particularities that led to the vulnerability we've found.

V1 UUID is constructed in 6 sections: High, Mid, Low, Clock Sequence, Node ID, and UUID version.

UUIDv1

Interestingly, the Node ID corresponds to the MAC address of the system generating the identifier. This means that if two consequent UUIDs are generated on the same device, this part remains the same, similar to the Clock Sequence.

Unchanged

When High, Mid, and Low are combined, they reveal a timestamp represented in hexadecimal value.

High Mid Low

Using some basic mathematics it's possible to substract the offset between the Gregorian Calendar and the Julian Calendar and then devide by 1000 to get an Epoch TimeStamp

Calculations

From this we can easily find back the date with this website:

date

VerSprite's team wrote an interesting article on How Secure are UUIDs, introducing the concept of the Sandwich Attack as a method to brute force unique identifiers. In this methodology, the attacker first triggers a reset token email to their account, generating the first "slice of bread" UUID. They then use the victim's email address to send a password reset, i.e., the "filling". Finally, they send another reset password email to their account creating the final "slice". Now, the target's reset token is sandwiched between two known points, establishing a time range for brute-forcing.

Back to our night of hacking, we found ourselves in this exact scenario. I reached out to my brother Holmes, who developed a Ruby script that generated all UUIDs between two given points. The API was returning 2 tokens with a difference of 100,000 possibilities.

That's not him

The tool to Generate the UUIDs is now Open Sourced on our Github:

Using the tool and an open-source tool called ffuf, we generated the possible list of identifiers and fuzzed the API of the Reset Password endpoint with these possibilities.

Of the 100,000 possibilities, our persistence finally paid off. We successfully executed a complete account takeover without any user interaction. The program recognized this as a High vulnerability and rewarded us with a bounty of $5000.

One important note to bear in mind is that multiple machines could potentially generate Password Reset Tokens for the same endpoint. We sent 30 requests for a reset password, examining the Clock and Mac Address values for each token. We noticed that there were 6 machines generating these tokens, therefore multiplying our brute force possibilities by 6.

Stay tuned for more Bug Bounty stories. Always stay one step ahead, and happy hunting !