6 ms·

The easiest bug bounties I have won

145 points by franjkovic 11y ago

dmix 11y ago
Mobile would be great for taking this kind of approach to bug hunting. Especially since Android just launched a (proper) bug bounty program [0]. A ton of old problems are new again on Android, especially due to the fact a significant percentage of the OS stuff is being re-implemented in Java (IPC, sandboxing, etc). The more I dig into it the more I'm convinced very few people are conducting serious security reviews outside of Google. Take this bug as an example: http://seclists.org/fulldisclosure/2014/Nov/81 http://seclists.org/fulldisclosure/2014/Nov/81 An apk with system privileges (the settings app) would accept IPC messages from any unprivileged app and relay them with system privileges. [0] http://techcrunch.com/2015/06/16/google-launches-bug-bounty-program-for-android-with-rewards-up-to-8000/ http://techcrunch.com/2015/06/16/google-launches-bug-bounty-...
kccqzy 11y ago
It is quite saddening that there is a recent trend of hiding the complete URL from the user when the URL itself conveys much information. When the URL is hidden the user is not given the incentive to look at the URL, let alone modify it. This kind of bug should have been discovered much sooner when the user is given the opportunity to directly look at the URL and experiment with it.
- dublinben 11y ago
  >experiment with it Be careful with simple "experimentation" like this. You can fall afoul of the CFAA for exactly this.
  - danieljchen 11y ago
    Explain?
    - dublinben 11y ago
      This is very similar to what Weev was indicted and convicted for.[0] Simply passing valid requests to a system can by construed as "unauthorized" if it is unexpected by the operator of that system. [0] https://en.wikipedia.org/wiki/Goatse_Security https://en.wikipedia.org/wiki/Goatse_Security
- interurban 11y ago
  It's not too hard to obfuscate the actual domain for non-technical users, leading to easier phishing. By only displaying the actual domain name, it's much easier for people to see that they aren't on the site they expect to be. IMO, the tradeoff of reducing phishing effectiveness is worth the small amount of additional effort needed to find this bug.
r3bl 11y ago
Been following your work for years now and I think that this is actually the first bug I fully understand.
joosters 11y ago
Doesn't this show just how crappy the backend permissions must be in Facebook's code? Every new page needs to get the permissions checks exactly right, otherwise... Disaster. As an analogy, It's like the most stupidly-designed UNIX system, where each user program that opens a file runs as root and must remember to do a permissions check when opening a file, rather than centralising the permissions system in the kernel. No-one would accept such a shoddy design in an OS, yet in today's web apps it is apparently standard practice...
- eterm 11y ago
  But facebook isn't an OS, and it's the kind of stuff that many developers aren't used to dealing with. It's the equivalent of saying that many desktop applications with server back-ends had leaky permissions. The consequences are potentially far worse at facebook scale of course, but it's not like we as software developers generally have gone from understanding how to easily prevent these problems to an amnesiac state where we're suddenly careless.
  - joosters 11y ago
    Given the relentless appearance of this style of security bug in multiple Facebook pages, I think your description of a careless, amnesiac state is spot on.
    - sneak 11y ago
      Move fast and break things. At least they're not a bank.
  - Erwin 11y ago
    In my app, I've been quite pleased with REST API endpoints mapping segments to objects the API will work on and explicitly declaring the permission before any page specific code runs. So if you have an URL like /{username}/year/{year}/profile_lists you would in a declarative style, say that "username" must match an existing Facebook user ID, and that the page viewer must be able to view certain privacy related settings of the username. When your code runs, you get the current user, the username from the URL is mapped to another user object, year is mapped to an integer etc. It's an error to declare an API which needs access to a resource without saying what type of access is required. In Facebook's case maybe I'd go one step further and create a proxy object for the user that codifies those rules. So if you ask for "view profile friend stats" access, and it's granted, the user object your function gets cannot start modifying things.
