ETH robado en Ropsten

¿Alguien ha encontrado el siguiente escenario en Ropsten:

  1. Creas una cuenta en Geth y procedes a transferirte algo de ETH a través de un faucet.
  2. Desbloqueas la cuenta y procedes a comenzar a compilar y ejecutar contratos.
  3. De repente, descubre que todos sus ETH se han ido, transferidos a 0x6Ef57BE1168628A2bD6c5788322A41265084408a.

Esto me sucedió a mí y a un grupo de participantes durante un taller donde en cuestión de segundos, todos nuestros ETH fueron robados.

Si observa la transacción que se ha realizado en esta cuenta en Etherscan, se ejecuta a borbotones, con una cantidad pequeña y, a veces, bastante considerable de ETH transferida a sí misma.

Quería saber si esto es algo explicable. Me di cuenta de que la misma dirección 0x6Ef57BE1168628A2bD6c5788322A41265084408a también se encuentra en Rinkeby.

Quería mencionar que como esto era simplemente una prueba, ninguno de nosotros aseguró nuestra instancia de Geth. Este fue el comando que ejecutó la instancia: geth --testnet --syncmode "light" --rpc --rpcapi db,eth,net,web3,personal,admin --cache=1024 --rpcport 8545 --rpcaddr 0.0. 0.0 --rpccorsdominio "*
¿Qué sitios web visitó mientras la cuenta estaba desbloqueada? Con esa configuración de RPC, cualquier sitio web que visite podría tomar los fondos.
Solo etherscan. Todos ingresamos nuestra identificación de cuenta en etherscan para monitorear nuestras transacciones. Sé que la configuración de RPC no era segura, pero me interesa saber cómo se puede escribir un script para rastrear la cadena de bloques en busca de geth no seguro para robar ETH y cómo lo hizo.
Parece poco probable que Etherscan sea el culpable. Para cualquier otro sitio web, son solo unas pocas líneas de código: new Web3('http://localhost:8545')y luego una llamada web3.eth.getAccountspara encontrar las cuentas y luego web3.eth.sendTransactionenviar ether.
Tampoco tiene que ser un sitio web... el software de su computadora o quizás el de cualquier otra persona en el taller podría hacer lo mismo. No hay nada particularmente difícil en hacerlo.
Suponiendo que deseo hacer 2 cosas: 1) tener una billetera mist conectada a mi instancia geth en la nube 2) ejecutar transacciones localmente desde la misma máquina en la nube, ¿cómo debo escribir la línea de comando geth para asegurarla?
Soy la persona equivocada para responder eso. Creo que --rpcaddr 127.0.0.1y deshacerse de --rpccorsdomainellos es un buen comienzo.

Respuestas (1)

Encontré exactamente la misma situación en una red privada cuando dejé una cuenta desbloqueada en un nodo con una dirección IP pública para ver qué sucedía: todos los fondos se transfirieron a la misma dirección que publicó segundos después de que se financiara la cuenta. Me sorprendió lo rápido que se encontró la vulnerabilidad, ¡pero no me sorprendió que se aprovechara!

Los comentarios de Smarx indican la solución para bloquear el acceso a su máquina local: --rpcaddr 127.0.0.1y eliminar la --rpccorsdomain "*"etiqueta mantendrá las cosas bien bloqueadas.

Si desea ampliar su punto de acceso para habilitar las consultas web3 (como alojar una interfaz DApp en un servidor) y suponiendo que desea mantener un nodo local en ejecución y no utilizar un servicio como infura.io, hay algunos posibles soluciones alternativas:

  1. use Nginx (o similar) como un proxy inverso para mantener ese punto de acceso abierto, pero limítelo solo a las partes autorizadas. Esto no es muy diferente del enfoque de infura.io y la seguridad será tan buena como usted lo haga, según los métodos de autenticación aplicados. Configure Nginx para reenviar solicitudes a su puerto RPC geth y configure geth para aceptar solo solicitudes locales con--rpcaddr 127.0.0.1
  2. web3.js 1.0 le permite firmar transacciones de forma remota para que pueda mantener un nodo en línea sin cuentas y simplemente usarlo para propagar esas transacciones firmadas directamente, sin posibilidad de acceso externo a sus cuentas a través de la interfaz HTTP-RPC. Esto no impide que nadie use su nodo para leer el estado y potencialmente atacarlo con un ataque DDOS.
  3. ( muy arriesgado, mucho menos seguro y no es algo que recomendaría ): mantenga sus cuentas de nodo financiadas bloqueadas y habilite la personaletiqueta en su configuración de RPC, luego envíe instrucciones inmediatamente antes y después de cualquier línea de transacción en su código web3.personal.unlockAccount(eth.accounts[0], "<password>"). web3.personal.lockAccount(eth.accounts[0])Si bien evita que sus fondos se extraigan fácilmente de una cuenta desbloqueada, habilitar la personaletiqueta conlleva sus propios riesgos, ya que deja una puerta abierta a una serie de ataques diferentes aquí.
dijiste: "Si bien evita que sus fondos se extraigan fácilmente de una cuenta desbloqueada, habilitar la etiqueta personal conlleva sus propios riesgos, ya que está dejando una puerta abierta a una serie de ataques diferentes aquí". ¿Puede proporcionar información sobre cuáles son esos diferentes ataques? Desbloquear y bloquear es lo que hace la niebla, ¿no? También, por defecto, geth usa -rpcaddr 127.0.0.1 ¿no es esto suficiente para asegurarse de que todas las solicitudes sean locales? soy curioso
Con personalhabilitado en una dirección IP disponible públicamente, está dejando una puerta abierta a los ataques de fuerza bruta en las contraseñas de su cuenta, ya que una parte malintencionada tiene rienda suelta para seguir intentando desbloquear su cuenta todo el tiempo que desee. También podrían crear cualquier cantidad de cuentas nuevas en su nodo y enviar spam a la red con transacciones firmadas de valor cero de esas cuentas, entre otras posibilidades. No tengo 100% claro cómo funciona Mist con el desbloqueo de cuentas. Creo que puede firmar transacciones localmente y luego solo enviar la transacción firmada al nodo, pero podría estar equivocado.
Mayormente correcto, excepto si especifica --rpccorsdomain "*", en cuyo caso cualquier sitio web que visite puede (en javascript) realizar una solicitud JSON a localhost en el puerto RPC e iniciar transacciones, etc. especificando un dominio CORS comodín en la respuesta que le está diciendo al navegador, esto está bien y usted aprueba tales acciones.
Hice algunas pruebas por mi cuenta. Especifico --rpcaddr 0.0.0.0 y --rpccorsdomain "<una dirección IP específica>". Mi ETH todavía fue robado. A partir de esto, deduje que el script de ladrón de ETH no fue escrito para robar a través de un script de sitios cruzados. ¿Es esta una deducción correcta?
Si su nodo está inactivo o su filtro de dominio rpc cors está funcionando, en teoría, el hacker no podría sacar dinero... sin embargo, tal vez fue lo suficientemente inteligente como para dejar un script ejecutándose en su nodo o algo así.
ETH robado en Ropsten
RespuestasAquíPolítica de privacidad1y, 1v