A new BUG of Ethereum with send ETH without balance.

haint87 commented 6 years ago

Hi there,

https://rinkeby.etherscan.io/address/0x6Ef57BE1168628A2bD6c5788322A41265084408a https://ropsten.etherscan.io/address/0x6Ef57BE1168628A2bD6c5788322A41265084408a

When I make a transaction (offline transaction by signTransaction and sendRawTransaction), I recognise transactions from another wallet without balance sent to this wallet 0x6Ef57BE1168628A2bD6c5788322A41265084408a. If transactions are made with high gasPrice(40.000.000.000) then ETH sending to 0x6Ef57BE1168628A2bD6c5788322A41265084408a is higher, followed by similar transactions with lower gasPrice (100.000, 10.000, 100, 0). Is it a mistake of Ethereum?

update:

Without balance: the source address wallet can send more ETH without balance, I tested in my testnet.
When you send transaction more gasPrice (eg: 1.000.000.000.000,....), more leaked ETH.
Hacker can create many wallets from nodes, end scan the nodes and start hijacking process.

error

please note that this is an issue tracker reserved for bug reports and feature requests.

For general questions please use the gitter channel or the Ethereum stack exchange at https://chat.stackexchange.com/rooms/75652/discussion-between-jackson-ng-and-smarx https://ethereum.stackexchange.com/questions/45008/eth-stolen-on-ropsten

System information

Geth version: 1.8.2 OS & Version: Windows/Linux/OSX Commit hash : (if develop)

Expected behaviour

Actual behaviour

Steps to reproduce the behaviour

Backtrace

[backtrace]

ligi commented 6 years ago

Please provide more information - with this little information it is really hard to tell where the problem's origin is.

blackwatertepes commented 6 years ago

I'm experiencing this exact issue, with the same eth address of 0x6ef57be1168628a2bd6c5788322a41265084408a

However, I'm using the Ganache CLI, and a similar issue seems to be happening there: https://github.com/trufflesuite/ganache-cli/issues/502

haint87 commented 6 years ago

https://ropsten.etherscan.io/txs?a=0x6Ef57BE1168628A2bD6c5788322A41265084408a https://ropsten.etherscan.io/tx/0x35d257fd25aaf4c67d5d44d15b75dfba4fd4dade1bb89e307e579047bf0634d1 Note that the wallet has transaction without balance, so the balance is from the sky falling. If the transaction before with higher "gasPrice", the hacker's wallet gets more ETH.

holiman commented 6 years ago

The balance is not falling from the sky, it's mining rewards: https://ropsten.etherscan.io/address/0x3f7d39bdbf1f5ce649c194571aed3d2bbb2f85cf#mine .

I don't understand what the actual issue being reported here is. Is it something about extra transactions being made? Or about inclusion logic? Or about balance from nothing? Please clarify (or close, if it has been answered)

haint87 commented 6 years ago

Rinkeby isn't rewards for mining, but this error has on rinkeky with poa. I check and confirm that the balance is falling from the sky. :)

dipenjoshi commented 6 years ago

I just saw bunch of transaction going out of my account to this address as well. here's my ropsten address 0xD9e5e4bdE24Faa2B277ab2Be78C95b9ae24259A8, starting block is 3002539 and ends at 3013254

blackwatertepes commented 6 years ago

I'm experiencing this issue on a private Ethereum network, with no world access. So, this issue does not only exist on the public test nets, and is most likely caused from something related to the Ethereum codebase.

laokan commented 6 years ago

this error is confim, the bug when use web3.js transfer token, the he account all blances will give the 0x6Ef57BE1168628A2bD6c5788322A41265084408a address at rinkeby network & 0x6Ef57BE1168628A2bD6c5788322A41265084408a at main network, what ?

laokan commented 6 years ago

https://rinkeby.etherscan.io/address/0x6ef57be1168628a2bd6c5788322a41265084408a https://etherscan.io/address/0x6ef57be1168628a2bd6c5788322a41265084408a

laokan commented 6 years ago

https://etherscan.io/tx/0x0bffe0c95207789b5c3ad233954cd754378474b4ca5732cac474a5e3951cea4f

and 0x6ef57be1168628a2bd6c5788322a41265084408a this account has out transfer， what's wrong ？

laokan commented 6 years ago

I Meet this bug When I Use the web3.js test token transfer

laokan commented 6 years ago

