/ burrito

(Almost) Free Burritos through App Signup Flaw

About two years ago now, I met a person (who will remain anonymous) at the Top 100 Future Leaders competition. This person worked within Cybersecurity and within their own time, enjoyed identifying vulnerabilities and exploits in everyday apps they used. They were explaining to me one of their older exploits which took advantage of an app giving away one free burrito if you signed up to their app. At the time of explaning to me, the exploit no longer worked.

Curious to see if it still worked, I did a bit of my own investigation on the app.

Please note: Both myself and the person not feel it was right to take advantage of this exploit and had not claimed any burritos from the exploit. This exploit no longer works it has since been patched by the company. I am not liable for you getting into trouble if you attempt the exploit and get into some sort of trouble.

Please also note: I wrote this article 1.5 years ago, but decided not to publish it at the time due to potentially getting into some sort of trouble. I'm only now posting it because they have changed their routes and none of the requests in the article work anymore.

The App Promotion

A fast food restaurant, who we will refer to as Brent's Burritos has an ongoing promotion with their app. The promotion states that they will give you a free food item if you create an account on their app.

Of course, they've thought about how to prevent people creating multiple accounts and using these accounts to claim multiple free burritos. To create your account, you must first verify your mobile phone number. They will send you an SMS which you have to enter into the app before you can create your account.

People are still able to go out and buy multiple sim cards, create new accounts and then claim their burritos. But that's quite a bit more involved process than simply entering fake details then receiving a free burrito.

The Exploit

First, a bit of experimentation was done on the app. A tool called Charles Proxy was used to analyse the requests sent by the app to Brent's Burritos servers.

Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet.

Note: I am using an android phone + the Charles Proxy app on Windows 10.

After setting up the proxy on my PC, then connecting to the proxy on my phone, all that was needed to do is to go through the process of creating an account and see what was going on in the background.

Analysing Create Account Traffic

Brent's Burritos has organised their create account process into 3 steps.

Email and Password

First, they require you to enter your Email / Password. Pretty standard stuff.

emailAddress-1

Looking at Charles Proxy, the only thing going on behind this page is a POST request:

checkEmail-1

With the body:

{
	"EmailAddress": "kingofburrito@gmail.com"
}

This is just to see if the e-mail had already been registered, if it has it'll stop you from proceeding to the next step.

Your Info

This page asks for your First and Last name and your Mobile Number, which they say they really need.

firtNameLastName

Clicking the Mobile Number form brings you to a new Mobile Phone Verification page, entering it then sends you an SMS which you have to enter into the form to verify. Here, there were some requests to what I assume to be SMS 3rd parties which allow verification of mobile numbers.

numberVerify

Entering in the code correctly, you can then proceed.

Review and Create

The final stage is just an overview of your account to which you then can just proceed. Here is where the juicy POST request is sent. Once you proceed to create an account it'll send the following POST request:

createAccount-1

Not terribly interesting, but take a look at the body that was sent:

postBodyReturn

Take special notice of the VerifiedNumber field! It's just a boolean value. Since there was no other request made during the account process (other than the request to send the text and check if an email existed). I thought it might be the case that they only use the 3rd party SMS API to get a boolean of mobile number validitity that is just fed through to this final POST.

Curious to see if this were true, I attempted to send a POST request using Postman the same request, new details and VerifiedNumber set to true.

postmanRequest--2--1

To my suprise it gave me a 200 OK! I used these details to log in and tada, it worked!

loginSuccess

Again, curious to see if the exploit (still) worked and I was able to get a free burrito, I added a burrito to my cart and checked out. Unfortunately, the coupon was not there, oh well.

orderAttempt

According to the person I met at the competition, at one stage, the steps I followed were what was required to get it working. They had probably since implemented device ID checking amongst other techniques to check the validility of created accounts and whether they're eligible for a free burrito.

Going through the whole process of this was not a whole time waste! I learned how (simple) exploits are performed. They're just a matter of understanding what's going on in the background and then experimentation to see if you can take advantage of some things the engineers who built it forgot to secure.

This knowledge will definitely be useful when securing the future applications I build in my career and own time.