Banner object (1)

Hack and Take the Cash !

661 bounties in database
18/07/2018

Microsoft Identity Bounty | MSRC

PROGRAM DESCRIPTION

Modern security depends today on collaborative communication of identities and identity data within and across domains. A customer’s digital identity is often the key to accessing services and interacting across the internet. Microsoft has invested heavily in the security and privacy of both our consumer (Microsoft Account) and enterprise (Azure Active Directory) identity solutions. We have strongly invested in the creation, implementation, and improvement of identity-related specifications that foster strong authentication, secure sign-on, sessions, API security, and other critical infrastructure tasks, as part of the community of standards experts within official standards bodies such as IETF, W3C, or the OpenID Foundation. In recognition of that strong commitment to our customer’s security we are launching the Microsoft Identity Bounty Program.

If you are a security researcher and have discovered a security vulnerability in the Identity services, we appreciate your help in disclosing it to us privately and giving us an opportunity to fix it before publishing technical details. Further in our commitment to the industry identity standards work that we have worked hard with the community to define, we are extending our bounty to cover those certified implementations of select OpenID standards. Submissions for standards protocol or implementation bounties need to be with a fully ratified identity standard in scope of this bounty and have discovered a security vulnerability with the protocol implemented in our certified products, services, or libraries.

Together we can bring assurance that digital identities are safe and secure.

The Microsoft Identity Bounty Program is subject to the legal terms outlined here and amended within this program description.

WHAT CONSTITUTES AN ELIGIBLE SUBMISSION?

The Microsoft Bug Bounty program is looking to reward high quality submissions that reflect the research that you put into your discovery. The goal of your report is to share your knowledge and expertise with Microsoft developers and engineers so that they can quickly and efficiently understand and reproduce your finding. This way, they have the background and context to fix the vulnerability.

Vulnerability submissions provided to Microsoft must meet the following criteria to be eligible for payment:

  • Identify an original and previously unreported critical or important vulnerability that reproduces in our Microsoft Identity services that are listed within scope.
  • Identify an original and previously unreported vulnerability that results in the taking over of a Microsoft Account or Azure Active Directory Account.
  • Identify an original and previously unreported vulnerability in listed OpenID standards or with the protocol implemented in our certified products, services, or libraries.
  • Submit against any version of Microsoft Authenticator application, but bounty awards will only be paid if the bug reproduces against the latest, publicly available version.
  • Include a description of the issue and concise reproducibility steps that are easily understood. (This allows submissions to be processed as quickly as possible and supports the highest payment for the type of vulnerability being reported.)
  • Include the impact of the vulnerability
  • Include an attack vector if not obvious

Scope:

  • login.windows.net
  • login.microsoftonline.com
  • login.live.com
  • account.live.com
  • account.windowsazure.com
  • account.activedirectory.windowsazure.com
  • credential.activedirectory.windowsazure.com
  • portal.office.com
  • passwordreset.microsoftonline.com
  • Microsoft Authenticator (iOS and Android applications)*