i'm sure this is config error ,when the node 8545 port is open the internet (open the rpc right to the internet) ,some one has 0x6ef57be1168628a2bd6c5788322a41265084408a will attion you wallect ,wen use console unlock the account ,then the ether will be losted! please use firewall blocked the 8545 rpc's port. please ban 0x6ef57be1168628a2bd6c5788322a41265084408a address

holiman commented 6 years ago

Ok, so this report relates to someone making transactions from your account(s)? Yes, do not open 8545 to the internet. That's highly dangerous. Especially if you use unlock.

ligi commented 6 years ago

I really wonder if this was the problem of the OP - hope he will answer and clarify (ping @haint87) - otherwise we should just close the issue as I see nothing actionable here

dipenjoshi commented 6 years ago

yes i use --unlock param when running geth. and port 8545 open from firewall. because i need to access to rpc from web3.js from another server.

ligi commented 6 years ago

@dipenjoshi as @holiman pointed out that is a really bad idea and you should stop doing this - there is no way to protect you when you are doing this. Can you elaborate a bit more on why you do this exactly?

Tudmotu commented 6 years ago

@ligi, if I need to be able to perform transactions on a private network via MetaMask, how do I do that without exposing 8545?

ligi commented 6 years ago

@Tudmotu exposing 8545 is not a problem generally - but this node should hold no accounts then. When using metamask the account is managed by metamask - so the node does not need the account ..

Tudmotu commented 6 years ago

OK, I am actually using ganache and I am using the auto-funded accounts feature, so the network starts up with 10 accounts that are pre-funded. I am using a custom mnemonic. All the funds are transferred to 0x6Ef57BE1168628A2bD6c5788322A41265084408a after a couple of minutes. ~Is there any explanation as to how is that possible?~ edit: I'm trying to figure the workaround for this. If I create a different node that only acts as external RPC endpoint, will that prevent this "attack"? What's the difference between that and a single ganache node? Is there any more info I should give? This issue only started in the last couple of days. Would appreciate any help, I'm pretty new to ethereum :)

haint87 commented 6 years ago

I confirm this is bug of Rinkeby and Ropsten.

Note:

If you send with the higher the gasPrice, 0x6Ef57BE1168628A2bD6c5788322A41265084408a will receive more ETH.
If you send without unlockAccount such as signTransaction, sendRawTransaction(Offline transaction), the bug is the same.

laokan commented 6 years ago

https://etherscan.io/txs?a=0x6ef57be1168628a2bd6c5788322a41265084408a this address continue , & ehterum founder can blocked this address?

philsmd commented 6 years ago

@laokan this is not how blockchain technology or cryptocurrency normally works: you can't say "we don't want this guy to be using this technology", therefore you can't ban anyone (see censorship resistance and yeah I agree every feature could possibly have also a few disadvantages besides the vast majority of advantages. but you can't simply block an account because you think this is a "bad guy", that would give you too much power)

@haint87 could you make a clean test without any old accounts (for which the attacker could have already "hacked"/access to) ? (of course you need to backup all your old important accounts) I would suggest that you make a setup with highest logging level and also copy the log files or somehow prohibit cleaning the history etc. An alternative would be to sniff and log the RPC traffic such that all communication can be inspected by the devs. I think that without you unlocking it, it would/should be impossible for the attacker to sent ether (therefore we need some evidence in terms of logs/sniffed data what the attacker is doing). Maybe you have --unlock set in your command line and do not remember that it's there ? Can you please explain in terms of a single transaction what you mean by the ether received is larger if the gas price is high ? I don't understand this part of your claims, please show a single (or only a couple of transaction) and explain in detail what you think is not okay with these transaction fees/gas price/ether value etc. Is this for instance a transaction with the problem that you are describing: https://ropsten.etherscan.io/tx/0x6d72fb71bbb03259f5de287061c96f301dcd684c379c8a0c55e03a18389c2b89 ? If yes, what exactly do you think is wrong with this transaction?

I would also suggest to the devs (@holiman, @ligi, @karalabe etc) that a user shouldn't be allowed to run dangerous command with geth running on open ports to the whole world that easily. I would suggest that geth should refuse to unlock accounts (or do any other dangerous commands like these) if the port is reachable by a non-localhost accessible network ... unless the user makes (all of these):

