Read it here: https://corben.io/blog/hacking-kucoin

(I’m trying to figure out how to integrate my newsletter & blog)

Somewhere at the end of the process was asked if I wanted to pay for a “rush” service. I did. I needed this asap for work travel. I also entered my credit card info.

Towards the end of the application process, I was given a link to check my order status, something like:

https://threat.dev/app/orderCheck

This page prompted me to log in using the credentials I had set up earlier. Then it redirected me to my account section where I saw my order status. On the page, I noticed I could print the order application with the click of a button.

I hovered over the button and the link looked like so:

https://threat.dev/app/printApplication?id=105608983

Clicking this button returned a printable page of all my info referenced above.

So… even when I’m not working, my hacker brain never turns off.

That number, 105608983… What if I changed it to 105608982? The number right before me?

Surely the application would recognize that was not my id, right?

Unfortunately, for me and all the applicants before me, the answer was “No”. Requesting:

https://threat.dev/app/printApplication?id=105608982

returned another user’s personal information. Big sad.

This type of web vulnerability is typically called an IDOR (an Insecure Direct Object Reference).

I found this bug totally outside of work, so I started to get very nervous about finding such a big bug on a gov site where I was traveling. I had to find a way to responsibly disclose it without getting in trouble. I reached out to several friends in the information security scene. Luckily one of them knew of someone who worked in Cyber Security for that government. They asked that I pass along a written report. I did and then worked with them to retest the issue once a fix was put in place.

I discovered 4 more vulnerabilities in this process, one of which was that the database was being backed up in a tar file to the same place user images were being uploaded. This share had no authentication on it. The database had credit card numbers in it. Big Sad #2. If you’re a security tester reading this, always check /backup or check for backup zip/tar files.

In the end, they were thankful for the disclosure and my work. My travel went without a hitch.

I didn’t even get a t-shirt but, I might have saved your personal data from evil hackers.

You’re definitely a user of a company that does this.

I know I am. And it makes me trust them less…

Why? Because I’ve seen it go wrong too many times first-hand.

Here's how I was able to steal the information of millions of people.

This company bragged about having over 1.5 million users for their mobile app.

Their mobile app allowed users to sign-up and control their products.

Sounded like an interesting target!

But, I didn’t want to target it.

Remember? I like hacking web applications 😅

So, I went after their web assets.

After subdomain enumeration and probing for webservers, I came across the following host:

https://installersupport.app.██████.com/

For content discovery, I started by looking for known paths on the host using gau.

getallurls (gau) fetches known URLs from AlienVault's Open Threat Exchange, the Wayback Machine, Common Crawl, and URLScan.

So I ran it against the domain:

$ gau installersupport.app.██████.com

---- results ----

gau responded with pages of results.

While scrolling through them, one caught my eye:

https://installersupport.app.██████.com/admin/admin_login.asp

Admin is a trigger word for me.

It should be a trigger word for you too (come on, admin stuff is always juicy!)

So, I visited the URL.

It asked for a username and password.

I tried entering default credentials like

• admin:admin

• admin:password

• admin:password123

• test:test

Nothing worked.

So, I tried brute-forcing for ‘.asp’ files.

Maybe I’d find one that didn’t check authentication correctly!

$ ffuf -u https://installersupport.app.██████.com/admin/FUZZ -w asp.txt -mc all -fw <number-of-words-in-404-page>

The results looked promising!

userinfo.asp
searchresult.asp

I visited the first one: https://installersupport.app.██████.com/admin/userinfo.asp

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
-- snip ---


<iframe width="610px" height="1200px" id="Iframe1" src="/crd/installersupport/NewEditUserInfo.aspx" frameborder="0" style="overflow:hidden;" scrolling="no">
</iframe>

Ooh, looked juicy!

However, the page it iframe’d to responded with “500 Internal Server Error”.

That’s odd – I wonder why!

