Originally published on quorummedia.xyz on January 30, 2023.

Writer: Samantha Marin

When you think of web3 security, you probably think of smart contract vulnerabilities. You think of being rugged in DeFi or not properly storing the keys to your crypto.

But web3 security isn't only about learning the do's an do-not's of this new technology. It's also about understanding the security attacks carried out in web2. In fact, DAOs might be even more vulnerable to traditional security breaches, because we spend more time focused on the web3-native components of security.

DAOs aren't only threatened by smart contract vulnerabilities or a multisig signer losing their keys: they're threatened by social engineering attacks.

A social engineering attack is when the attacker exploits people rather than code. It could come in the form of someone impersonating someone else on the phone or in a chat room, emails or messages containing malware, or even a fake job offer.

And we're starting to see those attacks at an alarming rate.

Like in traditional cybersecurity, attackers often attempt to exploit social vulnerabilities first. This is because social attacks are easier. Humans are often less trustworthy than code.

In fact, you don't even need knowledge of web3 to exploit DAOs today.

This is scary.

We recently saw one such attack in BanklessDAO.

In an editorial for the BanklessDAO weekly rollup, bDAO member Tomahawk described being impersonated by someone in the DAO's Coordinape round. The impersonator allocated funds to multiple wallets that they controlled, all under the guise of a core contributor.

Coordinape is a peer-to-peer rewards platform used by many DAOs today. Contributors allocate GIVE tokens based on the value they perceived them to bring during that season or cycle, and those GIVE are translated into the DAO's native token, which is then distributed to contributor wallets. In BanklessDAO, it's used like a bonus at the end of the season, and as a marker to see how your work is being received by the DAO. You sign in with your wallet, but when making an account there's no check to make sure you are who you say you are.

The DAO had to launch an investigation team into the issue, which unearthed more issues with DAO Coordinape rounds, particularly through how tags were used.

The levels of gaming of the system are unsettling. And it got me thinking about DAO vulnerabilities on all scales. This quote captured it:

"Coordinape, in its current form and without strong verification capabilities, is probably dead — at least for use with large teams. But beyond that, I don’t know how we will overcome Sybil vulnerabilities on a DAO-wide level. How many Discord handles were (or still are) controlled by Whales [the impersonator]? It raises uncomfortable questions from which we should not shy away."

—Tomahawk, BanklessDAO weekly rollup

This is an important lesson for DAOs in more areas than just Coordinape, and I applaud Tomahawk and the weekly rollup writers for bringing the issue to light so people can learn.

Even though Coordinape will probably not last in large DAOs like Bankless without some kind of verification, removing Coordinape is only knocking out one social attack surface. There are many other avenues to attack DAOs today, most of which are much easier than finding a bug in the code.

So, today I'm going to dive into the social side of DAO security. Not the code, not the smart contracts, but the social engineering and the soft exploits that happen in DAOs every day.

Soft treasury exploits

A soft treasury exploit is when a proposal passes to grant money to a wallet address in exchange for some type of work, but that work doesn't get done and the receiver simply keeps the money.

This is not an exploit done via code—it's an exploit done via social engineering.

Soft treasury exploits happen in DAOs more often than you may think. Optimism DAO suffered an exploit via misuse of their grant funds. Someone received funding for a project, and instead of working on the project, they simply bridged it to Arbitrum, Optimism's biggest competitor.

This will continue happening without further safeguards in DAO processes.

Some treasury exploits are obvious. For example, someone could propose to write five articles for the DAO in exchange for $2,000. If those articles never get written and the person who proposed it disappears with the money, that's clearly a funding exploit.

But the most dangerous forms of treasury exploits are the sneaky ones. Say an engineering team proposes to write a productivity software for your DAO. They're very active in discussions in the proposal phase because they want to get funded. But once they receive the funding, they quiet down. They're not very responsive, and they don't seem to be making progress. You notice that a few of the team members on the proposal totally dropped out of the DAO and seem to be working elsewhere now. After a few months they present a finished product, but it delivers on less than half that was originally included in their proposal. Upon asking them to finish their product, they say they need more funding to do so.