a config file entry where s/he enables a/this dangerous feature to unlock accounts etc even if on a non-localhost network (this setting should be marked/documented as dangerous and discouraged)
a command line switch where this feature must ALSO be enabled on each and every geth/process start individually (if the user really wants to run dangerous commands like this on a non-localhost listening geth instance)
the user must see a WARNING that s/he must accept at least once (and she must see the warning each and every time after the first run too and it must be logged too that this warning was shown! Furthermore, whenever a dangerous command is actually run on a non-local-only system, this event should be logged and it should be guaranteed that this logged event can't somehow be skipped/removed/hidden by the attacker), which s/he can only accept/bypass by writing some test to confirm that s/he is aware of the risk of using this/these dangerous feature(s) like: "If you have read and understood this warning and agree that you are using this possibly dangerous feature at your own risk, please type: 'I UNDERSTAND THAT USING THIS FEATURE IS VERY DANGEROUS' (all in caps lock without the quotes) below:". The user needs to confirm this before the actual geth console is started. For non-interactive systems or mass-installations geth could allow the administators to somehow bypass this confirmation (even though they should not allow unlocks etc on world writable system in the first place), but only with file system access (like writing a otherwise-not-writable system setting or an I-HAVE-ACCEPTED-IT file, which is only present if the user has understood/accepted this warning)... this "bypass" of the manual confirmation should of course be discouraged and the user should normally always read the warning and confirm it manually. I also suggest that even this bypass of the manual/interactive confirmation requires that the text above (I UNDERSTAND...) needs to be somehow present in the setting/was-accepted file such that it is guaranteed that even if the setup/installation was done with this bypass-the-manual-confirmation way, the system administrator did see the I UNDERSTAND text somehow (of course there is no 100% guarantee that the administrator always saw this string. for instance, what if they have a shell script that automatically writes this I UNDERSTAND... text into a file? geth can't easily prevent this. The only alternative would be to do not allow bypassing the interactive confirmation at all, which is fine by me but probably a burden for some other/professional highly connected systems with many geth instances which ALSO require unlocking but which are secured/firewalled/restricted. It's also somehow difficult to distinguish between these two cases, i.e. whether the user manually accepted the warning or if it was done automatically by writing to the config file etc... I wouldn't go that far to guarantee (or make sure) that the confirmation was done interactively, because this could probably bypassed/automated somehow anyways).

I know that this sounds paranoid and somehow "stupid"/overexaggerated, but the problem is that geth needs to make sure that the users understand the risk of unlocking (or running any other dangerous features). If it is too easy that the users are copy pasting the commands from guides/tutorials/stackexchange etc with "--unlock 0" in it without the user even understanding what this does and running geth on a world-reachable port and the user never saw any warnings, geth could of course somehow "made responsible" for allowing such a dangerous feature without any user confirmation/interaction. Therefore, I would suggest to make it much more difficult for users to accidentially allow running dangerous commands on wide open (world listening) geth instances. What do you think devs?

haint87 commented 6 years ago

https://etherscan.io/address/0x6ef57be1168628a2bd6c5788322a41265084408a

Check this url, mainnet has an error as this bug. @karalabe , @holiman , @ligi

philsmd commented 6 years ago

@haint87 yeah, this is an address and possibly a (known) address of a malicious users that is also mentioned on other forums/issues/stackexchange etc. The attacker probably automatically finds insecure systems with not-secured/not-firewalled geth instances which are using unlocked accounts.... this is a well-known dangerous "feature" of geth and developers always discouraged the use of unlocked accounts on non-local systems. I think currently we have no evidence that these systems are secure and locked therefore we must assume that these "hacked" accounts are very insecure systems (not firewalled and unlocked, which is very dangerous of course!).

I still do not understand your claims about the "without balance" and the "ether received is larger if gas price is higher" claims. You need to explain in detail with transactions (not ethereum addresses!) what you think is going on (i.e. what is not okay in your eyes with these transactions, transaction != addresses).

haint87 commented 6 years ago

@philsmd

Without balance: the source address wallet can send more ETH without balance, I tested in my testnet.
When you send transaction more gasPrice (eg: 1.000.000.000.000,....), more leaked ETH.
Hacker can create many wallets from nodes, end scan the nodes and start hijacking process.

philsmd commented 6 years ago

