Soy nuevo en seguridad de ICO y contratos inteligentes. Tratando de encontrar errores en los contratos verificados. Creo que encontré algunos problemas en 0x42dB5Bfe8828f12F164586AF8A992B3a7B038164 pero no sé cómo retirarlo. ¿Necesito crear una transacción por mí mismo?
Jaja - muy astuto.
Para cualquiera que tenga la tentación de meterse con este contrato , es decir, explotar la falla aparente: es probable que pierda su Ether.
La explicación sigue.
Parece que hay una vulnerabilidad bastante tentadora en la withdrawal()
función: cuando envía la función más que Limit
Wei, le enviará el saldo total del contrato: la cantidad que envió más los 0,36 Eth que ya están allí. Beneficio instantáneo!
Sin embargo , existe este aspecto inocente, pero no obstante peculiar delegatecall
de una logEvent()
función en un contrato diferente. Para acortar una larga historia, esto no registra un evento. En realidad, modifica furtivamente el valor de la adr
variable de almacenamiento para que ya no apunte a msg.sender
. Por lo tanto, el saldo del contrato no le será devuelto por la adr.send(this.balance)
llamada, sino que se enviará a otro lugar, ya adr
que ya no es igual a msg.sender
.
Está un poco ofuscado, pero parece que la llamada delegada a la email.logEvent()
función del contrato hace adr
que se establezca en la propia dirección del contrato: es decir, envía todo el Ether (incluido el que envió) a sí mismo. Solo el propietario del contrato (0x46Feeb381e90f7e30635B4F33CE3F6fA8EA6ed9b) puede retirar el Eth.
email
contrato está aquí . Simplemente copie y pegue el código de bytes en cualquier herramienta de implementación que utilice. Luego debe cambiar la dirección en el otro contrato para que apunte a la nueva dirección de email
. Uso un descompilador que escribí y muchos garabatos en pedazos de papel para analizar las cosas. Remix es bueno si hay un Tx existente para rastrear, pero no lo había en este caso.
Richard Horrocks
willjgriff