How bad firewall settings can make you lose 75 BTCs

[gmaxwell]

2. If you choose a short password, then every failed access attempt DOES trigger a timeout.
of-service attacks by people deliberately generating failed login attempts.

And in the process actually leaks information about the length of the password, though admittadly not much it's still kind of embarrassing since it lets the attacker know when their attack is likely to be profitable or not.

I have a patch in progress which improves logging and does the rate limiting. Being sure it doesn't create a dos and isn't gratuitously incompatible with the threaded RPC is why it's not already a pull request.  (also, I'm kinda uncomfortable about timeouts in the code since it's currently single threaded... any simple implementation of delays is an automatic DOS).

(the improved logging is important because it makes it slightly more likely that the attacker will get caught, but mostly because right now the vague logging causes people to open up allowip more than required because it's not clear why their requests are being rejected, especially as we have pretty weird wildcarding syntax)

And yes— m3ta had to do a lot of things to create this vulnerability.   But it isn't like he did them because he was _trying_ to get robbed, he did them because various tools and capabilities in our ecosystem put him in a position where the mistake was easy to make, and anytime that happens _someone_ will make the mistake eventually— it just happened to be him.  The fact that he was exploited was also because lots of other people are vulnerable too, otherwise the attackers wouldn't exist.

(And if you saw this thread and didn't go check your RPC and firewall settings, just to be sure, you're a fool— in my view)

If you look at industrial accidents there is a constant pattern in most of them— some stupendous feat of human error managed to bypass several safeties designed to prevent human error, all at the same time.   If you focus on the magnitude of the human error, you'll do nothing to reduce the incidence of failure in the future. Human error is a natural force as unstoppable as gravity.  We should build systems which have every worthwhile immunity, because the human failure is not going to go away. (It's going to get a lot worse, in fact, as more unsophisticated users adopt bitcoin)

In addition to some belts an suspenders in resisting basic brute-force attacks there are other things that could be done. There are _other_ daemons with similar RPC ports that don't have this problem because the daemon itself generates a default key and puts it in the file. e.g. Chrony.

[1714173247]

1714173247

[1714173247]

1714173247

[1714173247]

1714173247

[rjk]

Quick question: Can I use CIDR format in the allowip setting, and if not can this be implemented? I find it easier than using ranges and wildcards, but maybe that's just me.

Also, could rate-limiting be specific to the IP that is submitting invalid passwords? I realize that an attacker could use many endpoints to bypass this limitation, but it might be a step towards solving the denial of service concerns.

[Gavin Andresen]

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?

....

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. 

I apologize for coming across as harsh, it has been a hard couple of weeks.

And the reason it has been a hard couple of weeks is because I'm working really hard to try to get support for multisignature wallets... which would have prevented your loss (assuming you were using a multisignature-protected wallet).

The hacker would have been able to ask your bitcoind to send him your coins, but you would have got a confirmation on your cell phone (or SMS or email with a one-time-PIN or whatever) and realize immediately that you'd been hacked.

Or, in other words:  I've been working really hard trying to get a solution for the bigger problem of insecure computers, because I really do care about the "flock."

[gmaxwell]

Quick question: Can I use CIDR format in the allowip setting, and if not can this be implemented? I find it easier than using ranges and wildcards, but maybe that's just me.

Also, could rate-limiting be specific to the IP that is submitting invalid passwords? I realize that an attacker could use many endpoints to bypass this limitation, but it might be a step towards solving the denial of service concerns.

CIDR could be implemented, as could lists... might make sense to do as part of IPv6 support.

The rate limiting I coded up is per-IP, and localhost is exempted. I also started with per-group (e.g. /16 for ipv4) but thought it too risky.

Anti-brute-force is really a protection of last resort— the attacker doesn't have to be impatient he could use dozens of IPs (e.g. tor) and scan you for months in slow motion, even if its fairly aggressive it does not have that much protective value, e.g. even it it only allowed one bad attempt per IP ever, getting 1000 IPs is not _that_ hard and would have been sufficient here. So this sort of feature has to be carefully weighed against the DOS vulnerabilities it might create.

