Content
Web3 Builders vs Attackers: Timelines of Adversarial Tactics
When building a secure web3 product, where do you start when there are so many malicious actors attempting to exploit your project through novel and common threat vectors?
Web3 security is largely considered a defensive game, where builders fortify their project from external threats. In this post, we’ll examine the offensive perspective alongside defensive best practices in each stage of your project along with specific examples and consequences.
Even before your code is audited, shipped, and deployed, adversaries begin testing the moment your project is announced. From that point, every team member you onboard, creates another attack vector. We’ll examine both the soft and hard targets that provide both strengths and weaknesses.
By exploring parallel perspectives, we hope to reduce or eliminate the instances where remediation and negotiation need to occur.
A Timeline of Layered Security vs Attacks
STAGE ZERO : Team Funding and Digital Hygiene
Before we examine the defensive and offensive tactics specific to web3 development, we must address a basic reality; the majority of web3 exploits are inherently web2 issues (phishing, cyber and front end attacks). Scams and fraud are not unique to web3, and they happen to both seasoned experts, and brands.
The security process doesn’t begin once your code is ready to be audited, it started in 1933… From the attacker’s perspective, why wait for a project to launch when they can exploit newly funded companies before launch? Due to the United States Securities Act of 1933, if you seek capital from accredited or non-accredited purchasers in exchange for equity or debt, you’ll likely submit a Form D, outlining sensitive information including:
- Company address, valuation, total expected investment, company officer names/address/contact information, and other sensitive details.
Malicious actors crawl the web to find funding announcements and can do so through a variety of manual and automated mechanisms. Start by ensuring your staff and contractors follow digital hygiene best practices, protecting themselves and your project.
Top 3 simple security rules to remember via CISA
- Strong & unique account passwords (ideally, with a password manager).
- Multi-factor authentication (MFA/2FA).
- Be cautious of phishing scams (don’t click on any links from unknown sender).
Yeah, we have to talk about Phishing…
There are plenty of attack vectors, but phishing is the most common and prevalent. In 2023, web3 security reports estimate phishing attacks drained $300 Million from 300K+ wallets. Recently, when a former Ledger employee fell victim to a phishing attack, the bad actor was able to publish a malicious library that compromised Ethereum-based applications including Zapper, SushiSwap, Phantom, Balancer and Revoke.cash.
Whether your project is new or established, be sure your employees and contractors are aware of digital hygiene best practices. No one is immune. These attempts happen regularly at CUBE3, but we have protocols in place to protect against these schemes and so should you.
STAGE ONE : AUDITS
Once your project is underway, getting an audit from a reputable firm is the first technical step to start protecting your code, business, and community. When should you start the audit process? How do you know if the outcome is successful?
First, start making connections with auditors as soon as possible! We provide some recommendations here like our partner Resonance Security. We also suggest connecting with CUBE3 prior to your audit if you intend to block malicious transactions in real-time (see Stage Four below). Some believe audits are only necessary to get out of the way in order to get a project up and running. Not only is that short sighted, in fact, it’s wise to engage in regular audits by multiple firms through the lifecycle of your project.
Surprisingly, most projects don’t ever have an audit completed before launching. According to a recent report by Hacken, only 10% of exploited contracts underwent any form of audit in 2023:
Consequences Sans Code Audit?
According to the Rekt Leaderboard, of the top 3 exploited projects (measured by largest sum stolen) none were audited! Of the top 20 projects on the Rekt leaderboard, about 50% were audited.
While many others were key compromises, access control issues and phishing related (see Stage Zero) there’s no excuse for not having an independent third-party review your code. BTW, the losses of the top ten web3 exploits equal over $3 billion. Yeah, audits and digital hygiene are important layers to be aware of.
“Audits are critical, but only part of your layered security posture.”
-Chris Griffiths, CUBE3.AI CTO
Audits Aren’t Enough
Audits are a critical layer to your security strategy but relying on audits alone could provide a false sense of security. While an audit can identify potential vulnerabilities, it does not guarantee impermeability. Evolving exploits and zero-days are a moving targets.
A determined attacker may find ways to exploit a vulnerability missed in an audit, putting everyone at risk. Therefore, knowing if the outcome of your audit is successful can be complicated, for a variety of reasons:
- Security Shortcut Trap
Attackers know audits can be costly, so at this stage they are looking for projects that may be hastily building and not taking the time to comprehensively protect their code.
- Post-Audit Vulnerabilities
Audits are typically conducted at a specific point in time and may not reflect the current state of the wider ecosystem after delivery. Malicious actors are constantly determining the best way to discover and leverage new attack vectors.
- Out of Audit Scope
It is often the case that audits will only uncover issues that aren’t explicitly stated in the instructions. This means that there may be other vulnerabilities that are missed. Examples atop Rekt Leaderboard:
If your project is compromised, the remediation will be more costly than the amount you invest credible code audits upfront. Similarly, integrating real-time threat monitoring and blocking can save your project, reputation and capital dynamically (more in Stage 3 below).
STAGE 2: BUG BOUNTIES
Software development is inherently dynamic and web3 builders value transparency due to open source code and ethos. Therefore, crowd sourcing bug bounties is a cornerstone of blockchain cybersecurity. But as with any layer of the process, there are shadows cast where light illuminates.
Unleashing Your Code on the Internet: What could go wrong? 😑
The largest benefit of bug bounties is the global talent you can access. Diverse perspectives like those provided by Immunefi with security researchers across the globe, leverage unique skillsets. Collective intelligence can uncover vulnerabilities missed by traditional audits and pen testing.
On the other hand, whitehats, blackhats or even self-proclaimed “script kiddies” can inadvertently destroy an entire system once the code is live. One of the first web3 events of this sort happened when Ethereum was just two years-old.
In November, 2017 the parity multi-sig hack occurred locking 500K+ ETH from about 500+ accounts…$280million in 2017 – about $1.1 billion today of (still) frozen funds. The user [devops199] arbitrarily reset the library ownership and usage parameters of existing wallets. The user claimed it was an accident, some believe otherwise…
Whether this was inadvertent or purposeful, hackers don’t wait for scheduled assessments, and neither should your defenses. A constant influx of reports keeps your security posture agile and responsive to evolving threats.
Minor Bug, Major Risk?
Although bug-bounties “pay as you go” model can be cost effective, hackers may use a “Double Dipping” strategy. This is where hackers report only “minor” vulnerabilities, earn an immediate reward and later exploit critical “out-of-scope” flaw. Quantity over quality is the risk you run when giving the entire world intimate knowledge of your code construction.
Accumulated knowledge can be used to craft a customized, targeted attack in the future. This is called Knowledge Stockpiling.
Stockpiling zero-day vulnerabilities is common both with hackers and nation-states. For example, Chain Reaction Exploits can occur by understanding the overall system architecture, and use one minor flaw to create more damage. The previous example of the Ledger Connect Kit exploit from a simple phishing attack, required a patch for the entire ecosystem.
Just like any security measure, bounty programs have limitations that can require mitigation. If an issue in your contract is identified, you must make a decision — pause withdrawals or contract until you remediate, or hope for the best and wait for an update. With CUBE3’s Runtime Application Self Protection (RASP), you can inject a temporary patch, thereby giving yourself more time to redeploy.
STAGE 3: REAL-TIME MONITORING & BLOCKING
It’s clear that there is only so much you can do before and after launch to secure your project as the industry is rapidly evolving and ever expanding. You need detection and mitigation technology that evolves as quickly as the web3 ecosystem. Runtime threat monitoring tools for the blockchain continuously scanning smart contracts and transactions for suspicious activity in real-time. ML monitoring systems like CUBE3 analyze code for vulnerabilities, track abnormal behavior, and trigger alerts to prevent financial losses and reputation damage.
Attackers have come to expect that speed running basic monitoring tools is the key to success. For example, if they can deploy a reentrancy attack before web3 builders can pause the target contract(s) they can get away with millions. For the project, not only are they losing the hacked funds, they also have to contend with the downtime for pausing, patching and remediation efforts. Depending on the contract and community governance, this can take days to decades. In the Parity hack example above, the funds are still frozen 7 years later, with no fix expected.
So how do you outrun malicious speed runners? Block them from ever getting off the blocks…
Introducing Real-Time Transaction Security
There is a better way to dynamically safeguard participants in a decentralized system that does not require pausing contracts: Real-time transaction security. CUBE3 has pioneered Runtime Application Self-Protection (RASP) for web3. CUBE3 is another tool in your preparation and post-deployment process ideal for a variety of verticals:
- DeFi
- CeFi
- Crypto Traders
- Crypto Exchanges
Organizations in each of these verticals, are hesitant to pause protocols (read: lose revenue/trust from all customers) because the risk of halting the entire project could be due to false positives or cost prohibitive. Downtime risks revenue and reputation. However, with CUBE3 Protect product, the system is designed to only block a single transaction by a single user. Moreover, CUBE3 is designed to be modular and a transaction/address can be updated/whitelisted upon review.
Here’s how CUBE3 supports the web3 ecosystem in a unique and dynamic way:
- Continuous Threat Detection
CUBE3’s ML models analyze historical and real-time blockchain data across five chains; Ethereum, Polygon, Avalanche, Arbitrum, and BNB (with more on the way). This comprehensive intelligence provides a data-driven assessment of token activity, revealing hidden risks and uncovering potential red flags.
- Preemptive Risk Assessment
CUBE3’s real-time Risk Score system assigns a risk number (1–100) for every transaction based on threats in three categories: cybersecurity, fraud, and compliance risk. Real-time alerts give you instant insight into potential dangers and providing a clear basis for action.
- Proactive Threat Prevention
Automatically block threats at the contract level with CUBE3 Runtime Application Self-Protection (RASP) or front end using our SDK. CUBE3’s tools integrate seamlessly giving your organization integration optionality, unlike other monitoring providers. No more relying on manual intervention or delayed responses.
- Compliance Confidence
Stay ahead of evolving global regulations and industry standards with CUBE3’s built-in compliance checks and reporting tools. Ensure security aligns with ethical and legal obligations.
CUBE3 is one flexible solution for security coverage against fraud and cyber risk but also supports compliance, unlike other providers.
CONCLUSION
Security for web3 builders is a journey containing many levels, not a single destination. Embrace the strengths of digital hygiene, audits, bug bounties, but keep a watchful eye on their limitations. Once you begin to navigate the intricate world of web3, continue to educate yourself so you can do so with care and confidence. Having a real-time monitoring and blocking capability will help your layered security strategy stay fresh and timely.
As we’ve explored, audits, bug bounties and are not a substitute for continuous solid security practices for web3 builders. Audits should be used in conjunction with other security measures, such as bug bounties, penetration testing, and continual code reviews. Moreover, projects that prioritize security from the outset and adopt a proactive approach to security are more likely to provide a secure environment for their users.
In conclusion, one or two security layers are an important for identifying potential security vulnerabilities in web3 projects, but they are not enough on their own. Given the immutable nature of digital assets, security by design should become the standard from pre- to post-deployment. Shield yourself against contract exploits, scams and fraud with a layered security solutions before, during and after launch.
CUBE3.AI is here to ensure your projects are safe and secure post-launch as part of the process contact us, review our docs and access our free tools by signing up and joining our community today! Traditional methods of security, such as audits, bug bounties and monitoring, are not be enough to protect users from potential risks. If there’s one takeaway, employ layered security and make CUBE3 part of your plan.
Einaras Gravrock
CUBE3.AI
Sarunas Matulevicius
