An Analysis Report of the Attack on the WePiggy Front-End Servers
Dear WePiggy community users, WePiggy’s front-end service was interrupted in the early morning of May 20, 2021(UTC+8 Time), and normal access has been restored so far. In addition, after experiencing yesterday’s extreme market, the assets of our lending protocol are still safe, and the related debts have been successfully liquidated.
In order to let everyone better understand what happened and avoid misunderstandings, the following attack analysis report is hereby released for you to interpret in detail.
The whole report is mainly divided into three parts:
- What happened?
- Who was affected?
- Any improvement plan?
What happened?
In the early morning of May 20, 2021, users from chinese and overseas communities reported that WePiggy’s front-end service was interrupted
Then WePiggy overseas volunteers received a blackmail request from the attacker for 4 ETH, and the overseas volunteers immediately reported back to the core development team.
Through the back-stage data, the operation and maintenance personnel of the team determined that this was a DDOS attack and began to deal with it.
After upgrading the configuration and purchasing a higher-level defense solution, the server blocked most of the attacks, the front-end services became available again, and the attacker stopped the attack.
Who was affected?
Since the WePiggy protocol is running on the Ethereum mainnet and the OKExChain mainnet, the assets of the entire protocol have not been stolen when there are no vulnerabilities in the smart contract.
This DDoS attack caused WePiggy’s front-end service to be interrupted, and the main groups affected were normal users of the lending protocol.
Normal users do not have the relevant contract invocation knowledge, and it is difficult to use the lending protocol when the front-end is inaccessible, and then they may face the temporary situation of not being able to withdraw funds and repayment.
Any improvement plan?
In order to prevent such problems from happening again, we will make improvements in the following four aspects to increase the usability and anti-fragility of the system.
- Optimize server configuration and purchase more advanced defense solutions
- Add backup domains and servers
- Writing a tutorial based on the block explorer for normal users
- Evaluate and implement the operational plan to use IPFS as an alternative to front-end services
Optimize server configuration and purchase more advanced defense solutions
We will upgrade our server hardware configurations, increase bandwidth and performance, and launch a higher-cost DDoS attack protection solution. At the same time, we will enable multiple servers to provide better services.
This is the first step, that is to improve the availability of existing services.
Add backup domains and servers
We will add backup domains and servers. Under normal conditions, these backup domains and servers are not open to the public.
When our main domains and servers are subject to unexpected attacks, we will publish the backup domains in the community to guide community users to use this channel to access the website.
We will regularly update and maintain backup domains and servers to ensure their availability.
This is the second step, that is to provide users with a backup channel to access our front-end.
Writing a tutorial based on the block explorer for normal users
The user’s assets are stored on the blockchain, and they are safe. When the front-end interface is unavailable, users can directly use the WePiggy lending protocol through the blockchain explorer
For normal users, it is difficult to directly operate smart contracts, but it is a workable and important solution. In order to make it easier for users to know how to use the blockchain explorer, we will write a set of user manuals.
This is the third step, that is to provide users with a way to use the lending protocol through the blockchain browser.
Evaluate and implement the operational plan to use IPFS as an alternative to front-end services
The core development team will evaluate the possibility of using IPFS as a front-end alternative in the near future. If that is possible, we will transfer part of the front end to IPFS to ensure the high availability of the system.
This is the fourth step, that is to prepare more options for front-end interaction, to avoid the cloud service provider interrupting the front-end server hosting service.