How bad firewall settings can make you lose 75 BTCs - page 2.

kgo

hero member

Activity: 548

Merit: 500

Quote from: DeathAndTaxes on January 26, 2012, 01:45:41 PM

Quote from: Schleicher on January 26, 2012, 01:15:29 PM

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.

foggyb

legendary

Activity: 1736

Merit: 1006

Quote from: DeathAndTaxes on January 26, 2012, 04:46:43 PM

Quote from: foggyb on January 26, 2012, 04:43:50 PM

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.

rjk

sr. member

Activity: 448

Merit: 250

1ngldh

Quote from: foggyb on January 26, 2012, 04:43:50 PM

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.

m3ta

sr. member

Activity: 435

Merit: 250

Quote from: Gavin Andresen on January 26, 2012, 03:01:54 PM

Quote from: DeathAndTaxes on January 26, 2012, 01:45:41 PM

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?

Quote from: Gavin Andresen on January 26, 2012, 03:01:54 PM

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: foggyb on January 26, 2012, 04:43:50 PM

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.

foggyb

legendary

Activity: 1736

Merit: 1006

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

Not. Cool.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: Gavin Andresen on January 26, 2012, 03:01:54 PM

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.

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

Quote from: DeathAndTaxes on January 26, 2012, 01:45:41 PM

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.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Schleicher on January 26, 2012, 01:15:29 PM

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.

jjiimm_64

legendary

Activity: 1876

Merit: 1000

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

Maged

legendary

Activity: 1204

Merit: 1015

Quote from: caveden on January 26, 2012, 03:11:59 AM

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.

Costia

newbie

Activity: 28

Merit: 0

it was probably in a dictionary of commonly used passwords

Schleicher

hero member

Activity: 675

Merit: 514

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

m3ta

sr. member

Activity: 435

Merit: 250

Quote from: kgo on January 26, 2012, 11:06:50 AM

Quote from: m3ta on January 26, 2012, 11:02:20 AM

Quote from: kgo on January 26, 2012, 10:59:02 AM

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.

phelix

legendary

Activity: 1708

Merit: 1020

besides nolisten... does this make sense?

-rpcallowip=127.0.0.1

kgo

hero member

Activity: 548

Merit: 500

Quote from: m3ta on January 26, 2012, 11:02:20 AM

Quote from: kgo on January 26, 2012, 10:59:02 AM

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.

m3ta

sr. member

Activity: 435

Merit: 250

Quote from: kgo on January 26, 2012, 10:59:02 AM

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

hero member

Activity: 548

Merit: 500

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?

mrx

member

Activity: 86

Merit: 10

Quote from: kjj on January 26, 2012, 10:38:37 AM

Quote from: mrx on January 26, 2012, 10:32:22 AM

Quote from: kjj on January 26, 2012, 07:23:10 AM

Quote from: caveden on January 26, 2012, 03:11:59 AM

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=

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.....

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: mrx on January 26, 2012, 10:32:22 AM

Quote from: kjj on January 26, 2012, 07:23:10 AM

Quote from: caveden on January 26, 2012, 03:11:59 AM

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=

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.

Topic: How bad firewall settings can make you lose 75 BTCs - page 2. (Read 7672 times)