Facebook Doubles Bounties for Bugs in Ads Code, Offers 'Bounty Hunter's Guide'

Facebook continued its focus on security with two announcements Wednesday related to its white-hat program: The social network is doubling the bounties that it will pay out to researchers who discover white-hat bugs its ads code, and it released a “Bounty Hunter’s Guide” containing detailed instructions on how to submit those bugs. Security engineer Collin Greene wrote in a note on the Protect the Graph page: Starting today and extending through the end of 2014, all white-hat bugs in our ads code will receive double bounties. We recently completed a comprehensive security audit of this area ourselves. We found and fixed a number of security bugs but would like to encourage additional scrutiny from white hats to see what we might have missed. Also, since the vast majority of bug reports we work on with the white-hat community are focused on the more common parts of Facebook code, we hope to encourage researchers to become more familiar with the surface area of ads to better protect the businesses that use them. Greene also outlined the sections of the social network’s ad code: UI: The user interface is made up of our old and new Ads Manager tools (at /ads/manage/), as well as the JavaScript-based Power Editor tool that supports bulk ad edits and uploads. Most of the serious white-hat bugs in this area have surfaced around permissions, viewing ads or parts of an ad that is not yours. Ads API: The documentation for this frequently used application-programming interface is a good introduction to the describe components of ads: a user, a campaign, an account, creative and so on. While not present in the ads API itself, the following write-up describes an excellent bug of the type that might be found in there: http://stephensclafani.com/2014/07/08/hacking-facebooks-legacy-api-part-1-making-calls-on-behalf-of-any-user/. Analytics, also called insights: Analytics is what measures the performance of an ad, how well the ads are performing and so on. Like with UI, the bugs we've seen in this area that had the largest impact have been missing or incorrect permissions checks. For example, we had an issue where someone could access insights for any application via a Graph API token with the read_insights permission. Everything else: There is a lot of back-end code to correctly target, deliver, bill and measure ads. This code isn't directly reachable via the website, but of the small number of issues that have been found in these areas, they are relatively high impact. Greene concluded: At this stage of our bug bounty program, it's uncommon for us to see many of the common Web security bugs like XSS. What we see more often are things like missing or incorrect permissions checks, insufficient rate-limiting that can lead to scraping, edge-case CSRF issues and problems with SWFs. Ads-related code is the main part of Facebook that has and enforces roles, so it's also worthwhile to understand them: https://www.facebook.com/help/289207354498410. Among these roles, the permissions for reading or writing billing information are the most relevant. The best way to report an issue is to use your white-hat test account: https://www.facebook.com/whitehat/accounts/. Good luck, and keep the submissions coming! Greene also posted “A Bounty Hunter’s Guide to Facebook,” a note on the Facebook Bug Bounty page, offering best practices for submitting bugs to the social network. For full details, see the note, but a summary of recommended steps follows: Describe the bug: White-hat submissions require both a title and a summary. The title should be a quick description, while the summary should be longer and more free form. Reproduce the bug: To confirm that a bug is real, we need to be able to reproduce it. The ideal form for communicating how to reproduce is a step-by-step list of what actions were taken. Describe the impact: Describing the impact of a bug means saying what is broken and how bad it is. Another way to look at this is to say what can be done that shouldn't normally be possible. For our ads example, this is the issue: “Can read any file on a Web server.” Optional, supplementary sections: Videos can occasionally help your submission, but please keep any video content short and be sure to keep it private when you upload it (otherwise you may accidentally forfeit your bounty, since a public video could lead to public disclosure before the bug is fixed). If you are reporting a bug on a mobile application or similar, it can be helpful to include the version information. Additionally, a complete report will often include not only the bug, but also a recommended fix. Even if you are not sure how to fix a bug, spending time thinking about how we would fix it can lead to greater understanding of the issue on both sides. Greene also supplied the following questions that researchers should ask themselves before submitting bugs: Ask yourself: is this an issue at all? Sometimes white-hat reporters aren't clear about the intended behavior for a function on the site. For example, we've received a number of reports related to the ability for someone to save another person's profile photo. In these cases, it can be helpful to look through the Facebook Help Center for information about how our site and tools work. It turns out that being able to see another person's profile photo is not a security bug because current profile photos are public. An up-to-date list of false positive bugs can be found here: https://www.facebook.com/notes/facebook-bug-bounty/commonly-submitted-false-positives/744066222274273. What's the best way to test? First, make a white-hat test account here: https://www.facebook.com/whitehat/accounts/. If you absolutely cannot test with a white-hat test account, the next best option is to get permission from a friend to test using their account. Please don't test your issue in a disruptive or malicious manner; we've unfortunately had to refuse payments in the past for this reason. When we receive a report, we may ask questions of you that seem really basic or obvious. Please be patient -- our goal is to better narrow down the potential bug so that we can reproduce it as quickly as possible. How does Facebook reward bugs? The biggest factor in our decisions about reward amounts is impact. If there is a bigger theoretical risk to people using Facebook or Facebook itself, the reward will be higher. What this means is that if you and someone else find bugs with similar severities, we will pay roughly the same amount for both issues with minor allowances given to the cleverness of the issue and clarity of the report. We try to go above and beyond here; if someone submits a bug that has more impact than they realize, we pay out at the higher level. What tools are helpful? Keeping an inquisitive mind and thinking about the assumptions made by the person writing the code are the most helpful tools. For example, your thought process might look like this: “This endpoint works for someone using Facebook. What about for a page, or an ads account ...?”). We find scanners are generally not helpful. An intercepting proxy like Burp Scanner may be handy, though. Readers: What did you think of Facebook’s announcements related to its white-hat program? Image courtesy of Shutterstock.

Social Pro Daily

Facebook Doubles Bounties for Bugs in Ads Code, Offers 'Bounty Hunter's Guide'

David Cohen

About

Subscriptions

Events

Publications

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

David Cohen