我骗了自己——汉堡包被窃听了

雍和比特币 慢雾安全团队主张 DApp 开发者在移植其他协议的代码时，需充沛了解移植协议的架构，并充沛考虑移植协议和本身项目的兼容性，且需通过专业安全审计组织的审计后才上线，避免资金丢失状况的产生。 作者：于丹@慢雾保安队据慢雾区域音讯，2021年5月28日，币安智能链（BSC）defi项目遭到黑客进犯，形成330万美元丢失。慢雾安全小组初次参加剖析，共享成果如下：进犯细节剖析Burgerswap是uniswap AMM项目的仿制品，但它不同于uniswap体系结构。交流体系结构一般分为[托付-gt；lpPlatForm-gt；Pair】。托付层办理一切Pair信息，并担任创立lpplatform层。然后lpplatform层创立相应的pair contract。在整个体系结构中，渠道层充任uniswap的路由器，担任将核算出的业务数据和要交流的令牌转发给pair contract完结交流。此事情的本源是此体系结构的问题。通过逐渐剖析进犯者的买卖行为，能够复原整个进犯进程的中心这次突击始于pancake的闪电借款。进犯者从pancake借用很多wbnb，然后通过burgerswap传递这些wbnb；变成汉堡代币。完结上述操作后，进犯者通过托付层用自己的token（进犯契约本身）和burger token创立一个业务对，并添加流动性，为后续进犯做预备。创立和预备令牌后，进犯者当即通过paltform层的swapexacttokens for tokens函数发动交流。交流途径是[由进犯者操控的令牌-gt；汉堡-gt；WBNB】接下来，履行最要害的操作。因为前一个进犯者在创立业务对时使用了自己操控的令牌，因而在令牌交流进程中， the innertransferfrom函数调用进犯者操控的令牌契约，因而进犯者能够在innertransferfrom函数中，从头输入swapexactTokens for tokens函数。进犯者为什么要这样做？通过对渠道层swap exacttokens for tokens函数的代码剖析，不难发现契约在调用innertransferfrom函数时，先核算用户的交流数据，然后在操作innertransferfrom函数后调用，预先核算的数据被转发到底层进行真实的令牌交流。从这个函数的视点来看，即便进犯者从头输入swapexacttokens for tokens函数，底层swap函数也是独立的。乍一看，没有问题，但链条上的一个行为却引起了慢雾安保团队的留意咱们惊奇地发现，在再入交流进程中，交流量并没有因为滑动点而削减。原因是什么？好像要害是潜在的配对契约问题。咱们进一步剖析了底层调用的pair contract，代码如下：通过剖析pair的代码，咱们惊奇地发现，在交流进程中，合约没有依照常数积公式查看交流后的价值！！也就是说，pair契约彻底依赖于渠道层的数据进行交流，导致了这一事情的产生。因为pair层本身不校验常数积，在重入时预先核算渠道层交流数据，innertransferfrom函数完结后，pair的更新数据不反映在渠道层。因而，买卖地点再入买卖中产生的滑动点不影响下一个买卖所，形成丢失。图片如下：总结此进犯归于交流体系结构问题。pair层彻底信赖paltform层的数据，不会再次查看，然后导致进犯。近年来，defi安全事情频发。针对DAPP进犯日益密布的现状，slow fog安全团队主张DAPP开发者在移植其他协议的代码时，应充沛了解搬迁协议的架构，充沛考虑搬迁协议与本身项目的兼容性，而且只要通过专业的安全审计组织审计后才干上线，以避免资金丢失的产生。