FastFoodHackings: zseano’s live hands on live mentoring session

Sean (zseano)
Jun 30 · 7 min read

Firstly thank you to everyone who participated in my very first live hands on mentoring. I was a bit unsure how it would go and if people would understand the goal, but overall the day was a success and I plan on hosting the next live mentoring session on 21st July 2019 at 2pm BST, so mark your calendars and hopefully see you there? :)

A huge thank you to those who donated during my mentoring session. I would like to invite all 4 of you to a private mentoring session one week before on 14th July 2019. I will be in contact with what time works best for all involved.

What was this event about?

There is a *lot* of information out there and sometimes it can be information overload. I get a lot of DMs from various people asking a variety of questions, but the overall sentiment is, “how can I understand this more?”. It then hit me last month that a lot of people in this industry need a “nudge” in the right direction and some encouragement. This is exactly what I wanted to achieve from hosting this live event and help users live with understanding what the web application is doing and what you should maybe try, and why.

After the event ended I went through how *I* would attempt this target and my thought pattern. The idea was to teach people what they missed and why they missed it. You can check out the session here: https://www.youtube.com/channel/UCCUFgj-52_ryvpQUacylRpg

If you missed the first session then I recommend you check it out here: https://www.youtube.com/watch?v=-6tv1kvBZDQ — why? Because in this session I mention that sticking to the same program and learning how it works usually leads to higher success rate. But Sean.. why is this important? Because if you haven’t guessed already, FastFoodHackings devs are going to now go away and fix the bugs you found and improve their site. Round two will be hacking on the same web application :)

The idea with this entire mentoring “season” I am hosting is to take you from zero to hero, from the start, to the end. :)

A word of warning

Firstly, the rules very clearly stated that *NO* automated tools were to be used. This session was to help you get in the mindset of a hacker when it comes to understanding web applications, not to turn on Burp Intruder and start ddosing the site. Someone literally created thousands of bogus accounts over and over.. for no purpose. What did you gain? I had comments from a few researchers saying, “But Sean, you clearly have a bug with no rate limiting if someone can do this?”. I get it, but this is a PERSONAL challenge I have created for you. If I wanted you to test rate limiting, I would of not excluded automated tools (how else can you test for it…?). If someone sets an XSS challenge, do you honestly just run a giant payload wordlist against it? No, so don’t do it to my challenges please.

This is my only warning: If you can’t abide by simple rules setup by me, then how can I trust you will use my information correctly and abide by bugbounty policies? If you break those, you run the risk of no reward, or worse, arrest. I am not here to help unethical and malicious users. Take it elsewhere!

Cool PoC’s & winners!

So, with that out the way. There was a swag prize for the researcher who found all bugs that I purposely placed, but sadly no-one found all bugs. Some researchers such as sivaneshashok found some unintentional bugs and if i’m honest, that was really awesome, because it showed the creativity really coming alive for some. Unique swag for you!

With swag mentioned, I am also rewarding some unique swag to those who created a really cool POC for their bugs. RishabhShukla for creating an awesome stored XSS poc and Kira for creating a PoC with hijacking a users token via the open url redirect.

Some of you mentioned that I should host a session on writing good reports and I definitely plan on doing this. Some reports were quite tough to follow and understand and did not go into enough detail. I understand what bug you was trying to describe, but for analysts/developers, more detail is definitely needed. With that said, I would like to publicly apologise to NeoLex who reported a bug but I did not fully understand the report. You was correct all along, sorry!:) Unique swag coming your way.

So, with that out of the way, onto the winners! I am happy to announce the following winners who were the first to each bug first.

I will be in contact very shortly about shipping your swag to all of you :)

  • mrxlimitless — They discovered that when viewing your settings if you simply changed the username cookie value to another users, you could view their details. Shubs and naffy mentioned a similar bug in their “Scrutiny on the bug bounty”, as seen here: https://docs.google.com/presentation/d/1PCnjzCeklOeGMoWiE2IUzlRGOBxNp8K5hLQuvBNzrFY/edit#slide=id.g129ec7274d_1_169
  • element — They discovered three bugs in a very short time span. First they discovered that even though the settings page says “You can’t change this information”, by viewing the source you can actually see there was a FORM post and the ‘Save’ button had just been hidden. Inspecting this and testing the request he noticed you can actually change the display name, despite it saying you can’t. The second part to this bug was they then noticed you can set XSS in the name. When registering an account it strips all HTML characters, but there was no validation when updating it via your settings :)
  • yashrs — They discovered that even though there was a csrfToken in the request, it simply did nothing and was not validated at all.
  • kallie — They discovered that when signing up without setting a password, it would default to the same for each user. There was a bug disclosed on a HackerOne program in which users were all given default passwords upon signup (I am struggling to find it, if you can find it, please DM me so I can update this)
  • ch1naa — They discovered the big bug. Firstly they discovered that FastFoodHackings was leaking it’s apiKeys on GitHub, and from viewing robots.txt they discovered an internal endpoint. Putting two & two togethet they very quickly accessed the internal API and found an endpoint which just took a users ID and would reveal their login token. Access to everyone’s account ACHIEVED!
  • humbleham & dpx — They both discovered an open url redirect on setToken.php which would leak a users login token to a malicious website, but a real working PoC was not provided, only information. Next time, poc please:)
  • cela0x — Discovered an endpoint to browse an internal endpoint. This endpoint though had nothing sensitive on it, but a warning message that if you see this, report it ASAP. I wanted to test who would saw it first and reported it :)
  • No winners for the three XSS I left on the homepage. Right infront of everyone. :) If you’re reading this and are curious, I won’t spoil it.. see if you can easily find all 3: https://www.bugbountynotes.com/mentoring/session?id=2

Where some of you went wrong

I received a lot of reports that you could enumerate yourprofile.php?p=[user] and view another users profile. This was intentionally and instead you should of been asking yourself, “So we can share a profile with other users… register says I can’t add XSS in my name.. but can I do it else where?” and started looking around the site (which should of sparked you to check robots.txt, which lead to settings.php being revealed).

I received lots of reports about “admin:admin” being valid credentials. But when you logged in, nothing was different. Just because you can login to an account doesn’t mean it’s an issue. If you had of logged in and saw a big red, “Admins only” feature, then yes it would of been an issue. Someone else created that account, not me.

Rate limiting. I can understand why lots of people thought it was an issue, “no rate limiting to brute force passwords or on signup”, but the rules very clearly stated NO automated tools. If I built protection around rate limiting then I would of allowed it. Please read the rules next time.

I received reports about XSS in the name *before* the redirect on login. This says to me too many people jumped straight in and did not get a good “feel” for how the site worked, what was available on it etc. Bugbounties is not a race, take your time people, this is your chance to learn how to understand what is going on!:)

Until next time, happy hacking!

If you have any feedback please feel free to email me at zseano@bugbountynotes.com.

If you enjoy my mentoring and want to contribute you can find donation details when clicking “Thank Mentor” on mentor pages here: https://www.bugbountynotes.com/mentoring/session?id=1

Sean (zseano)

Written by

UK WebApp Security Researcher. Creator of https://www.bugbountynotes.com/ — designed to help people learn and get involved with hacking.