Alchemix事件分析：最长的路要走就是你自己的常规

作者：于丹@慢雾保安队

据慢雾地区消息，2021年6月16日，以太坊 DeFi项目alchemix的alETH合同被怀疑存在安全问题。17日，alchemix发布事故分析报告，慢雾安全小组迅速介入分析。在官方分析报告的基础上，梳理了事件的整体脉络和重点，供大家参考。

太长了，不能看连续剧

这篇分析文章很长。让我们从结论开始，这样我们才能有一个大致的了解。这起事故的主要原因是alchemix通过Tranuter添加了三次故障，导致收入信息记录在错误的元件上。调用Tranuter的harvest函数时，没有传入正确的索引值，导致通过错误的元素获取错误的收入，并将错误的4300ETH收入发送给适配器合同，帮助用户偿还alETH的贷款，导致收入增加的问题，导致悲剧的发生。

第一轮核心分析

根据官方的事故分析报告，此次事故的原因是官方的alETH部署脚本意外地产生了额外的故障，导致；Alchemix公司；使用了vaults数组中的错误索引并计算了错误的奖励，这导致Tranuter使用所有奖励来偿还用户的所有债务。我知道这个简短的分析有点混乱，所以我们只能把重点放在官方的交易上，看看能不能找到真相。

根据官方事务，通过分析工具ETHtx.info不难发现，该事务调用了alchemisETH contract的harvest函数，并传入了参数vaultid=0返回

“4308144937764982868765”和“4308144937764982866415”。

为了更好地理解收获函数的功能，需要对收获函数的整体功能进行分析

不难发现收获函数实际上包含两个重要的操作，即收获报酬和将报酬分配给转化者契约。vault是一个库合同，收获逻辑实现如下：

通过代码分析不难发现，金库库合同的收获函数实际上是检查外部适配器的资金总量，然后根据适配器中的资金量减去用户充值次数计算收入。

在这里，我们可以将这个适配器理解为一个策略池，用于管理用户的资金和利益。然后我们返回到alchemisETH合同中用户开始时的收获函数，发现返回的“4308144937764982868765”；以及；

“4308144937764982866415”这两个值实际上对应于要提取的代币数和从适配器（策略池）检索的代币数，这些代币数是由保险存储合同的收获函数计算的。由于与此适配器对应的代币的精度为18位，因此“4308144937764982866415”；此值转换为“4308.144937764982866415”；潮湿的天气。

也就是说，这个收获操作将产生超过4300 ETH的收入，这些收入将在下一步中传递，DistributeTommuter功能将给Tranuter合同进行分配。让我们看看分发过程的逻辑

_DistributeTranuter函数的逻辑只有三条简单的线。我们主要关注**一个外部调用，lowerhashminated函数。与此函数对应的xtoken在这里指的是alETH本身。因为亚力士本身是由用户通过贷款发放的，所以这里所说的lowerhashmited的操作实际上是利用收获的收益来减少亚力士发放贷款的总量，从而减少每个用户的贷款。综上所述，就是用嘉实4300 ETH的收益来偿还用户的贷款。

让我们做个总结

我们先来总结一下这个过程，即Alchemy士合约通过收获函数获得4300ETH的收益，然后分配收益来偿还用户的贷款，这就导致了我们看到的情况——贷款给了alETH的用户可以在不还款的情况下取回其抵押的ETH。毕竟，为什么会有4300 ETH的利润？额外的4300 ETH是怎么来的？为了解决这个问题，我们开始下一轮分析。

第二轮核心分析

要理解为什么要增加4300以太，我们必须了解Alchemy士的资本储存过程。在Alchemy士合同中，使用金库库的数据结构记录合同的总充值，然后通过flushactive金库功能更新相应的总存款。

然后，depositall函数将键入充值到相应适配器（策略池）的代币量。在下一次收获中，通过适配器（策略池）获得的总价值将是用户的本金加上策略池的收入。为了计算收益过程中的主体，我们调试了官方交易，发现本金只有9000 ETH，适配器加上本金的收益是13000 ETH，也就是说，9000 ETH的本金产生4300 ETH。

不过，按照上述分析的逻辑，用户的本金不会产生那么多收入。问题必须是适配器获得的总值。也就是说，适配器不仅有Alchemy士充值代币，还有其他收入渠道。为了验证我们的想法，慢雾安保团队对适配器的所有代币收入进行了分析，发现了一个异常的转入行为，金额刚好可以匹配4300 ETH的收入。也就是说，这就是问题所在。

通过查看事务数据，可以发现这是一个调用收获操作的事务，而调用的契约是一个Tranuter契约

换句话说，收获函数有问题。收获函数的逻辑如下：

又叫金库的收获函数，熟悉的公式，熟悉的味道。我们再次调试，发现了一个惊人的事实-在产生收入时，金库的总存款为0，这导致4300 ETH的收入直接分配给；适配器，导致适配器获得的totalvalue出错，增加4300 ETH。这就是为什么。

到目前为止，我们已经非常接近真相了。我们唯一要解决的是为什么存款总额是0？我们检查了Tranuter合同，在合同中我们可以更改总存款，发现只有plantorrecallexcessfunds函数可以更改此值，此函数的上层调用distribute函数。转化者契约的分配函数在收益时被Alchemy士契约调用。换句话说，过程本身应该是：

1.Alchemy士合同召唤收获来创收

2.炼金合同调用Tranuter合同的distribute函数来记录收入并将收入交给适配器

3.适配器从Tranuter获得收入，并根据收入偿还alETH的贷款

但问题是Plantorrecallexcessfunds函数。因为在记录充值信息时，我们使用 Last（）获取**的保险库，所以充值信息会叠加在**一个元素上。但是项目方调用了三次setactivevault函数，所以充值信息被叠加在了vaults数组的第三个元素上，即索引为2的vault元素上。但是Tranuter合同是在harvest时传入的，vaultid为0。元素0没有充值记录，所以Tranuter合同错误地把所有收入都给了适配器。这导致了悲剧。

总结

在这一点上，整个事情变得非常清楚。由于某种原因，alchemix项目方通过Tranuter添加了三次故障，导致收入信息记录在错误的元素上。调用Tranuter的收获函数时，没有传入正确的索引值，导致通过错误的元素获得错误的收益，错误的收益被发送到适配器契约，导致收益的增加和悲剧。

慢雾安全小组提醒我们，DeFi是一个复杂的系统。在执行DeFi操作时，我们应该记住检查业务逻辑中的每个流程，以防止发生意外。必要时，我们可以联系专业的安全团队进行专业的安全审核，以防止事故的发生。

[参考链接]

官方事故分析报告：

https://forum.alchemix.fi/public/d/137-incident-report-06162021

收入计算错误事务处理：https://ETHerscan.io/tx/0x3cc071f9f40294bb250fc7b9aa6b2d7e6ca5707ce4d6d222157d7a0feef618b3