The real hope of this kind of protection is to reduce the odds of success and increase the cost of attacking enough so that few people bother attacking in the first place... creating a kind of protective halo of disinterest around the few users where all of the other better protections have failed.

[m3ta]

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?

....

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.  

I apologize for coming across as harsh, it has been a hard couple of weeks.

And the reason it has been a hard couple of weeks is because I'm working really hard to try to get support for multisignature wallets... which would have prevented your loss (assuming you were using a multisignature-protected wallet).

The hacker would have been able to ask your bitcoind to send him your coins, but you would have got a confirmation on your cell phone (or SMS or email with a one-time-PIN or whatever) and realize immediately that you'd been hacked.

Or, in other words:  I've been working really hard trying to get a solution for the bigger problem of insecure computers, because I really do care about the "flock."

You did come a bit harsh, by beating a dead horse, but no one is here to judge (specially not me, the horse) - it can happen to everyone.
TBH, we know you care.  Thank you for that.

Just PLEASE don't get the idea there was a 'demand' for an instant solution from you.
You're not anyone's errand-boy - you don't need to be too defensive regarding that, and if you let anyone, for a second, make you think you are, beat them with a stick.

Cheers.

[rjk]

Anti-brute-force is really a protection of last resort— the attacker doesn't have to be impatient he could use dozens of IPs (e.g. tor) and scan you for months in slow motion, even if its fairly aggressive it does not have that much protective value, e.g. even it it only allowed one bad attempt per IP ever, getting 1000 IPs is not _that_ hard and would have been sufficient here. So this sort of feature has to be carefully weighed against the DOS vulnerabilities it might create.

The real hope of this kind of protection is to reduce the odds of success and increase the cost of attacking enough so that few people bother attacking in the first place... creating a kind of protective halo of disinterest around the few users where all of the other better protections have failed.

Yes, this only really applies when someone bangs a '*' into the allowip and calls it a day. I hope to see your changes for CIDR merged soon

[foggyb]

Or, in other words:  I've been working really hard trying to get a solution for the bigger problem of insecure computers, because I really do care about the "flock."

Since bitcoin is touted as a candidate for global adoption by the masses, I'd have thought that its being considered that 80% of PC's on the planet run an insecure OS. Root access is only a script-kiddie away.

Then again, perhaps those 80% households will run the bitcoin client only on mobile platforms. Problem solved. 

[byronbb]

the reason i'm not on IRC anymore and the reason why my bitcoin node is not exposed there with bitcoin client 'noirc' flag enabled.
to me it's just being an easy target as anyone can get IP lists from IRC and start probing different ports, default router l/p's and what not.

You can run on freenode using tor to mask your ip.

[gmaxwell]

the reason i'm not on IRC anymore and the reason why my bitcoin node is not exposed there with bitcoin client 'noirc' flag enabled.

noirc was not sufficient to prevent you address from being relayed— bad guys couldn't get it from IRC but they could get it from the regular node to node address exchanges.

noirc + nolisten will be enough in the next version of bitcoin, however.

[cypherdoc]

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.


This incident(accident) is not the first in cryptocurrency area. several weeks ago somebody lost all(2850) his fairbrix. Also because of open RPC.

how do u do this?

[Razick]

That guy's a real asshole... or else a lot of people just sent him tons of BTC... idk for sure.

Anyway, as a not-so-expert-when-it-comes-to-security-guy, how should a firewall be configured on a bitcoin-only machine?

[deepceleron]

That guy's a real asshole... or else a lot of people just sent him tons of BTC... idk for sure.

Anyway, as a not-so-expert-when-it-comes-to-security-guy, how should a firewall be configured on a bitcoin-only machine?

To allow Bitcoin through the firewall.

The original poster's problem was that he created a bitcoin configuration file specifically turning on the RPC remote control of Bitcoin (default off), setting an extremely simple user/password combination (default disabled), and adding an option to allow worldwide IP access (default local machine only). It would be the equivalent of leaving the keys in the ignition, leaving the car running, putting the signed-over vehicle title in the window, and posting a sign that said "free car".

[phelix]

That guy's a real asshole... or else a lot of people just sent him tons of BTC... idk for sure.

