Dedaub is proud to sponsor the DeFi Security Summit (DSS) 2024, which will be held from November 7th to 9th in Bangkok. The summit aims to enhance the security of smart contracts in decentralized finance. This sponsorship reflects our commitment to bolstering Web3 by elevating blockchain security standards and promoting collaboration within the ecosystem.
In the 2024 edition, we’re contributing to two key sessions:
1. SEAL Panel: “Safer Development: Don’t Get Rekt”
This panel will cover best practices for secure development, with insights from top security leaders. Gain practical strategies to avoid common pitfalls in smart contract development.
2. “Smart Contracts to Embeddings: Using Off-the-Shelf LLMs for Fun and Profit”
Dedaub will demonstrate how Large Language Models (LLMs) can improve smart contract analysis, providing developers with new tools to understand and enhance contract security.
DSS 2024 | About DeFi Security Summit
The DeFi Security Summit (DSS) is an annual, marketing-free event dedicated to advancing the security of decentralized finance (DeFi) applications and blockchain-based technology. Inspired by renowned security conferences like CCC and Defcon, DSS is a platform for white-hat hackers, protocol builders, security researchers, and tool providers to collaborate and share insights. The summit focuses on education, technical advancements, and best practices to secure blockchain applications’ on-chain and off-chain components. DSS 2024 will be the third edition, building on the success of previous years. For more info, visit https://defisecuritysummit.org/.
About Dedaub
Dedaub is a pioneer in Smart Contract security technology and auditing. We blend cutting-edge program analysis with real-world white-hat hacking. As a founding collaborator of the SEAL 911 initiative, we contribute to emergency response frameworks within the blockchain ecosystem. Trusted by leading protocols, Dedaub is the security partner for Oasis Protocol Sapphire and collaborates with the Chainlink BUILD program. Our role on the ZKSync Security Council and as a security advisor to Arbitrum DAO emphasizes our commitment to safeguarding major Web3 projects.
With the recent introduction of transient storage in Ethereum, the landscape of state management within the Ethereum Virtual Machine (EVM) has evolved once again. This latest development has prompted us at Dedaub to take a fresh look at how data is stored and accessed in the EVM ecosystem, as well as analyze how the new transient storage is used in real-world applications.
It’s important to note that even though transient storage has properly been integrated into the EVM, the transient modifier is still not yet available in Solidity. Therefore, all usage of transient storage is directly from the TSTORE and TLOAD opcodes using inline assembly, meaning usage is not that widespread yet, and could also be at a higher risk of vulnerability.
In this comprehensive blog post, we will explore the strengths and limitations of each storage type. We will discuss all their appropriate use cases, and examine how the introduction of transient storage fits into the broader ecosystem of EVM data management. If you do not need a refresher of how the EVM manages state, feel free to skip to the EIP-1153 impact analysis section.
EIP-1153 | Quick refresher of data storage and access
Storage
Storage in Ethereum refers to the persistent storage a contract holds. This storage is split into 32 byte slots, with each slot having its own address ranging from 0 to 2256 – 1. In total, that means a contract could store potentially up to 2261 bytes.
Of course, the EVM doesn’t track all of the bytes simultaneously. Instead, it’s treated more like a map—if a specific storage slot needs to be used, it’s loaded similar to a map, where the key is its index and the value is the 32-bytes that are being stored or accessed.
Starting with slot 0, (Solidity) will try to store static size values as compactly as possible, only moving to the next slot when the value cannot fit into the remaining space. Structs and fixed size arrays will also always start on a new slot and any following items will also start a new slot, but their values are still tightly packed.
Here are the rules as stated by the Solidity docs:
The first item in a storage slot is stored lower-order aligned, meaning the data is stored in big endian form.
Value types use only as many bytes as are necessary to store them.
If a value type does not fit the remaining part of a storage slot, it will be stored in the next storage slot.
Structs and array data always start a new slot and their items are packed tightly according to these rules.
Items following struct or array data always start a new storage slot.
However, for mappings and dynamically size arrays, there’s no guarantee on how much space they will take up, so they cannot be stored with the rest of the fixed size values.
For dynamic arrays, the slot they would have taken up is replaced by the length of the array. Then, the rest of the array is stored like a fixed size array starting from the slot keccak256(s), where s is the original slot the array would have taken up. Dynamic arrays of arrays recursively follow this pattern, meaning an arr[0][0] would be located at keccak256(keccak256(s)), and where s is the slot the original array is stored at.
For maps, the slot remains 0, and every key-value pair is stored at keccak256(pad(key) . s), where s is the original data slot of the mapping, .is concatenation, and the key is padded to 32 bytes if it’s a value type but not if it’s a string and byte array. This address stores the value for the corresponding key, following the same rules for other storage types.
As an example, let’s look at a sample contract Storage.sol and view its storage:
All the defined values are stored starting from slot 0 in the order they are defined.
First, the flags array takes up the entire first slot. Each bool only takes 1 byte to store, meaning the entire array takes 8 bytes total.
The uint160 time is stored in the second slot. Even though it only takes 20 bytes to store, meaning it can fit in the remaining space of the first slot, it must start on the second slot since the first slot is storing an array.
The string title takes up the entire third slot, since it is a dynamic data type. The slot stores the length of the string, and the actual characters of the string should be stored starting at keccak256(2).
Next, the entire data struct takes up 2 slots. The first slot of the struct packs both the x and yuint128 values, since they each only take 16 bytes. Then, the second slot of the struct stores the dynamic bytes value.
Finally, there are two mapping values, each taking up an empty slot to reserve their mapping. The actual mapping values would be stored at keccak(pad(key) . uint256(5)) or keccak(pad(key) . uint256(6)) respectively.
Here’s a diagram visualizing the storage:
If the title or z variable contain data that is longer than 31 bytes, they would instead be stored at keccak(s), as shown by the arrows. The mapping values are stored following the defined rules above for hashing the key.
Finally, storage variables can also be declared as immutable or constant. These variables don’t change over the runtime of the contract, which saves on gas fees since their calculation can be optimized out. constant variables are defined at compile-time, and the Solidity compiler will replace them with their defined value during compilation. On the other hand, immutable variables can still be defined during construction of a contract. At this point the code will automatically replace all references to the value with the one that was defined.
Memory
Unlike storage, memory does not persist between transactions, and all memory values are discarded at the end of the call. Since memory reads have a fixed size of 32 bytes, it aligns every single new value to its own chunk. So while uint8[16] nums might only be one 32-byte word when stored in storage, it will take up sixteen 32-byte words in memory. The same splitting also happens to structs, regardless of how they are defined.
For data types like bytes or strings, their variables need to be differentiated between memory pointers or storage pointers, using the memory or storage keyword respectively.
Mappings and dynamic arrays do not exist in memory, since constantly resizing memory is very inefficient and expensive. Though you can allocate arrays with a fixed size using new <type>[](size), you cannot edit the sizes of these arrays like you can with storage arrays using .push and .pop .
Finally, memory optimization is very important, since the gas cost for memory scales quadratically with size as memory expands, rather than linearly.
Stack
Like memory, stack data only exists for the current execution. The stack is very simple, being just a list of 32-byte elements that are stored sequentially one after another. It is modified using POP, PUSH, DUP, and SWAP instructions, much like stacks in standard executables. Currently, the stack only stores up to 1024 values.
Most actual calculations are done on the stack. For example, arithmetic opcodes such as ADD or MUL pop two values from the stack, then push the result with the binary operation onto the stack.
Calldata
Calldata is similar to memory and stack data in that it only exists within the context of one function call. Like memory, all values must also be padded to 32 bytes. However, unlike memory, which is allocated during contract interactions, calldata stores the read-only arguments that are passed in from external sources, like an EOA or another smart contract. It is important to note that if you want to edit the values passed in from calldata, you must copy them to memory first.
Calldata is passed in with the rest of the data during the transaction, so it must be packed properly according to the specified ABI of the function that is being called.
Transient Storage
Transient Storage is a fairly new addition to the EVM, with Solidity only supporting the opcodes starting 2024, with the proper language implementation expected to arrive in the near future. It is meant to serve as an efficient key-value mapping that exists during the context of an entire transaction, and its opcodes, TSTORE and TLOAD. It always takes 100 gas each, making it much more gas efficient than regular storage.
The specialty of transient storage is that it persists through call contexts. This is perfect for scenarios like reentrancy guards that can set a flag in transient storage, then check if that flag has already been set throughout the context of an entire transaction. Then, at the end of the entire transaction, the guard will be wiped completely and can be used as normal in future transactions.
Despite its transient nature, it is important to note that this storage is still part of the Ethereum state. As such, it must adhere to similar rules and constraints of those of regular storage. For instance, in a STATICCALL context, which prohibits state modifications, transient storage cannot be altered, meaning only the TLOAD opcode is allowed and not TSTORE.
EIP-1153 impact analysis
Since transient storage is a relatively recent feature we were able to be comprehensive in inspecting all cases of how it has been used as of Ethereum block number 20129223. We found that from the ~250 deployed contracts containing or having libraries containingTSTORE or TLOAD opcodes, there were ~180 unique source files, meaning over 60 of these deployed contracts were duplicates deployed cross-chain.
Here is the recorded distribution of the usage of transient storage in these ~190 contracts:
Out of the around 190 unique contracts on chain that use this feature, we were able to differentiate them into 6 general categories:
First and foremost, over 50% of the usage of transient storage is on reentrancy guards. This makes sense, as reentrancy protection is the perfect use case for transient storage and is also very easy to implement, with a simple one possibly looking like:
modifier ReentrancyGuard {
assembly {
// If the guard has been set, there is re-entrancy, so revert
if tload(0) { revert(0, 0) }
// Otherwise, set the guard
tstore(0, 1)
}
_;
// Unlocks the guard, making the pattern composable.
// After the function exits, it can be called again, even in the same transaction.
assembly {
tstore(0, 0)
}
}
On the other hand, only 3.6% of the contracts used this pattern as an entrancy lock, locking the contract state between transactions to ensure that certain functions could only be called after calling other functions. Here’s a short example.
Next, around 6% of the contracts used transient storage to preserve contract context for callback functions or cross-chain transactions. This was mostly on Bridge contracts, like this one here.
8.3% of the contracts used transient storage to keep a temporary copy of the contract state to verify that certain actions are authorized. For example, this contract by OpenSea temporarily stores an authorized operator, specific tokens, and amounts related to those tokens to validate that all transfers happen as they should.
A bit less than 9% of the contracts used transient storage for their own specialized purposes. For example, an airdropping contract utilizes tstore as a hashmap to track and manage eligible recipients within the transaction context.
20% of contracts although had no transient storage opcodes in the bytecode, contained functions that utilised transient storage in the referenced libraries. Most of these libraries are openzeppelin internals such as their implementation of ERC1967 (see StorageSlot).
The introduction of transient storage marks a significant evolution in the EVM’s data management capabilities. Our analysis at Dedaub reveals that while it’s still in its early stages of adoption, transient storage is already making a notable impact, particularly in smart contract security and efficiency.
The introduction of transient storage marks a significant evolution in the EVM’s data management capabilities. Our analysis at Dedaub reveals that while it is still in its early stages of adoption, transient storage is already making a notable impact, particularly in smart contract security and efficiency.
Key takeaways from our analysis of transient storage usage include:
Reentrancy guards dominate the current use cases, accounting for over 50% of transient storage implementations. This highlights the immediate value developers see in using transient storage for cross-function state management within a transaction.
Beyond security, innovative developers are finding creative ways to leverage transient storage for storing contextual information and managing contexts throughout complex transactions.
The adoption of transient storage, while still limited, shows promise for improving gas efficiency and simplifying certain smart contract patterns.
Gas efficiency improvements
In our analysis of transient storage usage, we also evaluated its gas efficiency compared to regular storage. To do this, we collected the last 100 transactions for each of the contracts analyzed. For each transaction, we obtained its execution trace and used a Python script to simulate gas costs by replacing TSTORE operations with SSTORE under the same conditions (including cold load penalties and other storage rules).
The results were impressive: across all use cases, using transient storage led to an average gas savings of 91.59% compared to regular storage operations. Below, you can find a more detailed graph that shows gas savings per category. Interesting to note that in the case of the Specialized Functionality, gas savings of around 98.7% were recorded. This is because of the airdropping contract mentioned above, and in this case memory might have been a more adequate comparison.
Conclusion
As the Ethereum ecosystem continues to evolve, we expect to see more diverse and sophisticated uses of transient storage emerge. Its unique properties – persisting across internal calls within a transaction while being more gas-efficient than regular storage – open up new possibilities for optimizing smart contract design and execution.
Below we are publishing the dataset and scripts that were used for the above post.
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.
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.