Target Policy

Structured Scope

• Asset Identifier

  Asset Type

  Max Severity

• https://github.com/rsksmart/flyover-sdk

  ---

  **Things that we are interested in finding:**

  - Ways to take control of the connected wallets
  - Ways to modify the information sent or received from the SDK to the server or blockchain RPC
  - Ways to skip the validations performed by the different SDKs

  **Out of scope**

  - All the tests (*.test.ts) and the `integration-tests` directory.
  - All the `*/docs` folders.
  - All the build and test config files (`rollup.config.js, jest.config.js, lerna.json, nx.json, etc.`) as they only have configuration that affects the SDK bundles

  SOURCE_CODE

  critical
• https://github.com/rsksmart/2wp-app

  ---

  # We are interested in finding:
  - Exploits to extract the private keys of the wallet from the memory
  - Ways to gain control over the software or hardware wallets
  - Ways to change the transaction by adding or removing data

  #Out of scope
  - `test` directory
  - NPM package takeover from unreferenced npm packages.
  - Vulnerabilities in dependencies/libraries
  - Clickjacking
  - Reports from automated tools or scans, without exploitability demonstration
  - Theoretical vulnerabilities without demonstrated security impact
  - 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.
  - Attacks requiring a compromised victim device.
  - 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
  - Missing best practices in Content Security Policy.
  - Missing HttpOnly or Secure flags on cookies
  - Missing HTTP headers hardening and recommendations (Clickjacking, X-Frame-Options, CORS, ...)
  - 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.
  - Open redirect - unless an additional security impact can be demonstrated
  - Issues that require unlikely user interaction
  - Cache poisoning without demonstrated security impact
  - Tabnabbing
  - Social engineering attacks, including those targeting or impersonating internal employees by any means (e.g. customer service chat features, customer support, social media, personal domains, etc.)
  - Reporting a leaked token without first confirming it is valid and has access to sensitive operations
  - Secret recovery phrase brute-forcing
  - Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)
  - Vulnerabilities under development branches in our source code.
  - Runtime hacking exploits (exploits only possible in a jailbroken/rooted environment)
  - Public User data, such as, public address, balances, transaction information etc. stored unencrypted on external storage and private directory
  - Lack of binary protection (anti-debugging) controls.
  - Absence of certificate pinning

  SOURCE_CODE

  critical
• bounty-node.rsk.co

  URL

  none
• https://github.com/rsksmart/rsk-powhsm/

  ---

  ## Scope
  * Attacks that allow extracting the seed from the device, including but not limited to:
  Gaining access to the device recovery mode without wiping the seed first.
  * Allowing the installation and use of arbitrary ledger apps without wiping the seed first.
  * Attacks that allow signing arbitrary hashes with the BTC key id.
  * Attacks that gain access to arbitrary BIP32 paths (either for signing or extracting the private key).
  * Attacks that allow the manipulation of the blockchain state's best block without the corresponding PoW.
  * Attacks that allow the manipulation of the blockchain state's ancestor block and/or ancestor receipts root without the corresponding proof of best block ancestry.
  * Attacks that fake an authentic attestation on a device running different versions of either the UI or Signer.
  * Attacks that allow producing an authentic attestation on a device with a pre-generated or well-known seed.
  * Attacks that lead the ledger into a DOS state without the need for physical device access. This does not mean ledger device has open external interface.
  * Attacks that lead the middleware manager into a DOS state without the need for physical access to the host. This does not mean the middleware has open external interface.
  * Transactions in either the RSK or Bitcoin networks that may lead the powHSM into signing arbitrary pegouts or hashes.
  * Side channel attacks.
  * Supply chain attacks that have direct consequences on the production software.
  * Identification and reporting of vulnerabilities in the Ledger source code will be eligible for rewards after 90 days from the initial disclosure from Ledger.
  * Vulnerabilities discovered in the Ledger source code will be rewarded according to the general reward table specified for the bug bounty program, rather than the powHSM project reward table.
  * Vulnerabilities found in the Ledger source code will not qualify for the bonus reward associated with Remote Execution Code.

  ## Out of Scope
  * Vulnerabilities related to the ledger devices used by the rsk-powhsm; this includes their physical security.
  * Vulnerabilities that don't ultimately allow for the arbitrary or unsecure use of any of the keys derived from the device seed.
  * Vulnerabilities in TCPSigner component, which is made solely for testing and fuzzing purposes.
  * Vulnerabilities located in code under the following path `firmware/src/hal/src/x86/` since is code related to the TCPSigner component.
  * All code related to SGX is out of scope.

  Due to the complexity of the project some of the points may be interpreted ambiguously, therefore we reserve a right to make a final decision on the report regarding its relevance to the scope and specified severity. Please, reach us if you have any doubts on the scope.

  URL

  critical