Anyway, as a not-so-expert-when-it-comes-to-security-guy, how should a firewall be configured on a bitcoin-only machine?

To allow Bitcoin through the firewall.

The original poster's problem was that he created a bitcoin configuration file specifically turning on the RPC remote control of Bitcoin (default off), setting an extremely simple user/password combination (default disabled), and adding an option to allow worldwide IP access (default local machine only). It would be the equivalent of leaving the keys in the ignition, leaving the car running, putting the signed-over vehicle title in the window, and posting a sign that said "free car".

Also he did not encrypt his prikeys.

[Rampion]

So, was the wallet encrypted or unencrypted?

[caveden]

So, was the wallet encrypted or unencrypted?

That was irrelevant. The RPC was open, and the authentication password was weak.
EDIT: To be honest I actually don't know if, when starting bitcoind as a RPC server, you have to open your encrypted wallet by typing the password. I'm assuming that's the case, what renders wallet encryption irrelevant.

[Rampion]

So, was the wallet encrypted or unencrypted?

That was irrelevant. The RPC was open, and the authentication password was weak.

I'm just trying to understand the RPC thing. When you do a transaction in Bitcoin-QT, you need the password to unencrypt your wallet. If you connect to RPC and authenticate you do not need to unencrypt the wallet to do transactions?

[caveden]

I'm just trying to understand the RPC thing. When you do a transaction in Bitcoin-QT, you need the password to unencrypt your wallet. If you connect to RPC and authenticate you do not need to unencrypt the wallet to do transactions?

I don't think so, otherwise every RPC-command should contain the encryption password as a parameter. I believe you unlock the wallet while starting the service. Or the RPC-authentication password is also the wallet encryption password (don't think so either because RPC is much older than wallet encryption).

You may check https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) for better info.

EDIT: Just checked and there are explicit RPC calls to lock and unlock the wallet. The wallet was then likely not encrypted, or encrypted with a weak password.

[camosoul]

So if I or anyone does 5 mistakes, what then, you think our house should blow up?

No, but if you screw up any worse, it'll probably blow up on it's own...

;-)

Sucks this happened man... But with gold in the ports, you KNOW it's being done... It's not a deterrent from a possible attack, it's a required defense against a known, perpetual, constant engagement.

You must take air with you if you're going underwater.... You will drown if you don't. It's not a maybe, it absolutely will happen.

Not meaning to toss any more gasoline on you. Just emphasizing the difference between a deterrent from a potential attack, and a required shield against a guaranteed ass-rape... This is guaranteed to happen unless you do something about it.

If it didn't happen, that would be the surprise.

[nathanghart]

I'm just trying to understand the RPC thing. When you do a transaction in Bitcoin-QT, you need the password to unencrypt your wallet. If you connect to RPC and authenticate you do not need to unencrypt the wallet to do transactions?

I don't think so, otherwise every RPC-command should contain the encryption password as a parameter. I believe you unlock the wallet while starting the service. Or the RPC-authentication password is also the wallet encryption password (don't think so either because RPC is much older than wallet encryption).

You may check https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) for better info.

EDIT: Just checked and there are explicit RPC calls to lock and unlock the wallet. The wallet was then likely not encrypted, or encrypted with a weak password.

That's correct. One has to first send the RPG command to unlock an encrypted wallet even when using the RPC commands.

[Rampion]

I'm just trying to understand the RPC thing. When you do a transaction in Bitcoin-QT, you need the password to unencrypt your wallet. If you connect to RPC and authenticate you do not need to unencrypt the wallet to do transactions?

I don't think so, otherwise every RPC-command should contain the encryption password as a parameter. I believe you unlock the wallet while starting the service. Or the RPC-authentication password is also the wallet encryption password (don't think so either because RPC is much older than wallet encryption).

You may check https://en.bitcoin.it/wiki/API_reference_(JSON-RPC) for better info.

EDIT: Just checked and there are explicit RPC calls to lock and unlock the wallet. The wallet was then likely not encrypted, or encrypted with a weak password.

That's correct. One has to first send the RPG command to unlock an encrypted wallet even when using the RPC commands.

So the thief brute forced two passwords, correct?