What is RPC attack?

[wsxdrfv]

Someone said that bitcoin.conf file setting should be properly for block RPC attack?

What this mean and how to set it properly?

[1713581702]

1713581702

[btj]

Purhapse he mean Brute Force Attack from JSON RPC.

You have to use strong password and username in bitcoin.conf.

But in the latest versions of bitcoin withdraw funds is removed using JSON RPC remotely, but an attacker can check for your coin balances etc.

I didn't tried if dumpprivkey method can be passed.

[wsxdrfv]

Purhapse he mean Brute Force Attack from JSON RPC.

You have to use strong password and username in bitcoin.conf.

But in the latest versions of bitcoin withdraw funds is removed using JSON RPC remotely, but an attacker can check for your coin balances etc.

I didn't tried if dumpprivkey method can be passed.

Then how withdraw done by what? if not using json rpc.

[btj]

Purhapse he mean Brute Force Attack from JSON RPC.

You have to use strong password and username in bitcoin.conf.

But in the latest versions of bitcoin withdraw funds is removed using JSON RPC remotely, but an attacker can check for your coin balances etc.

I didn't tried if dumpprivkey method can be passed.

Then how withdraw done by what? if not using json rpc.

Withdraw done using JSON RPC but locally and not remotely.

Must have access to your server node and make withdraw from there.

[HeRetiK]

Not sure if that someone was referring to a special kind of RPC attack, but in general it is wise to set up a strong rpcpassword (think 40 characters and beyond) as mentioned by btj.

Also make sure that rpcallowip is either set to localhost only or not set at all (making it default to localhost). If you need to access the RPC interface from a different server, but within the same local network (ie. 192.168.x.x) set it to the respective IP. Accessing the RPC interface from a different server over the internet is a very bad idea and should be avoided at all cost.

Finally keep in mind that all of this is worth nothing if the server itself is not secured enough.

[...]

But in the latest versions of bitcoin withdraw funds is removed using JSON RPC remotely, but an attacker can check for your coin balances etc.

[...]

Got any source on that? This doesn't seem to be mentioned in the recent release notes:
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.16.0.md
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.1.md

[btj]

Not sure if that someone was referring to a special kind of RPC attack, but in general it is wise to set up a strong rpcpassword (think 40 characters and beyond) as mentioned by btj.

Also make sure that rpcallowip is either set to localhost only or not set at all (making it default to localhost). If you need to access the RPC interface from a different server, but within the same local network (ie. 192.168.x.x) set it to the respective IP. Accessing the RPC interface from a different server over the internet is a very bad idea and should be avoided at all cost.

Finally keep in mind that all of this is worth nothing if the server itself is not secured enough.

[...]

But in the latest versions of bitcoin withdraw funds is removed using JSON RPC remotely, but an attacker can check for your coin balances etc.

[...]

Got any source on that? This doesn't seem to be mentioned in the recent release notes:
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.16.0.md
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.1.md

I was unable to perform that action in a recent work for my client, i was required to make a script that serve as API to perform that for the server itself.

But this can be related to some other issues in the custom altcoin he is using, or something else.

Locally the command work well, but when launched remotely the transaction is not sent (Note that the remote IP address was added and whitelisted in bitcoin config file.)

[achow101]

bitcoind's JSON-RPC interface is used to issue commands to bitcoind to have it do things. Having access to the JSON-RPC interface of a node means that you have a significant amount of control over that node. For example, an attacker can dictate what nodes that node connects to, send coins from the wallet, shut down the node, etc.

The really important thing to note is the control of the wallet. If the wallet has any funds in it and the wallet passphrase is known or not set, anyone who has access to the RPC interface can send commands to the wallet that result in the coins being sent elsewhere. Thus an attacker could potentially steal your coins if the RPC interface is insecure.

To secure the RPC interface, you set a password on it. This password is most securely set by using the rpcauth configuration option. You can generate a correctly formatted rpcauth line by using the script provided here: https://github.com/bitcoin/bitcoin/tree/master/share/rpcauth. That script can also generate a secure password for you to use.

Additionally, you should add rpcallowip=<ip> lines to your config file to limit the IP addresses that are allowed to access the RPC interface of bitcoind.

[btj]

bitcoind's JSON-RPC interface is used to issue commands to bitcoind to have it do things. Having access to the JSON-RPC interface of a node means that you have a significant amount of control over that node. For example, an attacker can dictate what nodes that node connects to, send coins from the wallet, shut down the node, etc.

The really important thing to note is the control of the wallet. If the wallet has any funds in it and the wallet passphrase is known or not set, anyone who has access to the RPC interface can send commands to the wallet that result in the coins being sent elsewhere. Thus an attacker could potentially steal your coins if the RPC interface is insecure.

To secure the RPC interface, you set a password on it. This password is most securely set by using the rpcauth configuration option. You can generate a correctly formatted rpcauth line by using the script provided here: https://github.com/bitcoin/bitcoin/tree/master/share/rpcauth. That script can also generate a secure password for you to use.

Additionally, you should add rpcallowip=<ip> lines to your config file to limit the IP addresses that are allowed to access the RPC interface of bitcoind.

Just another thing to note, actually bitcoin do not allow wildcard when using: rpcallowip=* (to authorize access from all IPs), but you are allowed to use subnet:
0.0.0.0/0 (just ipv4) or ::/0 (ipv4 and ipv6).

This lower a risk of been hacked, and add more layer of security to your node.

[DannyHamilton]

To secure the RPC interface, you set a password on it.

This is just one step in what ought to be a much larger intrusion detection and prevention plan.

If you don't start by taking security concerns into consideration in everything that you do, then you likely will leave a vulnerability somewhere.

A few additional things that you ought to consider are:

• The use of one or more properly configured firewalls (This can block RPC access from the internet)
• The use of cold wallets for storage, with limited funds in any hot wallets (This can reduce the amount of damage RPC commands can accomplish if your other security efforts fail)
• Restricting (through networking controls and other configurations) the hot wallet to being accessible ONLY from the 1 computer that you plan to use for generating outgoing transactions (This can block RPC access from internal systems and employees that aren't authorized to access the hot wallet)
• Sanity checks on outgoing transactions, using alerts and automatic shutdowns in case of unreasonable transactions (This can prevent loss of funds if an attacker gains access to other internal systems)
• Redundant verification and monitoring of all systems (This can alert you to the fact that someone may have gained access to internal systems before they get a chance to issue an RPC command)
• Timely application of security updates to your operating systems, firewalls, and all installed software. (This can prevent a user from exploiting a new security vulnerability to gain RPC access to your hot wallet)
• Limiting access to the minimum amount of access needed for any individual to perform their job (This can prevent unauthorized employees from accessing the hot wallet)

This is just the tip of an iceberg of security best practices and intrusion prevention.

If you are managing sums of bitcoin on behalf of others, and the value of that bitcoin is more than you would be able and willing to refund out of your own wealth, then in my opinion anyone involved in the operation of the business is criminally negligent if the business did not hire a well qualified technology security expert to be involved in all aspects of system development and maintenance.

In my opinion, any one involved in the development of such a user based system that does NOT hire a well qualified technology security expert AND loses user funds that they can not, or will not, refund deserves a significant (decades) amount of jail time.