The Impact of Phishing on Web 3.0

How to keep your smart wallets safe

Published in

GnosisDAO

5 min readMar 13, 2020

Phishing has always been an easy way to trick users into exposing private information. There are many recommendations¹ on how to avoid these tricks, but usually these suggestions protect against known attacks for web 2.0 — not web 3.0.

In actuality, with web 3.0, best practices against phishing become even more critical than ever before. When the user trusts a malicious website, it is the next worst thing after getting their private keys compromised. When a user starts out using a DeFi app, it usually requires a token approval call, meaning a confirmation that a target contract in the app can make use of an unlimited amount of a specific token in the user’s wallet. If the user does not verify what address is used for the approval, their funds might be at risk.

Most wallets decode these standard contract interactions, such as the token approval call. MetaMask even allows you to adjust the token approval amount to avoid that you approve an unlimited amount of funds. However, smart contracts are very flexible and not every contract interaction can be decoded. When you add smart contract wallets such as the Gnosis Safe into the mix, this becomes even more complex.

A recent blog post by OpenZeppelin mentions just such a scenario, where a malicious website is used to deploy a misconfigured Gnosis Safe. The data used to trigger this deployment is extremely complex. Without using more technical tools, it is nearly impossible to understand what is going on. The following is the hex data for a simple Gnosis Safe with 3 owners. For technical users, it might be possible to understand the data partially, but this is not feasible nor desirable for an average user.

0x61b69abd00000000000000000000000034cfac646f301356faa8b21e94227e3583fe3f5f000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001a4b63e800d0000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000180000000000000000000000000d5d82b6addc9027b22dca772aa68d5d74cdbdf440000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000000000000000000000000dcbeffbecce100cce9e4b153c4e15cb88564319300000000000000000000000032565cd5562a4f10462cbfc27d126d365a74634c0000000000000000000000009c28f1bb95d7e7fe88e6e8458d53be127cc2dc4f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

To avoid this scenario, you should employ the same best practices against phishing that you normally would with web 2.0 applications, such as online banking, and be sure to check URLs and security certificates. We also strongly recommend that you only use trusted interfaces that perform additional offline checks and manage deployments and integrations. An example of this would be using the canonical Gnosis Safe mobile application available in app stores.

However, as mentioned in the OpenZeppelin blog post, we felt that this approach is a limited way to access a trusted Gnosis Safe instance. That’s why we deployed a simple Safe factory² to fix this for users. This factory creates a Safe (Version 1.1.1) with one owner, being the account that triggered the transaction. And the only thing that the user needs to do is to send a transaction to the factory address 0x1337A824F3131c718b7a336E18CADb4BA0faffFc. If you send some ETH along with the transaction, it will be deposited to your newly created Safe. To be sure that you use the correct factory, check the Identicon and the address, or simply use the ENS name factory.safe.eth, which will always point to the secure factory for the latest version. A tutorial at the end of this post goes over how to do this in just a few easy steps.

Please be aware that a trusted Gnosis Safe setup is only the first step in securing your account against phishing. You need to make sure that you closely pay attention to every transaction performed with your Safe. For this, we recommend using our web app www.gnosis-safe.io/app/. There you can easily create and review transactions, as well as check your current Safe configuration, such as owners and required signatures.

Transaction decoding is an important topic within the Ethereum development ecosystem, and there are many interesting, related initiatives. Here are some recommendations to learn more:

Factory Contracts Release

https://github.com/gnosis/safe-factories/releases/tag/v1.1.1

Identicon (visual ID) and address info:

Blockies Identicon and address of factory: 0x1337…ffFc

MetaMask Identicon and address of factory: 0x1337…ffFc

Contract Interaction: The Safe factory is at the target address given above, but no data is required.

0.1 ETH: Initial amount of funds that should be sent to the new Safe on creation.

Tutorial for Creating a New Safe… Extra Safely

Send a transaction to 0x1337A824F3131c718b7a336E18CADb4BA0faffFc.

Enter no Hex Data: the field should stay empty.
Optional: The amount can be used to fund the newly created Safe.
The gas limit should be around 380K.
Choose a gas price or accept what gas price your wallet suggests.

2. Check the Identicon, address, and transaction details.

The address should start with 0x1337 and end with ffFc.
The Identicon should look like the examples given in the previous section.
The amount should correspond to the amount of funds you would like to send to your new Safe.
Fees should be slightly higher than the amount (depends on gas price and gas limit).