Phising 3.0 y tx.origin 

Los ataques de phishing se han convertido en una preocupación importante en el mundo digital, y es esencial tomar medidas para protegerse contra ellos. En la industria del blockchain, Solidity es el lenguaje más popular para desarrollar contratos inteligentes, pero también es vulnerable a los ataques de phishing. En este artículo, explicaremos cómo funciona tx.origin y cómo puede utilizarse para ejecutar ataques de phishing. 

Si hay múltiples invocaciones de funciones a lo largo de diferentes contratos en cierta cadena de transacciones, tx.origin siempre se referirá al EOA (externally owned address) que la inició, sin importar la pila de contratos involucrados, mientras que msg.sender se referirá a la última instancia (EOA o contrato inteligente) desde la que se llamó a cada función en esa cadena de transacciones. 

Un ejemplo podría ser útil para entender esto más claramente. 

Supongamos un escenario en el que hay un EOA que inicia una transacción hacia el contrato A, cuya ejecución implica la invocación de una función del contrato B. Desde la perspectiva del contrato A, el EOA sería el tx.origin y el msg.sender de la primera invocación. Sin embargo, mientras que el contrato B seguirá viendo al EOA como el tx.origin , verá al contrato A como el msg.sender de su invocación al método. 

En los ataques de phishing que utilizan tx.origin, el contrato atacante engaña al propietario de un contrato vulnerable para que realice acciones que sólo los propietarios deberían poder realizar. 

El atacante podría ser un contrato disfrazado de monedero en el que el método receive() incluye algún código malicioso. Así, si el propietario del contrato vulnerable (EOA atacado) envía tokens a este contrato malicioso, podría terminar invocando algún método crítico donde tx.origin se utiliza para comprobar la validez del llamante. De esta forma, el atacante tendría éxito ya que tx.origin se referiría al EOA atacado, impidiendo que el contrato vulnerable revierta ya que nunca sabría que en realidad está siendo invocado por un contrato inteligente y no por el propietario. Esto puede resultar en el robo de fondos, claves privadas u otros datos sensibles. Para prevenir dichos ataques recomendamos este artículo de nuestro blog. 

Vía Un informático en el lado del mal