Overview:

At Zebra, we are committed to collaborating with the security community to identify and address vulnerabilities. Our goal is to safeguard our businesses and ensure the safety of our customers.

Scope:

Everything Zebra-owned or controlled is in scope unless otherwise stated in the asset list.

Production and Non-Production Environments:

Production Environment: This environment consists of all live systems and services actively used by Zebra’s customers. Testing in this environment should be conducted with extreme caution to avoid any impact on our users. Non-Production Environment: This environment includes all systems and services used for development, testing, and staging purposes. Researchers are strongly encouraged to conduct tests here whenever possible to prevent disruptions to live services.

Response Targets:

Zebra will work to meet the following SLAs for ethical hackers (“Researchers”) participating in our program:

We’ll try to keep you informed about our progress throughout the process!

Disclosure Policy:

• As this is a private program, please do not discuss this program or any bugs or vulnerabilities (even resolved ones) outside of the program without express, written consent from Zebra.
• Always follow HackerOne’s disclosure guidelines.

Program Rules:

Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for validation.

• Try to provide a remediation; it helps the development team to know the fix from Researchers’s point of view.
• Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we only validate the first report that was received that can be fully reproduced.
• Multiple vulnerabilities caused by one underlying issue will be validated once even if multiple endpoints are affected by the one underlying issue.
• Social engineering (e.g., phishing, vishing, smishing) is strictly prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit, written permission of the account holder.

1. HTTP Headers:

   • Include a custom HTTP header in all your traffic. Burp and other proxies allow the easy automatic addition of headers to all outbound requests.
   • Identifier: Your Username
   • Format: X-Bug-Bounty:HackerOne-<username>
   • Example: X-Bug-Bounty: HackerOne-flyingtoasters
   • Identifier: Tool Identifier
   • Format: X-Bug-Bounty:<toolname>
   • Example: X-Bug-Bounty: BurpSuitePro

2. Email Alias:

• For anything that requires credentials, researchers must use their @wearehackerone.com email alias as part of the HackerOne platform.

Rules of Engagement:

To ensure the stability of our systems for Zebra, our customers, and fellow ethical Researchers, please follow these guidelines:

1. Account Usage:

• Conduct testing only with your own personal/test accounts or accounts for which you have explicit, written permission from the account holder.
• Include your @wearehackerone.com email address in reports for verification.

2. Testing Caution:

• Be careful during testing to prevent any negative impact on customers and their services.
• If unsure or if you suspect potential harm, stop immediately, report your findings, and seek authorization before continuing.

3. Demonstrating Vulnerabilities:

• For SQL Injection (SQLi), use safe methods like a sleep command to demonstrate vulnerabilities without unauthorized data access or modification.

4. Access Control Vulnerabilities:

• If you report an access control vulnerability, subsequent reports exploiting the same flaw will be treated as duplicates. However, additional credentials exposed will be considered “Medium” severity for validation.
• This policy applies globally to all domains and subdomains under our program. Once an access control issue is reported, similar root cause findings will follow this policy.
• Once the root cause is resolved, new, distinct vulnerabilities will be assessed independently.
• We will maintain open communication with researchers, ensuring clarity in classification and validation decisions.

5. Remote Code Execution (RCE):

• Use commands like ‘whoami’ to demonstrate RCE without further actions.
• Do not alter or delete files on the system.
• For root permissions, use the following commands in a vulnerable process:
  • Read: cat /proc/1/maps
  • Write: touch /root/<your H1 username>
  • Execute: id, hostname, password (also cat and touch for execution proof)

6. ==Subdomain Takeovers:==

• Any Subdomain Takeover submissions under the Vulnerability Disclosure Program (VDP) will be validated as “Low”.
• To validate this issue, researchers must attempt to claim the affected subdomain(s) and host a discreet Proof of Concept (PoC) file to demonstrate ownership. For example, they can host a file named /researcher.html containing the text "Hello world!".

7. ==Out-Of-Scope Vulnerabilities:==
   • Clickjacking on pages with no sensitive actions.
   • Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions.
   • Attacks requiring MITM or physical access to a user's device.
   • Previously known vulnerable libraries without a working Proof of Concept.
   • Reports based solely on historical data (e.g., archive.md, Wayback Machine).
   • Reports based solely on DNS records without a working PoC.
   • Comma Separated Values (CSV) injection without demonstrating a vulnerability.
   • Missing best practices in SSL/TLS configuration.
   • Any activity that could lead to the disruption of our service (DoS).
   • Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS.
   • Rate limiting or bruteforce issues on all endpoints.
   • Missing best practices in Content Security Policy.
   • Missing HttpOnly or Secure flags on cookies.
   • Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.).
   • Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version].
   • Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
   • Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case-by-case basis.
   • Tabnabbing.
   • Open redirect - unless an additional security impact can be demonstrated.
   • Issues that require unlikely user interaction].
   • Other publicly known vulnerabilities or theoretical vulnerabilities.

Reporting Guidelines:

When submitting a report, please consider including the following information to help us effectively validate and address the issue:

1. Testing Environment:

• Specify the environment you used for testing, including details such as browsers, app versions, devices, tools, and configuration settings.

2. Accounts Used:

• List any accounts you utilized during the testing process. This helps us determine potentially nefarious accounts.

3. Public-Facing IP Address:

• Provide your public-facing IP address if you’re reporting on an asset that might log this information. This helps us filter your activity and validate your findings more efficiently.

By participating in Zebra’s HackerOne program you agree to adhere to the above terms and any deviation may impact the potential validation or ability to make future submissions.