• https://github.com/rsksmart/liquidity-bridge-contract

  ---

  ### **Scope**

  - All the files in the `contracts` directory EXCEPT for `Quotes.sol` and `LiquidityBridgeContract.sol`.

  **Things that we are interested in finding:**

  - Ways to deposit pegout quotes without paying the correct amount
  - Ways for the user to refund pegout quotes when the quote was paid honestly by the LP
  - Ways to register a fraudulent pegin transaction
  - Possible attacks using the `callForUser` call to a contract instead of a EOA
  - Ways for the LP to increase their collateral/balance without paying
  - Possible attacks to the LP discovery mechanism

  ### **Out of scope**

  - `build`, `.openzeppelin` directories and `config.json`.
  - `test`, `scripts`, `integration-test`,`migrations` directories and `truffle-config.json.`
  - `contracts/Quotes.sol` and `contracts/LiquidityBridgeContract.sol` are out-of-scope

  SOURCE_CODE

  critical
• https://github.com/rsksmart/rif-wallet-services

  ---

  ##Out of scope
  * Clickjacking
  * NPM package takeover from unreferenced npm packages.
  * Reports from automated tools or scans, without exploitability demonstration
  * Theoretical vulnerabilities without demonstrated security impact
  * 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.
  * Attacks requiring a compromised victim 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.
  * 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
  * Missing best practices in Content Security Policy.
  * Missing HttpOnly or Secure flags on cookies
  * Missing HTTP headers hardening and recommendations (Clickjacking, X-Frame-Options, CORS, ...)
  * 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.
  * Open redirect - unless an additional security impact can be demonstrated
  * Issues that require unlikely user interaction
  * Cache poisoning
  * Tabnabbing
  * Social engineering attacks, including those targeting or impersonating internal employees by any means (e.g. customer service chat features, customer support, social media, personal domains, etc.)
  * Reporting a leaked token without first confirming it is valid and has access to sensitive operations
  * Secret recovery phrase brute-forcing
  * Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)
  * Vulnerabilities under development branches in our source code.
  * Runtime hacking exploits (exploits only possible in a jailbroken/rooted environment)
  * Public User data, such as, public address, balances, transaction information etc. stored unencrypted on external storage and private directory
  * Lack of binary protection (anti-debugging) controls.
  * Absence of certificate pinning

  SOURCE_CODE

  critical
• https://github.com/rsksmart/2wp-api

  ---

  # Scope
  We are interested in finding issues that lead to compromise of the app.

  # Out of scope
  - `__test__` directory
  - Vulnerabilities in dependencies/libraries
  - NPM package takeover from unreferenced npm packages.
  - Clickjacking
  - Reports from automated tools or scans, without exploitability demonstration
  - Theoretical vulnerabilities without demonstrated security impact
  - 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.
  - Attacks requiring a compromised victim device.
  - 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
  - Missing best practices in Content Security Policy.
  - Missing HttpOnly or Secure flags on cookies
  - Missing HTTP headers hardening and recommendations (Clickjacking, X-Frame-Options, CORS, ...)
  - 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.
  - Open redirect - unless an additional security impact can be demonstrated
  - Issues that require unlikely user interaction
  - Cache poisoning without demonstrated security impact
  - Tabnabbing
  - Social engineering attacks, including those targeting or impersonating internal employees by any means (e.g. customer service chat features, customer support, social media, personal domains, etc.)
  - Reporting a leaked token without first confirming it is valid and has access to sensitive operations
  - Secret recovery phrase brute-forcing
  - Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)
  - Vulnerabilities under development branches in our source code.
  - Runtime hacking exploits (exploits only possible in a jailbroken/rooted environment)
  - Public User data, such as, public address, balances, transaction information etc. stored unencrypted on external storage and private directory
  - Lack of binary protection (anti-debugging) controls.
  - Absence of certificate pinning

  SOURCE_CODE

  high
• https://github.com/rsksmart/rif-wallet-libs

  ---

  ##Out of scope
  * Clickjacking
  * NPM package takeover from unreferenced npm packages.
  * Reports from automated tools or scans, without exploitability demonstration
  * Theoretical vulnerabilities without demonstrated security impact
  * 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.
  * Attacks requiring a compromised victim 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.
  * 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
  * Missing best practices in Content Security Policy.
  * Missing HttpOnly or Secure flags on cookies
  * Missing HTTP headers hardening and recommendations (Clickjacking, X-Frame-Options, CORS, ...)
  * 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.
  * Open redirect - unless an additional security impact can be demonstrated
  * Issues that require unlikely user interaction
  * Cache poisoning
  * Tabnabbing
  * Social engineering attacks, including those targeting or impersonating internal employees by any means (e.g. customer service chat features, customer support, social media, personal domains, etc.)
  * Reporting a leaked token without first confirming it is valid and has access to sensitive operations
  * Secret recovery phrase brute-forcing
  * Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)
  * Vulnerabilities under development branches in our source code.
  * Runtime hacking exploits (exploits only possible in a jailbroken/rooted environment)
  * Public User data, such as, public address, balances, transaction information etc. stored unencrypted on external storage and private directory
  * Lack of binary protection (anti-debugging) controls.
  * Absence of certificate pinning

  SOURCE_CODE

  critical
