How bad firewall settings can make you lose 75 BTCs

[kjj]

The interesting part is for such a theft to happen, the thief needed to know that there was an accessible bitcoind on that IP. So, either it is someone close to OP who's stealing him, or there are hackers with crawlers searching for such vulnerable nodes. The latter sounds quite possible, what would mean people using bitcoind RPC should really pay attention to their access rules.

Every node on the network knows the IP addresses of every other node.  More or less.  And the port is well known.

except rpc port which could be changed freely. -rpcport=<port>

I'm changing my RPC ports to a higher area (10000+) to keep my wallets safe. It's set to allow *.*.*.* with very simple username and password.

You do know that it is trivial to scan all 65535 ports to find the bitcoin RPC interface, right?  And now that you've posted this, I'd be willing to bet that whoever wrote the brute force tool is modifying it to portscan right now.

[mrx]

The interesting part is for such a theft to happen, the thief needed to know that there was an accessible bitcoind on that IP. So, either it is someone close to OP who's stealing him, or there are hackers with crawlers searching for such vulnerable nodes. The latter sounds quite possible, what would mean people using bitcoind RPC should really pay attention to their access rules.

Every node on the network knows the IP addresses of every other node.  More or less.  And the port is well known.

except rpc port which could be changed freely. -rpcport=<port>

I'm changing my RPC ports to a higher area (10000+) to keep my wallets safe. It's set to allow *.*.*.* with very simple username and password.

You do know that it is trivial to scan all 65535 ports to find the bitcoin RPC interface, right?  And now that you've posted this, I'd be willing to bet that whoever wrote the brute force tool is modifying it to portscan right now.

With known IP that's true..... and the client itself is a great source. RPC interface is indeed easy to discover then.

Maybe I should try finding some insecure peers in irc too.....

[kgo]

First off, that sucks.

Do you actually have evidence that there was a brute force attack, or are you simply inferring all this because the bitcoins disappeared while your firewall was open?

[m3ta]

First off, that sucks.

Do you actually have evidence that there was a brute force attack, or are you simply inferring all this because the bitcoins disappeared while your firewall was open?

debug.log shows an abnormal number of connections made starting 3 minutes before the transfer was made, so i assumed that's how long it took for a brute force to be successful. I might be wrong, but it looks that way.

[kgo]

First off, that sucks.

Do you actually have evidence that there was a brute force attack, or are you simply inferring all this because the bitcoins disappeared while your firewall was open?

debug.log shows an abnormal number of connections made starting 3 minutes before the transfer was made, so i assumed that's how long it took for a brute force to be successful. I might be wrong, but it looks that way.

Yeah, that sounds like an attack.  You should post the log in a pastebin or something.

[phelix]

besides nolisten... does this make sense?

-rpcallowip=127.0.0.1

[m3ta]

First off, that sucks.

Do you actually have evidence that there was a brute force attack, or are you simply inferring all this because the bitcoins disappeared while your firewall was open?

debug.log shows an abnormal number of connections made starting 3 minutes before the transfer was made, so i assumed that's how long it took for a brute force to be successful. I might be wrong, but it looks that way.

Yeah, that sounds like an attack.  You should post the log in a pastebin or something.

22MB, i'd have to trim it.

# cat debug.log | grep 'incorrect pass' | wc -l
951

And forget the 3 minutes i talked about, looking more in-depth at the log, first incorrect attempt was at 05:12, last was at 05:23.
So, 951 attempts in 11 minutes.

[Schleicher]

Only 951?
That doesn't sound like a brute force attack.
Your password has a length of 2 characters?

[Costia]

it was probably in a dictionary of commonly used passwords

[Maged]

The interesting part is for such a theft to happen, the thief needed to know that there was an accessible bitcoind on that IP. So, either it is someone close to OP who's stealing him, or there are hackers with crawlers searching for such vulnerable nodes. The latter sounds quite possible, what would mean people using bitcoind RPC should really pay attention to their access rules.

It's the latter. I remember seeing a post like this just a few days ago.

[jjiimm_64]

Please tell us what the password was...  not secure anyway.

[DeathAndTaxes]

Only 951?
That doesn't sound like a brute force attack.
Your password has a length of 2 characters?

Yeah what was the password?  "password"?

951 attempts is negligible even compared to a common/weak password list which has a million or more passwords.

I mean getting nailed in 951 attempts is the world saying your password was in the top 0.1% of stupidest/weakest passwords on the planet.


However 951 attempts does raise a useful countermeasure.  Have bitcoind refuse connections for 30 sec after 3 failed password attempts and then after every failed password attempt after that.   So 951 attempts would require 951 - 3 = 948 *0.5 = 8 hours.  If the password was even slightly less weak (but still horribly weak) and was say 100,000th password on a brute force list it would take 30 days.

[Gavin Andresen]

There should be some deterrence in place for these cases of plain user dumbness.

Let me count the ways:

1. You must explicitly choose a username and password; you must have enough tech know-how to find your bitcoin.conf directory or run with -rpcpasswrod= options.