maybe I'm blind here, but if we look at the transaction https://ropsten.etherscan.io/tx/0x6d72fb71bbb03259f5de287061c96f301dcd684c379c8a0c55e03a18389c2b89 for which you claim that the address 0x71bed1e585f8cb8d840ac54715c9c5a642cb4cc1 (the sender) had 0 balance before the transaction, I can't confirm it with this tool: https://ropsten.etherscan.io/balancecheck-tool

if I put address 0x71bed1e585f8cb8d840ac54715c9c5a642cb4cc1 and BlockNo 2999514 I get Balance = 0.0000000000001 Ether (the balance was not zero!) and after that block (i.e. 2999515), I get 0.000000000000001 Ether, this is as expected less than the previous balance (be aware that these online block explorers may not display all the after-comma digits and they may do some roundings, therefore it would be better to double-check the actual balance with geth/web3 or other tools that show the whole balance in wei). I still do not see why you claim that the sender's account is "without balance". There were some wei in that account before the transaction. Maybe you have a different/better example?

andysign commented 6 years ago

Indeed, not really 0 balance but 1000 wei instead and because Etherscan is rounding up small numbers it looks like zero.

However, it appears the attacker was able to perform a zero fee transaction at BlockNo 3010233 as you can see here (gas: 21000, gasPrice: 0, that is Actual Tx Cost/Fee gas*gasPrice: 0): https://ropsten.etherscan.io/tx/0x75f978386134d5743370be1baa0dd0646fac48113330206dfd161d89a2e124c8

I think to mine blocks with zero fee transaction is a bad idea even on testnet and I would encourage the miner who's doing that to stop doing it.

haint87 commented 6 years ago

Update: The attacker exchanges ETH by Shapeshift... https://etherscan.io/address/0x9d4f99555f94ae9e89a793be705f99c6f2afa2d2 https://etherscan.io/address/0x96e38a38a0a8b76331c1b6d2d52ecf0f08862e34

karalabe commented 6 years ago

I'll close this issue as it's not a bug in go-ethereum, rather badly configured nodes + active attackers on mainnet. Feel free to continue discussions on reddit or more appropriate forums where the community at large can participate too.

haint87 commented 6 years ago

I think it's an error and ETH balance is from the sky falling

holiman commented 6 years ago

@haint87 please point to one specific transaction made with insufficient balance, and I will explain where it comes from.

haint87 commented 6 years ago

Thanks for your answer. I don't want to post my system here, but it has the same error with more gas, the attackers have more ETH. I sent a test transaction with gasPrice 10.000.000.000.000 the attacker has 200ETH I send a transaction the same with gasPrice 0 the attacker has 0.000000000000001 ETH.

I try to research and simulation as attackers do, but have not found yet.

Note:

My system opens rpcapi port default(8545), clear all pending transactions, sent a new tx -> the bug works.
My system opens rpcapiport other, clear all pending transactions, sent a new tx -> the bugs works.
I do not use the unlockAccount function.
I checked source address sent ETH to 0x6ef57be1168628a2bd6c5788322a41265084408a, all source address had very small balance ETH eg: <=1e-10 ETH

holiman commented 6 years ago

The gasPrice * gas goes to the miner/coinbase. Are you sure you haven't configured the 'attacker' account as the coinbase if you're on a private network? Or if you are on Ropsten, it may be a legit miner.

haint87 commented 6 years ago

All source wallet is not the miner/coinbase, and it doesn't receive any ETH from the miner/coinbase.

philsmd commented 6 years ago

Could you please make some screenshots (you could if you want/need only show the amount/fee/gas/gasPrice etc and hide/obscure the addresses etc) and explanation of the transaction flow etc. What I currently do not understand is if you are claiming that whenever you are making a new/fresh transaction you see a 2nd transaction that you did not authorize ? is this the case or did I get this wrong? maybe you can explain this in more detail.

I think it would be best to have some RPC sniff/logs to understand what is going on. Do you think you are able to set up a sniffer that can track what the attacker is doing ? btw: this would be a good idea for the security guys to look into as well so maybe you can help @holiman etc to think about setting a system up like the one of @haint87... that acts like a honeypot. I think this shouldn't be too difficult or too expensive to run a completely open honeypot with RPC sniffer like this. A problem could be that it could take some time before shodan or other services find this new open port and attackers connect to this (could take between some minutes to days if the IP is not already known). Another problem could be that different attackers connect to it and you can't really observe the same attack vector(s) like the one potentially used on @haint87 system. Maybe/probably honeypots like this already exist!? @holiman ?