Standards Scope**:

  • OpenID Foundation - The OpenID Connect Family
    • OpenID Connect Core
    • OpenID Connect Discovery
    • OpenID Connect Session
    • OAuth 2.0 Multiple Response Types
    • OAuth 2.0 Form Post Response Types
  • Microsoft products and services Certified Implementations listed here (http://openid.net/certification)

  • For mobile applications the research must reproduce on the latest version of the application and mobile operating system.

** LEGAL NOTE: Standards professionals with contributions or affiliations to identity standards working groups are not eligible to receive standards- related bounties.

Out of Scope:

  • Reports from automated tools or scans
  • Issues without clearly identified security impact (such as clickjacking on a static website), missing security headers, or descriptive error messages
  • Password, email and account policies, such as email id verification, reset link expiration, password complexity
  • Security misconfiguration of a service by a user, such as the enabling of HTTP access on a storage account to allow for man-in-the-middle (MiTM) attacks
  • Standards-based Vulnerabilities in any specification with a status of draft, candidate release, or implementation draft. Issues with candidate, implementation, or draft standards should be reported directly to the standards body in question as part of the normal standards creation process.
  • Standards-based Vulnerabilities in specifications not explicitly listed.
  • Standards-based vulnerabilities in non-certified implementations of Microsoft products and services.
  • Missing HTTP Security Headers (such as X-FRAME-OPTIONS) or cookie security flags (such as “httponly”)
  • Server-side information disclosure such as IPs, server names and most stack traces
  • Denial of Service issues
  • Vulnerabilities requiring unlikely user actions
  • Publicly-disclosed vulnerabilities which are already known to Microsoft and the wider security community
  • Vulnerabilities in third party software provided by Azure such as gallery images and ISV applications
  • Vulnerabilities in the web application that only affect unsupported browsers and plugins
  • Vulnerabilities used to enumerate or confirm the existence of users or tenants
  • Submissions that require manipulation of data, network access, or physical attack against Microsoft offices or data centers and/or social engineering of our service desk, employees or contractors will not be accepted
  • Two-factor authentication bypass that requires physical access to a logged-in device
  • Local access to user data when operating a rooted mobile device

HOW ARE PAYMENT AMOUNTS SET?

Rewards for submissions that qualify for a bounty range from $500 up to $100,000. Higher payouts are given based on the quality of the report and the security impact of the vulnerability. Security researchers are encouraged to provide as much data at the time of submission to be more likely of the highest payout possible. We typically reward lower amounts for vulnerabilities that require significant user interaction.

  • If we receive multiple bug reports for the same issue from different parties, the bounty will be granted to the first submission.
  • The first external report received on an internally known issue will receive a maximum of 10% of the maximum payout.
  • If a duplicate report provides us new information that was previously unknown to Microsoft, we will award a differential to the duplicate submission.
  • If a submission is potentially eligible for multiple bounty programs, you will receive single highest payout from a single bounty program.
  • Microsoft reserves the right to reject any submission at our sole discretion that we determine does not meet the above criteria.

A high-quality report provides the information necessary for an engineer to quickly reproduce, understand, and fix the issue. This typically includes a concise write up containing any required background information, a description of the bug, and a proof of concept. We recognize that some issues are extremely difficult to reproduce and understand, and this will be considered when adjudicating the quality of a submission.

Many of our sites share a common platform. Because of this, a vulnerability reported on one domain may exist on another domain if the issue exists in the shared platform itself. For example, an issue reported for account.microsoft.com may also present in the exact same way on account.microsoft.co.uk and the issue will be resolved on both sites with the same fix. We ask that you take the time to try to confirm this first, and include the other vulnerable locations in one report rather than submitting multiple reports. In these cases, we treat the issue as one bug and will close out others as duplicates.

AN IMPORTANT NOTE ABOUT RESEARCH AND CUSTOMER DATA

Independent security research is an important component to overall confidence in the security of products and services. As part of that research, the community must also be aware that these services are live and running in a production environment for the continual use of customers. We ask that security researchers make a good faith effort to:

  • Avoid privacy violations, destruction of data, and interruption or degradation of our service during your research. If you discover customer data while researching stop immediately and contact us.
  • Testing for vulnerabilities should only be performed on tenants in subscriptions/accounts owned by the program participant. In the list below, refers to a tenant in a subscription that you own – do not run tests against any other tenants.
  • Moving beyond “proof of concept” repro steps for server-side execution issues (i.e. proving that you have sysadmin access with SQLi is acceptable, running xp_cmdshell is not).

PROHIBITED SECURITY RESEARCH METHODS

To further help security researchers understand the bounds of research within our services, the following methods are prohibited:

  • Attempting phishing or other social engineering attacks against our employees. The scope of this program is limited to technical vulnerabilities in the specified Microsoft Online Services.
  • Any kind of Denial of Service testing.
  • Performing automated testing of services that generates significant amounts of traffic.
  • Gaining access to any data that is not wholly your own. For example, you are allowed to and encouraged to create a small number of test accounts and/or trial tenants for the purpose of demonstrating and proving cross-account or cross-tenant data access. However, it is prohibited to use one of these accounts to access the data of a legitimate customer or account.

Even with these prohibitions, Microsoft reserves the right to respond to any actions on its networks that appear to be malicious. When in doubt, consider the possible impact to customers using our services and take great deference to their experience and data.

WHAT CONSTITUTES AN INELIGIBLE SUBMISSION FOR THE MICROSOFT IDENTITY

BOUNTY?

The aim of the bounty program is to uncover significant vulnerabilities that have a direct and demonstrable impact to the security of our users and our users’ data. While we encourage any submissions that describe security vulnerabilities in our service, the following are examples of vulnerabilities that will not earn a bounty reward:

  • Vulnerabilities in user-created content or applications.
  • Security misconfiguration of a service by a user, such as the enabling of HTTP access on a storage account to allow for man-in-the-middle (MiTM) attacks.
  • Missing HTTP Security Headers (such as X-FRAME-OPTIONS) or cookie security flags (such as “httponly”)
  • Server-side information disclosure such as IPs, server names and most stack traces
  • Denial of Service issues
  • Vulnerabilities requiring unlikely user actions
  • 3rd party and customer sub-domain takeovers
  • Publicly-disclosed vulnerabilities which are already known to Microsoft and the wider security community
  • Vulnerabilities in third party software provided by Azure such as gallery images and ISV applications
  • Vulnerabilities in the web application that only affect unsupported browsers and plugins
  • Vulnerabilities used to enumerate or confirm the existence of users or tenants

HOW TO CREATE TRIAL ACCOUNTS FOR TESTING OF BOUNTY-ELIGIBLE AZURE AND

MICROSOFT ACCOUNT SERVICES?

You must create test accounts and test tenants for security testing and probing.

In all cases, where possible, include the string “MSOBB” in your account name and/or tenant name in order to identify it as being in use for the bug bounty program.

For inquiries on this program and its rules, you may contact bounty@microsoft.com. NOTE: We cannot pre- determine possible payouts prior to official submission of a vulnerability. Happy hunting!

LEGAL NOTICE

To review the terms and conditions for the Bug Bounty Program, please go to here.

Thank you for participating in the Microsoft Bug Bounty Program!

Thanks
Gift
Hall of Fame
Reward


List your Bug Bounty for free immediately!

Contact us if you want more information.

FireBounty (c) 2015-2018