Streaming Protocol contest - itsmeSTYJ's results

Handle

itsmeSTYJ

Vulnerability details

Impact

Some projects might rely on tx.origin to remove the need for calling approve() for their token. When these tokens are used as a deposit, reward or incentive token, it is possible to steal these funds by sending in a malicious token that calls the vulnerable token internally.

Stream creators who cannot read code are more susceptible to this attack as they are not aware that the token is using tx.origin instead of msg.sender.

Proof of Concept

• Vulnerable token (A) used as deposit token.
• Many users deposit token A
• User creates malicious token (B) which calls A.transfer() inside of B.transfer().
• User sends in a malicious token (B) and requests (or even pays) the stream creator to help retrieve these funds for them.
• When the stream creator calls recoverTokens(B, attacker), it will send back B to the attacker but at the same time, it will also steal all of A.

Here's an article of the rune token being attacked. https://www.adrianhetman.com/unboxing-tx-origin/

Recommended Mitigation Steps

• I think there's no way to prevent this at a smart contract level so my recommendation is that on the UI level, suggest tokens to the stream creators by allowing them to choose from a dropdown list e.g. token lists
• If they still wish to use a custom token, you can have a second prompt to remind them to check that the token does not use tx.origin.