Instruction: A RSKj JSON RPC server is available for testing. You can obtain the list of JSON RPC methods supported from the rskj source code and from RSK and Ethereum documentation.
You can attempt the following attacks:
* Bypass the Varnish JSON RPC method blacklist/whitelist filtering.
* Application level DoS: exploit the whitelisted methods to consume server's resources.
* System Information disclosure (file system, private keys)
* Code execution (Hint: check the object mapping capabilities of the JSON parser library and Java reflection)
**Only application level DoS attacks are allowed. Do not attempt volumetric transport level attacks**
Sample Request:
`curl -s -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"web3_clientVersion", "params": {}, "id":666}' https://bounty-node.rsk.co `
The whitelisted methods are the following:
```web3_clientVersion
eth_getUncleCountByBlockNumber
net_version
net_listening
net_peerCount
eth_protocolVersion
eth_hashrate
eth_mining
eth_call
eth_estimateGas
eth_gasPrice
eth_blockNumber
eth_getBalance
eth_getBlockByHash
eth_getBlockByNumber
eth_getBlockTransactionCountByHash
eth_getBlockTransactionCountByNumber
eth_getCode
eth_getStorageAt
eth_getTransactionByBlockHashAndIndex
eth_getTransactionByBlockNumberAndIndex
eth_getTransactionByHash
eth_getTransactionCount
eth_getTransactionReceipt
eth_getUncleByBlockHashAndIndex
eth_getUncleByBlockNumberAndIndex
eth_getUncleCountByBlockHash
eth_getUncleCountByBlockNumber
eth_sendRawTransaction
```
Good luck!
Instruction: - 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.
- 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.
Instruction: ## 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 public 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.
* Attacks that lead the middleware manager into a DOS state without the need for physical access to the host.
* 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.
## 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.
Instruction: 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`