2. If you choose a short password, then every failed access attempt DOES trigger a timeout.

3. You must explicitly tell bitcoin to listen for connections from IP addresses other than localhost, using the rpcallowip= option.

4. You must open a hole in your firewall that lets any arbitrary IP address through to your rpcport.

I'm sorry you lost 75 bitcoins, but you really made a LOT of mistakes. Adding more layers of protection to the RPC interface isn't high on the development priority list, but if anybody wants to volunteer to keep track of number of failed RPC authentication attempts over time then be my guest and write a patch. Just be sure it isn't vulnerable to denial-of-service attacks by people deliberately generating failed login attempts.

[kjj]

I'm sorry you lost 75 bitcoins, but you really made a LOT of mistakes. Adding more layers of protection to the RPC interface isn't high on the development priority list, but if anybody wants to volunteer to keep track of number of failed RPC authentication attempts over time then be my guest and write a patch. Just be sure it isn't vulnerable to denial-of-service attacks by people deliberately generating failed login attempts.

I suggested a second logfile for security matters so that tools like fail2ban could monitor something with less volume than debug.log.  Adding a second logfile seems much easier than implementing the lockout yourself.

[foggyb]

RPC hacks = encrypted wallet feature is useless. What if the attacker gains root access to the PC?

Not. Cool.

[DeathAndTaxes]

RPC hacks = encrypted wallet feature is useless. What if the attacker gains root access to the PC?

I guess someone could release a non-RPC capable version.  Then again if attacker has root access then they already installed a keylogger and your wallet has already been stolen.

[m3ta]

There should be some deterrence in place for these cases of plain user dumbness.

Let me count the ways:

1. You must explicitly choose a username and password; you must have enough tech know-how to find your bitcoin.conf directory or run with -rpcpasswrod= options.

2. If you choose a short password, then every failed access attempt DOES trigger a timeout.

3. You must explicitly tell bitcoin to listen for connections from IP addresses other than localhost, using the rpcallowip= option.

4. You must open a hole in your firewall that lets any arbitrary IP address through to your rpcport.

So, yes, i did 4 out of 4. I had no idea mistakes were prune to ratings.
So if I or anyone does 5 mistakes, what then, you think our house should blow up?

I'm sorry you lost 75 bitcoins, but you really made a LOT of mistakes. Adding more layers of protection to the RPC interface isn't high on the development priority list, but if anybody wants to volunteer to keep track of number of failed RPC authentication attempts over time then be my guest and write a patch. Just be sure it isn't vulnerable to denial-of-service attacks by people deliberately generating failed login attempts.

You said "layerS".
However, if ONE layer is well implemented, it should be enough, covering 4 out 4 ratings, or even 10 out of 10.
Out of all people, i think you would see these mistakes as a simple "something needs to be done". But if you're just following the easy path out of this issue by just throwing me a donkey hat, sure, i'll take it. From my first post, I did not make excuses, and admitted my guilt. You're giving me no novelty. Sorry about that.

It's just a disappointment to see development does not care about its 'flock' - we, who make mistakes as any human does, are on our own.
Fair enough, from your pedestal point of view, of course.

 

[rjk]

RPC hacks = encrypted wallet feature is useless. What if the attacker gains root access to the PC?

Not. Cool.

If the wallet is encrypted (is isn't by default), then there are 2 passwords needed. The first is the RPC password, which allows access to the RPC interface. Actually, the RPC interface also supports SSL, but that is almost never used. The second password is the encryption password. Once you have access to the RPC interface, you must then pass commands including the encryption password in order to unlock the wallet for access.

If configured correctly, it could remain open on the public internet, without too much fear. However, I would only use it over a VPN anyway.

[foggyb]

RPC hacks = encrypted wallet feature is useless. What if the attacker gains root access to the PC?

I guess someone could release a non-RPC capable version.  Then again if attacker has root access then they already installed a keylogger and your wallet has already been stolen.

True enough.

But if the RPC interface was hardened, at least this would buy some time.

As is, with root access the attacker could be in & out in a few seconds with a scripted hit.

[kgo]

Only 951?
That doesn't sound like a brute force attack.
Your password has a length of 2 characters?

Yeah what was the password?  "password"?

951 attempts is negligible even compared to a common/weak password list which has a million or more passwords.

I mean getting nailed in 951 attempts is the world saying your password was in the top 0.1% of stupidest/weakest passwords on the planet.


However 951 attempts does raise a useful countermeasure.  Have bitcoind refuse connections for 30 sec after 3 failed password attempts and then after every failed password attempt after that.   So 951 attempts would require 951 - 3 = 948 *0.5 = 8 hours.  If the password was even slightly less weak (but still horribly weak) and was say 100,000th password on a brute force list it would take 30 days.

A better way would be to start with an even smaller timeout, and double it upon each failed logon from the same IP.  This gives a human plenty of chances to retry the password, but quickly makes brute forcing impractical.