The Privacy4Web3 Hackathon, supported by Oasis Network, is an excellent opportunity for developers to use privacy-centric technologies while innovating in Web3. This edition, also known as Hackathon Oasis Network, has a prize pool of $130,000, with contributions from industry players, including Dedaub.
Developers can utilize Oasis’ confidential EVM, Sapphire, and the newly launched Runtime Off-chain Logic (ROFL) framework. ROFL enables off-chain components to interact with the on-chain domain, expanding Sapphire’s capabilities and creating new possibilities for composability. Learn more
Key Dates
Submission Period: September 19 – November 1
Judging Period: November 1 – November 10
Winner Announcement: November 12
Privacy4Web3 Hackathon | About Dedaub’s Role and Contribution
As a sponsor of the Privacy4Web3 Hackathon, Dedaub is offering $10,000 in audit credits to winning projects that utilize Sapphire and ROFL (Runtime Off-Chain Logic). By offering audit credits, Dedaub wants to emphasize the importance of security when starting new projects.
“Our work with Oasis Network reflects our commitment to Web3 security. We want to ensure developers building privacy-preserving solutions have the right tools and guidance to secure their smart contracts.” Neville Grech, Co-Founder, Dedaub,
Dedaub aims to enhance Web3 safety by employing advanced technology, conducting comprehensive audits, and providing extended security solutions. We have conducted over 200 audits for leading Web3 protocols, securing billions in Total Value Locked (TVL), partnering with industry leaders such as the Ethereum Foundation, EigenLayer, and Liquity. As a part of our commitment, we offer guidance as security advisors for various projects and initiatives.
Dedaub is a security partner of Oasis Protocol Sapphire, a founding collaborator of Seal 911, and a participant in the Chainlink Build Program. Additionally, we are a member of the zkSync Security Council and serve as a security advisor for the Arbitrium DAO.
Privacy4Web3 Hackathon | About Oasis
Oasis is home to Sapphire, the world’s first confidential EVM network. It also boasts the Oasis Privacy Layer (OPL), a cross-chain privacy solution that any EVM dApp can use. Oasis also has ROFL, a framework that supports off-chain components to runtimes like Oasis Sapphire.
Oasis is a layer-one blockchain built to support confidential applications at scale. This is done with a unique layered architecture that presents the optimal building and execution environment for DeFi, AI, RWAs, Gaming, NFTs, DAO governance, and more. Learn more
Privacy4Web3 Hackathon | Ocean Protocol
Ocean Protocol was created to democratize data access and ensure fair and secure sharing in the New Data Economy. Its tools enable seamless trading of tokenized data assets and data management throughout the AI model life cycle. Ocean Protocol is also a founding member of the Artificial Superintelligence Alliance. Learn more.
A few hours ago, the Dedaub team discovered a smart contract vulnerability in a number of uniBTC vault smart contracts in the Bedrock project. We disclosed the issue to the Bedrock account on Twitter and soon thereafter (after no response in 20 mins) to SEAL 911 for immediate investigation and action.
A SEAL 911 war room, under the guidance of @pcaversaccio, was created and we frantically tried for two hours to reach Bedrock developers. At that time, blackhats exploited the vulnerability for a $1.8m loss. However, given that this was an infinite-mint vulnerability on the uniBTC token, it is perhaps fair to assess that the damage was contained. Most of the potential losses were averted by pausing third party protocols exposed to the at-risk funds, including Pendle and Corn. Notably, Pendle had over $30M of liquidity on the Corn network for the vulnerable asset. On Ethereum, the market cap of uniBTC was $75M, which an infinite mint renders worthless, and the asset was deployed in (at least) 8 networks.
Root Cause
The root cause of this vulnerability is a mismatched calculation of the exchange rate between Ethereum and Bitcoin, in one path of the minting logic. In turn, this allows anyone who deposits Ethereum to the vulnerable smart contract vault to mint uniBTC in equal amounts. (Up until the vulnerability, uniBTC could exit to Wrapped Bitcoin at 1-1 rates.) Since the price of Ethereum is many times lower than the price of BTC, this creates an instant profit for any attacker exploiting any of these vaults. The vulnerable vault contract was a permissioned minter for uniBTC, so infinite amounts could be minted. The only adjustment made during this minting function is appropriate scaling in the number decimals of the assets.
In order to appreciate the gravity of this issue, we can illustrate this directly on the following code, straight from the vulnerable uniBTC vault smart contract (the implementation behind the proxy for the Vault):
function mint() external payable { require(!paused[NATIVE_BTC], "SYS002"); // Dedaub: adjust decimals and mint equal amount _mint(msg.sender, msg.value); }
Once the issue is exploited, the next step of a potential attacker would be to make use of this ill-gotten token on a number of other DeFi protocols, such as decentralized exchanges like Uniswap.
Reporting the issue to Bedrock and exploitation
As soon as our team had the issue, we contacted Bedrock on Twitter and entered a war room on SEAL 911.
Initial X.com exchange (time in UTC+2).
Unfortunately, even though we found the issue in the smart contract several hours before, by the time the team responded, the vulnerability had been exploited. The vulnerability could be discovered via shallow means (e.g., fuzzing bots) and the smart contract had only been deployed for under two days.
Timeline prior to exploit:
UTC 16:00 – issue discovered by Dedaub team and confirmed through simulation
The exploiter(s) subsequently minted large amounts of uniBTC and swapped them on a number of Uniswap and other AMM pools, stealing around $2M in funds directly. Note that the market cap of uniBTC on the Ethereum mainnet is $75M, which is the real potential loss for an infinite mint vulnerability.
Notably, the vulnerable contract was deployed on (at least) 8 different chains. We are aware of Ethereum, Binance, Arbitrum, Optimism, Mantle, Mode, BOB, and ZetaChain.
Averting Larger Losses
In addition to a number of pools on Uniswap (and Pancakeswap on Binance), the largest holder of uniBTC was Pendle. Luckily through war room actions, the Pendle team disabled the uniBTC token on their platform. With the main exit liquidity gone, the Bedrock team reacted some hours later (with the main devs in a 2-5am timezone) to also pause the relevant vaults.
This article will be updated with more detail and context on the discovery (which happened as part of a challenge task during our company retreat) in the next days.
Smart contracts are the underpinning of blockchain technology, and they present unique security challenges. To address this, platforms like Secureum have emerged, focusing on training researchers and developers to navigate and mitigate security risks, and we at Dedaub decided we wanted to partner Secureum in this mission.
Why we support the Secureum RACE
We decided to be part of the Secureum RACE because we believe hands-on challenges are the best way to learn. Security isn’t something you can fully grasp from reading papers or attending lectures—you need to get your hands dirty, confront real-world vulnerabilities, and think like an attacker.
The security of smart contracts is challenging due to the inability to modify the code once it goes live. This makes it extremely difficult to fix bugs or vulnerabilities. It’s even more complex, because contracts frequently interact with other contracts and different platforms, which adds even more complexity and multiplies the risk factor.
Secureum platform empowers researchers and developers to help improve their technical skills for what is needed in the challenge to secure Web3 technologies.
As the designer of RACE-32, we have the privilege of observing Web3 researchers and developers navigate complex security issues that mirror real-world vulnerabilities in Ethereum smart contracts. This allows us to witness firsthand and see how they apply their knowledge to devise creative and effective solutions.
As well as this, we see how researchers and developers grow in their ability to identify risks and exploit weaknesses, both of which are critical for the security of the Web3 ecosystem.
Why the RACEs are important
The Secureum RACE aims to create a community of researchers and developers who think critically about security. It’s an opportunity to expand their skills and immerse themselves in the world of Web3 security.
By addressing actual vulnerabilities in smart contracts, participants acquire necessary technical knowledge and develop the mindset to safeguard decentralized applications in real-world scenarios.
“RACEs are hands-on, immersive, and, frankly, a bit relentless—just like the threats we’re up against.” Yannis Smaragdakis, Dedaub Co-funder
Designing the RACE-32
We wanted much more than your standard easily graded competition, so we created the Secureum RACE 32 to be an educational challenge. Our main aim, therefore, was to encourage participants to delve deeply into complex smart contract security issues. With this in mind, The RACE is designed to create an experience that participants can refer to for a long time rather than single out the top performers based on scores.
Even though the time constraint made it challenging to understand the depth of the questions thoroughly, we stressed that the competition aims at learning and gaining insights. We urged participants not to feel disheartened if their scores hadn’t met their own high expectations. Instead, we praised some participants for putting together the solutions, pointing out that this would make the RACE a valuable educational resource beyond just the competition.
This focus on education shows Dedaub’s commitment to helping the smart contract developer community grow. This is the backbone of Dedaub’s mantra as our co-founders both have strong academic backgrounds and always value teaching and sharing knowledge. With this in mind, one of the company’s core values is to empower the next generation by educating and supporting future blockchain security experts and help them reach their full potential.
With challenges like Secureum RACE 32, we create real-world learning opportunities that give researchers and developers practical skills and deeper understanding. Our aim is to help them succeed in the Web3 space.
What is Secureum?
Secureum is a portmanteau of “Security” and “Ethereum” and their focus is safeguarding the Ethereum ecosystem through expert training and challenges. It’s an extensive educational platform that focuses on Ethereum smart contract security, providing a variety of resources and training programs. These include:
Secureum RACEs: Interactive quizzes that assess participants’ understanding of smart contract vulnerabilities. These quizzes are part of Secureum’s efforts to enhance practical security skills.
Community and Events: Secureum hosts events like TrustX to advance the Ethereum security ecosystem.
In summary, Secureum is committed to educating and preparing individuals for roles in Ethereum security through structured learning and practical challenges. Learn more
We’re thrilled to announce that Dedaub is now a member of the ZKsync Security Council. We’re grateful for the community’s recognition of our efforts to play an active role in securing and maintaining the integrity of the Web3 space.
What is the ZKsync Security Council?
The ZKsync Security Council is a governance body tasked with safeguarding the security of the ZKsync protocol (ZKsync ERA, ZK Chains, and other components of ZKsync). Comprised of at least nine technical experts, the council has the authority to perform both standard and emergency actions to address security threats. Members are Signers of a multisig wallet, giving them the power to execute critical decisions that protect the protocol. Read more.
Emergency Responses
The Security Council can freeze the ZKsync protocol in response to security threats, such as critical bugs or exploits. A Soft Freeze lasts for 12 hours and requires approval from three Security Council Members. A Hard Freeze lasts for seven days and requires approval from nine Security Council members.
An Emergency Upgrade can be implemented during a freeze to address the threat. Any Security Council Member may initiate an Emergency Upgrade without the approval of the Token Assembly.
Why Dedaub Was Selected
Dedaub was selected for the ZKsync Security Council because of its extensive expertise in smart contract security. The company has successfully completed over 200 security audits, conducted impact studies for the Ethereum Foundation, and developed innovative security Web3 technologies as part of its security suite.
The Dedaub team boasts exceptional academic credentials, with most members holding relevant PhDs, providing a solid foundation for our rigorous approach to Web3 security. ZKsync Security Council is one of many entities that trust Dedaub to increase its security expertise for its initiatives. Dedaub is also a founding member of the Security Alliance (SEAL), Arbitrum DAO Security Advisor, Oasis, and Chainlink Security Partners.
The Importance of Being Part of the ZKsync Security Council
Dedaub’s role in the ZKsync Security Council is actively protecting the ZKsync protocol. We our commitment to enhancing smart contract security and building trust in decentralized platforms and ZK rollups.
Dedaub has invested heavily in preparing for ZK technologies and sponsored the House of ZK event in Brussels, which featured discussions on Zero Knowledge technology and networking opportunities. Neville Grech, Dedaub’s co-founder, participated in a panel on “Trustless Interoperability Using ZK,” along with other industry experts.
Update (Mar/11/2025): Legal pardon given to the white-hats by parliamentary vote.
As a white hat hacker and educator, I’ve seen first hand how legal frameworks can fail to protect those who devote their lives to secure software systems.
A case that strikes close to home is a case involving a couple of my University students, who were arrested and were now summoned in court for responsibly disclosing a vulnerability, in Malta. A copy of the leaked vulnerability disclosure email is available here. Two of the students, Michael Debono and Giorgio Grigolo, were subsequently hired by Dedaub. We also extended financial aid to cover part of their legal fees. The arrests occurred after they found and exposed a security flaw in Malta’s largest student application and suggested a bug bounty. This incident shows how the law can treat these good-faith efforts no differently from malicious hacking.
In addition to these students, Mark Vella, a Professor who’s coincidentally a colleague of mine at the University of Malta, is also being charged as an accomplice.
The leaked list of charges (translated into English) includes very serious accusations, so let’s look at a couple of these and try to understand the absurdity of why these were levied. In doing so, I’m keeping in mind transcripts of their interrogation questions and emails that were exchanged.
Accusation levied
Likely reason why
1,2, 5 – 7: Unauthorized access to a computer, remotely, and copying part of its data.
As part of the responsible disclosure, the students allegedly included a screenshot demonstrating the issue (via a curl command).
9, 10: Intent to make an illicit gain, financial or otherwise.
The students, in their bug report, suggest that they would be eligible for a bug bounty.
9: Forcing the “victim” (the author of the software) to do (or omit) some action.
The students kindly asked for promotion of their CTF team.
8: With respect to Vella (University Professor) – having prepared the rest of the accused to commit crimes.
Allegedly, their Professor saw the email exchange and advised them to make some changes to the wording of their responsible disclosure.
Another interesting thing that struck me is that during the interrogation of Vella, the interrogator seemed to be toying with the idea of presenting him as a head of this (criminal) organization, with the students acting in his direction, which is obviously absurd.
Implications of this case
This case highlights the significant risks that white hat hackers face, particularly under outdated and rigid cybercrime laws. While the situation has been prominently demonstrated in Malta, it serves as a broader warning that such challenges could arise elsewhere. Malta’s cybercrime regulations, particularly Article 337C, are largely modeled after the Computer Misuse Act 1990 (CMA) from England and Wales. The CMA has not only shaped Maltese law but also influenced legislation in many Commonwealth countries, such as Australia’s Crimes Legislation Amendment Act 2001. Similarly, while the Computer Fraud and Abuse Act (CFAA) in the United States predates the CMA, it has been updated to include provisions strikingly similar to those in the CMA.
The crux of the problem in Malta stems from an excessively strict interpretation of these laws by the Attorney General. This rigid enforcement fails to account for the differences between malicious actors and ethical hackers, leaving well-intentioned individuals vulnerable to prosecution. But why should white hat hackers be penalized due to outdated laws and overly strict interpretations?
One potential solution is the implementation of Safe Harbor frameworks, such as the one proposed by the Security Alliance (SEAL), a leading security coalition in the Web3 space, of which we (Dedaub) are a founding member. The Safe Harbor framework provides legal protection to ethical hackers who responsibly disclose vulnerabilities. While it may not be a perfect solution, Safe Harbor offers a starting point for updating Malta’s outdated cybercrime legislation, aligning it more closely with the realities of modern cybersecurity.
The allegations against white hat hackers like Debono and his peers should serve as a wake-up call for lawmakers. It’s crucial that legislators rethink their approach to cybersecurity and ensure that ethical hackers—those acting in good faith to safeguard digital systems—are protected from prosecution.
Coincidental Visit of Malta’s Prime Minister
Finally, the story ends with a silver lining. The charges we discussed in this article were (ironically) served to the students at almost the same time that the Prime Minister and the Minister of the Economy came to the Dedaub offices. There, the students, as well as myself, had the opportunity to exchange views on the topic. The Ministers vowed to help and to set up better legal frameworks so as to avoid cases like this in the future. The Ministers clearly understood that the activities of white hat hackers are beneficial to society. I sincerely hope we will see more progressive legal changes that protect and promote the activities of white hat hackers over the next few months.
Dedaub is proud to sponsor the SPLASH 2024 conference, helping unite top thinkers in software, programming languages, and systems. We support the community’s advancement of computer science, extending beyond our Web3 security work.
The Doctoral Symposium, where mid-stage doctoral students receive vital research guidance, aligns with our academic roots. Led by university professors, our team is a powerhouse of expertise, with most members holding PhDs. We believe advanced knowledge is vital to delivering exceptional solutions and are excited to foster future tech leaders.
“SPLASH 2024 is where ideas meet action. At Dedaub, we push boundaries—whether in blockchain security or academic thought. By backing SPLASH 2024 , we’re investing in the minds that will define our industry. It’s about innovation, integrity, and preparing the next generation to lead.” Yannis Smaragdakis, Co-founder of Dedaub
Dedaub’s co-founders and senior researchers will attend, supporting open dialogue and contributing to the development of innovative solutions for technology’s future.
Sponsoring SPLASH 2024 emphasizes our commitment to expanding knowledge and empowering the next generation of technology leaders. We see this conference as a platform for pushing the boundaries of blockchain and smart contract security while nurturing emerging talents.
For those attending SPLASH 2024, we look forward to engaging with you, exchanging ideas, and exploring the future of programming together.
About SPLASH 2024
SPLASH (ACM SIGPLAN International Conference on Systems, Programming, Languages, and Applications: Software for Humanity) covers various software creation and delivery aspects. It’s a leading conference at the crossroads of programming languages and software engineering. SPLASH 2024 will feature the co-located OOPSLA, Onward!, SAS, GPCE, and SLE conferences, as well as SPLASH-E and other engaging workshops and events. SPLASH 2024 will bring together researchers and practitioners worldwide to explore the latest advancements and trends in software and programming languages. We are excited to be part of this dynamic event and to contribute to the ongoing dialogue on shaping the future of software development. Learn more.
On July 19th, Rho Markets — a Compound V2 fork on Scroll — was involved in an incident that led to the creation of $7.5mil in bad debt. The root cause of the vulnerability was the misconfiguration of the oracle for ETH, i.e., setting the address to a wrong price feed, at initialization time, and not a bug in the code. The price mis-alignment was quickly exploited by an MEV bot that observed the opportunity.
Fortunately, lost funds were returned due to the quick and coordinated efforts between the protocol team and SEAL 911 (of which we are also part). That being said, the willingness of the MEV Bot operator behind the incident to co-operate with the protocol and return the funds significantly sped up the recovery.
One may also read Rho Markets’ official statement [tweet | blog] on the incident, which does a great job of explaining the circumstances that led to the loss of funds.
Technical Details
The misconfiguration
Quoting Rho Markets’ incident report:
This issue occurred due to the erroneous configuration of the ETH oracle price feed to the BTC price feed. Normally, such settings are validated before any changes are implemented. However, due to a human error in overseeing the deployment process, this validation check was missed in the case of the oracle price.
As can be seen from the emitted event, the transaction has the effect of erroneously setting the oracle for the underlying asset at address(0) to be the WBTC/USD oracle.
At the time of the transaction, the configuration for the rWBTC token ( 0x1d7.. ) had not been set inside the oracle contract:
This is also evident by the fact that no calls to the PirceOracleV2‘s setRTokenConfig function had been performed, prior to the oracle update on block 7580111 and after rWBTC ’s deployment on block 7579842
The problem with setting the oracle for the asset at address(0) is that, as stated before, this address represents the underlying token of rETH (ETH) [ configuration of rETH ]
Which is a notion inherited from Compound’s semantics:
Screenshot depicting the configuration of ETH in Compound’s UniswapAnchoredView contract — the second address in the tuple is the underlying address
The consequences of the misconfiguration
At this point we can note that no contract code was vulnerable or broken, since the setter of the price oracle functioned as intended.
However, this misconfiguration alone was enough to enable the arbitrage opportunity that an MEV bot exploited. Since all ETH collateral would be priced at the value of WBTC —a 20X increase in the actual value of ETH— this allowed the bot to borrow more funds than one should normally get when using ETH as collateral (which lead to the creation of bad debt).
But it successfully manages to borrow ~942 wstETH which is then swapped into ETH
The total amount of bad debt that was created by this method ended up being ~7.5 million.
Return of funds
The war room set up with the protocol team and SEAL 911 was quick in gathering information on the attack and the operator of the MEV bot. However, the bot operator acted in good will and contacted the protocol team for the return of funds:
Hello RHO team, our MEV bot have profited from your price oracle misconfiguration. We understand that the funds belong to users and are willing to fully return. But first we would like you to admit that it was not an exploit or a hack, but a misconfiguration on your end. Also, please provide what are you going to do to prevent it from happening again.
The incident highlights the importance of rigorously reviewing deployment procedures. Even when there are no smart contract vulnerabilities, protocols must ensure that updates do not break any invariants posed by the protocol’s complex modules.
We’d like to thank Rho Markets for their quick action and transparency on the issue, as well as all the members of SEAL 911 who also participated in the war room with us.
Dedaub’s Security Audit teams comprise at least two senior security researchers, as well as any support they may need (e.g., cryptography expertise, financial modeling, testing) from the rest of our team. We carefully match the team’s expertise to your project’s specific nature and requirements. Our auditors conduct a meticulous, line-by-line review of every contract within the audit scope, ensuring that each researcher examines 100% of the code. There is no substitute for deep understanding of the code and forming a thorough mental model of its interactions and correctness assumptions.
Web3 Audit Methodology | 4 Main Strategies
Reaching this level of understanding is the goal of a Dedaub audit based on our Web3 audit methodology. To achieve this, we employ strategies such as:
Two-phase review: during phase A, the auditors understand the code in terms of functionality, i.e., in terms of legitimate use. During phase B, the auditors assume the role of attackers and attempt to subvert the system’s assumptions by abusing its flexibility.
Constant challenging between the two senior auditors: the two auditors will continuously challenge each other, trying to identify dark spots. An auditor who claims to have covered and to understand part of the code is often challenged to explain difficult elements to the other auditor.
Thinking at multiple levels: beyond thinking of adversarial scenarios in self-contained parts of the protocol, the auditors explicitly attempt to devise complex combinations of different parts that may result in unexpected behavior.
Use of advanced tools: every project is uploaded to the Dedaub Security Suite for analysis by over 70 static analysis algorithms, AI, and automated fuzzing. The auditors often also write and run manual tests on possible leads for issues. Before the conclusion of the audit, the development team gets access to the online system with our automated analyses, so they can see all the machine-generated warnings that the auditors also reviewed.
Dedaub’s auditors also identify gas inefficiencies in your smart contracts and offer cost optimization recommendations. We thoroughly audit integrations with external protocols and dependencies, such as AMMs, lending platforms, and Oracle services, to ensure they align with their specifications.
Understanding and Mitigating Solidity Security Vulnerabilities
Solidity Security Vulnerabilities are critical concerns for developers building smart contracts on the Ethereum blockchain and other EVM-compatible platforms. Solidity is the primary language for creating smart contracts on the Ethereum blockchain and other EVM-compatible platforms. It enables developers to build decentralized applications (DApps) that automate complex processes. However, blockchains’ immutability and decentralized nature make vulnerabilities in smart contracts especially critical. A single security flaw can result in the loss of millions of dollars in cryptocurrency, as demonstrated by numerous high-profile hacks.
This guide looks at the most common Solidity security vulnerabilities.
Access Control Failures
One of the most common Solidity security vulnerabilities is the failure to protect sensitive external functions with an access control modifier. Usually, a contract will have some privileged functionality that should only be called by the contract’s owner, for instance, to configure some of its parameters. Failing to protect this with an access control modifier such as onlyOwner can lead to disastrous consequences, as any attacker will be able to modify the core behavior of the smart contract.
Unchecked External Calls
Unchecked external calls can introduce significant Solidity security vulnerabilities.
Developers should control which contracts their application interacts with. Trusting arbitrary contracts and handing control to them means accepting malicious contracts could potentially interact with your application. This can lead to unintended behavior or even attacks.
In general, developers should interact only with trusted contracts. If these contracts are unknown, they should implement a system that allows the contract owner to whitelist contracts on demand.
Reentrancy Attacks
Reentrancy is a notorious Solidity security vulnerability where an external contract can hijack the control flow of the target contract. These can occur when one of the smart contract’s external functions temporarily transfers control to another contract before continuing to execute its own state-modifying code.
If the other contract is malicious, it can call the external function again, making it re-execute the code before the transfer of control happens. This takes place without the external function having completed the execution of the original call beyond the transfer of the control point. The procedure is called a re-entry and can allow an attacker to change the state of the contract in an undesirable manner.
Developers can prevent this kind of attack by using the checks-effects-interactions pattern. This pattern ensures that all state changes occur before transferring control to an external contract. Any re-entry attempt produces a fresh call, avoiding interaction with partially executed computations.
Integer Overflow/Underflow
Solidity uses integer data types for various calculations. Exceeding these data types’ maximum or minimum values can result in overflows or underflows. Solidity versions equal to or above 0.8.0 will revert automatically if this happens, and this can lead to unexpected reverts in your smart contracts. On the other hand, integer variables will wrap around if they are part of unchecked code, although this can lead to unexpected behavior unless there is a particular reason why overflow and underflow cannot occur.
Out-of-Gas Situations
Ethereum sets gas limits on transactions to prevent infinite loops and resource exhaustion. Smart contract developers must know these limits and gracefully handle out-of-gas situations.
For example, a resource-intensive loop can cause a transaction to fail due to hitting the gas limit, which may result in a frustrating user experience.
Sometimes, this situation can also lead to denial of service (DoS) attacks, where an attacker arbitrarily extends the length of the loop, effectively causing the functionality to become disabled.
An example of this scenario would be a function that loops over all registered users and sends them some funds. An attacker could increase the length of this loop by registering many bogus accounts with this system.
In general, it is preferable to avoid nested loops and adopt a pull system in which individual users request an operation rather than a push system that performs the operation for all users.
Oracle Staleness and Manipulation
Some contracts interact with oracles, which make off-chain data available on the blockchain, such as a Chainlink price feed. Developers should perform basic sanity checks on the provided data when interacting with oracles. It’s essential, therefore, to have a backup plan if the oracle fails.
For instance, contracts should always check that the data is not stale by checking the timestamp of the last data point is not further than a specified amount in the past. They should also check that the data is not an anomalous value such as zero or a negative number. In these cases, the contract should resort to a sensible default or pause the application until the feed starts reporting correct data again.
Developers should use only high-quality oracles to avoid some of the issues mentioned above. Some oracles, such as pricing data from an automated market maker (AMM), cannot be relied upon because they may suffer from value manipulation. Such manipulations will then have a ripple effect on your application as well.
Conclusion: Solidity Security Vulnerabilities
Solidity is a powerful language, but it’s easy to make mistakes that lead to severe vulnerabilities. These are only a tiny sample of the many vulnerabilities that can have a damaging effect on a smart contract. Therefore, before going live on the mainnet, it’s essential to audit your code.
You can also use tools like the Dedaub Security Suite to catch issues early. This tool helps you find and fix vulnerabilities in your smart contracts, giving you confidence in your code before deployment. Create your free account today at app.dedaub.com.
Today, I’d like to share my personal experience as a member of SEAL 911, the emergency hotline that assists Web3 projects in protecting their assets in case of hacks or malicious attacks.
I’ve been part of SEAL 911 since October 2023 and I witnessed:
Numerous vulnerability disclosures.
War rooms were set up to prevent the exploitation of live vulnerabilities or help protocols that were actively being exploited.
Many cases where individuals’ funds were stolen either because of investment scams, phishing attacks, or even drainer malware.
I had the opportunity to see many of the industry’s top security experts in action and gain useful insights.
Aside from addressing code vulnerabilities, SEAL 911 can also provide significant assistance in the area of on-chain forensics. Although this requires considerable time and effort, members of SEAL have been able to track the movement of stolen funds and provide victims with helpful information to report to law enforcement authorities. By effectively coordinating with authorities, the victim can often freeze stolen funds and even identify the perpetrators of the malicious activities.
With the increase in cryptocurrency capitalization, bad actors will continue attempting to steal funds from users by exploiting code vulnerabilities, stealing users’ wallet information, or even tricking users into sending the funds themselves. This poses a threat to the security of De.FI. As we have seen repeatedly, the most vulnerable group is non-tech-savvy regular users, so it is important to spread good operational security (op-sec) practices and fundamental cryptocurrency knowledge to the public.
What is Security Alliance (SEAL)
Security Alliance (SEAL), established with the support of blockchain innovators, has rapidly become a key asset of Web3 security. Before its public debut on February 14, 2024, SEAL connected users, developers, and experts to offer free Web3 simulation exercises.
Seal’s goal is to improve the security of the blockchain and cryptocurrency system by supporting security researchers and removing barriers that could prevent them from taking immediate action to safeguard protocols. The initial members include security teams at Paradigm, a16z crypto, and Dedaub, who have played a key role in significant recovery efforts. Seal’s programs include rapid response, legal assistance, and developer security training.
The Security Alliance (SEAL) offers several initiatives to enhance security. These include SEAL 911, a 24/7 emergency response hotline, and SEAL Wargames team exercises designed to identify and address vulnerabilities. Additionally, the Whitehat Safe Harbor Agreement provides legal protection for white-hat hackers participating in fund rescues, and the Legal Defense Fund supports researchers dealing with legal challenges. SEAL operates as a US 501(c)(3) nonprofit organization with the mission to protect the decentralized internet. For more information, please visit the Security Alliance.
What is SEAL 911?
SEAL 911 is a 24/7 emergency hotline for incident response, vulnerability disclosures, and other security issues in blockchain and crypto. It provides immediate assistance to address security threats quickly, ensuring expert help is available to mitigate risks and prevent damage.
Collaborative Defense: Working quickly with platform teams to temporarily pause contracts that have been hacked, when applicable.
Evolving Threats: Growing sophistication in cyberattacks requiring advanced strategies.
Rapid Response: Speed and coordination prevent losses and restore confidence.
What Are the SEAL Wargames?
SEAL conducts SEAL Wargames and red team exercises to help developers prepare for security incidents. These simulated attacks help identify weaknesses and improve defense strategies. Many developers have never experienced the high-intensity environment of a security incident before. It can be challenging to stay focused and productive when every second could potentially mean millions of additional dollars lost to attackers. The SEAL Chaos Team provides projects with the resources and training to respond to the worst-case scenarios.
Each wargame consists of two phases:
1. A tabletop exercise in which the Chaos Team presents hypothetical attack scenarios to project developers and notes potential weaknesses.
2. A simulated attack in which the Chaos Team exploits a vulnerability on a test network and challenges the project developers to set up an incident war room, triage the exploit, and remediate the situation.
Yannis Smaragdakis and I from the Dedaub Security search team are currently active members of SEAL 911.
Conclusion
As a member of SEAL 911, I have seen firsthand how critical our role is in securing the Web3 ecosystem. The collaborative efforts and rapid response capabilities we’ve developed are essential in combating the evolving threats in the crypto space. Working with some of the brightest minds in the field has been invaluable, and I’m proud to contribute to a safer, more resilient blockchain community.