This is a much sneakier treasury exploit, but an exploit all the same. It's dangerous because not many people will catch it, and it can keep happening over and over.

I'm not arguing that every team needs to be perfect and deliver on every single thing they say they will do in their proposal. I'm also not arguing that teams need to sign a legally-binding contract to work on the project to create meatspace accountability. But, without proper safety mechanisms, treasury exploits are going to increase once we see another bull market and DAO treasuries start topping out again.

Let's explore a few solutions:

Possible solutions

Payment streaming over time, which can be stopped with a vote: Services like Superfluid allow you to stream tokens to a wallet rather than transferring them all at once. Add in the possibility to stop the stream with a vote, and this mechanism can prevent people from simply running away with a chunk of cash. A portion could be reserved to pay to the team only after final delivery.

Token gating of proposals to prevent spam proposals: The DAO could choose to token gate their proposal platform so only governance token holders can post. But, I acknowledge that this is a tough one. On one hand, it can block people from being able to enter the DAO and get funding for projects. On the other hand, it can save time for voters and prevent spam proposals that can be a major security risk for the DAO. I think the choice to token gate on the proposal level is ultimately up to how much the DAO has to lose if it were to have a funding exploit. A DAO that's just starting out and doesn't have anything in its treasury likely wants new talent to come through, and it doesn't need to worry about losing money yet. But a DAO with a large treasury is at significant risk of funding exploits via proposals without a token gate.

Impersonation and sybil attacks

DAOs are at risk of impersonation attacks in many aspects, not just the Coordinape example from BanklessDAO above.

Let me walk through one such attack.

Imagine someone creates multiple Discord handles under different pseudonyms and builds up different reputations associated with those pseudonyms. They will then use those reputations to get elected to different positions, such as coordinators of guilds, operations managers with access to the DAO's assets, grants committee members, multisig signers, and more. This person could even hold multiple positions on one multisig so that they can meet quorum with just their own wallets.

This person holds enough positions in the DAO to start swaying the general direction of it. They vote multiple times in non-sybil-resistant polls all over Discord and the forum. They tweet from non-sybil-resistant twitter accounts, all expressing the same sentiment. They socially engineer the DAO to put more funding to the guilds that the exploiter has secret multisig control over. And once that happens, the exploiter can drain all the multisigs and run away with the cash.

Wouldn't someone notice, you ask? Wouldn't the exploiter's voice sound the same in calls, showing something fishy between all the Discord handles? Or their face be the same in meetings?

In a largely pseudonymous environment, there are no video calls. And if the DAO is big enough, it's easy to slip by without attending meetings, or only attend ones in different corners of the DAO without contributor overlap.

Okay, so wouldn't their reputation be damaged?

Doesn't matter—they can show up to the same exact DAO tomorrow and run the same exact attack, just with a different name.

This type of attack might sound far-fetched, but it's not too far off the attack the impersonator launched in BanklessDAO just last month. And it's something we all need to think about in the DAO space.

Possible solutions:

Application-gated DAOs and/or roles: Adding an application into the onboarding process is an example of good friction that introduces one extra step that makes it harder to attack the DAO. For example, contributors could apply like they do with traditional jobs, and be accepted to the DAO if it's a good fit. While this goes against some of the 2021 WAGMI ethos of DAOS, it definitely feels relevant and necessary in many cases in 2023. If you don't want to go so far as gating the entire DAO, application gated roles could be one way to keep more powerful roles somewhat sybil-resistant.

Rely less on humans, more on code: Funds could be stored in a smart contract that automatically executes the results of the vote when it passes, rather than in vulnerable multisigs where running an attack and gaining quorum with wallets controlled by a single person is fairly easy.

Ghosting

