Challenge Overview

  • For scoring, the submitter with the most accepted bugs will win 1st place prize. In addition to $100 for each unique accepted Vulnerability bug reported.

  • For each submitters who submitted accepted Vulnerability bugs, if they submit bugs that aren't covered in the first submission, they will receive $100 for each unique  Vulnerability bug reported.

Project Overview

BrivoLabs has a beta version of a node.js/coffeescript application that is called Social Access Management (SAM) API. It uses postgres database, runs on heroku, consists of both a web and a worker process, and uses a redis-based message queue to communicate between them.

The scope of this bug hunt is to find Vulnerabilities in the new version of SAM API which is currently in beta.  The goal of the bug hunt is to improve the overall security of the API.

Contest Objective

The goal of this competition is to clearly identify the limitations and vulnerabilities in the SAM API. You can find the documents describing the API in contest forum.

Vulnerabilities of special interest include:

  • Ability to trade without proper authentication (OAuth2 bypass/spoof)
  • Multi-tenancy (accessing data from other domains, etc)
  • Unauthorised account access (i.e. roles bypass .. etc)
  • Disclousre of users data (Identity, Account, Credentials ..etc)
  • Significant Information leaks
  • Here is a list of top 25 vulnerabilities https://cwe.mitre.org/top25/ you can also check the full list
  • You should also focus on Vulnerabilities that can be caused by dependencies node modules.

General Notes

  • The testing environment is in development mode. This mode does not have SSL enabled, so reported bugs related to https/SSL will not be accepted.
  • We have 4 roles in the api, 'global_admin', 'admin', 'superadmin', and 'user'. You can refer to src/route.coffee file to see what each role can perform. if 'public' flag exits in the route, it means that the API does not need an oauth to access it.
  • Any endpoint logic that deal with external services like ACS (Brivo internal service) and Salesforce (chatter) are out of scope of this challenge.
  • You can use any 3rd party tools that help inspecting Vulnerabilities, such as Checkmarx (checkmarx can be run using thurgood tool), also you can look at this Whitepaper for security testing fore more guide and tools recommendations.

Testing Environment

You have two options for hacking the API :

  • Use the Heroku deployed version located in https://brivolabs-sam-dev.herokuapp.com
    • Post in the contest forums to get OAuth 2.0 client id/secret or you can use the default values :
      • client id : 1
      • client secret : demo-secret
      • calback URI : http://localhost:5000/oauth/callback
    • You need salesforce and google accounts to login and generate access tokens via OAuth 2.0 flow.
    • Pst in the forums a request to get admin role associated with your account. we will give you two domains so you can test multi-tenancy.
  • Also you can deploy the API locally or in your own Heroku account, the deployment is straightforward, you will need to follow the deployment README file in the provided code.

You can use postman.json to make calls to the API (you can find it in the provided source code), please read the README file in the source code to understand how to use the postman and deploy the API.

Challenge Guidelines

The guidelines for this contest are given below:

  • As issues are identified they need to be logged in JIRA.
  • Issues must follow the Bug Report Format section below.
  • First competitor to find an issue gets credit, duplicates will not be counted.
  • Reviewers will accept, reject or mark the issues as duplicate.
  • Please DO take a look at the reported bugs, duplicated bugs cost your work time and the reviewer's time.

Important Notice:

You must also be the first person to report the issue and submit it while submission phase is open.  JIRA will allow you to file issues before and after the submission phase, but these will NOT be counted.

Technologies

  • Node.JS
  • PostgreSQL
  • Coffeescript
  • Heroku
  • OAuth 2.0
  • Salesforce
  • Google

Provided Resources

Documentation Provided

The source code is provided in challenge forums. It includes a readme for how to setup the API, it also includes architecture documents of the API.

Additional Resources

Some of the additional resources helpful for the project are

Contest Prize Eligibility

The submitter with the most accepted bugs will win the contest.



Final Submission Guidelines

Bug Report Process

Bug Report Format

For each report of a limitation or bug, we need the following information:

  • Title of the vulnerability (this is the name of the jira ticket)
  • API Endpoint URL
  • Vulnerability type
  • Description
  • Vlunerability Details
    • HTTP Request
    • Requests Params
    • Prerequisits (i.e. Specific Authorization? Authenticated user required ? .. etc)
    • Steps to reproduce
    • Tools used
    • Suggested fix
    • Screenshot images (if needed!)

 Important Notice:

  • If you do not properly document your bug reports, they will likely be rejected due to lack of information or documentation. Also, make sure your bug reports are reasonably general.
  • If you submit the same bug that is seen in multiple screens, for instance, you will likely only get credit for the original bug report. The others will all be closed as duplicates.

Ticket Logging

You will log your tickets here: https://apps.topcoder.com/bugs/browse/BRVOBH and when creating a bug you MUST select the "2014 March - BrivoLabs SAM API Vulnerabilities". Bugs will not be counted if a selection is not made.

Scoring

The Scoring guidelines followed for the contest are given below:

  • For scoring, the submitter with the most accepted bugs will win.
  • For submitters who submit but don't take first or second, if they submit bugs that aren't covered in the first, they will receive $100 for each unique Vulnerability bug reported.

 Important Notice:

If two submitters submit the same bug report, the submitter who submitted the report first into JIRA will get credit for the bug. The second submitter will not. 

Tips

Some of the tips helpful for the contest are:

  • Submitting what is obviously the same issue multiple times with small variations will only annoy the reviewer that has to sort through all the issues and will only count as one issue anyway. If it's less obvious if it is the same issue or not, use your best judgment and the reviewers will do the same.
  • Put an eye on the issues being submitted by other members to minimize the time you may be spending on duplicate efforts. Knowing what has already been reported will allow you to better focus your time on finding yet undiscovered issues.
  • Double check your steps to reproduce and test cases to make sure they are clear. Make sure your steps include creation of any necessary data.

Submission Deliverables

You need report your issues in JIRA. Please submit a text file contains the bugs you reported to OR.

Final Submission

  • For each member, the final submission should be uploaded to the Online Review Tool.
  • You must not include any identifying information, such as your handle, in your submission. Your submission should be anonymous and you will be scored down in screening for not complying.

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30041477