ThreatDEV

Share this post
Stealing the Information of Millions of People
newsletter.threat.dev

Stealing the Information of Millions of People

Corben Leo
May 2, 2022
40
Share this post
Stealing the Information of Millions of People
newsletter.threat.dev

Companies love bragging about how many users they have.

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

Share this post
Stealing the Information of Millions of People
newsletter.threat.dev
Comments
TopNew

No posts

Ready for more?

© 2023 ThreatDEV
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing