[BIP-443] Restore Brand Trust in Balancer by Assisting DNS Hack Users

Governance General Proposal
1

PR with Payload

Summary

Restore brand trust in Balancer by assisting DNS hack users, allowing them to immediately recover 75% of lost funds, while Balancer continues to investigate this incident. Users claiming immediate restitution shall forfeit all further claims relating to this incident, with any further recovery accruing to the Balancer DAO.

Background

On September 19, the Balancer frontend was attacked via social engineering on EuroDNS, the domain register used for .fi TLDs.

Due to prompt action from community members, damage was mitigated, and control was quickly restored.

Unfortunately, users interacting with the Balancer frontend while the attack was ongoing were affected. Final damage numbers have not been published. However, rough estimates would be around 200-300K USD.

Motivation

Brand trust is the publicā€™s perception of a brandā€™s reliability and trustworthiness, as informed by both personal experience and marketing communication. Itā€™s a complex concept that encompasses a variety of factors, including security and privacy, product quality, customer service, brand mission and values, and political or philanthropic efforts. In crypto, brand trust is an important, and arguably the most vital, differentiator between comparable products in competitive market conditions.

Brand trust is a critical component of brand loyalty. Customers who trust a brand are more likely to utilize it again, even if they have a negative experience from time to time or one-off experiences that donā€™t meet their expectations.

Consistency is another strong component of successful branding. Communicating the same values in the same voice at every customer touchpointā€“treating all users alikeā€“is important in creating an authentic brand. Inconsistent actions are unpredictable, and unpredictability dissuades consumers.

[BIP-XXX] Decide on direction of restitution for affected LPs in Boosted Pool Incident is an excellent example of striving to restore brand trust. While Balancer is neither obligated to provide restitution, nor responsible for user actions, the community has nonetheless found it worthwhile to seek a resolution to the first hack and make its users whole.

Similar, Balancer should attempt to take any possible actions within its power to mitigate harm caused by the second hack as well to known, affected users. We propose that verified actors affected by the DNS hack be allowed to claim 75% of their lost funds from Balancer while it continues to investigate this incident, forfeiting further claims to their lost funds, with any additional funds recovered going to the Balancer DAO. By doing so, Balancer will be not only be able to restore, but grow its brand trust, which will be essential if it seeks to succeed in the long term. In todayā€™s competitive marketplace, users have more choices than ever before, and are increasingly demanding, especially with consumer security and safety. Consumers want to interact with brands, like Balancer, that can provide a safe transactional environment and positive overall experience.

Specification

Upon approval of this BIP, immediately send $117,806.25 USDC (72.0528468675 ETH) to address 0xD14f076044414C255D2E82cceB1CB00fb1bBA64c, a verified, known, damaged wallet, who will be providing an on-chain signature for wallet verification referencing this BIP in the comments below, along with a statement forgoing all further claims to restitution. The amount to be sent is 75% of the $157,075 USD (96.07046249 ETH) total lost by this wallet during the attack period across 5 transactions, which can be verified on chain here.

Further:

1.The max budget for this program shall be 350K USD.
2. A 60 day reporting window shall by announced via appropriate channels, including Discord and Twitter, following approval of this BIP, with a second reminder at 30 days, and a final reminder in the final week to deadline. The 60 day claim period will start upon announcement of the claim window.
3. To submit claims, users will verify wallet ownership and report any DNS hack losses via a Google Form, which shall be prepared by a volunteer committee of 5 well-qualified, objective individuals with experience in DeFi opsec, who shall serve as a technical advisory committee to process these transactions. Because a widely used angel drainer was used in this attack, itā€™s not possible to determine whether tokens drained during the timeframe of the attack were from user interactions with the Balancer FE or from elsewhere. Some blockers can be put in place to prevent potential double-dipping from the attacker himself, such as gathering identifying information on the claim form. But ultimately, whether a user making a claim was truly affected will come down to a human call. If the committee reviews a claim, finds it satisfactory, submits a BIP, and governance approves that BIP, then that claim is legitimized.
4. To validate and approve claims, the committee will verify the address and transaction details on Etherscan, arriving at an independent total to be compared against details submitted on the Google Form. Should the details match, the claim shall be recommended for processing. Should the details conflict, the claim will be rejected for resubmission.
5. To execute, the committee will aggregate all claims in batches, and prepare two BIPs to be approved by governanceā€“one BIP to be submitted 30 days after the start of the 60 day claim period announcement, the second BIP to be submitted at the 60 day deadline. Each BIP shall include a list of affected wallet addresses and amounts, and be sent to the Balancer DAO signers on the following Tuesday after each BIP has been approved, who shall use transaction builder to execute one multi-send transaction to send the verified amounts to the affected wallets.
6. Further claims following the 60 day period will require a new BIP and must go through governance.

Voting

To ensure the effectiveness of public relations campaigns, immediate action is necessary. Consequently, weā€™d respectfully request that this BIP be moved to vote this week.

Technical specification

The DAO Multisig 0x10A19e7eE7d7F8a52822f6817de8ea18204F2e4f will interact with USDC 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 by writing transfer passing the affected user address identified as auramaxi.eth as the recipient 0xD14f076044414C255D2E82cceB1CB00fb1bBA64c and amount 117806250000

3 Likes
2

Want to add another point of view to this.

Is Balancer obligated to reimburse affected users? No.
Should Balancer do so? Well, probably yes, from my perspective, though itā€™s generally debatable.

Letā€™s also consider another perspective: utility.
If Balancer were to take a proactive approach and reimburse the affected users, it would send a very powerful signal: we are a protocol that takes care of our users when something goes wrong, even if that issue isnā€™t directly our fault.
The value of such a statement, in terms of reputation, likely exceeds the cost that the protocol would incur. This cost might even be recouped from the responsible third-party vendor.

In my opinion, the above proposal should be put to a vote and receive a ā€œyes.ā€ This is not only because I personally believe itā€™s the right thing to do, but also because it could enhance the brandā€™s value far beyond the potential cost.

5 Likes
3

I believe this should have the same treatment as the previous case for the following reasons:

  • The users were trying to interact with Balancer FE, unaware that something was wrong;
  • While what happened was not strictly Balancerā€™s fault, it was an issue on a SP that Balancer hired to provide the service;
  • The reputational damage will probably be larger than the economic one.

As a quick answer is important in cases like this, I support this going to a vote this week too.

4 Likes
4

Thank you very much to Aura for taking the lead on this. This looks like reasonable governance to me. A few things that I think should be added to the spec to make it fit into our multisig processes and procedures.

1: A max budget for this program, after which more governance will be required.
2: A clear and formalized method for submitting, validating, approving and executing payout requests.
2a: At best this would be via governance conducted 1-3 times over the 60 day period.
2b: If more frequent payouts are desired, a technical committee should be appointed to assess requests against a clear set of parameters as part of this BIP. This committee should be responsible for and authorize to request relevent transaction execution by the DAO multisig, referencing the specification in this BIP.

2 Likes
5

Itā€™s the right thing to do based on what happened imo.

Two most notable things imo:

  • In this market, affected users will value this approach.
  • It also shows that the Balancer can take responsibility even though itā€™s not completely necessary (at least for others).

So, I support this proposal and the timelines for implementing it. :+1:

Thanks, Tritium for being practical here. =)

I think all points make sense and should be implemented asap.

As for the last point, who do you think can be responsible for this? Maxis or a different committee?

1 Like
6

I tend to agree with this sentiment and also approve of this BIP. Many of the users involved seem to be very regular Balancer users and supporters who are now in a financially stressed situation, and it seems the cost to bail them out is relatively low. Itā€™s good to take care of our own.

That being said wallets are getting a lot better these days and phishing a lot more prevalent. I didnā€™t try but I imagine a wallet like Rabby would have blocked/made it very hard to sign this transaction for most users for a number of reasons.

Most of the responsibility for managing personal OpSec and being sure what you sign sits with users, and today there is tooling that makes it pretty easy to be a lot more safe.

I really think this is the last time we should do this. I strongly advise users who are operating in DeFi to spend a good deal of time learning about and improving your personal OpSec, and making sure you are using the best tooling to keep you safe. I also advise being careful when installing such tooling and to take your time doing so. Your keys, your coins, your responsibility for what you sign.

I stand ready to connect any 7+ figure addresses with real web3 OpSec experts who can advise you/help you to make sure you keep your funds SaFu. Feel free to reach out to me on the Balancer Discord or message me here on the Forum.

I think this BIP would be stronger if part of the process of accepting/claiming the 75% involved surrendering all claims to further restitution and accepting some degree of personal responsibility for what happened.

3 Likes
7

The Maxiā€™s are pretty slammed. I think there is a war room going on with some folks already doing research. Iā€™ll ask to get them to take a look at this BIP and suggest someone from there come back with suggestions.

1 Like
8

How would claims be verified?

1 Like
10

Mmm wanna add some colours to this.

I have worked in cyber threat intelligence for several years.

One thing happens: common attack vectors, if applied to field/industries in which they are new, tend to be successful especially in the beginning, because users are on average just not aware of where the danger might lie. As an example, Middle East and Eurasian APT in the past years used (and still use), effectively, a phishing technique with fake email job offers. This technique, quite basic, is inherited from the (apparent) cultural behaviour of middle east users to check a lot this type of content. Initially this technique proved to be very effective against western targets, just because western users were not used to be brainwired about a possible threat coming in this form.

A DNS redirect is something that used to be a common as attack vector (when is possible to execute) and quite effective. If I bookmark google.com and I go there I tend to not even think it could be a fake website build from scratch. Since this technique is quite effective, the only real defence has been using third party vendors that are less prone to be exploited. Regarding this point, avoind using the .fi domain is a good and safe move, even at the cost of the brand that has universally be known so far as ā€œbalancer.fiā€. On this, props to you and the team.

While I agree that wallets are getting better, and that some users were probably prompted to not sign, for the reasons highlighted above the burden of this attack should not be put on the victims.

2 Likes
11

Thanks for the suggestionsā€“just edited.

12

Iā€™ll accept your assessment here ser. I still stand ready to connect high value wallets with OpSec experts. If you have big bags in DeFi and are not one, you should be talking to one.

2 Likes
13

This proposal is not really proper without a max budget put in place in the snapshot vote itself. Multisig payloads should be voted upon, not left up to the discretion of individual teams. Letā€™s do this proper and not give the maxis power to slip in arbitrary airdropped payments without any governance oversight. I also donā€™t think itā€™s proper to assign other teams potentially risky work through governance without talking to them first.

In terms of the proposal, Iā€™m not entirely against it. It hurts to see community members be affected by things like this. But what I will say is that it is up to the user to check everything they sign with their crypto wallet.
DNS hijacks will continue to happen in defi and I donā€™t know how much you can fault defi projects for the failings of web2 infrastructure. There is not much precedent for defi projects paying out full value for dns hijacks, such as the one that happened with curve. You really should never be signing random approvals that pop up without making any actions on the webpage and I do think there is at least partially some fault on the users who fell for this.

That all being said, I donā€™t want Balancerā€™s biggest supporters to be hurt from all this. Iā€™m not opposed to restitution in this instance but I am against making this precedent. Individual defi projects cannot be liable for the uncapped losses of users who are not verifying what they use their wallet to sign.

The proposal should be fixed so that the transactions that dao multisig makes are verifiable through a governance vote and not left up to a team who never consented to undertaking this responsibility.

4 Likes
14

Thanks for the suggestions, edited.

15

Can you please clarify what this verification process wold look like?

The attacker has been executing this attack for long before the hijack and continues to do so after Balancer regained control of the admin account. Fake_Phishing180397 | Address 0x00006DEAcd9ad19dB3d81F8410EA2B45eA570000 | Etherscan

Is your proposal that the Balancer DAO should refund any address hacked by them within the timeframe of the domain hijack?

1 Like
16

Thanks for your commentsā€“just edited.

17

Is there any investigation that will be done to ensure the hacker didnā€™t pretend to be victim with various addresses, therefore doubly profiting from this attack (stealing from actual users but also from the DAO that will restitute funds he/she sent to him/herself)?

1 Like
18

I donā€™t think the DAO can/should approve this BIP without knowing who makes up this committee

This is too short of a time frame. Voting concludes on Tuesdays and another round starts on Thursdays. Not enough time to prepare the form and process the claims

19

This means people could have been victim on other malicious frontends and Balancer DAO would be restituting them too. Is there a way for the committee to somehow filter these out?

20

From my understanding, there are several investigations ongoing, but these would be outside the scope of this proposal, as we wouldnā€™t be requiring the committee or DAO conduct the investigation. Claims will be reviewed FCFS, but there doesnā€™t necessarily need to be any immediate action on them. We can hold all claims until the end of period, which would give us an additional 60 days to find a resolution, or if we feel that this time period is too short, we can extend it as well.

From our discussions w/ the Balancer Maxis, a majority Balancer committee, i.e. 3 Balancer + 2 Aura, or 2 Balancer + 1 Aura would be ideal. From our side, we can volunteer well-qualified individuals, such as Maha, JayC, some of our more independent security researchers, like Hephyrius, who have conducted audits for us before, even Jojo, whose background is in network security, so itā€™s no issue on our end to fill out partial or full membership. However, like Mike was mentioning above, we wouldnā€™t want to volunteer anyone on Balancerā€™s side, so ultimately, final committee composition will be dependent on who Balancer would like to bring to the table.

As presently envisioned, the first BIP will only be processing 1 or 2 claims from known, verified community members that are already working w/ us at this moment to get this resolved, so the timetable will work for them.

There is an imperfect way to filter, but itā€™s quite time consuming, as I believe you need to hunt for prior transactions where the wallet has interacted w/ Balancer contracts, then make an assumption that wallet was on Balancer at the time of the hack rather than another platform. Some time could be saved here if we require the user themselves to submit the transactions where they have interacted w/ Balancer when they submit their claim. If this is a big concern, we can filter only for wallets that have interacted w/ Balancer at some point in the past, but first time users of Balancer that were hacked would be out of luck.

21

Been thinking about this off and on today. Committees are tricky in a decentralised environment, especially when they are making financial decisions for others. Perhaps a committee is a good idea here, but more time and thought and discussion should go into it before we codify something in my opinion. It is clear there are a lot of dragons here.

On the other hand, it seems like there are already a few clear cut cases of members of our community and regular users of the Balancer Protocol who lost money in incident and a desire to show good faith and quickly take care of them. Could we just simplify this BIP to focus on the clear cut cases that we have already identified or can identify before it is felt there is need for this to go to snapshot. Then everything would be in place for payout assuming all conditions of payout were met.

We can figure the rest out later, once the post mortem is complete, and we perhaps have details like how long the attack was running for before the Metamask block came up, and how many unique users there were to the site during that time, and after the block.

1 Like