PREMINT攻击事件全解析

　　7月17日16：00（UTC8），premint。xyz遭遇黑客攻击，部分用户的NFT失窃。攻击事件发生后，GoPlus安全分析师迅速对其进行了全面解析，并从普通投资者和开发者两个角度给出了安全建议。攻击过程攻击者通过在premint。xyz网站中通过植入恶意的JS脚本进行攻击，当用户进行常规操作时，执行恶意代码，欺骗用户对授权操作setApprovalForAll（address，bool）的交易进行签名。骗取到授权后，盗取用户的NFT等资产。攻击原理当用户访问https：www。premint。xyz时，网站将加载如下js资源文件https：s3redwoodlabs。premint。xyzthemejsboomerang。min。js。
　　此文件被黑客注入了一个script脚本，该脚本加载了另一个托管在属于黑客的假域名（s3redwoodlabspremintxyz。com）中的攻击脚本文件https：s3redwoodlabspremintxyz。comcdn。min。js？v1658050292559。此脚本含有骗取用户授权的交互（目前已无法访问了）。当用户进行常规的Verifyingyourwalletonwership签名（也就是签名登陆）操作时，此脚本将被触发，将原有的验证签名代替为一笔授权攻击者可转移用户高价值NFT的交易。一旦次交易被签，资产将会失窃。（注：攻击脚本也可能会视情况骗取用户的ERC20token授权，由于脚本已无法访问我们当前无从得知。）防不胜防本次攻击对于普通用户来说，可能是最不好对付、最容易中招的。攻击的全部C端交互都在Premint的官方网站中，首先就很容易让大家放松警惕，因为大家总是默认官方网站是没有任何问题的。骗取交易签名的过程发生在正常操作的签名验证过程中，由于多数用户不会去看钱包的签名详情（大部分用户不了解如何判断签名是否安全，同时出于对官方的信任而极为容易忽略这一步可能存在的风险），所以攻击过程极为隐蔽。漏洞在哪里大家可能会奇怪，为什么Premint的官方网站还会出现攻击代码，这是因为托管的S3（AWS的对象存储服务）上的js资源文件被黑客侵入遭到篡改。至于为什么会被入侵，根据现有的资料，我们怀疑是S3配置出现错误，导致了Bucket未授权访问，使得攻击者可以随意列出、读取或者写入S3bucket，从而对js资源文件进行篡改。整个过程中最为令人不解的是，黑客的攻击行为在17日16：00（UTC8）就被发现，但直到17日22：00（UTC8）之前，Premint官方依然没有对被攻击的js文件进行归正，boomerang。min。js文件中仍然包含被黑客注入的恶意script，页面载入时仍然会去加载黑客的攻击脚本文件，只是这段恶意script本身已经无法访问了（攻击域名s3redwoodlabspremintxyz。com已无法访问）。这种状态维持了6个小时，很难判断如果此时该脚本复活，会不会引发更大的损失。
　　启示
　　启示1：作为普通投资者我们该怎么办？如果官网都不可靠了，如何避免上当受骗？本次攻击对于很多不了解技术的用户来说，基本可以说是初见杀，百分百中招，毕竟谁也不会无端怀疑官网有诈。但仔细想想，所有链上的交易都必须通过钱包的签名，所以只要注意签名内容还是可以识别出其中风险的。很多区块链用户都有个非常不好的习惯，只要操作进入到钱包中，除了调gas的过程，其他步骤都是下意识操作。实际上签名前的确认信息包含着大量关键内容，GoPlusSecurity建议大家进行任何签名操作前都必须仔细确认。以此次攻击为例。当用户对Premint进行签名验证时，由于只是进行信息验证，没有任何上链的必要，所以发起的SignatureRequest应只包含Origin信息（请求方），用户的地址，Nounce信息，可能有一些附加返回信息。如下图（由于https：www。premint。xyz已经暂时offline，我们以Opensea为例）：
　　但对于被注入攻击后遭到篡改的交易签名，由于须要将交易上链，交易将会以合约调用的形式呈现出更多的信息。例如在一个使用setApprovalForAll的NFT授权中，会显示出这笔交易是在哪进行的（图中为etherscan），调用了什么方法（setApprovalForAll），授权对象是谁，消耗多少ETH。
　　回过头来，我们根据网友贡献的截图可见，Permint被注入攻击后，虽然操作提示的是验证签名，但是实际拉钱包签名的交易完全是上链的setApprovalForAll，完全与上图相符，稍加观察就能知道此处是有问题的。
　　实际上，合约各类调用、转ETH（或其他原生币）、转Token等，在钱包中签名信息都是不同的，所有投资者都应该了解其中的差异，以免遭到此类攻击时产生损失。在此GoPlusSecurity非常建议大家再亲自模拟一下操作过程，了解各种不同的签名信息（只要交易不发出去就不会产生任何费用，没有任务学费），一旦学会看签名信息，你将基本上规避掉几乎所有钓鱼、注入、欺诈攻击。不要懒惰，想要保证自己的安全，学习是唯一的途径。
　　启示2：作为开发者我们该怎么办？如何避免被注入攻击？此次攻击对于开发者最大的启示在于，web3。0世界既然无法脱离web2。0独立存在，那就必然会承受和web2。0一样的攻击方式。仅仅在合约层面保障自己的安全是不够的，所有传统的安全准备一样都不能落下，任何一个小的疏忽都可能造成重大损失。另外，遇到此类问题后应马上修复或者隔离，倘若存在侥幸心理，没有第一时间处理风险源，被安全分析师扒皮嘲讽是小事；万一攻击手段还可用，损失可是会持续产生的，这可是大事。