This is an odd type of security vulnerability that I've watched happen. It's when a contributor who has some kind of power in the DAO just disappears on all platforms, so you can't get in touch with them. This wreaks havoc when funds are held in a mulitisig that requires their signature, or multiple multisigs across the DAO. Imagine if another signer had already ghosted, or if that one individual held multiple wallet addresses on the same mulitisig in the impersonation attack described above. This can lock funds for months or even for eternity if quorum cannot be met on multisigs.

In a pseudonymous environment, it's impossible to track down this missing contributor. They likely use a different name elsewhere, or if you do find them, they might not be responsive. There's nothing you can do in this situation but wait and hope they come back.

There is, of course, the potential that they didn't mean to ghost. Maybe something bad happened to them and they could no longer work or use their computer. Or they lost their keys to their wallet. This person might not be malicious, but it's still a huge security risk.

This is also a vulnerability in a softer sense: morale of contributors. It's a very weird sensation to watch a contributor drop off the face of the earth, and can initiate a search party within the contributors who knew this individual. This puts morale in a weird spot and makes you question your trust of everyone around you. Generally, this isn't great for the DAO's health and well-being of the people behind it.

Possible solutions:

Same as above, both application-gated roles and converting multisigs to automatically executing smart contracts can be workarounds here.

Requiring multisig signers to turn on a deadman's switch: This tool with a sinister name is actually extremely useful and is something everyone who holds crypto should have. A deadman's switch is a service that triggers a sequence of events after you die or become unresponsive. Here's how it works: every so often it emails you to ask if you're still alive, and if you reply, the switch is not turned on. If you don't reply, it triggers the sequence, which usually involves sending your critical information to your loved ones, such as wallet addresses and their private keys. Having a deadman's switch for all multisig signers or powerful people in the DAO ensures that if one of them were to die or become unresponsive, the funds would not be locked. Maybe the other multisig signers would get the email, and it would just be the address and key to the wallet associated with that multisig—it wouldn't have to be the person's entire assets.

Here's an example of one deadman's switch service.

Quarterly/seasonal check-ins with core contributors: Sometimes, when someone ghosts, it's not because they wanted to. Maybe they were in a severe mental health crisis or family emergency. There are legitimate reasons that ghosting happens. One way to stay on top of this is for a regular check-in of all core contributors. If someone can't have the burden of the multisig anymore, they can say that. Creating an environment for people to say share their needs and offload responsibilities can help with this security vulnerability.

Maybe "soft" DAO audits could help solve these issues.

A soft DAO audit would be when an external company audits the social layer of the DAO rather than the smart contract code underlying it.

They would analyze how easy it is to get private contributor information, to impersonate someone without others noticing, to get seats on multiple multisigs (and the same multisig), and other forms of social engineering attacks. Basically, they'd be auditing the human side of the DAO.

This company could even red team the organization to see what can get through. A red team (sometimes called a penetration test/pen test) is, according to Hack the Box, "an organized, targeted, and authorized attack that tests IT infrastructure, applications, physical security, company personnel, and their defenders." So, a DAO penetration test might involve auditors entering the Discord server, impersonating someone, and seeing if they can steal funds effectively. Or, it could involve something entirely different! The point is that it's an attack authorized by the DAO, but it's a surprise. The auditors act like malicious hackers and test the security of the DAO's fortress.

A web2 security lens applied to web3 organizations feels necessary in this moment, before more hackers realize that the walls have holes.

The more you have to trust humans, the more vulnerable your DAO might be

We're here in web3 because believe that trustless, permissionless technology will change the world. We're not here to put untrustworthy humans at the center of every equation.

So, let's hold those values true in DAOs, too.

Social engineering attacks are scary. They happen on massive scales in web2 companies all the time, and DAOs and web3-native organizations are at the same risk.

By implementing some of the security measures listed above, and maybe even start a soft audit, DAOs can significantly lock down their processes and become less vulnerable to social attacks. Bear markets are tough, and right now it might feel like many bad things are happening to DAOs.

But all DAOs need to do right now is survive, and security is the backbone of that.

Here's to surviving!