BTW: it could also be that your system is somehow (independently from go-ethereum etc) compromised @haint87 and some malware code is for instance attaching to the geth instance or you are running a modified/trojanized version of the geth binary etc. Did you try with a different system for which you know that there is no possibility that it is compromised/infected (update: and as @karalabe pointed out below of course also the addresses shouldn't be compromissed or been compromissed in the past) ? A fresh operating system installation with up-to-date anti-virus and operating system updates, for instance. The problem is that the causes for these problems could be very different. Furthermore, we really need some evidence and/or more detailed facts which you didn't provide yet... if you say that the attacker does this type of attack a lot also on non-private chains, why can't you link to a transaction ID (not a ethereum address, but a transaction, or set of transactions) where we can check the gas/fee/gasPrice/amount/input/outputs etc ?

karalabe commented 6 years ago

If you take a look at the transaction pool, the attacker doesn't just sign one transaction, rather submits thousands of pre-signed transactions. The effect is that it doesn't matter whether you secure your setup after the fact. Whenever your account receives funds, there's already a pending transaction pre-authorized with your account to spend those. You can't reuse an already compromised account, rather you need to switch to a new one.

philsmd commented 6 years ago

but let me understand this, this attack only works because the account was already unlocked in the past and the attacker had access to this unlocked account, right? of course (and I fully agree with you @karalabe) you shouldn't continue using an address which you know was already compromised in the past.

karalabe commented 6 years ago

Indeed, that is my guess.

E.g. on Rinkeby, there are accounts with thousands of pre-authorized transactions going to this sink:

    0x300BAB56a81c096A21f2075964f095D635658834: {
      1000: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1001: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1002: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1003: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1004: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17857298877250104992 wei + 21000 gas × 75000000000 wei",
      1005: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1006: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1007: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1008: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1009: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1010: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1011: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1012: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1013: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17857298877250104992 wei + 21000 gas × 75000000000 wei",
      1014: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1015: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1016: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1017: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1018: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1019: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1020: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1021: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1022: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17857298877250104992 wei + 21000 gas × 75000000000 wei",
      1023: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1024: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1025: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1026: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1027: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1028: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1029: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1030: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17858852877250104992 wei + 21000 gas × 1000000000 wei",
      1031: "0x6Ef57BE1168628A2bD6c5788322A41265084408a: 17857298877250104992 wei + 21000 gas × 75000000000 wei",
[...]

philsmd commented 6 years ago

Is there some way that geth could (in future releases of geth) prevent pre-signing all these transactions even if the account has no funds ? As far as I know this is the main security hole that the attacker is exploiting, right? Couldn't geth just refuse signing any transaction if the funds are not enough ? Or did I interpret this incorrectly (yeah, I'm still learning about all these details so please forgive me if I'm completely wrong here) ?

hmm, a problem could be that before the legitimate transaction (initiate by the actual user) was confirmed by the network the balance is still > 0 and therefore the attacker can keep pre-signing transactions.... this might be the main problem we are experiencing here (because this is kind of a wanted feature that unless the transaction is confirmed you still have those ethers in your account and therefore a > 0 balance !) btw: as far as I know this also is a main difference between ethereum and bitcoin, with UTXO within the bitcoin network an attack like this would be kind of impossible (I'm not trying to say that bitcoin is better or ethereum is badly designed to allow "such attacks" or anything like that. I'm just pointing out that this attack is kind of difficult with UTXO, right?)

haint87 commented 6 years ago

Thanks for yours hard working.

I'm still learn how to attacker do it. I think the problem is gas and gasPrice.

Tudmotu commented 6 years ago

@karalabe - To me, this happens on test nets with randomly generated accounts, that have not been compromised. Our system is docker based which means it's probably not "malware"...

How is it possible for someone to perform a transaction if they don't have the private key of the account? This feels like a real issue, where someone is able to perform transactions on behalf of arbitrary accounts. In our case, all we do is start up the ganache node, and a couple of seconds later all the funds are transferred to the 0x6Ef57BE1168628A2bD6c5788322A41265084408a address.

philsmd commented 6 years ago

@Tudmotu are you sure that you do not use -u or --unlock within your ganache-cli command? I think it would make sense to see if this only happens if you use ganache or also happens for you if you "just" use the latest geth binary alone. Could you please test this?

update: it seems that ganache also requires you to use --secure to lock accounts by default !? I must admit that I'm not too familiar with ganache yet, but it's worth investigating these command line switches cc: @blackwatertepes , same question goes to you: are you sure you are using --secure with ganache ?

Tudmotu commented 6 years ago

Thanks @philsmd! I am not using --secure. I will try that and see if it prevents this issue. What does the --secure flag mean? Does it mean without it people don't need private keys to perform transactions on behalf of accounts? The ganache docs don't really explain this. 😕

philsmd commented 6 years ago

If we look at the description of --secure over here: https://github.com/trufflesuite/ganache-cli/ , it seems that the accounts are unlocked by default (which is very dangerous if you are running it on a world reachable/open network connection) if you do not use --secure. Only with --secure the accounts are locked by default (and by using --unlock you can unlock specific accounts... which of course you should not do for these testings here because whenever you unlock the accounts the attackers can sign transactions on your behalf if they have access to your node).

I think this genache problem/discussion is mostly off-topic here, because it doesn't have anything to do with geth, as far as I can tell. Therefore, I would suggest that you just do not use unlocked accounts on wild open ports (insecure setup).

Tudmotu commented 6 years ago

Hi all, This happens to me also with the --secure option. It's also transferring to 0x7097f41f1c1847d52407c629d0e0ae0fdd24fd58 now. Next thing I'll try is to setup a geth node without accounts that is connected to the private ganache network. Anyone knows how to do that by any chance?

siong1987 commented 6 years ago

@Tudmotu you might find this helpful: https://github.com/ethereum/go-ethereum/wiki/Setting-up-private-network-or-local-cluster

this post can be helpful too: https://hackernoon.com/ethereum-development-walkthrough-part-2-truffle-ganache-geth-and-mist-8d6320e12269

Tudmotu commented 6 years ago

Thanks @siong1987 :) Seems like I need to manually set peers via geth console, but I will look more into that and see if it can be done non-interactively.

Jockeyvb commented 6 years ago

ai... i am do err some nothing, same issues ,the address 0x7097f41f1c1847d52407c629d0e0ae0fdd24fd58

haint87 commented 6 years ago

@Tudmotu this is a real issue.

bradlucas commented 6 years ago

I see that this issue was Closed but the original issue of the sending of ETH without a balance didn't seem to be addressed in the comments.

I may be wrong but it seemed that having an open port of 8545 seemed to the issue and that was allowing outside actors to access an account.

I agree that having the open port and an unlocked account is a user issue but what about the ability to send ETH from an account which does not have a balance.

For example, see the following account.

Account https://ropsten.etherscan.io/address/0xd60e64afb753583941e1ab42f836ced0d23af2db

It is on Ropsten and by design is only meant to be a prototype and does have the 8545 port open and is accessed from a web page.

But, look what happened 20 days ago.

First, the account was empty so I used a Faucet to get 2 ETH. Those transactions are here:

Loaded the account with 2 ETH

0xb0a84863a0a6411fcfcc924d2b3439d3a4654cdac085aadb113bb707231f2a03  3155757 20 days 2 hrs ago   0xe17f97b518e9e8bbc9b72ab88fd3f9db10bea981    IN    0xd60e64afb753583941e1ab42f836ced0d23af2db  1 Ether 0.00021004
0x7dd9fceccfc230d234f54cbcad9a48f404cf472042f658a90cd028fb13a5e1b0  3155652 20 days 2 hrs ago   0x687422eea2cb73b5d3e242ba5456b782919afc85    IN    0xd60e64afb753583941e1ab42f836ced0d23af2db  1 Ether 0.00000105

Then the prototype was used a few times. You'll see the 0 ETH transactions (only TxFee).

But, after three transactions there was this one which looks like entailed a transfer of 89 ETH out of this account.

Somehow 89 ETH was transferred out

0x68442d7de4c4790dd53caaf0ea5eaee51e4c7775a85eb75f3088e87b6763ce22  3179284 16 days 14 hrs ago  0xd60e64afb753583941e1ab42f836ced0d23af2db  OUT 0x6ef57be1168628a2bd6c5788322a41265084408a  89.968911587469 Ether   0.00483

How could this happen? The account has a bit under 2 ETH in it but the transaction appears to be for about nearly 90 ETH.

I'm curious.

ethereum / go-ethereum