Retr0spectrum 11y ago
I've been wanting to start doing bug bounties for a while now, but I have only been able to find serious bugs in sites without bug bounty schemes. I was starting to think that it would be impossible to get any bug bounties because of the number of people searching, but this post gives me some confidence.
- ssclafani 11y ago
  I've been doing bug bounties for the past few years, here's some advice to get started: 1. Monitor https://hackerone.com https://hackerone.com, https://bugcrowd.com https://bugcrowd.com and Twitter for announcements of new programs. 2. When looking for bugs in sites with existing programs like Facebook your best chance is when they announce a new feature or product. This includes acquisitions (Facebook paid out over $100,000 for bugs when they added the Oculus websites to their program).
  - earlz 11y ago
    In general do you need to register or anything like that? I think it'd be a fun thing to try, but also don't want any of the bad legal repercussions that can come with it
    - ssclafani 11y ago
      Some programs require you to register an account to report a bug while others use email, but you don't need to get permission to look. All bug bounty programs have rules that outline what parts of their site/product you can test and what kinds of bugs they are looking for (here's Facebook's https://www.facebook.com/whitehat/ https://www.facebook.com/whitehat/). As long as you follow the rules you won't have any legal problems.
- SamHoustonCM 11y ago
  New programs are launching all the time or the scope of current programs is expanding out to include new products or features. It's never too late to get started, there's actually more work than researchers at the moment and it will be like that for many, many years to come. In terms of how to get started, I definitely suggest monitoring the various bug bounty sites to see what's new and if a bounty's scope has expanded. There's also a bunch of guides, tutorials, and tools listed on Bugcrowd's Forum: https://forum.bugcrowd.com/c/security-research https://forum.bugcrowd.com/c/security-research
colinbartlett 11y ago
Can anyone comment on when is a good time to start a bug bounty program? I have some clients with relatively small scale (small budget) projects. Is it better to post a bounty program on HackerOne? Or force them to budget to hire a security researcher consultant for a day to find high-level issues? Or both?
- arkem 11y ago
  In my experience with running bug bounties it will be cheaper in terms of time (and probably in terms of money) and more effective to hire an application security consultant to look at the projects first. Bug bounties require a lot of time to keep on top of the submissions (essential in providing a good experience for researchers) and to filter out the noise of invalid and working-as-intended bugs. Having a consultant come through will mean that your bugs will be the exception rather than the rule. Instead of every form field and parameter having a cross site scripting bug only that deprecated status page that you'd forgotten about will be vulnerable. A good consultant will also be able to help you fix the bugs and avoid them in the future. Getting the low hanging fruit out of the way before launching This difference can easily pay for the consultant, since each XSS can be worth >$500 (or thousands in the case of the bounty programs I've worked on) so getting the low hanging fruit out of the way before launching is definitely worth it.

145 points by franjkovic 11y ago

dmix 11y ago

Mobile would be great for taking this kind of approach to bug hunting. Especially since Android just launched a (proper) bug bounty program [0]. A ton of old problems are new again on Android, especially due to the fact a significant percentage of the OS stuff is being re-implemented in Java (IPC, sandboxing, etc). The more I dig into it the more I'm convinced very few people are conducting serious security reviews outside of Google. Take this bug as an example: http://seclists.org/fulldisclosure/2014/Nov/81 http://seclists.org/fulldisclosure/2014/Nov/81 An apk with system privileges (the settings app) would accept IPC messages from any unprivileged app and relay them with system privileges. [0] http://techcrunch.com/2015/06/16/google-launches-bug-bounty-program-for-android-with-rewards-up-to-8000/ http://techcrunch.com/2015/06/16/google-launches-bug-bounty-...

kccqzy 11y ago

It is quite saddening that there is a recent trend of hiding the complete URL from the user when the URL itself conveys much information. When the URL is hidden the user is not given the incentive to look at the URL, let alone modify it. This kind of bug should have been discovered much sooner when the user is given the opportunity to directly look at the URL and experiment with it.

dublinben 11y ago
>experiment with it Be careful with simple "experimentation" like this. You can fall afoul of the CFAA for exactly this.
- danieljchen 11y ago
  Explain?
  - dublinben 11y ago
    This is very similar to what Weev was indicted and convicted for.[0] Simply passing valid requests to a system can by construed as "unauthorized" if it is unexpected by the operator of that system. [0] https://en.wikipedia.org/wiki/Goatse_Security https://en.wikipedia.org/wiki/Goatse_Security
interurban 11y ago
It's not too hard to obfuscate the actual domain for non-technical users, leading to easier phishing. By only displaying the actual domain name, it's much easier for people to see that they aren't on the site they expect to be. IMO, the tradeoff of reducing phishing effectiveness is worth the small amount of additional effort needed to find this bug.

r3bl 11y ago

Been following your work for years now and I think that this is actually the first bug I fully understand.

joosters 11y ago