I visited the other file I found: https://installersupport.app.██████.com/admin/searchresult.asp

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
-- snip ---

<iframe width="610px" height="1200px" id="frameUserInfo" src="/crd/installersupport/NewEditUserInfo.aspx?action=editaccountinfo&UserId=" frameborder="0" style="overflow:hidden;" scrolling="no">
</iframe>

This responded similarly.

But wait. Look closer!

What do you see? Extra parameters!

https://installersupport.app.██████.com/crd/installersupport/NewEditUserInfo.aspx?action=editaccountinfo&UserId=

The title of this page was “User Info”.

But there was an error:

“User Name is missing”

Well, what is UserID expecting?

Maybe a numeric user ID?

So I threw the request into Burp Intruder and started brute-forcing the UserId parameter.

It found a valid ID: 2000953!

So I visited: https://installersupport.app.██████.com/crd/installersupport/NewEditUserInfo.aspx?action=editaccountinfo&UserId=2000953

And it returned the users:

• Name

• Address

• Phone number

• Email

• Job Title.

Not. Good.

Then I remembered the mobile app.

I had signed up with an email address. I hadn’t seen a numeric ID in the app (or in any previous shenanigans).

While this web application seemed completely unrelated, I thought I should try specifying my email in the UserId parameter!

But that wouldn’t work, right?

https://installersupport.app.██████.com/crd/installersupport/NewEditUserInfo.aspx?action=editaccountinfo&UserId=corben@sxcurity.pro

It. Worked.

To verify, I went to the mobile app and created another account.

I tried again with that email and it worked again!

Wow.

An attacker could easily brute-force user ids (ex: 0-999999999999) or spray email addresses.

I reported it to their HackerOne program and eventually got a bounty!

Hope you learned from this story!

If you enjoyed it, make sure to follow me on Twitter or buy me a coffee (to fuel my writing for the next one).

See you around,

Corben Leo

That would be awesome right? (Yes. The answer is yes).

Here's how I was able to generate and steal "infinite money" from a car company.

Note: I found this issue during a legal, cybersecurity engagement with the car company.

This car company offered rewards points.

You earned points by spending money on their services and products.

So, buying a new vehicle or getting your vehicle fixed with them would give you points.

You could spend these points on:

• Vehicle accessories (like floormats)

• Tires, Tire rotations, Oil changes, Brakes & Engine repairs.

• $1000's off of a new vehicle

• Gift cards

• Shirts, sweatshirts, backpacks, & more.

Their website at https://rewards.███.com described how it all worked.

On this website, there was a "Sign-Up" button. So I clicked it of course.

Underneath the registration form, was a note:

"1000 point reward for signing up for ███ Rewards!"

So, I signed up.

Sign-up flow:

1. Enter name, email, address, phone number, and password.

2. Click register.

3. Check your email and click the verification link.

Then the site awarded 1000 points to your account. You could transfer your points to another user. There were requirements to transfer points:

1. You must have the same address as the person you're transferring points to.

2. You confirm the transfer via your email.

Sign-in flow:

To sign in, the application redirected to Microsoft to log in:

https://customerlogin.███.com/█████.onmicrosoft.com/oauth2/v2.0/authorize?SNIP

Wait for the page to load. Enter username & password.

The application set a cookie called "████Rewards.AspNet.ApplicationCookie".

Then it redirected to https://rewards.███.com.

Transfer flow:

1. Sign-in

2. Go to the transfer page.

3. Fill in the fields to transfer your points to another member

4. The web application will generate a TransferID and email it to you

5. The user confirms the transfer by visiting the link (containing the transfer ID) in the email

So what do we know so far?

1. Anyone can sign up at https://rewards.███.com/

2. You get 1000 points for signing up

3. You can transfer your 1000 points to any account that has the same address on it.

Low-severity problems:

Problem #1:

Registering through the sign-up form would result in a POST request to: https://rewards.███.com/api/EN/Profile/SignUp

