Scope and Rules of Engagement

Responsible Disclosure Rules of Engagement

  • No Denial of Service testing
  • No Physical or Social Engineering
  • No testing of Third-party Services
  • No uploading of any vulnerability or client-related content to third-party utilities (e.g. Github, DropBox, YouTube)
  • All attack payload data must use professional language
  • If able to gain access to a system, accounts, users, or user data, stop at point of recognition and report. Do not dive deeper to determine how much more is accessible.
  • When documenting a vulnerability, if a vulnerability is public, please make sure it is discreet and doesn't identify the client.

In-Scope Targets

Any publicly-accessible system owned, operated, or controlled by the Federal Reserve System or Federal Reserve Banks, including any Federal Reserve owned web applications or services hosted on those systems.

Federal Reserve Bank sites use non-government top-level domains such as .com, .org, .net, etc.

Federal Reserve Bank domains include, but are not limited to:

  • federalreserveonline.org, etc.
  • atlantafed.org, etc
  • bostonfed.org, etc
  • chicagofed.org, etc
  • clevelandfed.org, etc.
  • dallasfed.org, etc.
  • kansascityfed.org, etc.
  • minneapolisfed.org, etc.
  • newyorkfed.org, etc.
  • philadelphiafed.org, etc.
  • richmondfed.org, etc.
  • sanfranciscofed.org, etc.
  • stlouisfed.org, etc.

Out-of-Scope Targets

This VDP applies to the private sector Federal Reserve Banks (generally .com and .org sites) and not the public sector Federal Reserve Board of Governors (.gov sites).

The following are beyond the scope of this VDP:

  • *.gov
    • This includes any United States government system, application, or service such as those pertaining to the Federal Reserve Board of Governors or the United States Department of the Treasury
  • People, including Federal Reserve employees, contractors, and vendors
  • Physical assets, including Federal Reserve property, facilities, and physical security controls
  • Federal Reserve Board of Governors

Activities

In-Scope Activities

Activities are limited exclusively to:

  • Testing to detect a vulnerability or identify an indicator related to a vulnerability
  • Sharing or receiving Federal Reserve information about a vulnerability or an indicator related to a vulnerability

All testing activities should abide by relevant laws

Header identification:

Sometimes abnormal traffic can be considered malicious. Please provide the following header to allow us to correctly identify your traffic:

  • `VDP-Synack-Researcher: username`
  • Also, please append `Synack/username` to the User Agent String

Out-of-Scope Activities

  • Do not harm the Federal Reserve, its customers, employees, or contractors
  • Do not intentionally compromise the privacy or safety of Federal Reserve personnel or any third parties
  • Do not intentionally compromise the intellectual property or other commercial or financial interests of any Federal Reserve personnel or entities, or any third parties
  • Do not exfiltrate or retain any data or sensitive information under any circumstances
  • Do not detrimentally compromise/alter, or destroy Federal Reserve or customer data
  • Do not perform physical testing
  • Do not perform social engineering, including phishing
  • Do not perform denial of service testing, including resource exhaustion
  • Do not hijack or intentionally disrupt legitimate user sessions
  • Do not degrade the quality of Federal Reserve assets, resources, or information
  • Do not conduct or initiate fraudulent financial transactions
  • Do not perform automated scanning

Vulnerabilities

In-Scope Vulnerabilities

All vulnerabilities are in scope for disclosure excepting those explicitly listed as out-of-scope below.

Out-of-Scope Vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:

  • Clickjacking on pages with no sensitive actions
  • Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
  • Attacks requiring Man in the Middle (MITM) or physical access to a user's device.
  • Previously known vulnerable libraries without a working Proof of Concept.
  • Comma Separated Values (CSV) injection without demonstrating a vulnerability.
  • Missing best practices in SSL/TLS configuration without proof of concept/demonstrating a vulnerability.
  • Any activity that could lead to the disruption of service (DoS) for the Federal Reserve
  • Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
  • Rate limiting or bruteforce issues on non-authentication endpoints
  • Missing best practices in Content Security Policy without demonstrating a vulnerability.
  • Missing HttpOnly or Secure flags on cookies not related to authentication or sessions
  • Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
  • Vulnerabilities only affecting users of outdated or unpatched browsers (More 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).
  • Tabnabbing (persuading users to submit login details and passwords by impersonating a Federal Reserve website)
  • Open redirect - unless an additional security impact can be demonstrated
  • Issues that require unlikely user interaction unless an additional security impact can be demonstrated

Low Impact Vulnerabilities - Out of Scope

The following vulnerabilities are considered too low of an impact to the client and would be marked as Out of Scope if submitted:

  • Google Maps API Keys
  • Account/e-mail enumeration using brute-force attacks
    • Valid user account/email enumeration not requiring brute-force will be considered
  • Any low impact issues related to session management (i.e. concurrent sessions, session expiration, password reset/change log out, etc.)
  • Bypassing content restrictions in uploading a file without proving the file was received
  • Clickjacking/UI redressing
  • Client-side application/browser autocomplete or saved password/credentials
  • Descriptive or verbose error pages without proof of exploitability or obtaining sensitive information
  • Directory structure enumeration (unless the fact reveals exceptionally useful information)
  • Incomplete or missing SPF/DMARC/DKIM records
  • Issues related to password/credential strength, length, lockouts, or lack of brute-force/rate-limiting protections
    • Account compromises (especially admin) as a result of these issues will likely be considered VALID
  • Lack of SSL or Mixed content
    • Leaking Session Cookies, User Credentials, or other sensitive data will be reviewed on a case by case basis
    • If leaking of sensitive data requires MiTM positioning to exploit, it will be considered out of scope
  • Login/Logout/Unauthenticated/Low-impact CSRF
    • CSRF Vulnerabilities may be acceptable if they are of higher impact. Examples of low impact CSRF include: Add/Delete from Cart, Add/remove wishlist/favorites, Nonsevere preference options, etc.
  • Low impact Information disclosures (including Software version disclosure)
  • Missing Cookie flags
  • Missing/Enabled HTTP Headers/Methods which do not lead directly to a security vulnerability
  • Reflected file download attacks (RFD)
  • Self-exploitation (i.e. password reset links or cookie reuse)
  • SSL/TLS best practices that do not contain a fully functional proof of concept
  • URL/Open Redirection
  • Use of a known-vulnerable library which leads to a low-impact vulnerability (i.e. jQuery outdated version leads to low impact XSS)
  • Valid bugs or best practice issues that are not directly related to the security posture of the client
  • Vulnerabilities affecting users of outdated browsers, plugins or platforms
  • Vulnerabilities that allow for the injection of arbitrary text without allowing for hyperlinks, HTML, or JavaScript code to be injected
  • Vulnerabilities that require the user/victim to perform extremely unlikely actions (i.e. Self-XSS)
    • Self-XSS for a Persistent/Stored XSS will be considered. The only circumstances under which we will not require proof of impact to multiple users is for Persistent/Stored XSS in cases where only one set of credentials is available to the researcher and other users cannot be tested. We will require documentation or evidence reasonably proving the functionality is available to other users/backend team/admin for the report to be considered.
    • Any type of XSS that requires a victim to press an unlikely key combination is NOT in scope (i.e. alt+shift+x for payload execution)

Additional specific vulnerability types considered out of scope due to low impact:

    • IIS Tilde File and Directory Disclosure
    • SSH Username Enumeration
    • Wordpress Username Enumeration
    • SSL Weak Ciphers/ POODLE / Heartbleed
    • CSV Injection
    • PHP Info
    • Server-Status if it does not reveal sensitive information
    • Snoop Info Disclosures