小心那些利用Etherscan招摇撞骗的人

去中心化金融社区｜2022-03-07 15:24

区块链索引服务依赖于合约事件来帮助归档数据，并在一个漂亮的用户界面中给我们提供交易记录，其通常被称为“区块浏览器”，比如Etherscan。但恶意合约可以表现得无比“正常”，却会污染这些事件，从而欺骗区块浏览器，向毫无戒备的用户提供关于代币来源的误导性信息。例如，恶意用户可以部署一个简单ERC20

区块链索引服务依赖于合约事件来帮助归档数据，并在一个漂亮的用户界面中给我们提供交易记录，其通常被称为“区块浏览器”，比如Etherscan。但恶意合约可以表现得无比“正常”，却会污染这些事件，从而欺骗区块浏览器，向毫无戒备的用户提供关于代币来源的误导性信息。

例如，恶意用户可以部署一个简单ERC20合约和“空投”代币给一群用户，在自动做市商上创建一个看起来健康的流动资金池，等待用户根据错误的宣传购买或出售代币，认为此代币是已知开发人员/实体的一部分。

分解

ERC20代币(它是代币接口的通用标准)是合约的属性、函数、输入、输出和事件的集合。只要我们的合约具有正确的函数特征，我们就可以在这些函数中使用自定义逻辑——即使是提供不正确数据的函数。

例如，如果合约部署者发送一个代币，我们可以让一些/所有区块浏览器向最终用户（在某些视图中）显示不同的地址。假设如下；

合约部署者是有恶意的，想要为他们的代币制造一些炒作。代币在AMM中有一些流动性(如Uniswap)供用户购买/出售，主要的流动性提供者头寸属于代币背后的团队。许多用户都知道发送者，而不是某个随机的地址。

这不仅仅是ERC20的问题……受污染的数据可以被插入到任何代币标准事件中，如NFT (ERC721, ERC1155)，以迷惑用户和潜在投资者，让他们认为项目有特定的利益方/影响者，而实际上并没有。

这个问题并不“新鲜”，但我们写这篇文章是为了强调正在发生的事情，以及用户在“模仿”“看起来合法”的项目之前应该做些什么。

当区块浏览器看到交易发出的事件时，他们将其记录在他们的链下数据库中，并与其他数据建立关系，这样他们就可以建立一个很好的交易关系图，在他们的UI中显示给终端用户。

概念验证

我们将部署一个概念验证合约，使用一个老版本的 Solidity，同时也要证明它与任何Solidity版本或以太坊中的任何东西都没有问题，其是一个来自链下应用程序信任合约的信任问题。一般来说，对事件的继承信任是“正确”的，它是一种合约将可用数据提供给链下程序进行索引的方式。

在上面的合约(位于0x3afe99bd92b1aed3237196b26743681766d4940e)中，我们修改了逻辑，将 Transfer 事件中的发送者地址更改为流行区块浏览器上标记为“OpenSea：Wallet”的地址，前提是我们（创建合约的人）发送代币。

它所做的是，当区块浏览器索引该事件时，它从Transfer事件中看到地址为0x5b32…1073发送了代币，而不是实际的发起者0x11b6…04C9，这可能导致该方法被不良行为者利用，诱使用户认为;

一个受欢迎的人物在代币上有既得利益一个受欢迎的人物正在“卸载”大量的代币代币是合法的，因为在区块浏览器上，它显示了已知的实体与代币合约“交互”

让我们从合约部署者地址调用transfer()，看看区块浏览器索引了什么。我们只是将代币从我的地址(0x11b6…04C9)移动到一个目标地址(0x4bbe…1520)。

“OpenSea: Wallet”ERC20活动视图显示它似乎已经发送了一个名为OpenSeaRevenueShare的代币到目的地。

交易表明(在“token Transferred”中)“OpenSea: Wallet”将代币发送到目标地址。

目标地址显示“OpenSea: Wallet”给他们转移了10个代币。

寻找什么？

大多数这样的以利用用户的恶意合约都没有被“验证”，又因为我们只能接触到区块浏览器上的字节码，如果事件被污染了不良数据，再基于某些条件，都很难让用户进行验证，就像我们的概念验证一样。如果合约没有被验证，比如我们无法看到Solidity/Vyper/...代码，并且只暴露于字节码，那么在与合约交互之前，我们应该采取预防措施。

如果一个代币被“空投”给我们或其他实体，我们应该谨慎，特别是当我们试图在DEX上清算代币时，因为过去有一些事件是利用人为制造价格的方法从窃取的。