ETH auf Ropsten gestohlen

Hat jemand das folgende Szenario auf Ropsten erlebt:

  1. Sie erstellen ein Konto in Geth und überweisen etwas ETH über einen Wasserhahn an sich selbst.
  2. Sie entsperren das Konto und beginnen mit der Erstellung und Ausführung von Verträgen.
  3. Plötzlich stellen Sie fest, dass alle Ihre ETHs weg sind, übertragen auf 0x6Ef57BE1168628A2bD6c5788322A41265084408a.

Dies ist mir und einer Gruppe von Teilnehmern während eines Workshops passiert, bei dem in Sekundenschnelle alle unsere ETH gestohlen wurden.

Wenn Sie sich die Transaktion ansehen, die auf diesem Konto in Etherscan stattgefunden hat, läuft sie in Schüben ab, wobei eine kleine und manchmal ziemlich beträchtliche Menge an ETH auf sich selbst übertragen wird.

Wollte herausfinden, ob das etwas Erklärbares ist. Mir ist aufgefallen, dass die gleiche Adresse 0x6Ef57BE1168628A2bD6c5788322A41265084408a auch auf Rinkeby zu finden ist.

Ich wollte erwähnen, dass keiner von uns unsere Geth-Instanz gesichert hat, da dies nur ein Versuch war. Dies war der Befehl, der die Instanz ausgeführt hat: geth --testnet --syncmode "light" --rpc --rpcapi db,eth,net,web3,personal,admin --cache=1024 --rpcport 8545 --rpcaddr 0.0. 0.0 --rpccorsdomain "*
Welche Websites haben Sie besucht, während das Konto entsperrt war? Mit diesen RPC-Einstellungen könnte jede von Ihnen besuchte Website das Geld nehmen.
Nur Etherscan. Wir alle haben unsere Konto-ID in Etherscan eingegeben, um unsere Transaktionen zu überwachen. Ich weiß, dass die RPC-Einstellungen unsicher waren, aber ich bin daran interessiert zu erfahren, wie ein Skript geschrieben werden kann, um die Blockchain nach unsicheren Geth zu durchforsten, um ETH zu stehlen, und wie es das getan hat.
Es scheint unwahrscheinlich, dass Etherscan der Übeltäter ist. Für jede andere Website sind es nur ein paar Codezeilen: new Web3('http://localhost:8545')und dann ein Aufruf an web3.eth.getAccounts, um die Konten zu finden und dann web3.eth.sendTransactionEther zu senden.
Es muss auch keine Website sein ... Software auf Ihrem Computer oder vielleicht jemand anderes in der Werkstatt könnte dasselbe tun. Es ist nichts besonders schwierig dabei.
Angenommen, ich möchte zwei Dinge tun: 1) eine Mist-Wallet mit meiner Geth-Instanz in der Cloud verbinden 2) Transaktionen lokal von demselben Computer in der Cloud ausführen, wie soll ich die Geth-Befehlszeile schreiben, um sie zu sichern?
Ich bin die falsche Person, um das zu beantworten. Ich denke --rpcaddr 127.0.0.1, und loswerden --rpccorsdomainsind ein guter Anfang.

Antworten (1)

Ich bin in einem privaten Netzwerk auf genau die gleiche Situation gestoßen, als ich ein Konto auf einem Knoten mit einer öffentlichen IP-Adresse entsperrt ließ, um zu sehen, was passiert ist - alle Gelder wurden an dieselbe Adresse überwiesen, die Sie innerhalb von Sekunden nach der Finanzierung des Kontos gepostet haben - Ich war erstaunt, wie schnell die Schwachstelle gefunden wurde, aber nicht überrascht, dass sie ausgenutzt wurde!

Die Kommentare von Smarx weisen auf die Lösung hin, um den Zugriff auf Ihren lokalen Computer zu sperren: --rpcaddr 127.0.0.1und das Entfernen des --rpccorsdomain "*"Tags wird die Dinge gut sperren.