Doesn't this show just how crappy the backend permissions must be in Facebook's code? Every new page needs to get the permissions checks exactly right, otherwise... Disaster. As an analogy, It's like the most stupidly-designed UNIX system, where each user program that opens a file runs as root and must remember to do a permissions check when opening a file, rather than centralising the permissions system in the kernel. No-one would accept such a shoddy design in an OS, yet in today's web apps it is apparently standard practice...

eterm 11y ago
But facebook isn't an OS, and it's the kind of stuff that many developers aren't used to dealing with. It's the equivalent of saying that many desktop applications with server back-ends had leaky permissions. The consequences are potentially far worse at facebook scale of course, but it's not like we as software developers generally have gone from understanding how to easily prevent these problems to an amnesiac state where we're suddenly careless.
- joosters 11y ago
  Given the relentless appearance of this style of security bug in multiple Facebook pages, I think your description of a careless, amnesiac state is spot on.
  - sneak 11y ago
    Move fast and break things. At least they're not a bank.
- Erwin 11y ago
  In my app, I've been quite pleased with REST API endpoints mapping segments to objects the API will work on and explicitly declaring the permission before any page specific code runs. So if you have an URL like /{username}/year/{year}/profile_lists you would in a declarative style, say that "username" must match an existing Facebook user ID, and that the page viewer must be able to view certain privacy related settings of the username. When your code runs, you get the current user, the username from the URL is mapped to another user object, year is mapped to an integer etc. It's an error to declare an API which needs access to a resource without saying what type of access is required. In Facebook's case maybe I'd go one step further and create a proxy object for the user that codifies those rules. So if you ask for "view profile friend stats" access, and it's granted, the user object your function gets cannot start modifying things.

Retr0spectrum 11y ago

I've been wanting to start doing bug bounties for a while now, but I have only been able to find serious bugs in sites without bug bounty schemes. I was starting to think that it would be impossible to get any bug bounties because of the number of people searching, but this post gives me some confidence.

ssclafani 11y ago
I've been doing bug bounties for the past few years, here's some advice to get started: 1. Monitor https://hackerone.com https://hackerone.com, https://bugcrowd.com https://bugcrowd.com and Twitter for announcements of new programs. 2. When looking for bugs in sites with existing programs like Facebook your best chance is when they announce a new feature or product. This includes acquisitions (Facebook paid out over $100,000 for bugs when they added the Oculus websites to their program).
- earlz 11y ago
  In general do you need to register or anything like that? I think it'd be a fun thing to try, but also don't want any of the bad legal repercussions that can come with it
  - ssclafani 11y ago
    Some programs require you to register an account to report a bug while others use email, but you don't need to get permission to look. All bug bounty programs have rules that outline what parts of their site/product you can test and what kinds of bugs they are looking for (here's Facebook's https://www.facebook.com/whitehat/ https://www.facebook.com/whitehat/). As long as you follow the rules you won't have any legal problems.
SamHoustonCM 11y ago
New programs are launching all the time or the scope of current programs is expanding out to include new products or features. It's never too late to get started, there's actually more work than researchers at the moment and it will be like that for many, many years to come. In terms of how to get started, I definitely suggest monitoring the various bug bounty sites to see what's new and if a bounty's scope has expanded. There's also a bunch of guides, tutorials, and tools listed on Bugcrowd's Forum: https://forum.bugcrowd.com/c/security-research https://forum.bugcrowd.com/c/security-research

colinbartlett 11y ago

Can anyone comment on when is a good time to start a bug bounty program? I have some clients with relatively small scale (small budget) projects. Is it better to post a bounty program on HackerOne? Or force them to budget to hire a security researcher consultant for a day to find high-level issues? Or both?

arkem 11y ago
In my experience with running bug bounties it will be cheaper in terms of time (and probably in terms of money) and more effective to hire an application security consultant to look at the projects first. Bug bounties require a lot of time to keep on top of the submissions (essential in providing a good experience for researchers) and to filter out the noise of invalid and working-as-intended bugs. Having a consultant come through will mean that your bugs will be the exception rather than the rule. Instead of every form field and parameter having a cross site scripting bug only that deprecated status page that you'd forgotten about will be vulnerable. A good consultant will also be able to help you fix the bugs and avoid them in the future. Getting the low hanging fruit out of the way before launching This difference can easily pay for the consultant, since each XSS can be worth >$500 (or thousands in the case of the bounty programs I've worked on) so getting the low hanging fruit out of the way before launching is definitely worth it.