POST /api/EN/Profile/SignUp HTTP/1.1
Host: rewards.███.com

--- snip ---

{
    "phonetype": "Home Phone",
    "country": "USA",
    "UsernameVerification": "",
    "username": "<unique>@youremaildomain.com",
    "ConfirmUsername": "<unique>@youremaildomain.com",
    "password": "password123",
    "ConfirmPassword": "password123",
    "firstname": "<random-string>",
    "lastname": "<random-string>",
    "address1": "1337 Hacker Way",
    "city": "Test",
    "state": "CA",
    "zipcode": "55555",
    "number": "<random-10-digit-phone-number>",
    "TermsAndConditions": true
}

Notice:

• No captcha.

• Also, there was no rate-limiting.

Problem #2:

After signing up, the website sent you an email to confirm your account.

This email contained a link: https://rewards.███.com/confirm/<TOKEN>

When you visited the link, it would send a POST request to: https://rewards.███.com/api/EN/Profile/Confirm?randomId=<TOKEN>

Again:

• No captcha.

• No rate-limiting.

Problem #3:

Well, not a problem, but you could use a headless browser to login in and out.

Problem #4:

Remember the transfer flow from earlier?

Step 4:

The web application will generate a "TransferID" and email it to you

Step 5:

The user confirms the transfer by visiting the link (containing the transfer ID) in the email

Filling out the Transfer form would result the following HTTP request:

POST /api/EN/Rest/CreateTransfer HTTP/1.1
Host: rewards.███.com
Content-Type: application/json

---- snip ----

{    
    "username":"attackerMain@example.com",
    "ConfirmUsername":"attackerMain@example.com",
    "message":"enjoy the points",
    "points":"1000"
}

In the HTTP response? The TransferID. No need to check your email for the link.

You could take the TransferID and make an HTTP request to the following URL:

https://rewards.███.com/api/EN/Rest/ConfirmTransfer?tNum=TransferID&confirmation=Approve

Where does that lead us to?

Exploitation:

The overview:

An attacker could:

1. Create a bunch of accounts that share the same address. Automate it by abusing Problem #1.

2. Verify the accounts via the links in the verification emails. Automate it with a script that listens on SMTP and abuses Problem #2.

3. For each of the created accounts, log in. Automate it abusing Problem #3.

4. Create a transfer to your main account. Automate it by abusing Problem #4.

The automation:

First, I added a DNS MX record to a domain I controlled. I pointed it to my VPS.

Here's what the zone file looked like:

vps.example.cloud.	IN	A 167.172.xxx.xx
hackerone.cloud. IN MX 10 vps.hackerone.cloud.

Then I wrote a tool to automate it (I'll link the Github Repo at the bottom).

The tool does the following:

1. Generates a random name, phone number, and also a random email that I have control over.

2. It then POST's it to /api/EN/Profile/SignUp

3. It launches a mail server. It listens for emails that have the subject of Confirm Your Rewards Account. Then it grabs the confirmation token from the email.

4. It makes a POST request to /api/EN/Profile/Confirm?randomId="+confirmationToken to confirm the account.

5. It logs into https://rewards.███.com via https://customerlogin.███.com using a headless chrome browser. This grabs the cookies and exits. (I used headless chrome because I was too lazy to automate the Microsoft OAuth process)

6. With those cookies, it POSTs to /api/EN/Rest/CreateTransfer to create a transfer to my account I'm boosting.

7. It takes the TransactionID from the response from the last HTTP request. It then requests /api/EN/Rest/ConfirmTransfer to confirm the transfer.

You can find the code here.

I ran it and stopped once it generated 250k points. For reference, it cost 200,000 points to get $1000 off a new car purchase.

I reported it to the company and after about 3 weeks they paid me $500.

Outro:

I hope you learned from this story! I spent a few hours trying to write this clearly.

If you enjoyed it, make sure to sign up for the newsletter and follow me on Twitter.

See you around,

Corben Leo