Wenn Sie Ihren Zugriffspunkt erweitern möchten, um Web3-Abfragen zu ermöglichen (z. B. das Hosten eines DApp-Frontends auf einem Server), und vorausgesetzt, Sie möchten einen oder mehrere lokale Knoten am Laufen halten und keinen Dienst wie infura.io verwenden, gibt es einige Möglichkeiten Problemumgehungen:

  1. Verwenden Sie Nginx (oder ähnliches) als Reverse-Proxy , um diesen Zugriffspunkt offen zu halten, aber nur auf autorisierte Parteien zu beschränken. Dies unterscheidet sich nicht wesentlich vom infura.io-Ansatz und die Sicherheit wird so gut sein, wie Sie es machen, abhängig von den angewendeten Authentifizierungsmethoden. Richten Sie Nginx so ein, dass Anfragen an Ihren Geth-RPC-Port weitergeleitet werden, und konfigurieren Sie Geth so, dass nur lokale Anfragen akzeptiert werden--rpcaddr 127.0.0.1
  2. Mit web3.js 1.0 können Sie Transaktionen remote signieren, sodass Sie einen Knoten ohne Konten online halten und ihn einfach verwenden können, um diese signierten Transaktionen direkt weiterzugeben, ohne dass über die HTTP-RPC-Schnittstelle ein externer Zugriff auf Ihre Konten möglich ist. Dies hindert niemanden daran, Ihren Knoten zum Lesen des Status zu verwenden und ihn möglicherweise mit einem DDOS-Angriff zu treffen
  3. ( sehr riskant, weit weniger sicher und nicht etwas, das ich empfehlen würde ) - halten Sie Ihre finanzierten Knotenkonten gesperrt und aktivieren Sie das personalTag in Ihrer RPC-Konfiguration, senden Sie dann web3.personal.unlockAccount(eth.accounts[0], "<password>")und web3.personal.lockAccount(eth.accounts[0])Anweisungen unmittelbar vor und nach allen Transaktionszeilen in Ihrem Code. Während Sie verhindern, dass Ihr Geld einfach von einem entsperrten Konto genommen wird, birgt die Aktivierung des personalTags seine eigenen Risiken, da Sie hier eine Tür für eine Reihe verschiedener Angriffe offen lassen
Sie sagten: "Während Sie verhindern, dass Ihr Geld leicht von einem entsperrten Konto genommen wird, birgt das Aktivieren des persönlichen Tags seine eigenen Risiken, da Sie hier eine Tür für eine Reihe verschiedener Angriffe offen lassen." Können Sie Informationen darüber geben, was diese verschiedenen Angriffe sind? Entriegeln und Verriegeln macht Mist, oder? Außerdem verwendet geth standardmäßig -rpcaddr 127.0.0.1. Reicht dies nicht aus, um sicherzustellen, dass alle Anforderungen lokal sind? Ich bin neugierig
Mit personalder Aktivierung auf einer öffentlich zugänglichen IP-Adresse lassen Sie eine Tür für Brute-Force-Angriffe auf Ihre Kontokennwörter offen, da eine böswillige Partei freie Hand hat, um so lange zu versuchen, Ihr Konto zu entsperren, wie sie möchte. Sie könnten auch eine beliebige Anzahl neuer Konten auf Ihrem Knoten erstellen und das Netzwerk unter anderem mit signierten Nullwerttransaktionen von diesen Konten spammen. Mir ist nicht 100% klar, wie Mist mit der Kontoentsperrung funktioniert - ich denke, es kann Transaktionen lokal signieren und dann nur die signierte Transaktion an den Knoten senden, aber ich könnte mich irren
Meist korrekt, außer wenn Sie angeben --rpccorsdomain "*", in welchem ​​Fall jede von Ihnen besuchte Website (in Javascript) eine JSON-Anfrage an localhost auf dem RPC-Port ausführen und Transaktionen initiieren kann usw., indem Sie in der Antwort, die Sie mitteilen, eine CORS-Platzhalterdomäne angeben Browser ist dies in Ordnung und Sie stimmen solchen Aktionen zu.
Ich habe selbst einige Versuche gemacht. Ich spezifiziere --rpcaddr 0.0.0.0 und --rpccordomain "<eine bestimmte IP-Adresse>". Meine ETH wurden trotzdem gestohlen. Daraus habe ich geschlossen, dass das ETH-Dieb-Skript nicht geschrieben wurde, um über ein Cross-Site-Skript zu stehlen. Ist das eine korrekte Ableitung?
Wenn Ihr Knoten ausgefallen ist oder Ihr RPC-Cors-Domänenfilter aktiv ist und läuft, könnte der Hacker theoretisch kein Geld abheben ... aber vielleicht war er schlau genug, ein Skript auf Ihrem Knoten oder so laufen zu lassen.
ETH auf Ropsten gestohlen
AntwortenHierDatenschutz-Bestimmungen1y, 0v