Unique Mindset: Hacking with @zseano
WHOAMI?
~ My name is Sean and I go by the alias @zseano online.
~ Focus on webapp (websites) hacking.
~ Spend time in bug bounty programs, currently working on a new training platform..
Update on new platform
I am working on it :))
Two pieces to the puzzle
No verification means i’m you
New features for $ = bugs
Developers love to verify things.. right?
Just keep it simple
API docs are friends
01
02
03
04
05
06
Two pieces to the puzzle: Critical IDOR in front of you
~ On every site I will always test for opting in/out, it’s part of my ‘flow’
~ In this case when opting in I noticed two parameters: “1” and “jOgRwvXmE0” - and my full email was on the page.
~ Tried changing “1” to “2” but it failed
~ Tried visiting opt in URL on account B - success, I could see account A email.
Two pieces to the puzzle: Critical IDOR in front of you
~ Okay.. so WTF is this encrypted looking value?
~ Referred to notes and remembered writing this value down as being used in user profiles when leaving “feedback”
~ Okay, I can get a users encrypted ID, but what about the integer? I could brute force.. But ehh… nah.
~ Used site as normal looking for any integer IDs when interacting with other users: success! When deleting feedback integer value was used for profileID
Two pieces to the puzzle: Critical IDOR in front of you
Final steps:
No verification means i’m you
~ When signing up on websites I will always test how they handle @maindomain.com (imagine scope is example.com, your email would be test@example.com)
~ To start the process of claiming ownership of a page it required your account email to be @whitelisteddomain.com and there was no way to discover this domain.
~ So I simply tried @maindomain.com and success, I could begin the process to claim! But wait, it says check your email. Damn, failed, I don’t have access to this inbox.
No verification means i’m you
~ This is still interesting @maindomain.com is whitelisted. It is also interesting that before sending an email you can click ‘Send’ or ‘Cancel’.
~ The hacker in me thought, what happens if we change our email BEFORE pressing send? Will it send it to my email?
~ If you thought the same, well done l33t haxor! A verification email was sent to an email i controlled and I could claim ownership of any page.
New features for revenue generation = bugs ?? :)
~ New features are often released to generate revenue (do you ever check the stocks for the site you’re testing? Or the news? Keep up to date with features they are planning etc!!). New features = maybe rushed code? Rushed code = maybe bugs?
~ Noticed code had been released to run specific ads for your account. These types of ads were new.. Let’s play.
New features for revenue generation = bugs ?? :)
~ When purchasing, part of my ‘flow’ again is to always test for how they handle sandbox CC (4111 1111 1111 1111).
~ Upon testing… failed. The end.
~ I kid. Another part of my ‘flow’ is to test if different countries use a different payment handler perhaps. Changed to foreign country and suddenly bank option appeared.
New features for revenue generation = bugs ?? :)
~ Tried sandbox CC bank information (google it).. Success! Okay cool so I can run free ads for my account, low business impact though to most companies
~ Back to the start we go, how does the flow look? I noticed you have to search for your account first. What happens if I search for my other account and try the same?
~ Upon pressing ‘run ad’ with sandbox bank information I was granted access to my other account with full control.
Developers love to verify things.. right?
~ I could add another team member via email. Accepting was as simple as visiting the URL you received in an email. No ‘are you sure you want to accept?’ page was prompted. This is important to note.
~ Invited my third account but accepted the invite on my fourth….
~ Fourth accounts email was leaked but was NOT granted access (created ‘Pending’ invite that did not exist!)
Just keep it simple!
~ Noticed every type of feature used weird looking values when referencing IDs. *;EkbTyHnmemGB,_j)Qxajrg(T/-D%
~ Looked everywhere to find any references to ‘encrypt’ ‘decrypt’ in js files. Looked through all features and found no leaks of anything. Everything looked pretty secure..
Just keep it simple!
~ Almost gave up and then thought to myself: why not just try an integer value?
~ Quickly queried for my account information, changed *;EkbTyHnmemGB,_j)Qxajrg(T/-D% in the URL to 1 and the output was….
~ User ID “1” full information. This issue turned into a site wide issue (all features were vulnerable)
API Docs are friends
~ Site allowed me to create my own app in the developer portal. Tested for the various setting redirectURI to “javascript:” but no success with anything.
~ Logged into account ‘B’ and tested allowing & removing the app. Not much special really.
~ Tested pressing ‘Cancel’ and noticed in the Referer: header there was some an access_token value ..? Huh?
API Docs are friends
~ I thought, surely this token does nothing since I declined the app. Tested an api call via my app and I received invalid_token.
~ So my thinking was correct, but something still tells me this token may do something. So I dug deep into their API docs and discovered something….
~ “X-USER-TOKEN:” could be used rather than “X-APP-TOKEN”.. What about if this token could be used here?!
API Docs are friends
~ SUCCESS. The token had NOTHING to do with my app and from the user pressing ‘Cancel’ it actually leaked their ROOT user token. BIG oops!
~ The token never expired and it leaked a LOT of information. What’s worse is google was even indexing user tokens before this issue was fixed. Double BIG oops!
(Just because emongg said he’d rather a mercy one trick, this is for you mish lol)
Any questions?
Visit virseccon.com and join the discord!