• https://github.com/rsksmart/bridges-core-sdk

  ---

  **Things that we are interested in finding:**

  - Ways to take control of the connected wallets
  - Ways to modify the information sent or received from the SDK to the server or blockchain RPC
  - Ways to skip the validations performed by the different SDKs

  **Out of scope**

  - All the tests (*.test.ts) and the `integration-tests` directory
  - All the `docs`/* folders
  - All the build and test config files (`rollup.config.js, jest.config.js, lerna.json, nx.json, etc.`) as they only have configuration that affects the SDK bundles

  SOURCE_CODE

  critical
• https://github.com/rsksmart/liquidity-provider-server

  ---

  **Things that we are interested in finding:**

  - Exploits to extract the private keys of the LP
  - Ways to gain control over the LP management API
  - Ways to make the LPS pay for a quote with a fraudulent transaction
  - Ways to make the LPS pay multiple times for the same quote
  - Ways to make the LPS pay an incorrect amount for a particular quote

  ### **Out of scope**

  - `test`,`coverage` and `docs` directories.
  - All the test files (*_test.go) in `internal`, `cmd` and `pkg` directories.
  - `local`, `localstack`, `lbc-deployer`, `powpeg`, `rskj` directories of the `docker-compose` directory.
  - `go.mod` and `go.sum` files are out of scope.
  - DoS scenarios are generally out of scope, we may grant exceptions for highly novel or low-resource attacks

  SOURCE_CODE

  critical
• https://github.com/rsksmart/rif-wallet

  ---

  ##Out of scope
  * Clickjacking
  * NPM package takeover from unreferenced npm packages.
  * Reports from automated tools or scans, without exploitability demonstration
  * Theoretical vulnerabilities without demonstrated security impact
  * 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.
  * Attacks requiring a compromised victim 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.
  * 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
  * Missing best practices in Content Security Policy.
  * Missing HttpOnly or Secure flags on cookies
  * Missing HTTP headers hardening and recommendations (Clickjacking, X-Frame-Options, CORS, ...)
  * 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.
  * Open redirect - unless an additional security impact can be demonstrated
  * Issues that require unlikely user interaction
  * Cache poisoning
  * Tabnabbing
  * Social engineering attacks, including those targeting or impersonating internal employees by any means (e.g. customer service chat features, customer support, social media, personal domains, etc.)
  * Reporting a leaked token without first confirming it is valid and has access to sensitive operations
  * Secret recovery phrase brute-forcing
  * Perceived security weaknesses without evidence of the ability to demonstrate impact (e.g. Missing best practices, functional bugs without security implications, etc.)
  * Vulnerabilities under development branches in our source code.
  * Runtime hacking exploits (exploits only possible in a jailbroken/rooted environment)
  * Public User data, such as, public address, balances, transaction information etc. stored unencrypted on external storage and private directory
  * Lack of binary protection (anti-debugging) controls.
  * Absence of certificate pinning

  SOURCE_CODE

  critical
• https://github.com/rsksmart/rskj

  ---

  RSKj Installation instructions: https://dev.rootstock.io/rsk/node/
  Binary releases: https://github.com/rsksmart/rskj/releases
  Discord channel for technical questions: https://discord.com/invite/fPerbqcWGE

  Important: DoS attacks that require sending multiple network packets at any layer are out of scope. We’re interested in DoS that depends on the data and can't be stopped at the network level.

  SOURCE_CODE

  critical
• https://github.com/rsksmart/tokenbridge

  ---

  The system is designed to allow to move tokens between blockchains if and only if 50% of the members approve it. Vulnerabilities that require access to a member's private key will be valid but will be considered medium risk at most.

  # Out of scope
  * The private key handling and storage is out of scope.
  * Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.
  * Multi-signature wallet.
  * Tests located under `test` folder in (all of them).
  * Open Zeppelin contracts located in `bridge/contracts/zeppelin`

  SOURCE_CODE

  critical
• https://github.com/rsksmart/powpeg-node

  ---

  Out of scope:
  - Attacks requiring physical access or local user level access to a user's device.
  - Previously known vulnerable libraries without a working Proof of Concept.
  - Denial of our service (DoS) not directly related to a flaw in the IOVLabs code or environment.
  - DoS attacks that require sending multiple network packets at any layer. We’re interested in DoS that depends on the data and can't be stopped at the network level.
  - Flaws on the configuration related to the option to store private keys on disk.
  - Vulnerabilities reported on the rskj project are out of scope for the powpeg-node.

  SOURCE_CODE

  critical

• 1 Subdomain
• Download wordlist

Last Finished Scan: