Bitcoin Forum
October 22, 2017, 02:03:18 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Worst case scenario  (Read 1895 times)
codymanix
Full Member
***
Offline Offline

Activity: 203

Gir: I'm gonna sing the Doom Song now..


View Profile
October 10, 2013, 03:41:25 PM
 #1

Could it happen that an attacker injects malicious code into the satoshi client? For example that all money of the user's wallet is transferred to the attacker (If the wallet is encrypted, as soon as user enters the password). Then the infected client would have to made available for download on official site bitcoin.org.
Even if the problem is noticed within a few hours, the attacker could have gained lots of money, so such an attack would be very attractive for a criminal hacker.
Additional to the damage done to the users, this could do much damage to bitcoin itself, if not even destroying it.

I can think of a lot possible access points for the attacker:

- An attacker could break directly into the source control where the source code is stored and unnoticed injects his code which is then automatically include in the next version.
  But since bitcoin is open source, the attacker should hide its code in a file where people rarely look into or file which at first glance does not look important but are indeed source files

- An attacker could hack a computer of one of the bitcoin client developers (Either through direct physical access or through some trojan)

- The attacker could threaten one of the bitcoin developers and such force his to do what he wants

- An attacker could break into the website bitcoin.org and place his malicious client for download, or redirect bitcoin.org via some dns attack to his own (same looking) website
  With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?

This are my greatest fears. Please tell me that these scenarios are almost impossible to happen. So the question is, could this be possible?

Programming tutorials, Tools, Games & Humor http://deutronium.de.vu
My Vircurex referral code for persistant 0.05% trade discount: 750-33267 or use
https://vircurex.com/welcome/index?referral_id=750-33267
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508680998
Hero Member
*
Offline Offline

Posts: 1508680998

View Profile Personal Message (Offline)

Ignore
1508680998
Reply with quote  #2

1508680998
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
October 10, 2013, 04:32:22 PM
 #2

- An attacker could break directly into the source control where the source code is stored and unnoticed injects his code which is then automatically include in the next version.
  But since bitcoin is open source, the attacker should hide its code in a file where people rarely look into or file which at first glance does not look important but are indeed source files

This won't work. Everyone looks at diffs. Making the change in something that changes all the time would be a better strategy. In GIT it is not possible to make invisible changes either, and rewriting the history will make all git clients refuse to pull until forced.

Quote
- An attacker could hack a computer of one of the bitcoin client developers (Either through direct physical access or through some trojan)
- The attacker could threaten one of the bitcoin developers and such force his to do what he wants
If the system is vulnerable to this, then you can remove the third party "attacker" from the equation: One of the developers could just do this if it were possible.  Hopefully, enough people are auditing all changes that this wouldn't be possible.

Quote
- An attacker could break into the website bitcoin.org and place his malicious client for download, or redirect bitcoin.org via some dns attack to his own (same looking) website
  With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?

About 1% check. But users update very slowly and we intentionally do not have a forced auto-update. And there are people running automated signature tests who would quickly notice a problem.

Quote
This are my greatest fears. Please tell me that these scenarios are almost impossible to happen. So the question is, could this be possible?

Certainly it would be possible, few things are not possible.  It's less clear that there would be a large amount of funds taken this way...

Bitcoin will not be compromised
jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 10, 2013, 05:12:01 PM
 #3

What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
October 10, 2013, 06:00:37 PM
 #4

What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?
A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message:

"URGENT: Alert key compromised, upgrade required"

Bitcoin will not be compromised
michagogo
Member
**
Offline Offline

Activity: 80


View Profile
October 11, 2013, 11:52:26 AM
 #5

What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?
A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message:

"URGENT: Alert key compromised, upgrade required"


Maybe I'm missing something, but wouldn't the attacker in this case simply set the sequence number and priority to the maximum?
jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 11, 2013, 01:08:44 PM
 #6

What if the alert system key(s) is compromised? Any mechanism to revoke the old key and migrate to a new one?
A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message:

"URGENT: Alert key compromised, upgrade required"


Maybe I'm missing something, but wouldn't the attacker in this case simply set the sequence number and priority to the maximum?

I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
codymanix
Full Member
***
Offline Offline

Activity: 203

Gir: I'm gonna sing the Doom Song now..


View Profile
October 11, 2013, 03:24:02 PM
 #7


Quote
- An attacker could hack a computer of one of the bitcoin client developers (Either through direct physical access or through some trojan)
- The attacker could threaten one of the bitcoin developers and such force his to do what he wants
If the system is vulnerable to this, then you can remove the third party "attacker" from the equation: One of the developers could just do this if it were possible.  Hopefully, enough people are auditing all changes that this wouldn't be possible.
If someone puts a manipulated client on bitcoin.org with his own source, that is without checking in anything?

Quote
- An attacker could break into the website bitcoin.org and place his malicious client for download, or redirect bitcoin.org via some dns attack to his own (same looking) website
  With this attack, the checksum of the client won't be ok but how many users will (or even know how to) check that?
About 1% check. But users update very slowly and we intentionally do not have a forced auto-update. And there are people running automated signature tests who would quickly notice a problem.
If done from a computer of a bitcoin developer, the executable could also be signed valid, so no one will notice the difference.

It would be great some kind of multi key signing would be used, that is, multiple persons have to sign with their private keys to make the signature valid.

Programming tutorials, Tools, Games & Humor http://deutronium.de.vu
My Vircurex referral code for persistant 0.05% trade discount: 750-33267 or use
https://vircurex.com/welcome/index?referral_id=750-33267
piotr_n
Legendary
*
Offline Offline

Activity: 1750


aka tonikt


View Profile WWW
October 11, 2013, 04:07:00 PM
 #8

This is exactly the reason why people shall be using cold wallets, to store their major BTC holdings.

It doesn't even need to be a bug or a backdoor in the actual bitcoin client - more likely it would be a virus/trojan/malware or just a bug/backdoor in the OS.

Keep your bitcoins offline and do not move any signed transaction from your cold storage without double checking whether it does exactly what you intended.
Just use your imagination combined with the already available technology and the worst case scenario would not be a threat to you.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
October 11, 2013, 05:00:27 PM
 #9

I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.
Correct.

It would be great some kind of multi key signing would be used, that is, multiple persons have to sign with their private keys to make the signature valid.
We have that, thats what gitian is for.

Bitcoin will not be compromised
Cryddit
Legendary
*
Offline Offline

Activity: 840


View Profile
October 12, 2013, 04:33:37 AM
 #10

Actually, this could be done on a far simpler basis attacking individual users via a MITM attack.  Here is your scenario:

1.  Your ISP hires a dishonest worker.  Let's call him "Mallory".  (I say ISP, but this could happen upstream from the ISP, too, on the backbone).

2.  Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.

3.  Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.

4.  "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
     to a server where Mallory's fiddled version is served.

5.  A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.

6.  These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client.  Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.

7.  Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.

8.  It will be at least two or three months before most of the victims notice. 

jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 12, 2013, 05:22:11 AM
 #11

This won't work because people use https, not http

Actually, this could be done on a far simpler basis attacking individual users via a MITM attack.  Here is your scenario:

1.  Your ISP hires a dishonest worker.  Let's call him "Mallory".  (I say ISP, but this could happen upstream from the ISP, too, on the backbone).

2.  Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.

3.  Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.

4.  "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
     to a server where Mallory's fiddled version is served.

5.  A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.

6.  These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client.  Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.

7.  Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.

8.  It will be at least two or three months before most of the victims notice. 



Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Shallow
Sr. Member
****
Offline Offline

Activity: 280


View Profile
October 12, 2013, 06:02:41 AM
 #12

This is very unlikely i would hope. Pretty sure the source code is thoroughly checked by many paranoid people upon an update.

michagogo
Member
**
Offline Offline

Activity: 80


View Profile
October 12, 2013, 07:45:15 PM
 #13

I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.
Correct.

Sorry if I'm being slow... Are you saying that the "URGENT: Alert key compromised, upgrade required" message is hard-coded into the client to display when it sees a maximum-sequence alert?
jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 12, 2013, 08:00:47 PM
 #14

I think sending a maximum sequence alert is equal to sending the "URGENT: Alert key compromised, upgrade required". It's equivalent to revoking the key.
Correct.

Sorry if I'm being slow... Are you saying that the "URGENT: Alert key compromised, upgrade required" message is hard-coded into the client to display when it sees a maximum-sequence alert?

Yes.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
cowandtea
Sr. Member
****
Offline Offline

Activity: 434


View Profile
October 13, 2013, 02:29:00 PM
 #15

Unlikely, it would happen long before when it is still vulnerable. Right now seems like it has all patched up.

juhakall
Sr. Member
****
Online Online

Activity: 443



View Profile
October 13, 2013, 02:41:50 PM
 #16

This won't work because people use https, not http

Actually, this could be done on a far simpler basis attacking individual users via a MITM attack.  Here is your scenario:

1.  Your ISP hires a dishonest worker.  Let's call him "Mallory".  (I say ISP, but this could happen upstream from the ISP, too, on the backbone).

2.  Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.

3.  Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.

4.  "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
     to a server where Mallory's fiddled version is served.

5.  A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.

6.  These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client.  Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.

7.  Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.

8.  It will be at least two or three months before most of the victims notice. 



http://kent.dl.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.8.5/bitcoin-0.8.5-win32-setup.exe

This is what I'm offered to download when clicking through bitcoin.org. No HTTPS there.
jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 13, 2013, 02:48:43 PM
 #17

This won't work because people use https, not http

Actually, this could be done on a far simpler basis attacking individual users via a MITM attack.  Here is your scenario:

1.  Your ISP hires a dishonest worker.  Let's call him "Mallory".  (I say ISP, but this could happen upstream from the ISP, too, on the backbone).

2.  Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.

3.  Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.

4.  "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
     to a server where Mallory's fiddled version is served.

5.  A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.

6.  These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client.  Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.

7.  Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.

8.  It will be at least two or three months before most of the victims notice. 



http://kent.dl.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.8.5/bitcoin-0.8.5-win32-setup.exe

This is what I'm offered to download when clicking through bitcoin.org. No HTTPS there.

Oh, that's really bad. Even bitcoin.org is not https enabled. (but at least the package is signed by bitcoin foundation)

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Cryddit
Legendary
*
Offline Offline

Activity: 840


View Profile
October 13, 2013, 06:17:22 PM
 #18

Well.... yeah, it really is that bad. 

Maybe we should ask sourceforge/github/ any others we can influence, never to serve executable (or, really, even source) using http rather than https? 

https isn't all that secure, for that matter, but it is better than nothing.

Anybody got a better idea?



gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2324



View Profile
October 13, 2013, 07:13:57 PM
 #19

https isn't all that secure, for that matter, but it is better than nothing.
Anybody got a better idea?
HTTPS is not that secure. Fortunately we have _two_ different signature systems which are better than HTTPS which are in use. GPG signatures by Gavin's signing key, and gitian signatures.

Bitcoin will not be compromised
jl2012
Legendary
*
Offline Offline

Activity: 1694


View Profile
October 13, 2013, 07:35:52 PM
 #20

https isn't all that secure, for that matter, but it is better than nothing.
Anybody got a better idea?
HTTPS is not that secure. Fortunately we have _two_ different signature systems which are better than HTTPS which are in use. GPG signatures by Gavin's signing key, and gitian signatures.


I opened a discussion here: https://bitcointalk.org/index.php?topic=310161.0

So what is your comments for the use of PKI in payment protocol?

For Gavin's key, how do I verify if I do not know him and do not have a web-of-trust?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Pages: [1] 2 »  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!