Bitcoin Forum
December 03, 2016, 09:46:44 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: How bad firewall settings can make you lose 75 BTCs  (Read 7077 times)
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
January 26, 2012, 03:38:37 PM
 #21

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480758404
Hero Member
*
Offline Offline

Posts: 1480758404

View Profile Personal Message (Offline)

Ignore
1480758404
Reply with quote  #2

1480758404
Report to moderator
1480758404
Hero Member
*
Offline Offline

Posts: 1480758404

View Profile Personal Message (Offline)

Ignore
1480758404
Reply with quote  #2

1480758404
Report to moderator
1480758404
Hero Member
*
Offline Offline

Posts: 1480758404

View Profile Personal Message (Offline)

Ignore
1480758404
Reply with quote  #2

1480758404
Report to moderator
mrx
Member
**
Offline Offline

Activity: 83


aka ff19


View Profile
January 26, 2012, 03:44:26 PM
 #22

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


Successfully traded with:
bulanula
kgo
Hero Member
*****
Offline Offline

Activity: 548


View Profile
January 26, 2012, 03:59:02 PM
 #23

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
Sr. Member
****
Offline Offline

Activity: 427



View Profile WWW
January 26, 2012, 04:02:20 PM
 #24

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.

Why the frell so many retards spell "ect" as an abbreviation of "Et Cetera"? "ETC", DAMMIT! http://en.wikipedia.org/wiki/Et_cetera

Host:/# rm -rf /var/forum/trolls
kgo
Hero Member
*****
Offline Offline

Activity: 548


View Profile
January 26, 2012, 04:06:50 PM
 #25

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
Legendary
*
Offline Offline

Activity: 1680


nmc:id/phelix


View Profile
January 26, 2012, 04:24:32 PM
 #26

besides nolisten... does this make sense?

-rpcallowip=127.0.0.1

blockchained.com ■ bitcointalk top posts
m3ta
Sr. Member
****
Offline Offline

Activity: 427



View Profile WWW
January 26, 2012, 04:30:00 PM
 #27

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.

Why the frell so many retards spell "ect" as an abbreviation of "Et Cetera"? "ETC", DAMMIT! http://en.wikipedia.org/wiki/Et_cetera

Host:/# rm -rf /var/forum/trolls
Schleicher
Hero Member
*****
Offline Offline

Activity: 630



View Profile
January 26, 2012, 06:15:29 PM
 #28

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

Bitcoin donations: 1H2BHSyuwLP9vqt2p3bK9G3mDJsAi7qChw
Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 26, 2012, 06:28:01 PM
 #29

it was probably in a dictionary of commonly used passwords
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 26, 2012, 06:37:15 PM
 #30

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
Legendary
*
Offline Offline

Activity: 1680


View Profile
January 26, 2012, 06:43:17 PM
 #31


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

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 26, 2012, 06:45:41 PM
 #32

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
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 26, 2012, 08:01:54 PM
 #33

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.

How often do you get the chance to work on a potentially world-changing project?
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
January 26, 2012, 08:06:59 PM
 #34

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
foggyb
Legendary
*
Offline Offline

Activity: 1302


View Profile
January 26, 2012, 09:43:50 PM
 #35

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

Not. Cool.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
January 26, 2012, 09:46:43 PM
 #36

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
Sr. Member
****
Offline Offline

Activity: 427



View Profile WWW
January 26, 2012, 09:47:25 PM
 #37

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.

 

Why the frell so many retards spell "ect" as an abbreviation of "Et Cetera"? "ETC", DAMMIT! http://en.wikipedia.org/wiki/Et_cetera

Host:/# rm -rf /var/forum/trolls
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
January 26, 2012, 09:49:17 PM
 #38

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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
foggyb
Legendary
*
Offline Offline

Activity: 1302


View Profile
January 26, 2012, 09:57:21 PM
 #39

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
Hero Member
*****
Offline Offline

Activity: 548


View Profile
January 26, 2012, 10:14:59 PM
 #40

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.
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!