According to the SlowMist intelligence zone, Premint was attacked by hackers on July 17th. We immediately started our investigation and alerted the community via twitter.
This article contains submissions from Scam Sniffer, who is a partner of the SlowMist Zone. The specific analysis of the attack is as follows:
Attack Details
When opening a project page on Premint, we can see that cd.min.js has been injected into the page. Not the call stack, a js created by [boomerang.min.js](https://s3-redwood-labs.premint.xyz/ theme/js/boomerang.min.js), where the domain name s3-redwood-labs-premint-xyz.com has stopped parsing and was unable to be accessed normally.
When we query Whois, a domain name that was registered with Tucows Domains Inc on 07–16–2022:
Opening virustotal.com, you can see that the domain name has been previously resolved on CloudFlare:
Looking at the source code, we notice that boomerang.min.js is a UI library that was used by Premint:
The js is under the s3-redwood-labs.premint.xyz domain name, so we assume:
- That a vulnerability in the upload file interface exists, which allows any file to be uploaded to any Path (a common web vulnerability)
- Hackers were able to inject malicious code after gaining access to their Amazon S3
- This 3rd party library was corrupted through a chain attack
Downloading the boomerang.min.jjs code, we notice that the front end displays normal coding, however there is an encrypted layer of code at the end:
This is the code responsible for injecting the code ‘s3-redwood-labs-premint-xyz.com/cdn.min.js into the page:
Malicious code - cdn.min.js
According to the code’s contents, it can be seen that the NFT assets of the user have been queried by calling the interface of dappradar.com (we’ve also seen malicious websites query user assets through Debank, Opensea’s API, etc. in the past).
Here’s what happens If a users holds the relevant NFTs:
Users were tricked into approving malicious contracts under the pretext of two-step wallet verification. By clicking approve, users initiate setApprovalForAll and authorize users to the address returned by their back-end interface (attackers generally do this in order to increase the cost of blocks, they will basically divert and control each address within 200 transactions).
Once someone approves the function, the attacker will also call the monitoring code to inform himself that someone has approved the function:
If the user’s doesn’t have any NFTs, it will try to initiate an token request directly and transfer any ETH that may be in the wallet:
In addition to all of this, this method of encrypting the code variable name to start with _0xd289 _0x has been seen on other phishing websites such as play-otherside.org and thesaudisnfts.xyz.
Initiation of the ‘setApprovalForAll’ will transfer ETH directly based on the users assets, and prevents any users from using developer tools to debug these issues:
Preventative Method
So how can this be prevented for the ordinary user? At the current stage, the risk warning for MetaMask’s ERC 721’s ‘setApprovalForAll’ is inferior to ERC20.
Even if users are unable to comprehend the risk of this type of behavior, as an average user it’s still important to be careful when interacting with any unknown contracts, especially when viewing transactions that involve ‘Approve’. It’s also important to check whether the recent transactions of those addresses contain any abnormal activity (such as ‘safeTransferFrom). Always double check before authorization for any transactions!
This kind of attack was similiar to one where Coinzilla used ads to inject malicious attacks on Etherscan, so we ask ourselves, is this preventable?
For example, behavior and characteristics of some malicious js code that are known:
- The encryption method used in the code
- Any code key characteristics that are malicious
- Debugging of the code
- The use of call on opensea, debank, dappradar and other APIs to query user assets
Based on the behavior methodology of these malicious codes, we can try to detect whether a page contains code with any known malicious features before a user initiates a transaction. Or, simply set up a mechanism for whitelisting websites. Also be cautious of sites that automatically initiate authorization without any warnings or risks.
Ps. A big thank you to Scam Sniffer for this analysis.
