<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:cc="http://cyber.law.harvard.edu/rss/creativeCommonsRssModule.html">
    <channel>
        <title><![CDATA[Stories by Natachi Nnamaka on Medium]]></title>
        <description><![CDATA[Stories by Natachi Nnamaka on Medium]]></description>
        <link>https://medium.com/@natachigram?source=rss-11a4cede12e7------2</link>
        <image>
            <url>https://cdn-images-1.medium.com/fit/c/150/150/1*ELc95tm-arI7Up38AnbFsg.jpeg</url>
            <title>Stories by Natachi Nnamaka on Medium</title>
            <link>https://medium.com/@natachigram?source=rss-11a4cede12e7------2</link>
        </image>
        <generator>Medium</generator>
        <lastBuildDate>Sat, 14 Nov 2026 05:30:16 GMT</lastBuildDate>
        <atom:link href="https://medium.com/@natachigram/feed" rel="self" type="application/rss+xml"/>
        <webMaster><![CDATA[yourfriends@medium.com]]></webMaster>
        <atom:link href="http://medium.superfeedr.com" rel="hub"/>
        <item>
            <title><![CDATA[DeFi Security Wrapped 2024]]></title>
            <link>https://medium.com/@natachigram/defi-security-wrapped-2024-d92b00914c07?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/d92b00914c07</guid>
            <category><![CDATA[web3-security]]></category>
            <category><![CDATA[auditing]]></category>
            <category><![CDATA[blockchain-security]]></category>
            <category><![CDATA[defi-security]]></category>
            <category><![CDATA[web3-hack]]></category>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Sat, 14 Dec 2024 17:22:30 GMT</pubDate>
            <atom:updated>2024-12-14T17:22:30.324Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*wtVfeoPa2DNqBxdaJADV6Q.jpeg" /></figure><p>Another year, another wild ride in the world of Web3 security. DeFi moved at breakneck speed this year, and with it came a wave of hacks, exploits, and lessons learned. Luckily I took notes.</p><h3>What was LOST and RECOVERED</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*gguG5aNKrYpjnvghUadGzA.jpeg" /></figure><p>Hackers exploited various vulnerabilities to steal over $1.4 billion in digital assets. While seeing such a large loss is sad, there’s a little ray of hope. Thanks to the relentless efforts of security researchers, over $105 million of the stolen funds were recovered. This represents around 7.43% of the total losses.</p><h3>Top 5 Exploits of 2024</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*YsWIVXWdhNw7r2Ikl4XnAw.jpeg" /></figure><p>Topping the list of significant hacks in 2024 is DMM, suffering losses of approximately $300 million. Following closely is WazirX, with reported losses of $230 million. In third place is Chris Larsen, whose wallet compromise resulted in a staggering $112 million loss. The fourth-largest hack targeted Munchables, with hackers making off with $62.5 million. Rounding out the top five is Radiant Capital, which experienced a $58 million loss. <a href="https://de.fi/rekt-database"><em>(source REKT Database)</em></a></p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*YjLv0SXkur9nPhO_jvUJkA.jpeg" /></figure><p>In 2024, over 200 plus hacking incidents were recorded across the Web3 landscape.</p><h3>What Attack Vectors Topped This Year</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qCAqeCjW2GEftBQZW0dciQ.jpeg" /></figure><p>Among the most prevalent Web3 attack vectors observed this year, access control issues, price manipulation, private key compromises, contract vulnerabilities, and phishing attacks emerged as the most significant threats. These attack vectors collectively accounted for a substantial portion of all security incidents within the Web3 ecosystem.</p><h3>Controversial Highlight</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*6fKNFrX_NHteAgiF3KkJFw.jpeg" /></figure><p>A lot of controversial events happen we will be looking at a few:</p><p>The “CertiK vs Kraken Saga” involved a dispute over $3 million during a bug bounty program, raising questions about how ethical the process was. The “DMM Bitcoin Hack” revealed serious weaknesses in exchange security. SushiSwap faced internal struggles with its governance, showing the challenges of managing decentralized systems. The Cosmos project drew attention due to claims of North Korean developers being involved in its code, leading to discussions about transparency and trust in open-source projects. The issue of “Required and Non-Required POCs for Audit Contest Researchers” highlighted gaps in clarity for security competitions. Lastly, the “WazirX Hack” reminded everyone of the ongoing risk hackers pose to crypto platforms. These stories reflect the growing pains of a fast-moving and sometimes unpredictable industry</p><h3>2024 Security Researchers Hall of Fame (Audit Contest Edition)</h3><p>The 2024 audit season saw a surge in the number of security researchers participating in competitive auditing platforms. These platforms provide a unique opportunity for researchers to showcase their skills, collaborate with others, and contribute to the security of emerging technologies.</p><p>Below are some of the top-performing researchers who distinguished themselves in various audit contests throughout the year:</p><h4><a href="https://codehawks.cyfrin.io/leaderboard?t=contests&amp;r=12-months&amp;sc=reward&amp;sj=reward&amp;page=1">CodeHawks</a> Top 5 👇🏾</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*mBrYJ-PJyZH520OiInmCXQ.jpeg" /></figure><h4><a href="https://code4rena.com/leaderboard?timeframe=2024">Code4rena</a> Top 5 👇🏾</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*GsVwvjutonUo9MzExUPOKQ.jpeg" /></figure><h4><a href="https://cantina.xyz/leaderboard">Cantina</a> Top 5 👇🏾</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*qVkjDs1ZHa61H7lOqWkclw.jpeg" /></figure><h4><a href="https://immunefi.com/leaderboard/">Immunefi</a> Top 5 👇🏾</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*O4fRLk46A74SDNEoCFBQvw.jpeg" /></figure><h3>Tools and Resources</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*fvCJmD-D7sU5dtirkaOeQQ.png" /></figure><p>Below are some cool stuff you might need:</p><ul><li><a href="https://github.com/Recon-Fuzz/create-chimera-app?utm_source=substack&amp;utm_medium=email">Chimera</a>: This Foundry template allows you to bootstrap a fuzz testing suite using a scaffolding provided by the <a href="https://getrecon.xyz/">Recon</a> tool.</li><li><a href="https://libmev.com/">Libmev</a>: A public resource by Cryptic Woods for exploring and analyzing MEV on Ethereum.</li><li><a href="https://key.trueblocks.io/">TrueBlocks Key:</a> TrueBlocks Key is a Web 2.0 API providing easy access to TrueBlocks Core’s comprehensive Ethereum address appearance index, covering transactions, logs, and rewards.</li><li><a href="https://app.d23e.ch/explorer">Incident Explorer</a>: A tool for exploring blockchain security incidents, including hacks, exploits, and attacks.</li><li><a href="https://docs.runtimeverification.com/simbolik/overview/getting-started">Simbolik</a>: A symbolic debugger for Solidity.</li><li><a href="https://github.com/Cyfrin/moccasin">Moccasin</a>: A fast, pythonic, Vyper smart contract testing and development framework.</li><li><a href="https://dune.com/1inch/dunescan">DuneScan</a>: the most visual tool for viewing and analyzing blockchain entities.</li><li><a href="https://app.nefture.com/">Threat Stream</a>: Monitor and overview recent blockchain alerts.</li><li><a href="https://docs.google.com/spreadsheets/d/1HgduKqtxKhhaZkx-00jEfv6oO3z0oUu2q_J6b9TGXJM/edit?gid=1578251797#gid=1578251797">Immunefi Contest Rewards Calculator</a></li><li><a href="https://rugcheck.xyz/?utm_source=substack&amp;utm_medium=email">Rug Check</a> for Solana</li><li><a href="https://lumos.chainlight.io/">Lumos</a>: A web3 security incident database</li><li><a href="https://www.rareskills.io/blog">RareSkills</a>: Blockchain education platform</li><li><a href="https://de.fi/rekt-database">REKT Database</a>: A web3 security incident database</li><li><a href="https://www.cyfrin.io/updraft">Cyfrin Updraft:</a> Web education platform</li><li><a href="https://solodit.cyfrin.io/">Solodit</a>: Explore and read previous bug findings and reports</li><li><a href="https://rekt.news/">Rekt.news</a>: Explore the latest web3 security events and news</li></ul><h3>Conclusion</h3><p>DeFi in 2024 was a mix of innovation and challenges, with over $1.4 billion lost to hacks but over $104 million recovered through persistent efforts. The year highlighted critical vulnerabilities, groundbreaking tools, and the importance of collaboration among security researchers. As Web3 evolves, the focus remains on building a safer, more resilient ecosystem in 2025.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=d92b00914c07" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Learning from the Biggest DeFi Hacks of 2023]]></title>
            <link>https://medium.com/rektify-ai/learning-from-the-biggest-defi-hacks-of-2023-1cab753ac4ea?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/1cab753ac4ea</guid>
            <category><![CDATA[web3-security]]></category>
            <category><![CDATA[smart-contract-security]]></category>
            <category><![CDATA[2023-defi-hacks]]></category>
            <category><![CDATA[defi]]></category>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Thu, 22 Feb 2024 21:06:26 GMT</pubDate>
            <atom:updated>2024-02-22T21:06:26.278Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*TDwwaPdCEI8DUZMTqbmS9g.jpeg" /></figure><h3>Introduction</h3><p>For a while now, DeFi has emerged as a transformative force in the financial sector, promising transparency, efficiency, and inclusivity. However, the growth of DeFi has not been without its challenges, particularly in the form of security threats. In 2023 alone, there were numerous instances of hacks, leading to the whole space losing almost $2 billion. This showed that there are still problems to fix in the DeFi space.</p><p>These hacks took advantage of various weaknesses, such as flash loan attacks, manipulation of arbitrage bots, problems with the code, reentrancy flaws, poor access controls, and phishing scams. They made it clear that DeFi security is a big concern and that we need to learn from these mistakes.</p><p>This article is going to take a closer look at these major 2023 DeFi hacks and pull out some important lessons for improving DeFi security. We’ll look at the details of these attacks, figure out what went wrong, and spot any patterns or common problems. The goal is to understand why these attacks happened, identify what could lead to similar incidents in the future, and suggest ways to make DeFi safer.</p><h3>Top 2023 DeFi hacks</h3><p>Let’s dive into the biggest DeFi hacks of 2023, starting from the beginning of the year and ending in December. We’ll focus on the most eye-catching hacks and give them a thorough look.</p><h3>January</h3><p>January was a chaotic start to 2023 for DeFi protocols and projects, with several major hacks leading to significant financial losses. These attacks exploited a variety of vulnerabilities, from flash loan attacks and arbitrage bot manipulation to issues with vulnerable code logic, reentrancy flaws, inadequate access controls, and phishing schemes. The cumulative financial impact of these hacks emphasized the high stakes involved in DeFi security and the urgency of learning from these incidents. In the following section, we will delve into some of the specific attacks that transpired in January, dissecting the technical aspects and extracting crucial lessons for the future.</p><ul><li><strong>GDS Chain</strong></li></ul><p>GDS Chain is a public blockchain that aims to utilize blockchain technology to enhance value transmission and contribution distribution approaches for business applications. Its native token, GDS, is a BEP20 token deployed on the Binance Smart Chain.</p><p>On January 3, 2023, the GDS chain lost about $187,000 due to a flash loan attack. The BSC lending pool for the project was compromised, thereby leading to an 84% drop in the price of GDS currency.</p><p>The root cause of the hack was a vulnerability in the settlementLpMining function of the<a href="https://bscscan.com/address/0xC1Bb12560468fb255A8e8431BDF883CC4cB3d278"> </a>GDS<a href="https://bscscan.com/address/0xC1Bb12560468fb255A8e8431BDF883CC4cB3d278"> </a>contract<a href="https://bscscan.com/address/0xC1Bb12560468fb255A8e8431BDF883CC4cB3d278">.</a> This function calculates LP mining rewards based solely on the weight of LP tokens held by users, without factoring in time. As a result, an attacker was able to redeem more rewards than entitled, draining liquidity from the GDS-USDT pair. The failure to account for the time component in reward calculations enabled the exploit.</p><ul><li><strong>Mycelium</strong></li></ul><p>Previously known as Trecer DAO, Mycelium specializes in providing data via its Mycelium Node and enables users to open leveraged long or short positions on digital assets through its Mycelium Perpetual Swaps derivatives exchange.</p><p>On January 7th, 2023, Mycelium’s ETH/USDT pool was attacked by arbitrage bots that detected an excessive spread in ETH prices on the platform and exploited it. The price discrepancy was linked to the Bitfinex API broadcasting highly volatile ETH/USDT trading pair prices around 2:45 AM AEST. The Mycelium pool suffered approximately $300,000 in losses.</p><p>Additionally, the IP address of the protocol was blacklisted by the Binance API component. This prevented Mycelium from rebalancing prices through independent feeds.</p><ul><li><strong>BRA Token</strong></li></ul><p>BRA is a token on the BSC Chain, available for trading at PancakeSwap. On January 10th, 2023, the BRA token suffered an exploit in which a hacker stole 819 WBNB, equivalent to about $225,000. The root cause was a logical vulnerability in the code that enabled the attacker to call the transfer function in a way that wrongly duplicated rewards if the sender and recipient were a matched pair. After this happened, the value of the BRA token dropped a lot, losing 98% of its value.</p><ul><li><strong>LendHub</strong></li></ul><p>LendHub is a cross-chain DeFi lending platform. On January 12, 2023, the lending platform lost about $6,000,000 due to a vulnerability in their smart contract that was exploited by a hacker.</p><p>When LendHub updated its system, it rolled out a new version of its IBSV token but didn’t properly disable the old token. There ended up being two IBSV tokens that were both active in the market and identically priced.</p><p>The attacker(s) realized they could use the two token contracts separately and take advantage of how they differed. Using the old token, they minted and redeemed assets. Then they took out loans against the new token. With the tokens calculating liabilities differently, the hacker managed to steal about $6 million from the new token’s reserves.</p><p>LendHub learned the hard way that leaving old code hanging around during an upgrade can seriously backfire.</p><ul><li><strong>Midas Capital</strong></li></ul><p>On the DeFi lending platform, Midas Capital, on January 15, 2023, lost about $650,000 to an exploit by a hacker. The hack happened because of a problem with how token prices were calculated when using certain Curve pools.</p><p>The issue had to do with read-only reentrancy, where view methods that are not supposed to change contract storage can be exploited if storage gets altered from a callback. The hacker manipulated this by using flash loans to trick the smart contracts into incorrect price calculations.</p><ul><li><strong>Omm Finance</strong></li></ul><p>The OMM protocol is a cross-chain money market. The protocol lost about $1.9 million on January 21, 2023, due to a smart contract exploit. The attacker deployed a malicious contract and, over 18 transactions, drained IUSDC, USDS, and bnUSD collateral that wasn’t theirs. After supplying the stolen USDS as collateral, they took out sICX loans.</p><p>The root issue was in Omm’s Redeem function, which accepts an address for the collateral being returned. The hacker injected a harmful contract, letting them bypass normal supply procedures and steal other users’ collateral.</p><p>The hacker used Balanced to swap much of it, skewing bnUSD and stablecoins from their $1 pegs. They also bridged IUSDC to Ethereum and Polygon through Orbit. And finally, they cashed out ICX to centralized exchanges.</p><p>While hacking for profit may sound glamorous, it severely impacts innocent users and projects. Let’s hope Omm and others learn from this and prioritize patching risky code.</p><ul><li><strong>Azuki</strong></li></ul><p>On January 27, the Twitter account of Azuki, a nonfungible token (NFT) project, was compromised, resulting in hackers stealing more than $750,000 worth of USDC. The hackers used a malicious “wallet drainer link” disguised as a virtual land mint to carry out the attack.</p><p>Within just 30 minutes of the malicious links being tweeted, the hackers managed to steal $751,321.80 in USDC from a single wallet. Additionally, the hackers also stole $6,752.62 worth of USDC from multiple wallets holding 11 NFTs and over 3.9 Ether (ETH), valued at $2,217.</p><h3>February</h3><p>January 2023 was marked by chaos, and February continued in the same vein. DeFi platforms were heavily targeted, resulting in significant losses for the funds held by hackers. These attacks leveraged a multitude of vulnerabilities, including flash loan attacks, Oracle issues, flaws in vulnerable code logic, reentrancy flaws, and inadequate access controls.</p><p>These hacks showed just how serious the risks are in DeFi, and it’s important to learn from them. We’ll look at some of the specific attacks from February in more detail.</p><ul><li><strong>BonqDAO</strong></li></ul><p>BonqDAO is a non-custodial, over-collateralized lending protocol. It allows any project or protocol to borrow against their token at a zero interest rate. It is deployed on the Polygon blockchain.</p><p>BonqDAO and AllianceBlock fell victim to an exploit, resulting in losses of around $120 million. The attack targeted a smart contract within BonqDAO.</p><p>On February 1st, 2023, BonqDAO’s protocol suffered a severe exploit, resulting in a $120 million loss. The attack capitalized on a vulnerability in the price feed system, allowing the perpetrators to manipulate the value of the WALBT token. This enabled them to borrow an excessive amount of the protocol’s stablecoin (BEUR) beyond their authorized limit.</p><p>Within a brief two-minute window, the attackers executed another crucial manoeuvre. By manipulating the Oracle price downward, they triggered a cascade of liquidations across over 30 undercollateralized borrower positions. This move yielded the attackers a substantial loot of approximately 113 million WALBT, leaving BonqDAO with a significant financial loss.</p><ul><li><strong>Platypus Finance</strong></li></ul><p>On February 16, 2023, Platypus Finance, an Automated Market Maker (AMM) protocol operating on the Avalanche network, fell victim to a security hack. The attack resulted in an estimated loss of over $8,500,887 million.</p><p>The flaw exploited by the attacker was in the collateral holding contract’s USP Platypus’ stablecoin solvency check mechanism. This vulnerability was a logic error that allowed the attacker to borrow against flash-loaned collateral and then withdraw it without repaying the debt.</p><p>The attack caused such significant damage that it led to the de-pegging of the Platypus USD stablecoin from the U.S. dollar, resulting in a 52.2% drop to $0.478 as of February 16.</p><ul><li><strong>Shata Capital EFVault</strong></li></ul><p>Shata Capital EFVault is a decentralized protocol that enables users to earn interest on their cryptocurrency holdings by providing liquidity. It operates on the Ethereum blockchain.</p><p>On February 24, 2023, an attacker exploited a vulnerability in the smart contract of the EFVault project, successfully draining $5.1 million from the protocol.</p><p>Approximately 27 days before the attack, the attacker made a 0.1 Ether deposit into the EFVault contract, acquiring a certain number of shares in the process.</p><p>The EF Vault contract underwent an upgrade before the attack, introducing new variables to key functions that were improperly configured. In the upgraded contract, the new redeem function was directly assigned by reading the wrong value from the corresponding storage location of the agent contract before the upgrade. This miscalculation resulted in excessive user withdrawable assets calculated in the redeem function. Consequently, the hacker exploited this vulnerability, calling the redeem function twice and profiting $3.43 million and $1.71 million, respectively.</p><p>The vulnerability stemmed from the fact that the initialize function of the newly implemented contract could not be called again after the upgrade, rendering it impossible to initialize the new variables.</p><p>Subsequently, the attacker converted all funds to ETH and transferred them to Tornado Cash.</p><ul><li><strong>dForcenet</strong></li></ul><p>dForce is a decentralized protocol offering a range of DeFi services, including assets, lending, and trading.</p><p>On February 10, 2023, the protocol experienced a significant loss of over $3.6 million due to a reentrancy attack. The hacker managed to steal funds by taking advantage of a vulnerability in a smart contract function related to calculating Oracle prices when connected to Curve Finance.</p><p>The vulnerability in question was a read-only reentrancy flaw. To exploit it, the attacker deposited flash-loaned funds and then withdrew their deposit. During this withdrawal, the attacker could exploit the reentrancy vulnerability, manipulating the perceived virtual price of the asset. By artificially lowering the virtual price, the attacker successfully liquidated positions held by other users in the wstETH/ETH pool, allowing them to siphon off funds.</p><ul><li><strong>Orion Protocol</strong></li></ul><p>On February 2, 2023, the Orion Protocol, a liquidity aggregator for both CeFi and DeFi exchanges, experienced a significant hack. The attack exploited a vulnerability known as a “reentrancy bug” in one of its smart contracts.</p><p>The hacker used a function called swapThroughOrionPool that allowed anyone with crafted tokens to hijack their transfer by re-entering the deposit asset function. This enabled the hacker to increase their balance without any actual cost of funds.</p><p>The attacker used a newly constructed token called ATK and a self-destructing smart contract to manipulate Orion’s pools. The hack began on the Binance Smart Chain (BSC) with an initial fund of 0.4 BNB from TornadoCash. Another part of the hack involved Ethereum and drew an initial fund of 0.4 ETH from SimpleSwap_io. After the hack, the hacker gained 1100 ETH, which they then deposited into TornadoCash while keeping 657 ETH in their account.</p><p>The total amount stolen from the hack was over 1700 ETH, which was worth over $3 million at the time of the attack.</p><ul><li><strong>Dexible</strong></li></ul><p>Dexible, a decentralized exchange platform, announced on February 16, 2023, that Dexible v2 was live. Just a day later, they were already investigating a hacking attack on their v2 contracts. Michael, one of the co-founders of Dexible, sent a message on Dexible’s Discord, stating that all contract actions had been paused as the company investigated the situation.</p><p>Powers, another co-founder of Dexible, later provided additional information, stating that the vulnerability was specific to v2 and that impacted accounts had been granted an infinite allowance to the newest contracts. This allowed the hacker to steal funds from any wallet. As a result, all v2 contracts had been paused until the vulnerabilities could be patched and redeployed.</p><p>The Dexible team later disclosed that a total of 17 traders had been affected by the hack, with 4 on Ethereum and 13 on Arbitrum. The total stolen funds stood at $2,047,635.</p><h3>March</h3><p>March 2023 was a rough month for the DeFi (Decentralized Finance) world. Several big platforms got hit hard by hackers, causing a lot of money to disappear. These attacks used different ways to break into the systems, including flash loan attacks, problems with oracles, flaws in the code, and more.</p><p>We’ll look at some of the attacks that happened in March in more detail.</p><ul><li><strong>Euler Finance</strong></li></ul><p>In March 2023, Euler Finance, a decentralized lending protocol, suffered a significant hack. The attack was attributed to a pseudonymous whitehat hacker named Kankodu, who claimed that a fix he proposed inadvertently led to the hack.</p><p>Kankodu had previously identified the Euler “first deposit bug” in July 2022 and was awarded $50,000 for his discovery. He reported the bug because it could potentially allow attackers to artificially inflate exchange rates, enabling them to withdraw all tokens.</p><p>The fix for this bug introduced an additional function to Euler’s code, “donateToReserves,” intended to bolster reserves. However, this change unintentionally led to a larger vulnerability that was exploited for nearly $200 million.</p><p>The March 13 flash-loan attack on Euler resulted in a loss of nearly $200 million across multiple assets, including $136 million in staked ether, $34 million in USDC, $19 million in wrapped bitcoin, and $8.7 million in DAI.</p><p>Following the attack, Euler’s EUL token experienced a nearly 70% decrease in value, falling to $2.07. The attacker later returned $177 million in a series of transactions in March and April, accounting for the expected “recoverable funds” from the hack after adjusting for a bounty offered by the project.</p><ul><li><strong>Monkey Drainer</strong></li></ul><p>Monkey Drainer was a wallet drainer malware that became active in August 2022 and was involved in crypto phishing scams. According to Scam Sniffer’s report, Monkey Drainer managed to steal $16 million from 18,000 victims before its activities ceased in March 2023.</p><p>Monkey Drainer was part of a broader trend of phishing scams that increased in sophistication throughout 2023, causing nearly $300 million in losses from about 320,000 victims. These wallet drainers were deployed on phishing websites, which tricked users into signing malicious transactions and subsequently drained funds from their cryptocurrency wallets.</p><p>The trend of wallet drainers saw an alarming escalation in scale and speed, with some drainers like Inferno outpacing Monkey Drainer’s theft amount significantly in a shorter time frame. After ZachXBT exposed Monkey Drainer, it announced its shutdown after six months of operation.</p><p>Wallet drainer scams often coincide with significant crypto events, such as airdrops or security breaches, exploiting these occasions to maximize their impact. Drainers typically took a 20% fee for their services.</p><ul><li><strong>SafeMoon</strong></li></ul><p>On March 28, 2023, the Safemoon exchange, which operates on the BNB chain, experienced a security breach that led to nearly $9 million being siphoned from its liquidity pool. On-chain data confirmed that approximately $8.9 million worth of assets were moved from the liquidity pool.</p><p>The incident was facilitated by a “public burn bug” introduced in a recent update to Safemoon’s system. This bug allowed the hacker to burn a large portion of SFM tokens within the liquidity pool, which artificially inflated the price of the remaining SFM tokens. The attacker exploited this inflated price by first purchasing SFM tokens, then using the public burn bug to further increase their price, and finally selling the tokens back to the liquidity pool at the higher price, effectively draining the pool’s wrapped BNB (WBNB) in a single transaction. The total profit from this exploit was greater than $8.9 million.</p><ul><li><strong>TenderFi</strong></li></ul><p>TenderFi, a decentralized finance (DeFi) lending and borrowing platform, experienced a potential hack on March 7, 2023. The platform suspended all borrowing operations due to an “unusual amount of borrowing,” indicating a possible exploit.</p><p>A known hacker with the wallet address EOA, 0x896D, gained approximately $1.58 million from the exploit. However, after investigations and attempts to contact the user, TenderFi discovered that the exploit was carried out by a whitehat hacker. In this case, the exploit revealed significant vulnerabilities in TenderFi’s system that needed immediate attention.</p><p>The incident caused a notable drop in the value of TenderFi’s token (TND), which declined from a 24-hour high of $3.77 to a seven-day low of $2.22. Despite the exposure, the company maintained that the hack was ethical, so there was no cause for alarm among users.</p><ul><li><strong>Hedera Token</strong></li></ul><p>Hedera, a public distributed network governed by 28 major corporations, was targeted by hackers, leading to the network being taken offline. The attackers targeted liquidity pools holding large amounts of tokens to enable trading on decentralized exchanges (DEXs), and some tokens were stolen.</p><p>The attack exploited the decompiling process in smart contracts, affecting many smart contracts rather than just one. The attackers used the Smart Contract Service code of the Hedera mainnet to transfer Hedera Token Service tokens held by victims’ accounts to their account.</p><p>The hack occurred between March 9–11, 2023, during which around $600,000 was exploited from the Hedera ecosystem. An ecosystem-wide collaboration led to the pausing, remediation, and replenishment of all user funds.</p><p>The hacker used the Hashport bridge to send tokens to Ethereum. When the issue was alerted, Hedera, Stader, and SaucerSwap were notified. The Hedera DevOps team then shut off proxy access to the Hedera mainnet, preventing users from accessing the mainnet and the attacker from draining additional tokens.</p><p>The next day, a code change was made for Hedera, preventing a smart contract from using a delegate call to call a precompiled contract. Within hours of the network proxy access being turned on, all USDC/USDT and USDC/WHBAR user tokens were fully restored to user accounts. Pangolin replenished affected user funds with the support of the HBAR Foundation.</p><ul><li><strong>Poolz Finance</strong></li></ul><p>March 15, 2023, Poolz Finance, a decentralized cross-chain Initial DEX Offering (IDO) platform, suffered a significant hack. The attack took advantage of an arithmetic overflow issue on the platform, allowing the hacker to drain funds from its smart contract.</p><p>The attacker exploited a vulnerability in the CreateMassPools function, which was intended to allow users to create pools in batches, provide initial liquidity, and then create the pools using the CreatePool function. The issue arose with the getArraySum function controlling the amount in the poolTransferInToken, which was used to establish liquidity in the pool. The function iterates through the startamount array and accumulates its values. However, the array sum exceeded uint256, causing the function to return. Despite this, the CreatePool function still used startamount to record the pool attributes, allowing the attacker to deposit only 1 token with an extremely large startamount value.</p><p>The attacker was able to make off with various tokens, including POOLZ, Ecio (ECIO), Adaswap (ASW), and World of Defish (WOD). They reportedly converted part of the loot into Binance Coin (BNB) but have yet to transfer it.</p><p>The multi-pronged attack happened on the Polygon blockchain and the Binance Smart Chain (BSC), and the hacker made off with more than $390,000 in multiple cryptocurrencies. Following the attack, the price of Poolz Finance’s native token, POOLZ, lost more than 93% of its market value.</p><h3>April</h3><p>April 2023 was a challenging period for DeFi, with several high-profile platforms getting hacked. These attacks used a variety of tactics, including flash loan attacks, Oracle issues, and flaws in the code. We will delve deeper into some of the attacks that took place during this time, examining how they unfolded and what steps were taken in response.</p><ul><li><strong>Mev Boost</strong></li></ul><p>On April 2, 2023, a group of MEV bots operating on the Ethereum blockchain suffered a loss of over $25 million due to an attack.</p><p>The attacker, who was a validator, tricked some of these MEV bots by replacing their regular transactions with malicious ones, leading to the theft of their funds. The attacker likely set up “bait” transactions to attract the MEV bots. Once the bots interacted with these transactions, the attacker replaced them with new, harmful ones.</p><p>Before the attack, the attacker put 32 ETH into a validator position 18 days before the incident. The attacker probably waited until it was their turn to suggest a block as a validator, which happened at the same time as the attack. They then changed the contents of the block and created a new one with their harmful transactions, which let them drain the money.</p><p>In response to the incident, the developer of the primary MEV software used on Ethereum, known as MEV-Boost, introduced a fix to prevent such incidents from happening again. The fix involves instructing relayers, a trusted intermediary party between block builders and validators, to publish a signed block before transmitting its contents to a proposer. This step was previously missing and aims to reduce the likelihood of a malicious proposer within MEV-Boost proposing a block that deviates from what they received from a relay.</p><ul><li><strong>Bitrue</strong></li></ul><p>The Singapore-based cryptocurrency exchange Bitrue experienced a hack on April 14, 2023, that resulted in the loss of approximately $23 million in digital assets. The hackers were able to exploit one of Bitrue’s hot wallets, allowing them to withdraw assets worth approximately $23 million in various currencies such as ETH, QNT, GALA, SHIB, HOT, and MATIC.</p><p>The affected hot wallet contained less than 5% of Bitrue’s overall reserves, leaving the rest of the wallets secure and unaffected by the breach.</p><p>This is not the first time Bitrue has experienced a hack. In 2019, the exchange lost around $4.2 million in user assets due to a similar exploitation.</p><ul><li><strong>Yearn Finance</strong></li></ul><p>Yearn Finance, a yield aggregator on the Ethereum blockchain, got hacked on April 13, 2023, and lost around $11.54 million. The hack happened because of a mistake in the yUSDT vault. Instead of using the correct token, they used a different one, which let the hacker make lots of yUSDT tokens.</p><p>The attack process began with the attacker funding their wallet using Tornado Cash. They took a flash loan of 5M DAI, 5M USDC, and 2M USDT, and deposited these funds into the yUSDT contract. The attacker then redeemed yUSDT and withdrew all assets from the Aave V1 vault. They minted bZxUSDC and sent it to the contract, which increased the price of each share. The attacker triggered a rebalance, which led to the redemption of bZxUSDC into USDC, effectively reducing the value per yUSDT to zero. The attacker then deposited 1 wei of USDT to the yUSDT contract, allowing them to mint over 1 quadrillion yUSDT tokens. The yUSDT was swapped for USDT, USDC, and DAI in Curve pools. After paying back the borrowed flash loan, the attacker kept most of the stolen funds</p><p>This hack could have been prevented if proper validation and confirmation of the Fulcrum address had been performed before deployment.</p><ul><li><strong>Hundred Finance</strong></li></ul><p>On April 15, 2023, Hundred Finance, a multi-chain lending protocol, lost around $7 million to attackers.</p><p>The hack was executed by manipulating the exchange rate between Ethereum ERC-20 and hTOKENS, which are interest-bearing, tokenized representations of user deposits on Hundred Finance’s platform.</p><p>The attack process began with the attacker donating a large amount of wrapped Bitcoin to the smart contract on Hundred Finance that determined the exchange rate between wrapped Bitcoin and Hundred Finance wrapped Bitcoin (hwBTC). This inflated the exchange rate, after which the attacker took out a large loan and was then able to get the amount they had donated back by redeeming a relatively small amount of Hundred Finance Wrapped Bitcoin.</p><p>The attacker was able to withdraw more tokens than they had deposited to Hundred Finance. The attacker flash-loaned 500 $WBTC, then called the redeem function to redeem the previously staked 0.3 WBTC. Next, Attack Contract 1 sent 500.3 WBTC to Attack Contract 2. Contract 2 used 4 BTC to mint 200 hWBTC. The redeem function was then called to redeem the 4 BTC. Here, the attacker can redeem the 4 WBTC previously staked with less than 200 hWBTC. At this point, the attacker had a very small amount of hWBTC left on contract 2. Attack contract 2 then sent 500.3 WBTC to the hWBTC contract and borrowed 1021.91 ETH via the remaining 2 hWBTCs. Finally, Attack Contract 2 repaid the previous debt by using 1 hWBTC and withdrew 500.3 WBTC from the contract.</p><p>After the hack, the attacker bridged most of the stolen funds to ETH, where centralized stables USDT and USDC were swapped or deposited into Curve.</p><ul><li><strong>Terraport Finance</strong></li></ul><p>Terraport Finance is a DeFi platform on the Terra Classic Network. It was hacked on April 10, 2023, leading to a loss of approximately $3.9 million. The hack was made possible due to a mathematical weakness in the algorithm used to calculate LP prices.</p><p>The attacker exploited this weakness by adding a small amount of liquidity to the protocol and then manipulating the LP share price. This allowed them to withdraw a large amount of liquidity.</p><p>Two pools were affected by the hack. The first pool was drained for 9,148,426 TERRA tokens, valued at approximately $1.8 million, and 15,100,861,997 LUNC tokens, worth $1.88 million. The second pool was drained for 576,736 TERRA tokens, valued at approximately $115K, and 5,487,381 USTC tokens, worth $117K.</p><ul><li><strong>Ovix</strong></li></ul><p>The OVIX protocol is a polygon-based lending protocol. It fell victim to a major exploit that resulted in a loss of at least $2 million. The attacker manipulated the price of the vGHST token, a staking token for the Aavegotchi blockchain gaming project, to obtain substantial loans.</p><p>The attacker exploited the protocol using the vGHST token, initially borrowing stablecoins to gain access to the vGHST lending pool and the OVIX lending platform. This led to a significant increase in the value of the native token $GHST, with its value shooting up by as much as 24.7% in less than half an hour.</p><ul><li><strong>Merlin DEX</strong></li></ul><p>Merlin DEX, a decentralized exchange built on zkSync, suffered a hack on its liquidity pool on April 26, 2023, resulting in a loss of approximately $1.82 million. This incident occurred shortly after the platform’s public sale of its token went live.</p><p>One of the exploiters, identified as 0x2744, managed to withdraw around $850,000 worth of USDC tokens from the zkSync platform and bridge them to Ethereum. Another address, starting with 0x2744d62, also participated in the exploit, taking away $844,000 USDC.</p><p>Additionally, the exploiter sent $133,800 USDC to MEXC Global and $31,000 USDC to Binance.</p><p>This incident comes after a recent audit by Certik, which completed a re-audit of Merlin’s codebase’s security on April 24. According to Certik’s website, there were no critical findings in the audit report. Certik tweeted that it is investigating the incident and that its initial findings suggest a potential issue with private key management.</p><ul><li><strong>Sentiment</strong></li></ul><p>Sentiment, a decentralized finance (DeFi) lending platform, was hacked in April 2023. The attack resulted in the theft of nearly $1 million in various tokens, including wrapped Bitcoin and Ether.</p><p>The attacker exploited a re-entrance vulnerability to steal the tokens and then switch them to the Ethereum chain. The attacker borrowed assets with a tilted price in the fallback function, which reduced demand but left the pool balances of Wrapped Bitcoin (WBTC), Wrapped Ether (WETH), and Uniswap (USDC) unchanged. This allowed the attacker to borrow many assets at the slanted price.</p><h3>May</h3><p>May 2023 experienced several hacks on high-profile platforms. These attacks used various strategies, including rug-pulling investors, exploiting technical flaws, flash loans, and manipulating governance systems. We will delve into four key incidents that transpired during this period, detailing the circumstances surrounding each and the responses that followed.</p><ul><li><strong>Fintoch</strong></li></ul><p>In May 2023, a popular online investment platform called Fintoch Rug pulled people out of about $31.6 million. Fintoch claimed to be supported by Morgan Stanley, a well-known company and promised high daily returns of 1%. But later, Morgan Stanley said they didn’t support Fintoch, making people doubt the platform.</p><p>The people behind Fintoch set up a public sale and collected a lot of USDT in a special smart contract. When they collected enough USDT, they traded these tokens for USDT, causing the token’s price to drop dramatically. This left investors with useless tokens.</p><p>The people who did this tricked people into thinking they had a real CEO, Bob Lambert, who was an actor named Mike Provenzano. They used him to pretend that the platform was real.</p><p>The Monetary Authority of Singapore warned investors about Fintoch on May 4, 2023. On May 13, 2023, Fintoch held an event in Dubai to announce the launch of their token. But on May 22, 2023, the people behind Fintoch stole over 31 million USDT from the fundraising smart contract.</p><ul><li><strong>Jimbos Protocol</strong></li></ul><p>On the 28th of May, Jimbo&#39;s Protocol, an arbitrum-based project, was hacked, costing the platform around $7.5 million in stolen Ether. The hack was made possible due to a flaw in the smart contract of the project, specifically a lack of slippage control. Without this control, the liquidity invested in the protocol was allowed to use price ranges that didn’t need to be equal.</p><p>The attackers started by creating a swap that was intended to upset the balance of a trading pair. They then used a shift function to push investments into the now-unbalanced pair. With a final reverse swap, they were able to take advantage of the imbalance they had created, extracting profits from the protocol.</p><p>Due to the absence of proper slippage controls, the attacker was able to steal $7.5 million from the newly launched protocol, causing the value of its token to drop by 40%. After the attack, the attacker moved their stolen funds to the Ethereum network using the Stargate bridge and Celer Network.</p><ul><li><strong>Deus Finance</strong></li></ul><p>On May 5, 2023, the Deus Finance protocol, which operates on the Ethereum Mainnet, Arbitrum, and BNB Chain, experienced a major hack. This incident was caused by an implementation error in the token contract, leading to the unauthorized burning and transfer of tokens.</p><p>Deus Finance is a protocol that acts as a peer-to-peer bilateral Over-The-Counter (OTC) infrastructure platform. It facilitates the on-chain trading of digital derivatives, options, and swaps. The stablecoin DEI is integral to its ecosystem, being used as collateral for various third-party financial instruments within the platform.</p><p>The core vulnerability that triggered the Deus Finance hack was a coding error within the DEI token contract. Specifically, there was an issue with implementing the token’s allowance mechanism. This error allowed an attacker to burn tokens from any holder’s account without requiring approval. The problem arose in the contract’s burnFrom function, where the _allowances mapping order was incorrectly reversed. Consequently, the attacker could use their allowance to authorize themselves to burn tokens from another user’s address.</p><p>This flaw enabled the attacker to manipulate the allowances and extract tokens, resulting in a loss of over $5 million from Arbitrum, about $1.3 million from BNB Chain, and $135,000 from Ethereum.</p><p>The stolen funds were initially moved through various addresses, and some were returned following the hacker’s discussions with the Deus Finance team.</p><ul><li><strong>Tornado Cash Governance</strong></li></ul><p>Tornado Cash, a decentralized protocol that allows for private transactions on Ethereum, was exploited on May 20, 2023, due to a vulnerability in its governance system. The governance system of Tornado Cash enables the community to vote on proposals, which, if passed, are executed and can change the protocol’s parameters.</p><p>The exploit occurred because an attacker was able to leverage the CREATE2 opcode for deterministic deployment and then used the self-destruct function to remove a legitimate proposal. After the legitimate proposal was removed, the attacker deployed a new malicious proposal contract to the same address with parameters that would grant them control over the governance system.</p><p>The malicious proposal looked similar to a previously passed proposal but included a self-destruct function that was executed to deploy new, malicious code to the proposal’s address. This malicious code, once executed via a delegate call, allowed the attacker to assign approximately 1.2 million votes to addresses they controlled, which outnumbered the existing 700,000 votes in the contract.</p><p>With control over the governance system, the attacker could take various actions, such as draining staked TORN tokens and manipulating the Tornado Classic Router contract to reroute deposits and withdrawals. They also compromised the Nova contracts. In total, the attacker stole approximately $2,173,500 from the protocol by washing away funds worth around 372 ETH via the Tornado Cash Router.</p><h3>June</h3><p>In June 2023, a series of hacks affected various DeFi platforms, leading to substantial losses. These attacks leveraged a range of vulnerabilities, including flash loan attacks, Oracle issues, flaws in vulnerable code logic, reentrancy flaws, and inadequate access controls.</p><p>DeFi platforms were heavily targeted during this period, with some of the major attacks including Atomic Wallet, Pink Drainer, Atlantis Loan, Sturdy Finance, Midas Capital, and Themis Protocol.</p><p>We’ll delve deeper into some of the specific attacks in the following sections, examining each case in detail.</p><ul><li><strong>Atomic Wallet</strong></li></ul><p>In June 2023, Atomic Wallet suffered a significant security breach, known as the “June 3 hack.”. This hack was reportedly one of the largest of the second quarter of 2023.</p><p>The hack resulted in a loss of over $100 million. The victims of the hack reported being blocked by the Atomic Wallet team on social media platforms like Reddit and having their posts removed.</p><p>Some victims were also unable to receive compensation for their losses. For example, a user named Steven E. lost $300 due to an extended exchange process that lasted nine hours. When he attempted to get compensation, Atomic Wallet set the Ether price twice lower than its actual value.</p><p>The Atomic Wallet team’s handling of the situation has been criticised. They have consistently published the same statement about the hack without providing any detailed information or statistics about the incident. This has led to accusations of the team covering up the extent of the hack and even stealing from its users.</p><ul><li><strong>Pink Drainer</strong></li></ul><p>The Pink Drainer is a hacking group that stole approximately $3 million in assets across various blockchain platforms. This criminal group executed their attacks by sending phishing links through compromised Discord accounts and tricking users into opening malicious websites and signing malicious signatures, which led to the loss of their assets.</p><p>The hacking incidents involved a large number of Discord and Twitter hacks, including high-profile victims such as the OpenAI CTO and Orbiter Finance. ScamSniffer’s analysis linked Pink Drainer to almost all Discord hacks in the preceding month, with the group having a total of about 1,932 victims across chains like Mainnet, Arbitrum, BNB, Polygon, and Optimism.</p><p>Pink Drainer employed social engineering attacks to gain access to many projects. They impersonated well-known media outlets and used a process that included interviews and a final KYC authentication step, which embedded phishing related to Discord. The attacks involved guiding Discord administrators to open a malicious Carl verification bot and convincing them to add bookmarks containing malicious JavaScript code, which stole the user’s Discord token.</p><p>After successfully gaining access, the group took steps to extend their control: they eliminated other administrators, made the malicious account an administrator, and participated in actions that caused Discord to block the main account, making it difficult to remove phishing messages.</p><p>Among the notable victims was the address 0xf529127107c91bbf6c141304718491a437fb2f5f, which lost nearly $320,000 in NFTs, including Otherside Koda, BoredApeYachtClub, MutantApeYachtClub, and Otherdeed. The address that transferred the assets was resolved as pink-drainer.eth a few hours after the incident, which led to the group being named Pink Drainer.</p><ul><li><strong>Atlantis Loan</strong></li></ul><p>The Atlantis Loans hack occurred on June 7, 2023, causing a loss of approximately $2.5 million. Atlantis Loans was a lending protocol on the Binance Smart Chain (BSC) that was abandoned earlier in 2023. The hack was executed through a governance attack, taking advantage of the project’s abandoned status and limited attention.</p><p>The attacker designated themselves as the administrator of the token’s proxy contract. On June 7, 2023, the attacker initiated a harmful governance proposal within the GovernorBravo contract, which resulted in setting multiple ABep20Delegator contracts’ administrators as malicious contracts. The attacker was able to execute the proposal once the time lock expired. After a lockup period of 172,800 seconds, the malicious contract was appointed as the proxy contract administrator for all tokens. Subsequently, the attacker modified the ABep20Delegate implementation address to the contract containing the backdoor.</p><p>As a result of the project being abandoned, there were no user deposits left in the system, but there were still many users that had active approvals granted to the Atlantis Loans smart contracts. The attackers were able to drain over $2.5 million from these users by using the updated smart contracts to drain the approved funds.</p><ul><li><strong>Sturdy Finance</strong></li></ul><p>The Sturdy Finance hack occurred on June 12, 2023. It was a reentrancy attack that resulted in a loss of approximately 442 ETH, equivalent to $800k in value. Sturdy Finance is a decentralized finance (DeFi) lending protocol that allows lenders to earn yields from the farming profits that borrowers make.</p><p>The attacker exploited a vulnerability in the Balancer Vault, which was discovered in February 2023. The attacker used a flash loan of 110,000 ETH tokens to manipulate the price of B-wst-ETH, causing it to surge from approximately 1 ETH to 3 ETH. Then, the attacker used B-wst-ETH as collateral to borrow WETH from Sturdy Finance. The attacker executed this operation five times in a single transaction.</p><p>The attacker’s contract had a fallback method that was triggered when the liquidation process was nearing completion. Within this method, the attacker used their 233.348 B-wst-ETH as collateral. At this point, the price of B-wst-ETH skyrocketed to 3.008 ETH, allowing the attacker to easily secure collateral at 2.2 times their borrowed WETH.</p><p>The attacker’s strategy involved creating a new contract each time and draining the pool’s entire balance. As a result, Sturdy Finance’s contract had to liquidate the collateral to minimize losses. The attacker repeated this process until the pool’s balance was depleted.</p><p>This attack highlighted several vulnerabilities in Sturdy Finance’s contracts. The getAssetPrice function in SturdyOracle.sol was manipulated by the attacker to inflate the price of B-wst-ETH. The getRate function, which was called within the _get function, was found to be susceptible to this attack. During the withdrawal process, totalSupply() was not accurately calculated, leading to an artificially inflated price.</p><ul><li><strong>Midas Capital</strong></li></ul><p>The Midas Capital on July 6, 2023, was hacked. The attacker exploited a rounding issue in the company’s lending protocol, resulting in a loss of approximately $600,000. The attacker was able to manipulate the system to bypass the debt ceiling on borrowing ankrBNB collateralized by HAY/BUSD LP tokens.</p><p>The hacker initially supplied $689,000 worth of ANKR collateral and borrowed 115 ankrBNB (worth approximately $28,700) from the pool, which they supplied back from another contract. This action bypassed the debt ceilings on borrowing ankrBNB collateralized by HAY/BUSD LP Tokens.</p><p>Using the newly obtained collateral, the hacker borrowed a smaller amount of ANKR (around $13,500) to repay the flash loan fees. The hacker then redeemed the supplied $689,000 worth of ANKR, leaving $519,000 worth of collateral and $320,000 worth of debt in the pool.</p><p>The hacker chose to withdraw 519.13 LP tokens out of the currently held 259,826.61 LP tokens in the market due to a specific calculation. However, there was a bug in the system, causing the calculation to round down to just 1 wei instead of rounding up to 2 wei.</p><p>The hacker then performed self-liquidations. When the value of the partially damaged LP tokens reached approximately $30,000, they utilized 90.9 out of the 115 ankrBNB they had supplied to settle their outstanding debt. This self-liquidation process allowed them to take possession of the LP tokens and redeem them for the remaining value they held.</p><p>In response to the hack, Midas Capital locked the protocol, contacted the authorities, and sent the hacker a message for a bounty in exchange for the returned funds.</p><ul><li><strong>Themis Protocol</strong></li></ul><p>The Themis Protocol hack occurred on June 27, 2023, due to a price manipulation vulnerability, leading to a loss of approximately $365,000. The Themis Protocol is a decentralized, multi-chain-supported peer-to-peer lending and borrowing platform.</p><p>The attacker initiated a flashloan of 22,000 ETH from Aave, borrowed an additional 10,000 ETH from one Uniswap pool and 8,000 ETH from another Uniswap pool, and deposited the borrowed 22,000 ETH. In return, they borrowed DAI, USDT, USDC, ARB, and WBTC. The attacker then withdrew 55 ETH and created a new contract.</p><p>The 55 ETH was added to a Balancer pool, resulting in the attacker obtaining B-wstETH-WETH-Stable-gauge LP tokens. Using the corresponding pool on Balancer, they swapped WETH for wstETH. By manipulating the token quantities in the pool via the swap operation, the attacker could increase the LP token’s price and subsequently borrow 317 ETH.</p><p>The attacker then borrowed an additional 10,000 ETH from one Uniswap pool and 8,000 ETH from another Uniswap pool. The borrowed 22,000 ETH was deposited again, and in return, they borrowed DAI, USDT, USDC, ARB, and WBTC. Afterwards, they withdrew 55 ETH and created a new contract.</p><p>The attacker’s success was due to his ability to artificially manipulate the price of the token through a flawed oracle. The incident highlights the importance of the security of Price Oracle for DeFi protocols. It suggests that using trusted price oracle services that aggregate price data from multiple sources and guard against manipulation can help mitigate such exploits.</p><h3>July</h3><p>Starting in the second half of 2023, the month of July experienced lots of major hacks. These attacks exploited a variety of vulnerabilities, ranging from flash loan attacks, Oracle issues, flaws in vulnerable code logic, reentrancy flaws, and inadequate access controls. Major DeFi platforms like Multichain, Vyper Compiler, CoinsPaid, Bald, Alphapo, Poly Network, and Eralend were among those heavily targeted.</p><p>This report will delve deeper into these specific attacks, providing a detailed analysis of each case.</p><ul><li><strong>Multichain</strong></li></ul><p>On July 6, 2023, MultiChain faced a significant hack that led to the unauthorized withdrawal of an estimated $126 million in digital assets.</p><p>The hack occurred through several token bridges, leading to a significant outflow of assets. The affected bridges included MultiChain’s Moonriver bridge contract, which saw $6.8 million in token outflows with nearly all its wBTC, USDT, USDC, and DAI going to a specific address. Another bridge, identified as MultiChain’s Dogecoin bridge, experienced over $600,000 in outflows of USDC.</p><p>One theory proposed for the hack involves a potential compromise of the private keys used to approve transactions travelling over the bridge. Given that the attack impacted multiple bridges and doesn’t appear to be related to vulnerabilities discovered during the project’s smart contract audits, this theory suggests that the private keys might have been compromised.</p><ul><li><strong>Vyper Compiler</strong></li></ul><p>On July 30, 2023, a critical vulnerability was identified in the Vyper compiler versions 0.2.15, 0.2.16, and 0.3.0, affecting several DeFi protocols. The vulnerability was related to faulty reentrancy protections, which were supposed to stop smart contracts from making recursive calls. The reentrancy guard failed because it set different storage positions depending on the function that was calling it, rendering them ineffective.</p><p>The exploit involved the exploitation of certain Curve pools. The exploiter of these protocols called the add_liquidity and remove_liquidity functions interchangeably, thus bypassing the reentrancy guard. The decompiled Vyper Pools deployed contract code showed that different storage slots in stor_0 and stor_2 were used as reentrancy locks, thus rendering the reentrancy lock ineffective.</p><p>The exploit resulted in a total loss of approximately $73.5 million worth of assets. Following the occurrence of the incident, several MEV bots were reported to have front-runned some of the exploits.</p><ul><li><strong>CoinsPaid</strong></li></ul><p>CoinsPaid, a leading cryptocurrency payment provider, suffered a significant hack on July 22, 2023, that led to the theft of $37.3 million USD. The attack was suspected to be orchestrated by the Lazarus Group, a powerful hacker organization known for its sophisticated methods and large-scale attacks.</p><p>The attack was meticulously planned and involved tricking a critical employee into installing software to gain remote control of a computer, allowing the hackers to infiltrate and access CoinsPaid’s internal systems. The hackers spent six months studying and tracking CoinsPaid, employing tactics such as bribery, fake hiring, and social engineering to achieve their goals.</p><p>Once inside, the hackers leveraged a vulnerability in the cluster to open a backdoor. They then used this access to create authorized requests to withdraw funds from CoinsPaid’s hot wallets. Although the hackers could not breach the hot wallets and acquire private keys to access funds directly, they were still able to steal a significant amount of money.</p><p>Despite the attack, client funds were not affected and remained fully available. CoinsPaid’s internal security measures triggered an alarm system, allowing the company to swiftly stop malicious activity and remove the hackers from the company’s perimeter.</p><ul><li><strong>Bald Rugpull</strong></li></ul><p>The BALD token rug pull happened on July 31, 2023. It was a meme coin that initially saw a surge in value but then experienced a drastic drop. This was attributed to a liquidity drain, with a massive amount of liquidity, equivalent to $22 million, disappearing from the market.</p><p>The deployer of the BALD token claimed that they hadn’t sold any tokens since deployment and were not involved in the alleged scam. However, suspicions arose due to their association with Sam Bankman-Fried, the former CEO of FTX, and the movements of large amounts of Ethereum (ETH) between FTX and the BALD project.</p><ul><li><strong>Alphapo</strong></li></ul><p>Alphapo, a crypto payment platform used by various gambling services, including Bovada, HypeDrop, and Ignition, was hacked on July 22, 2023, resulting in their losing about $22.8 million.</p><p>The hot wallet private keys of Alphapo were leaked to execute the attack. Once the attackers gained access to these keys, they could create transactions transferring value from these wallets to their accounts.</p><p>The stolen assets totalled around $22.8 million. This included over 6 million USDT, 108k USDC, 100.2 million FTN, 430k TFL, 2.5k ETH, and 1,700 DAI. Interestingly, all of these funds were consolidated at the same address before being moved across different cryptocurrency blockchains via cross-chain bridges.</p><ul><li><strong>Poly Network</strong></li></ul><p>On July 20, 2023, Poly Network was hacked. The attacker exploited a flaw in the smart contracts of the project, allowing them to mint tokens valued at around $43 billion.</p><p>The attack was executed by creating a malicious parameter, which included a counterfeit block header and validator signature. This enabled the attacker to circumvent the bridge’s validation process and withdraw tokens from the bridge to their address.</p><p>The attack resulted in the attacker withdrawing assets from the bridge contract that didn’t exist. The attacker exploited 57 different cryptocurrencies across 10 different blockchains. Their account ended up holding an estimated $43 billion in stolen assets.</p><p>However, despite this massive balance, the attacker couldn’t withdraw it. Limited liquidity meant that the attacker could only steal an estimated $10 million from the protocol.</p><ul><li><strong>Erelend</strong></li></ul><p>The decentralized lending protocol Eralend, hosted on zkSync, fell victim to a hack. An attacker leveraged a read-only reentrancy vulnerability in Eralend’s smart contracts, allowing them to repeatedly call a vulnerable function within a single transaction. This exploitation of the reentrancy vulnerability enabled the attacker to manipulate the token values tracked by the project’s internal oracle, draining an estimated $3.4 million from the smart contract’s USDC assets.</p><p>The vulnerable smart contract included code taken from SyncSwap that contained vulnerabilities. The vulnerable function included a comment that noted that the function waited to update reserve values, which is what created the read-only reentrancy vulnerability. However, this code was left untouched, leaving the protocol vulnerable to attack.</p><p>The attacker took a flash loan of approximately 14,080,109 USDC and 7,566 ETH and deposited them in the SyncSwapVault vault. The read-only reentrancy manipulated the Oracle price, allowing the attacker to borrow more assets than they were supposed to. The loan against this borrowed amount was repaid using the calculations from the updated reserves; thus, the difference amount after repaying the flash loan was held as profits for the attacker.</p><p>The stolen funds have so far been bridged to eight different wallets on the Ethereum, Arbitrum, and Optimism chains.</p><h3>August</h3><p>August 2023 experienced a series of hacks that led to substantial losses. These attacks exploited various vulnerabilities, including flash loan attacks, oracle issues, flaws in vulnerable code logic, reentrancy flaws, and inadequate access controls. This section will explore some of the notable attacks that occurred in August 2023.</p><ul><li><strong>Exactly Protocol</strong></li></ul><p>August 18, 2023, the Exactly Protocol, a DeFi project built on the Optimism blockchain, was hacked, resulting in a loss of over $7 million. The attack was made possible due to a flaw in the protocol’s contracts.</p><p>The hack was facilitated by weak validation checks. The attacker managed to circumvent the permit check on the DebtManager peripheral contract by supplying it with the address of a fake market contract.</p><p>Once the malicious contract was in place, the attacker performed a malicious deposit function, gaining access to the funds users had deposited into the protocol’s contracts. Consequently, the attacker managed to pilfer approximately $7.3 million worth of ETH from the project.</p><ul><li><strong>Magnet Finance</strong></li></ul><p>On August 28, 2023, Magnate Finance, a lending protocol on the BASE chain, rug pulled, resulting in a loss of approximately $5.3 million to its users. Shortly after on-chain analyst ZachXBT issued a warning, the protocol’s website and Telegram group were rendered unavailable.</p><p>Magnate Finance altered the provider of the price oracle and removed all the assets.</p><p>This event was linked to the deployer of Magnate Finance, who was also involved in the Solfire exit scam. The deployer’s address was found to match that of the Solfire exit scam, further confirming the connection.</p><p>Following the incident, Magnate Finance’s MAG token saw an 86% drop in value.</p><ul><li><strong>Zunami Protocol</strong></li></ul><p>The Zunami Protocol, a decentralized yield aggregator, experienced a major hack on August 13, resulting in a loss of around $2.1 million. The attacker used price manipulation, exploiting a vulnerability in the protocol’s contracts.</p><p>The attack was executed through a series of flash loan attacks. In this case, the attacker manipulated the value of a pool by continuously buying and selling the same asset to artificially inflate its price.</p><p>The Zunami Protocol’s smart contract contained a calcTokenPrice function that determined the value of the project’s tokens by dividing the total holdings of its pool by the number of existing tokens. This calculation method made it possible for the attacker to inflate the token value either by increasing the value of the pool or decreasing the total number of tokens.</p><p>The attacker inflated the pool’s value by donating to the pool. Once this was done, the tokens that the attacker held would have a much larger perceived value. This enabled the attacker to drain approximately $2.1 million worth of tokens from the project’s pools.</p><ul><li><strong>Balancer Pools</strong></li></ul><p>The Balancer team announced a critical vulnerability affecting its boosted pools on August 22, 2023. Assets deployed on Ethereum, Polygon, Arbitrum, Optimism, Avalanche, Gnosis, Fantom, and zkEVM were at risk. Initially, only 1.4% of its total assets were at risk, representing over $5 million worth of asset exposure.</p><p>Despite the prompt action of liquidity providers (LPs) to withdraw funds from the affected pools, the vulnerability was exploited for approximately $979,000 less than a week after the initial announcement. This exploit occurred through multiple flash loan attacks, where an attacker borrows a large amount of cryptocurrency from a DeFi platform, manipulates affected pools, and siphons funds from them, all within the same transaction.</p><p>As a result, the Balancer team urged users to withdraw funds from the at-risk liquidity pools to protect against further losses. However, 0.08% of the total TVL ($565,199) remained at risk, with users advised to withdraw ASAP using the user interface.</p><p>The founder and CTO of the cryptocurrency security company Cyvers, Meir Dolev, discovered the attacker’s Ethereum address, which since the vulnerability was revealed has received three transfers of DAI stablecoin totaling about $979,420.</p><ul><li><strong>Speadefi</strong></li></ul><p>On August 7, 2023, Steadefi, a DeFi platform known for its leveraged yield aggregation, fell victim to a hack. The attacker managed to get hold of the private keys used to manage the project’s deployed contract, leading to a loss of nearly $1.1 million.</p><p>The attack started with the attacker gaining access to the private key of the protocol’s deployer wallet, which held access to all the project’s smart contracts. This gave the attacker access to functionalities reserved only for the owner.</p><p>Once they had access to these owner-exclusive features, the attacker transferred the ownership of the smart contracts to their accounts. They then used these privileges to lend out all the funds in the contract’s lending vaults to their accounts, effectively draining $1.1 million from the protocol.</p><p>It’s important to note that the protocol’s depositor and strategy vaults didn’t have these owner-exclusive functionalities. Therefore, funds stored in these vaults remained unaffected by the hack. The attacker also managed to pause certain contracts, leaving the funds stuck inside them.</p><p>After the hack was discovered, the Steadefi team offered a bug bounty to the attacker in exchange for the return of the stolen funds.</p><ul><li><strong>Cypher Protocol</strong></li></ul><p>The Cypher Protocol was hacked on August 7, 2023. The hacker took advantage of a flaw in the project’s smart contracts to steal around $1 million from the project.</p><p>The Cypher Protocol operates on a unique structure where a primary user account, known as CypherAccounts, can attach multiple CypherSubAccounts. These sub-accounts store data linked to the primary account. By default, all sub-accounts are interconnected with the master account, enabling a deposit into one to serve as collateral for a loan from another.</p><p>However, the protocol has a feature that allows a sub-account to operate independently, although this function can be disabled. A bug in the system triggered when switching to this independent mode resulted in the master account failing to recognize this change.</p><p>Additionally, a coding glitch affected margin checks before granting a loan. This error, coupled with the absence of active Oracle price feeds, enabled users to borrow when they shouldn’t have been able to.</p><p>The hacker leveraged this vulnerability across various primary accounts, leading to the extraction of approximately $1 million worth of assets from the Cypher Protocol.</p><ul><li><strong>RocketSwap</strong></li></ul><p>RocketSwap, the second-largest decentralized exchange on Base, was hacked on August 14, 2023, for around $866,500 due to a private key compromise from their online servers. The hackers managed to drain the farm of the project’s governance tokens, RCKT and Wrapped Ethereum (WETH), and later converted RCKT tokens to approximately 471 ETH worth $866,500.</p><p>The hack was carried out through a brute-force attack on the server where the team stored its private keys. When the launchpad was first deployed, the team used offline signatures and stored the private keys on the server, which turned out to be a vulnerability that the hackers took advantage of.</p><p>After the hack, the RocketSwap team took several steps to mitigate the damage and secure their platform. They confirmed the hack and shut down the farm. They also revoked and waived the minting rights for new positions.</p><ul><li><strong>LeetSwap</strong></li></ul><p>LeetSwap experienced a hack on August 1, 2023, due to an access control vulnerability on the base platform. This led to a loss of over 342.56 ETH (628,583 USD). To carry out the attack, the public _transferFeesSupportingTaxTokens function was manipulated to change the pool’s behaviour. The attacker transferred token A using this function, invoked the sync function to increase the price of token A, swapped token A back for $WETH, and drained the pool, likely benefiting significantly from this operation.</p><p>The vulnerability was caused by an incorrectly assigned public visibility specifier to a function. This allowed anyone to invoke a call to this function to transfer tokens from the contract to the fee-collection address.</p><h3>September</h3><p>September 2023 witnessed a series of high-profile hacks. These attacks exploited a range of vulnerabilities, including flash loan attacks, Oracle issues, flaws in vulnerable code logic, reentrancy flaws, and inadequate access controls. This section will delve deeper into some of the notable attacks that took place during this period.</p><ul><li><strong>Mixin Network</strong></li></ul><p>The Mixin Network, a protocol designed to address blockchain scalability issues, was hacked in September 2023. The database of Mixin Network’s cloud service provider was attacked by hackers on September 23rd, resulting in the loss of some assets on the mainnet.</p><p>The hack resulted in a loss of $142,041,764 million.</p><p>Mixin Network is a service similar to a layer-2 protocol, designed to make cross-chain transfers cheaper and more efficient. However, it is reliant on a centralized database, creating a single point of failure.</p><p>After the breach, Mixin Network temporarily suspended deposit and withdrawal services. These services were reopened once the vulnerabilities were confirmed and fixed.</p><p>This hack is considered the biggest theft in the crypto world in 2023</p><ul><li><strong>CoinEx</strong></li></ul><p>In September 2023, the Hong Kong-based cryptocurrency exchange CoinEx suffered a significant security breach, resulting in the theft of over $70 million in tokens. The breach was due to compromised private keys, which allowed hackers to gain access to the exchange’s hot wallets.</p><p>The hackers first flagged “anomalous withdrawals” from one of the hot wallets on September 12, starting with a transfer of 4,947 Ether (ETH). They then began withdrawing large amounts of other tokens to the same address. The value of the stolen funds was first estimated at $27 million but has since doubled.</p><p>After being notified of the incident, CoinEx suspended its withdrawal service to avoid further losses, patched system vulnerabilities and transferred the remaining assets from the affected hot wallets. The exchange planned to resume withdrawals progressively within seven working days.</p><p>The hackers responsible for the breach were suspected to be the North Korean Lazarus Group. Despite the large amount of cryptocurrency stolen, CoinEx claimed that this amount represented a small percentage of its total assets under management. The exchange stated that affected users would be compensated entirely for any lost funds.</p><ul><li><strong>Coindroplet</strong></li></ul><p>In September 2023, a phishing scam targeted a crypto whale who lost nearly $24.2 million worth of Rocket Pool ETH (rETH) and Lido Staked ETH (stETH). The phishing attack was executed by an exploiter associated with at least ten phishing sites, including<a href="http://coindroplet.io/"> coindroplet.io</a></p><ul><li><strong>GMBL Computer</strong></li></ul><p>The GMBL.COMPUTER crypto casino was exploited shortly after its launch. The casino, which operates on the Arbitrum network and promises to generate yield from casino games, was exploited for around 471 ETH (approximately $770,000).</p><p>The exploitation occurred due to a flaw in the platform’s referral system. Users were able to place bets without depositing any funds and use these bets to generate referral bonuses. The GMBL team later confirmed this as the cause of the exploit.</p><p>In response to the exploit, the GMBL team offered a “bug bounty” to the attacker. The exploiter later returned 235 ETH (approximately $382,000), which is half of what they had stolen.</p><ul><li><strong>Balancer Frontend</strong></li></ul><p>On September 19, 2023, Balancer, a decentralized exchange, experienced a DNS attack, which led to the theft of over $250,000 in cryptocurrency. The attackers compromised Balancer’s domain names, redirecting users to a malicious site where they prompted users to approve a contract that drained their wallets.</p><p>The stolen funds were moved to various addresses, with some being bridged to Ethereum and Bitcoin, and over $25,000 was deposited on the MEXC exchange. Balancer has since regained control over its domain and declared its .fi domains safe again, and advised users to avoid interacting with their UI until they confirmed it was secure. This was the second attack on Balancer within a month, following an exploit in August.</p><h3>October</h3><p>Just like every other month in 2023, October faced several high-profile hacks. These attacks utilized various vulnerabilities, including flash loan attacks, Oracle issues, and reentrancy flaws, causing significant financial losses. Key incidents include the Fantom Foundation, the Stars Arena reentrancy hack, the Hope Lend DeFi exploit, and the UniBot call injection attack.</p><ul><li><strong>Fantom Foundation</strong></li></ul><p>On October 17, 2023, the Fantom Foundation fell victim to a cyber heist that resulted in a loss of over $7 million, with a significant portion of the stolen assets coming from an employee’s wallet. This wallet had formerly been under the foundation’s control but had been reallocated for personal use by the employee.</p><p>During the initial investigation, there was speculation that the cybercriminals exploited a heap overflow vulnerability in Google Chrome, identified as CVE-2023–4863. This weakness had been discovered a month before the incident. Despite these early reports, the Fantom Foundation has indicated that further research is needed to confirm the exact cause of the breach.</p><p>The incident stands out because it involves the transfer of ownership of blockchain addresses from the Foundation to an individual employee. Such a move is unconventional and raises security concerns, as these addresses may still be recognized as part of the foundation by external parties, potentially leading to trust and security issues.</p><p>The Foundation has affirmed that the stolen $550,000 constitutes less than 1% of its total assets. Additionally, they clarified that some funds were incorrectly identified by blockchain explorers and were not removed from wallets directly owned by the Foundation.</p><ul><li><strong>Star Arena</strong></li></ul><p>Stars Arena, a blockchain-based social token platform, lost an estimated $2.9 million to a hack that happened on October 7, 2023. The attackers exploited a reentrancy vulnerability in the project’s smart contract.</p><p>Stars Arena operates on a model where creators can sell tickets to private chat rooms, providing buyers with increased access to the creators and the potential for exclusive rewards and opportunities. The hack was made possible by a reentrancy vulnerability in the project’s contracts.</p><p>In the Stars Arena case, the reentrancy vulnerability was located in the code that managed “shares.”. Normally, these shares should be sold at a specific amount. However, thanks to the reentrancy vulnerability in the contract’s code, the attackers were able to inflate the weight associated with a share, effectively increasing its value. This led to a drastic increase in the price of a share, reaching around $274K.</p><p>This vulnerability allowed the attackers to drain value from the smart contract, ultimately leading to the theft of an estimated $2.9 million from the project.</p><p>Once the attack was detected, the Stars Arena team acknowledged the issue and temporarily halted the platform to commence repairs. Unfortunately, during this recovery period, the project’s website also fell victim to a distributed denial-of-service (DDoS) attack, hindering its ability to communicate with its users.</p><ul><li><strong>Hope Lend</strong></li></ul><p>The Hope Lend DeFi platform was targeted by a hack on October 18, 2023, resulting in a significant loss of assets. Specifically, 526 Ether ($834,616) was taken from the platform. This exploit led to a drop in Hope Lend’s Total Value Locked from just under $1 million to $0.</p><p>Crypto analyst Spreek discovered the hack and speculated that it might have something to do with rounding errors and decimals in WBTC. The blockchain security firm SlowMist confirmed the attack.</p><p>A second hacker managed to outmanoeuvre the initial attacker by offering them a bribe of 263 ETH. This hacker then proceeded to split the stolen assets evenly with the initial attacker.</p><p>However, Hope.money, the developers of the DeFi protocol, reported a slightly different scenario. According to them, a single hacker took 526 ETH from the platform, paying 263.91 ETH in bribes to a validator allegedly managed by Lido Finance. This resulted in a net gain of 264.08 ETH for the hacker.</p><p>Despite these events, Hope.money emphasized that all protocols deployed on Hope Lend are independent and will not affect other products and protocols on the platform. They also stated their commitment to protecting the rights of affected users and ensuring the security of the funds.</p><ul><li><strong>UniBot</strong></li></ul><p>In October 2023, Unibot, an automated Telegram trading bot, was hacked via a call injection attack. This led to a total loss of over 500,000 dollars.</p><p>The root cause of the hack was a call-injection vulnerability. Attackers were able to inject their malicious data into the 0xb2bd16ab() method, enabling them to transfer tokens that were approved to Unibot contracts. The attacker exploited the Unibot contract by obtaining excessively high token allowances for various addresses, surpassing their actual token balances. The exploit contract processed a list of addresses with elevated allowances, examining the balance stored in ’ stor1&#39; within the Unibot contract and the allowance allocated within ’stor1&#39;. For each address in the list, it evaluated the Unibot balance and the allowance. When the allowance exceeded the balance, a callback to itself was initiated, passing along the address, the Unibot contract, balance, and allowance. The self-triggered callback involved the execution of transferFrom() with the excessively high allowance amount, allowing the attacker to drain Unibot tokens from the contract into their account.</p><p>As a result of this hack, over $600,000 was stolen from users of Unibot. However, the Unibot team refunded all the affected users after the hack. Affected users remained at risk as long as they hadn’t revoked their approvals, so it was recommended to use tools like Revoke.cash Exploit Checker to ensure safety.</p><h3>November</h3><p>In November 2023, many DeFi projects faced serious attacks, leading to big losses. These attacks took advantage of different weak spots, from things like fast loan attacks and bot tricks to problems with how code works, re-entry flaws, poor access controls, and phishing. All these incidents showed how important it is to keep DeFi safe and what we can learn from these events. Let’s take a closer look at some of the specific attacks that happened in November.</p><ul><li><strong>Poloniex</strong></li></ul><p>On November 10, 2023, Poloniex experienced a security breach, which resulted in the loss of approximately $126 million from its hot wallets. The Lazarus Group, a cybercrime collective with ties to North Korea, is suspected to be behind the Poloniex attack.</p><p>The identification of the Lazarus Group as the likely perpetrator is based on the attack patterns observed in the Poloniex breach. The group’s modus operandi includes sending different types of tokens to various specialized addresses, using an intermediate address to exchange ERC20/TRC20 tokens on a decentralized exchange, and then transferring them to a new address. These actions, while not necessary (since one address can manage multiple token types), are characteristic of the Lazarus Group’s approach.</p><ul><li><strong>Heco Bridge</strong></li></ul><p>The Heco Bridge hack occurred in November 2023 and was a significant security breach that affected Huobi Global’s HTX exchange and its HECO Chain’s Ethereum Bridge.</p><p>The HECO bridge’s operator account, which had special access to oversee the bridge’s operations, was compromised, and this was the main reason behind the exploit. An attacker gained access to this account, allowing them to perform unauthorized actions on crucial functions.</p><p>The attacker used the compromised operator account to initiate unauthorized withdrawals from the HECO bridge, amassing stolen assets worth approximately $86.8 million. The stolen assets included USDT, HBTC, SHIB, UNI, USDC, LINK, ETH, and TUSD.</p><p>In response to the incident, Justin Sun, the founder of Tron, acknowledged the incident and confirmed the HTX and HECO Cross-Chain Bridge compromise. HTX committed to fully compensating for the losses of hot wallet addresses, and all deposits and withdrawals were temporarily suspended.</p><p>The exploit resulted in a cumulative loss of approximately $99.3 million, split between the HTX hot wallets ($12.5 million) and the HECO bridge ($86.8 million). Upon detecting the breach, the HTX team promptly suspended deposits and withdrawals while initiating efforts to recover the stolen assets.</p><ul><li><strong>KyberSwap</strong></li></ul><p>KyberSwap Elastic, a decentralized exchange’s concentrated liquidity protocol, fell victim to a hack on November 23, 2023. The attacker exploited a minor precision error in KyberSwap’s liquidity calculations, enabling them to steal approximately $48 million.</p><p>The attack started with a flash loan, but instead of typical price oracle manipulation, the attacker leveraged KyberSwap’s concentrated liquidity model. They used their flash loan to shift the pool price of targeted liquidity pools to a range where no liquidity was present, giving them complete control over liquidity calculations.</p><p>Once the pool price was within that range, the attacker created liquidity in the area. They then performed two precise swaps: selling a token (like wstETH) to push the price just below the target range, followed by buying the same token to push the price above their target liquidity range.</p><p>The attacker managed to drain the pool by controlling when the updateLiquidityAndCrossTick function was called. This function is meant to execute whenever the pool value crosses a tick value and updates the amount of liquidity available to a user. The issue arose because the first swap (the sell) did not call this function, but the second (the buy) did. This resulted in the double-counting of liquidity, allowing the attacker to manipulate the exchange rate of a token pair.</p><p>In the second swap, they received significantly more of the token than they paid in the first, thereby draining multiple liquidity pools and stealing about $48 million.</p><ul><li><strong>Florence Finance</strong></li></ul><p>On November 28, 2023, Florence Finance, a lending protocol for real-world assets, was hacked, which led to them losing approximately $1.45 million in USDC. This attack was a clever form of deception known as address poisoning.</p><p>Address poisoning works by creating a counterfeit wallet address that closely mirrors a genuine one. When users engage with cryptocurrencies and rely on autofill features or quickly scan their address books, they might mistakenly select a fraudulent, deceiving address. Consequently, the funds are directed to the attacker’s wallet instead of the intended recipient.</p><p>The attack on Florence Finance began when the victim sent USDC to a legitimate address. Then, fraudsters contaminated the victim’s address by sending fake tokens from the victim’s address with the same quantity to a destination address that closely resembled the legitimate one. The destination address was a hash of the scammer’s address. This action was designed to poison the transaction history of the victim’s address. In the next step, the victim inadvertently copied the scammer’s address from their transaction history and sent them real tokens like USDT or USDC.</p><p>After the initial transaction, the phishing wallet 0xB087 forwarded the funds to another wallet, 0x18d8, which then transferred the funds to 0x88E2. As of the time of the report, 0x88E2 was in the process of transferring the funds to THORChain after converting them to Ethereum (ETH).</p><ul><li><strong>TrustPad</strong></li></ul><p>TrustPad, a decentralized finance (DeFi) protocol, suffered a security breach on November 6, 2023, due to a business logic vulnerability in its smart contract, specifically within the staking logic of the LaunchpadLockableStaking contract. This resulted in an approximate loss of $155,000.</p><p>The attack was carried out through the receiveUpPool function in the LaunchpadLockableStaking contract. The attacker was able to control the newLockStartTime state of the contract by depositing TPAD tokens into it.</p><p>Once the attacker had control over the newLockStartTime, they were able to repeatedly call receiveUpPool() and withdraw() to collect rewards. The attacker then used the stakePendingRewards function to convert these rewards into staked amounts. Finally, the attacker withdrew the rewards using withdraw()</p><h3>December</h3><p>Toward the end of the year 2023, December witnessed a series of high-profile security breaches across the DeFi landscape. Hackers exploited a range of vulnerabilities, such as phishing, access control issues, and smart contract weaknesses, leading to substantial financial losses. Notable events included the Orbit Chain theft, the Herencia Artifex NFT controversy, the OKX DEX exploit, and a phishing attack on Ledger.</p><ul><li><strong>Orbit Chain</strong></li></ul><p>Orbit Chain, a blockchain platform designed to support interoperability between various blockchains, decentralized applications (DApps), and services, experienced a significant security breach in December 2023, leading to a loss of approximately $82 million in cryptocurrency. This included Ether, Dai, Tether, and USD Coin.</p><p>The first unauthorized transaction of a series of drain attacks involving multiple asset types was performed by unidentified hackers on December 31, 2023. Blockchain intelligence platform Arkham reports that Orbit Chain’s balance went from $115 million to $29 million instantly.</p><p>It is still unclear what kind of exploit the hackers used to carry out the attack. However, it is believed that the attackers carry signs of sophisticated state-sponsored attackers, possibly based out of North Korea.</p><p>Arkham Intelligence, a blockchain analysis platform, pointed out that a total of $81.68 million in cryptocurrencies were siphoned from the protocol in five separate transactions. The largest transaction made by the attackers was $30 million in Tether, while the others are $10 million in USD Coin, 9,500 Ether worth over $21.6 million, 231 wrapped Bitcoin (WBTC) worth about $9.8 million, and the rest $10 million in the algorithmic stablecoin DAI.</p><ul><li><strong>Herencia Artifex NFT</strong></li></ul><p>The Herencia Artifex NFT project, which operated under the native token HXA, faced a significant incident in December 2023. Initially, it appeared that the project had fallen victim to a supply chain attack where an attacker manipulated a signature to transfer over 450 billion HXA tokens from a burning address to their account. This was linked to a flaw in the ThirdWeb development kit, particularly in the msgSender parameter of the multiCall function.</p><p>However, the subsequent actions of the Herencia Artifex team led to suspicions that the incident might have been an exit scam rather than a genuine exploit. Indicators of this include the project’s website going offline without explanation, the sudden shutdown of their social media accounts, and the removal of their website for the coin. This series of events culminated in a 90% drop in the value of the HXA coin within 24 hours of the exploit announcement and later the apparent wiping out of the project by the Herencia Artifex team.</p><ul><li><strong>OKX DEX</strong></li></ul><p>The OKX DEX experienced a hack on December 12, 2023, causing a loss of around $2.4 million. The incident was triggered by a compromised proxy contract, which was used by the attackers to steal money from users who had authorized it.</p><p>The Proxy Admin Owner recently updated the DEX Proxy contract to a newer version. This update altered the contract’s functionality, allowing it to start token transfers directly and bypass regular security checks. Normally, users allow token exchanges through the TokenApprove contract, but the compromised DEX Proxy contract could bypass these permissions.</p><p>The problem was caused by a private key leak, which was used against an older version of a smart contract. OKX, a centralized exchange based in the Seychelles, also runs a decentralized exchange (DEX) and a cross-chain bridge aggregator. The DEX Proxy admin of a trusted contract that controls OKX DEX trades was compromised.</p><p>After the hack was discovered, OKX confirmed the exploit and committed to reimbursing the affected users. The exchange quickly took steps to secure all user funds and revoke the compromised contract’s permissions.</p><p>OKX has also vowed to conduct a thorough security review to prevent such incidents in the future. The exact number of users affected by the breach is not known, but OKX DEX had more than 50,000 active user wallets in the 30 days before the hack.</p><ul><li><strong>Ledger</strong></li></ul><p>In December 2023, Ledger, a popular cryptocurrency wallet manufacturer, experienced a serious security breach. One of the former employees of Ledger fell for a phishing scam, which is how the hack got started. The attacker then used the employee’s NPMJS account to publish a malicious version of the Ledger Connect Kit, which affected versions 1.1.5, 1.1.6, and 1.1.7. This allowed the attacker to trick EVM DApp users into signing transactions that emptied their wallets.</p><p>The hack was detected on December 14th, 2023, and Ledger responded swiftly. Within 40 minutes of being informed, Ledger deployed a genuine version of the Ledger Connect Kit. Despite the malicious code being present for about five hours due to CDN caching mechanisms, the actual period during which user assets were drained was less than two hours.</p><p>The hack sparked mixed reactions within the deFi community. Some suggested switching to other wallet platforms, while others called for Ledger to open-source its code for better transparency. The incident highlighted Ledger’s past security issues and raised concerns about the company’s commitment to operational security.</p><h3>What are the lessons learned?</h3><p>Looking at the major hacks of 2023, several common vulnerabilities and attack methods can be identified. The most prevalent ones include:</p><ul><li><strong>Flash Loan Attacks</strong>: Flash loans are a type of crypto loan that is instantly filled without requiring collateral. These attacks involve borrowing cryptocurrencies and performing transactions before the loan needs to be paid back. This allows the attacker to perform malicious actions without the risk of their identity being tied to the transaction.</li><li><strong>Arbitrage Bot Manipulation</strong>: Arbitrage bots are automated programs designed to take advantage of price differences on different exchanges. Attackers have used these bots to exploit price discrepancies, leading to significant financial losses.</li><li><strong>Vulnerabilities in Code Logic</strong>: Many of the hacks involved vulnerabilities in the code logic of the protocols. These could be flaws in the way the system calculates rewards, prices, or other key functions.</li><li><strong>Reentrancy Flaws</strong>: Reentrancy flaws occur when a contract calls an external contract before it resolves its state. This can allow an attacker to drain funds from the contract.</li><li><strong>Phishing Schemes</strong>: Phishing attacks involve tricking users into revealing sensitive information, such as login credentials or private keys. These attacks have been used to gain unauthorized access to accounts and steal funds.</li></ul><p>Secure coding practices, code audits, and vulnerability assessments are very important to prevent these types of attacks. Developers should follow best practices for secure coding, regularly conduct code audits to identify potential vulnerabilities and implement vulnerability assessments to ensure the security of their systems.</p><p>Talking about audits, professional security audits play a crucial role in identifying and mitigating risks. Regular audits can help detect vulnerabilities before they can be exploited and provide recommendations for improving security.</p><p>However, it is important to note that user education is essential for the security of DeFi. Users should be educated on best practices for protecting their assets. This includes using strong passwords, implementing multi-factor authentication, and being vigilant against phishing scams.</p><h3>Recommendation for the future</h3><p>Looking at the major hacks that occurred in 2023, we can identify several key areas that need improvement if we want to enhance the security of DeFi. Let’s break down these improvements into three main categories: smart contract development, auditing methodologies, and user education initiatives.</p><p>Firstly, for smart contract development, we need to focus on rigorous testing. We should aim for high test coverage, ideally above 85–90%, to ensure that even minor bugs don’t slip through. Additionally, we should make use of both static and dynamic analysis tools, such as Slither, Mythril, Echidna, 4naly3er etc, to identify potential vulnerabilities in our smart contracts. Another strategy is to adopt formal verification methods, which allow us to mathematically prove the correctness of our smart contracts. Lastly, we should create and stick to security checklists based on industry best practices.</p><p>Next, for auditing methodologies, regular audits are crucial. As new attack vectors are constantly emerging, we need to keep our systems up to date. To achieve this, we should engage multiple independent auditors to identify different types of vulnerabilities. Penetration testing, where we simulate attacks to identify weaknesses, should also be part of our routine. Furthermore, we should protect our contracts from unauthorized access or key loss by implementing multisig schemes, where multiple signatures are required for critical transactions.</p><p>Lastly, user education plays a vital role in enhancing DeFi security. We need to raise awareness among users about the importance of good security practices, such as avoiding phishing scams and using hardware wallets for better security. Providing educational resources and tutorials on how to interact with DeFi platforms securely is also crucial. Finally, involving the community in finding and reporting security issues can lead to more robust and secure code.</p><p>To further strengthen DeFi security, we need to encourage collaboration between developers, auditors, and security researchers. Sharing knowledge and best practices can lead to more robust and secure code. Making smart contracts open-source allows the community to review and contribute to them, leading to more secure code. Lastly, staying updated on the latest security developments and updating protocols and practices accordingly is key to maintaining strong DeFi security.</p><h3>Conclusion</h3><p>To wrap it up, the big hacks in 2023 showed that DeFi isn’t safe just yet. We saw a lot of problems with flash loans, bot manipulation, and code flaws. But the good news is, we can fix these problems.</p><p>For smart contract development, rigorous testing and the adoption of formal verification can enhance reliability, while the use of tools like Slither, Echidna, and 4naly3er etc, can help identify weaknesses. Regular audits are recommended to keep up with emerging threats.</p><p>We also need to educate people on how to use DeFi safely. This means telling them to watch out for phishing scams and use secure wallets. It’s also a good idea to give them resources to learn how to use DeFi safely.</p><p>Working together is the key to making DeFi safer. Developers, auditors, and security researchers should share their knowledge and work together. We need to keep learning and updating our security measures to keep up with the changing DeFi world.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=1cab753ac4ea" width="1" height="1" alt=""><hr><p><a href="https://medium.com/rektify-ai/learning-from-the-biggest-defi-hacks-of-2023-1cab753ac4ea">Learning from the Biggest DeFi Hacks of 2023</a> was originally published in <a href="https://medium.com/rektify-ai">Rektify AI</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Learning From The Biggest DeFi Hacks of January 2024]]></title>
            <link>https://medium.com/web3-writers-guild/learning-from-the-biggest-defi-hacks-of-january-2024-0caa1b4af45b?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/0caa1b4af45b</guid>
            <category><![CDATA[smart-contract-auditing]]></category>
            <category><![CDATA[smart-contract-security]]></category>
            <category><![CDATA[ethereum]]></category>
            <category><![CDATA[web3-hack]]></category>
            <category><![CDATA[web3-security]]></category>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Tue, 06 Feb 2024 01:46:46 GMT</pubDate>
            <atom:updated>2024-02-06T01:46:46.907Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*U02VyZ1LoW6MDUU-BFOGxw.jpeg" /></figure><h3>Introduction</h3><p>Decentralized Finance (DeFi) has taken the financial world by storm, offering a more efficient and transparent way to handle transactions without the need for traditional banks. However, as DeFi grows, it’s also becoming a prime target for hackers, leading to significant financial losses. This article aims to shed light on some of the recent security breaches in the DeFi space, detailing the vulnerabilities that were exploited, the fallout from these incidents, and why we all must learn from these experiences to strengthen the security of DeFi platforms.</p><h3>Deep Dive Into January&#39;s Biggest Hacks</h3><ul><li><strong>GAMEE token exploit</strong></li></ul><p>GAMEE is a blockchain gaming platform backed by Animoca Brands, offering a range of games that allow players to earn cryptocurrency rewards. Its native cryptocurrency is GMEE.</p><p>The GAMEE hack on January 22, 2024, targeted its GMEE token. The root cause was unauthorized access to the project’s smart contracts, leading to an estimated <strong>$16 million</strong> in losses.</p><p>The attack was made possible through unauthorized access to the project’s GitLab environment. The attacker identified a vulnerability in GAMEE’s GitLab environment, granting them access to an old version of the project’s repository. Inside this old repository was a copy of the private key used to control the project’s deployer address on the Polygon blockchain. With access to this private key, the attacker was able to execute a recoverERC721s function to transfer approximately 600 million GMEE tokens to attacker-controlled wallets.</p><p>The GAMEE team quickly acted to stop the hack. They blocked all unauthorized access to the token contracts and moved them to a new address. They also stopped providing liquidity to all decentralized exchanges and told centralized exchanges to stop accepting new deposits and freeze the tokens linked to the hack.</p><ul><li><strong>Gamma Strategies</strong></li></ul><p>Gamma Strategies is a decentralized asset management protocol that operates on Ethereum and other blockchains. It allows users to deposit funds into pools known as “<strong>hypervisors</strong>”. Users earn a return on their investment through active liquidity management and market-making strategies.</p><p>On January 4, 2024, Gamma Strategies was exploited through a series of attack transactions using flash loans from Uniswap and Balancer. This exploit resulted in a loss of approximately <strong>$6.4 million</strong>.</p><p>The primary issue was the deposit proxy settings related to the price change threshold, which was set too high, allowing for a -50% to +100% price change on certain LST and stablecoin vaults.</p><p>The attacker revealed a flaw in the deposit proxy configurations, specifically targeting stable and LST vaults. Despite having four primary deposit protection measures against flash loans, the exploit highlighted a vulnerability in one of these safeguards. The hackers bridged stolen funds from the Arbitrum chain to the Ethereum network using the Stargate bridge and deposited part of the stolen funds into TornadoCash.</p><p>In response to the attack, the protocol swiftly implemented measures to prevent further losses, temporarily disabling deposits to all public DeFi vaults while keeping withdrawals active for users in need of accessing their funds.</p><ul><li><strong>Radiant Capital</strong></li></ul><p>Radiant Capital is a multichain lending protocol that operates on the Ethereum network. Launched in October 2023, Radiant Capital aims to offer the lowest price-to-fee ratio among decentralized protocols.</p><p>On January 2, 2024, Radiant Capital was hacked via a flash loan exploit, the protocol lost 1,900 ETH, valued at over $4.5 million. The attacker exploited a vulnerability in the project’s token quantity calculation, involving precision expansion and rounding. By controlling the precision and using rounding to expand profit margins, the attacker drained all USDC from the pool.</p><p>The Radiant team received reports of an issue regarding the new USDC market on Arbitrum late on January 2, 2024. Its DAO Council temporarily suspended the protocol’s lending and borrowing markets while they investigated the situation. The team identified the root cause of the exploit and paused the protocol to address the exploit and assess necessary remedial actions.</p><ul><li><strong>Abracadabra</strong></li></ul><p>Abracadabra Finance is a DeFi lending and borrowing platform. The platform allows users to deposit various crypto assets as collateral and receive its Magic Internet Money (MIM) token in return.</p><p>On January 30, 2024, Abracadabra Finance was exploited, resulting in a loss of $6,414,205 (2737.48 ETH). The root cause of the exploit was a loss of precision during smart contract operations, specifically a rounding issue. The attacker targeted specific Cauldrons V3 &amp; V4, allowing unauthorized MIM borrowing. The attacker was funded by Tornado Cash and transferred the stolen funds to two other Externally Owned Accounts (EOAs).</p><p>In response to the attack, the Abracadabra Money team acknowledged the exploit and stated that they were investigating the situation. To mitigate the impact of the crypto theft, the DAO treasury planned to buy back MIM from the market and burn them.</p><ul><li><strong>Socket Protocol</strong></li></ul><p>Socket Protocol is a cross-chain bridge protocol that plays a crucial role in helping different decentralized protocols interact. It is commonly used behind the scenes to bridge the Ethereum network with over a dozen other blockchains that utilize Ethereum Virtual Machine (EVM) infrastructure.</p><p>On January 16, 2024, Socket Protocol fell victim to a hack that targeted the approval vulnerability. The security breach originated from wallets with unlimited approvals to Socket contracts, which provided the attacker with the means to exploit vulnerabilities within the protocol’s performAction function. This flaw allowed for a call injection attack, as it enabled inserting the malicious code into the call() function, compromising the contract’s state and enabling unauthorized fund withdrawals.</p><p>The total losses incurred during the event were valued at approximately $3.3 million. However, the Socket Protocol team was able to recover over half of the stolen funds, totalling 1,032 ETH, equivalent to almost $2.297 million.</p><ul><li><strong>Goledo Finance</strong></li></ul><p>Goledo Finance is a cross-chain lending and borrowing protocol based on Aave. On January 28, 2024, Goledo Finance suffered a $1.7 million hack. The hacker used a flash loan attack to manipulate the price of a token, inflating the amount of collateral for borrowing tokens. The hacker then used the inflated collateral to take loans out on the rest of the tokens in Goledo’s lending pool. This was all executed within a single block hash by setting up a smart contract to execute all of this simultaneously.</p><p>The hacker managed to obtain a greater amount of assets than a typical user should have been allowed to borrow. The hacker’s actions resulted in a significant decrease in the value of Goledo Finance’s native token, GOL, which experienced a 35% plunge in value.</p><ul><li><strong>Concentric Finance</strong></li></ul><p>Concentric Finance is a yield aggregator protocol that allows users to manage their liquidity across different decentralized finance (DeFi) platforms.</p><p>On January 22, 2024, Concentric Finance suffered a security breach where an attacker exploited the protocol’s deployer account. The attacker used a social engineering attack to compromise the private key of the deployer account. Once the attacker gained control of the deployer account, they upgraded the vaults, minted new Liquidity Pool (LP) tokens, and subsequently drained the vaults of their assets. The attacker also minted 0.001 CONE-1 tokens and burnt them to redeem the CONE-1 tokens for funds from the AlgebraPool. This process was repeated several times, allowing the attacker to obtain multiple ERC-20 tokens, which were subsequently swapped for Ether (ETH).</p><p>The attack resulted in the loss of over $1.8 million. The attacker’s wallet was linked to the wallet that performed the OKX decentralized exchange exploit in December 2023, suggesting that both attacks may have been carried out by the same person.</p><p>In response to the hack, Concentric Finance advised users to revoke all approvals from all vault addresses listed in the protocol’s documents.</p><ul><li><strong>Wise</strong></li></ul><p>Wise Lending is a web3 lending application and yield aggregator. It provides various financial services to its users, including lending and borrowing tokens.</p><p>On January 12, 2024, Wise Lending suffered an attack due to a precision loss vulnerability, leading to a loss of over $449,413. The attacker exploited a flaw in Wise Lending’s share accounting logic. The attacker inflated share prices in a nearly empty market and then borrowed heavily based on this inflated value. The attacker used a flash loan attack to carry out the exploit.</p><ul><li><strong>Nebula Revelation</strong></li></ul><p>Nebula Revelation is a space-themed open-world Web3 game that embeds some elements of blockchain technology. The game includes a staking mechanism where players can earn tokens by participating in the game.</p><p>Nebula Revelation suffered a reentrancy attack on its staking contract. This attack happened on January 25, 2024. The attacker exploited a vulnerability in the staking contract, which led to the unauthorized withdrawal of tokens. The attacker used a self-destructing contract to complete all operations in one transaction, exploiting the security vulnerability.</p><p>The total losses incurred during the event were valued at approximately $180,264.</p><ul><li><strong>BasketDAO</strong></li></ul><p>BasketDAO is a DeFi protocol that allows users to create, manage, and trade token baskets. These token baskets are essentially collections of tokens that represent various digital assets and can be traded as a group, providing a way to diversify investments and reduce risk.</p><p>However, on January 17, 2024, BasketDAO was hacked due to a flaw in its smart contracts. The hackers took advantage of these vulnerabilities to steal approved user funds. To be specific, they manipulated the “transferFrom” issue in the BasketDAO contract due to arbitrary low-level calls.</p><p>$107,070 (42.55 ETH) was stolen from BasketDAO in this incident.</p><ul><li><strong>Rosa Finance</strong></li></ul><p>Rosa Finance is a decentralized non-custodial liquidity market protocol operating on the Arbitrum network.</p><p>Rosa Finance was exploited on January 18, 2024, via a flash loan attack. The attacker exploited the protocol by initiating a series of flash loans. These loans were then used to manipulate the market, allowing the attacker to steal various cryptocurrencies. The stolen assets included 12,601 DAI, 2,749 USDC, 0.2317 WBTC, 97.12 GMX, 3,873 ARB, and 3,396 PENDLE. The total loss incurred from the attack was estimated at $44,670.</p><h3>Unveiling Common Patterns and Pinpointing Overarching Issues</h3><p>The analysis of the hacks reveals that all of them involved unauthorized access to critical areas of the systems. Each attack exploited vulnerabilities in the smart contracts or the overall design of the protocols. For instance, the GAMEE hack was facilitated by unauthorized access to the project’s GitLab environment and the subsequent misuse of a private key stored in an old repository. Similarly, Gamma Strategies was breached through a series of transactions using flash loans from Uniswap and Balancer, exploiting a flaw in the deposit proxy configurations. These examples illustrate the common pattern of unauthorized access and exploitation of vulnerabilities across all the hacks analyzed.</p><p>The hacks have highlighted several systemic issues within DeFi security. Many of the protocols had insufficient security measures in place, making them susceptible to attacks. Additionally, the protocols lacked continuous verification processes, which could have helped identify and rectify vulnerabilities before they were exploited. Furthermore, many DeFi projects focused primarily on growth, and not enough on implementing and maintaining robust security systems. Some protocols also relied on third-party programs for key functionalities, which could potentially be compromised.</p><h3>Mitigation and Prevention Strategies</h3><p>To improve the security of DeFi protocols, developers must ensure that their smart contracts and codebases undergo thorough reviews by security experts. This process helps uncover vulnerabilities, potential risks, and areas for improvement. It’s crucial to prioritize modularity and clear code for easy maintenance and future upgrades. Implementing security measures such as reentrancy guards, access control, and so on, is also essential. Implementing very good and advanced toolkits for static analysis and formal verification is crucial for enhancing security.</p><p>Engaging with the DeFi community is another key strategy. Developers should actively participate in online forums, social media, and developer channels. This not only builds trust but also helps gather valuable feedback to refine the protocol based on user needs. It’s important to remember that user awareness is a vital aspect of security. Offering educational resources, tutorials, and best practices can help users understand potential risks and how to protect their assets.</p><p>Collaboration between DeFi projects and security experts is also essential. Auditors should be engaged to uncover hidden vulnerabilities. Bug bounties can encourage responsible disclosure, promoting this type of collaboration. Additionally, developers should consider using multi-signature wallets for governance and key management, adding an extra layer of security.</p><h3>Conclusion</h3><p>The DeFi sector faces significant security challenges that require immediate attention. The experiences of the past few months show the importance of robust security measures and constant vigilance. By learning from these experiences, the DeFi community can develop more resilient and secure protocols, fostering a safer and more trustworthy ecosystem for all participants. Developers must conduct thorough reviews of their smart contracts and codebases by security experts, prioritize modularity and clear code, and implement security measures. Engaging with the DeFi community and collaborating with security experts are also vital steps toward enhancing DeFi security.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=0caa1b4af45b" width="1" height="1" alt=""><hr><p><a href="https://medium.com/web3-writers-guild/learning-from-the-biggest-defi-hacks-of-january-2024-0caa1b4af45b">Learning From The Biggest DeFi Hacks of January 2024</a> was originally published in <a href="https://medium.com/web3-writers-guild">Web3 Writers Guild</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Bad Randomness in Solidity]]></title>
            <link>https://medium.com/rektify-ai/bad-randomness-in-solidity-8b0e4a393858?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/8b0e4a393858</guid>
            <category><![CDATA[smart-contract-auditing]]></category>
            <category><![CDATA[solidity]]></category>
            <category><![CDATA[attack-vector]]></category>
            <category><![CDATA[smart-contract-security]]></category>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Sat, 18 Nov 2023 01:55:41 GMT</pubDate>
            <atom:updated>2023-11-18T01:55:41.287Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*4pqF5nMT_2QIewC5" /></figure><h3>Introduction</h3><p>It is easy to generate random numbers in programming languages like JavaScript or Python, but it is more challenging to do so securely in Solidity. Solidity needs secure randomness for different applications, such as games and lotteries. The reason is that blockchains are deterministic, meaning that the output of any function is always the same for the same input. This makes it difficult to generate truly random numbers on the blockchain, as any algorithm used to generate randomness could be exploited.</p><p>This article will cover the role of randomness in solidity, sources of bad randomness, how to get randomness using Chainlink oracle VRF functions, hacks, and mitigation techniques.</p><h3>The Role of Randomness in Solidity</h3><p>Randomness is an important element of many Web3 applications, including on-chain games, lotteries, and decentralized finance (DeFi) protocols. It is used to create unpredictable outcomes, which can be added to gameplay mechanics, ensure fair distribution of rewards, and prevent fraud.</p><p>For example, in a Web3 game, randomness can be used to determine the outcome of a battle, the rarity of an NFT item, or the distribution of loot. In a lottery, randomness is used to select the winning numbers. In DeFi protocols, randomness can be used to generate private keys, which are used to secure users’ funds.</p><p>When it comes to randomness, there are two different forms, namely pseudorandomness and true randomness. Pseudorandomness is generated by deterministic algorithms, while true randomness relies on unpredictable and unbiased sources of entropy.</p><p>Pseudorandom numbers appear to be random, but they are generated by a formula. This means that they can be predicted if you know the formula and the initial seed value.</p><p>True randomness is generated by physical processes that are inherently unpredictable. True randomness is used for more security-sensitive applications, such as generating cryptographic keys.</p><h3>Bad Randomness</h3><p>Bad randomness vulnerability occurs when a smart contract relies on a source of randomness that is not truly random or that can be predicted by an attacker. This can allow an attacker to manipulate the outcome of a transaction or gain an unfair advantage over other users.</p><p>There are different sources of bad randomness in smart contracts, and we will be looking at some of them:</p><ul><li><strong>Using block hash as a source of randomness:</strong></li></ul><p>A block hash is a value that is derived from the contents of a block on the Ethereum blockchain. It is considered to be pseudorandom because it is based on the transactions and other data contained in the block, but it is not truly random because it is determined by the contents of the block, which may be known or predictable to an attacker.</p><ul><li><strong>Using the current block timestamp as a source of randomness:</strong></li></ul><p>It is not recommended to use <strong>block.timestamp</strong> as a source of randomness because it can be influenced or manipulated by validators (miners). Validators have a degree of control over the <strong>block.timestamp </strong>value. They can adjust the timestamp of a block they are mining, as long as it is within a certain tolerance range. This means that miners can potentially manipulate the timestamp to generate specific outcomes in smart contracts that rely on <strong>block.timestamp</strong> for randomness. On a higher level, a front-running attack can occur.</p><ul><li><strong>Using local variables and storage as a source of randomness:</strong></li></ul><p>Local variables and storage variables in Solidity can be used to generate random values or to make decisions that should be unpredictable. However, the values of these variables are visible to all participants in the contract, making it possible for malicious actors to predict or manipulate the outcomes.</p><h3>Hack Caused By Bad Randomness</h3><p>We will be looking at a real-world hack that occurred due to bad randomness in a contract:</p><h4>Fomo3D Hack</h4><p>Fomo3D is a lottery game where the last person to buy a key wins. Players can buy keys during a round, and the price of keys increases slightly with each purchase. Players also earn passive income from the game as keys are bought. When the round ends, the last person to buy a key wins the pot.</p><p>What attracted players to the game were the airdrops. Airdrops are prizes that are given to random players. This also attracted attackers.</p><p>Winners are chosen completely randomly. The Fomo3D contract uses multiple sources of randomness to generate random numbers, such as <strong>block creation time, the miner address of the current block, and the address of the current player, </strong>which we explained above that they are sources of bad randomness.</p><p>Here is the formula used:</p><pre>contract FoMo3Dlong is modularLong {<br>    /**<br>     * @dev generates a random number between 0-99 and checks to see if thats<br>     * resulted in an airdrop win<br>     * @return do we have a winner?<br>     */<br>    function airdrop()<br>        private<br>        view<br>        returns(bool)<br>    {<br>        uint256 seed = uint256(keccak256(abi.encodePacked(<br>            (block.timestamp).add<br>            (block.difficulty).add<br>            ((uint256(keccak256(abi.encodePacked(block.coinbase)))) / (now)).add<br>            (block.gaslimit).add<br>            ((uint256(keccak256(abi.encodePacked(msg.sender)))) / (now)).add<br>            (block.number)<br>        )));<br>        if((seed - ((seed / 1000) * 1000)) &lt; airDropTracker_)<br>            return(true);<br>        else<br>            return(false);<br>    }<br>}</pre><p>Using this method to determine random winners for the airdrop makes the Fomo3D contract predictable and vulnerable to attack.</p><p>The attacker performed his attack by using a contract to deceive the Fomo3D contract that it was an EOA (because only EOA are eligible for airdrops and not contracts) and was also able to manipulate the randomness of the Fomo3D smart contract and get the airdrop, getting away with lots of ether.</p><h3>Getting Randomness Using Chainlink VRF</h3><p>Chainlink is a decentralized Oracle network that provides secure and reliable data feeds and off-chain computation for smart contracts. It allows smart contracts to access real-world data and events and perform complex off-chain computations without compromising their security.</p><p>Chainlink is used by a wide range of decentralized applications, including DeFi protocols, insurance platforms, and gaming applications. One of the major services of Chainlink is VRF (verifiable random function), in which you get random numbers.</p><p>Chainlink VRF is a provably fair and verifiable random number generator (RNG) that allows smart contracts to use random numbers without sacrificing security or usability. For each request, Chainlink VRF produces one or more random numbers and a cryptographic proof of how they were generated. The proof is published and verified on the blockchain before any applications can use it. This process ensures that no one, including Oracle operators, miners, users, or smart contract developers, can tamper with or manipulate the results.</p><p><a href="https://docs.chain.link/vrf/v2/subscription"><strong>Subscription</strong></a> and <a href="https://docs.chain.link/vrf/v2/direct-funding/"><strong>Direct funding</strong></a> methods are the two methods you can use to generate random numbers using Chainlink VRF.</p><p><a href="https://docs.chain.link/vrf/v2/subscription"><strong>The subscription method</strong></a> is good for regular requests for randomness where you need to request randomness frequently. With this method, you create a subscription account and pre-fund it with LINK tokens. Then, when you need randomness, you simply request it from your subscription account. VRF costs are calculated after your requests are fulfilled and then deducted from your subscription balance.</p><p><a href="https://docs.chain.link/vrf/v2/direct-funding/"><strong>The direct funding method</strong></a> is good for infrequent, one-off requests for randomness. With this method, you don’t need to create a subscription account. Instead, you directly fund the consuming contract with LINK tokens before it requests randomness. VRF costs are estimated and charged at request time.</p><p>The main difference between the two methods is that the subscription method is more efficient for regular requests, while the direct funding method is more efficient for infrequent requests.</p><p>Chainlink provided a simple guide on how to use <a href="https://docs.chain.link/vrf/v2/subscription/examples/get-a-random-number">ChainlinkV2 VRF to generate random numbers</a> in your smart contracts in their <a href="https://docs.chain.link/vrf/v2/subscription/examples/get-a-random-number">documentation</a></p><h3>Mitigation Techniques:</h3><p>To avoid using bad randomness in Solidity, it is important to implement secure randomness in your smart contracts when building your blockchain applications.</p><ul><li>Use Chainlink VRF: Chainlink VRF is a secure way to generate random numbers in your smart contract projects. Whenever you want to implement randomness in your solidity contract, do not use block-related data, such as block hashes, block timestamps, or block numbers, to generate random numbers because they can be manipulated. It is advised to integrate Chainlink VRF.</li><li>Keep your smart contract up-to-date with the latest security fixes and best practices, and have it audited regularly to find any weaknesses, especially those related to randomness.</li></ul><h3>Conclusion</h3><p>Bad randomness is a serious security flaw in Solidity contracts. It can be exploited by attackers to manipulate the outcome of smart contracts, leading to financial losses for users. Developers should be aware of this vulnerability and take steps to mitigate it, such as using decentralized oracles that provide secure randomness functions, such as Chainlink VRF.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=8b0e4a393858" width="1" height="1" alt=""><hr><p><a href="https://medium.com/rektify-ai/bad-randomness-in-solidity-8b0e4a393858">Bad Randomness in Solidity</a> was originally published in <a href="https://medium.com/rektify-ai">Rektify AI</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Mastering Reentrancy Security]]></title>
            <link>https://medium.com/rektify-ai/mastering-reentrancy-security-b576c305cd25?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/b576c305cd25</guid>
            <category><![CDATA[crypto-hack]]></category>
            <category><![CDATA[solidity]]></category>
            <category><![CDATA[smart-contracts]]></category>
            <category><![CDATA[reentrancy-attack]]></category>
            <category><![CDATA[smart-contract-security]]></category>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Thu, 09 Nov 2023 06:05:00 GMT</pubDate>
            <atom:updated>2023-11-09T06:05:00.944Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*pnhMIPJcXNARC5Hk" /></figure><h3>Introduction</h3><p>In the early phase of the second quarter of the year 2023 (specifically, April 4), a liquidity protocol named Sentiment suffered a loss of around $1 million. The loss was caused by a reentrancy vulnerability in the protocol’s smart contract, which an attacker exploited.</p><p>To jog your memory, let’s rewind to the year 2016 when Ethereum faced a significant hack known as the DAO hack. During this incident, approximately $60 million was lost due to a reentrancy vulnerability within the contract.</p><p>As you can see, reentrancy vulnerability is an issue that requires serious attention. This is exactly why the purpose of this article is to provide a thorough explanation of reentrancy, how it occurs, various types of reentrancy, and mitigation methods.</p><h3>What is Reentrancy?</h3><p>Reentrancy in Solidity refers to a situation where a contract can be called multiple times before its initial execution is completed. This can lead to unexpected behaviours and vulnerabilities that attackers can take advantage of if not properly managed.</p><p>To simply illustrate how a reentrancy attack occurs, let’s look at the example below:</p><pre>// SPDX-License-Identifier: MIT<br>pragma solidity ^0.8.0;<br><br>contract VulnerableContract {<br>    mapping(address =&gt; uint256) public balances;<br><br>    function deposit() public payable {<br>        balances[msg.sender] += msg.value;<br>    }<br><br>    function withdraw(uint256 amount) public {<br>        require(balances[msg.sender] &gt;= amount, &quot;Insufficient balance&quot;);<br>        (bool success, ) = msg.sender.call{value: amount}(&quot;&quot;);<br>        require(success, &quot;Transfer failed&quot;);<br>        balances[msg.sender] -= amount;<br>    }<br><br>    function getBalance() public view returns (uint256) {<br>        return balances[msg.sender];<br>    }<br>}<br><br>contract AttackerContract {<br>    VulnerableContract public vulnerableContract;<br><br>    constructor(address _vulnerableContract) {<br>        vulnerableContract = VulnerableContract(_vulnerableContract);<br>    }<br><br>    function attack() public payable {<br>        // Deposit a small amount<br>        vulnerableContract.deposit{value: 1 ether}();<br><br>        // Start reentrancy attack<br>        vulnerableContract.withdraw(1 ether);<br>    }<br><br>    receive() external payable {<br>        // Reentrant function<br>        vulnerableContract.withdraw(1 ether);<br>    }<br><br>    function getBalance() public view returns (uint256) {<br>        return address(this).balance;<br>    }<br>}</pre><p>Looking at the example above, we have two contracts: <strong>VulnerableContract</strong> and <strong>AttackerContract</strong>. The <strong>VulnerableContract</strong> is exposed to a reentrancy attack due to a flaw in the way withdrawal works. When a user calls the withdraw function, it transfers the requested amount to the user’s address before updating the balance. This allows an attacker to repeatedly call the withdraw function from their contract (<strong>AttackerContract</strong>) before the balance is updated.</p><p>The <strong>AttackerContract</strong> exploit this vulnerability by initiating the attack. It first deposits a small amount into the <strong>VulnerableContract</strong>, and then immediately triggers a reentrancy attack by calling the withdraw function and recursively invoking it within the receive function.</p><h3>Types of Reentrancy Attack</h3><p>There are various ways in which a smart contract can experience reentrancy, and we will be discussing them:</p><ul><li><strong>Read-only Reentrancy:</strong></li></ul><p>Read-only reentrancy is a type of reentrancy where the view function in a contract is reentered, and usually, it’s not protected because it doesn’t change the contract’s data. However, if the contract’s data is messed up, it might give incorrect results. The main difference between read-only reentrancy and normal reentrancy in Solidity is that read-only reentrancy occurs when a view function is reentered, while normal reentrancy occurs when a regular function is reentered.</p><p>In a read-only reentrancy attack, an attacker triggers a function in a target contract that calls an external contract. Then, the attacker quickly triggers the same function again before the external call completes. This can be done through another contract or a callback function.</p><p>Since the original function is still running when reentered, the attacker can read the target contract’s state before the external call updates it. This gives an attacker an edge when performing an attack.</p><p>Here is an example:</p><pre>// SPDX-License-Identifier: MIT<br><br>pragma solidity ^0.8.0;<br><br>contract VulnerableContract {<br>    mapping(address =&gt; uint256) public balances;<br>    bool private locked;<br><br>    constructor() {<br>        locked = false;<br>    }<br><br>    function deposit() external payable {<br>        balances[msg.sender] += msg.value;<br>    }<br><br>    function withdraw(uint256 amount) external {<br>        require(balances[msg.sender] &gt;= amount, &quot;Insufficient balance&quot;);<br>        require(!locked, &quot;Contract is locked&quot;);<br><br>        locked = true;  // Lock the contract<br><br>        (bool success, ) = msg.sender.call{value: amount}(&quot;&quot;);<br>        require(success, &quot;Transfer failed&quot;);<br><br>        balances[msg.sender] -= amount;<br>        locked = false; // Unlock the contract<br>    }<br><br>    // This function is supposed to be read-only, but it can be exploited<br>    function getBalance(address account) external view returns (uint256) {<br>        // Malicious contract can exploit this function<br>        return balances[account];<br>    }<br>}</pre><p>Looking at the example, the vulnerable contract allows users to deposit and withdraw funds. But there is a problem: it has a flaw where a malicious contract can repeatedly withdraw funds while exploiting the read-only <strong>getBalance</strong> function. This can lead to unauthorized changes to the contract’s state and the potential loss of funds.</p><ul><li><strong>Single function Reentrancy:</strong></li></ul><p>Single-function reentrancy is a type of attack that involves a situation in which the attacker aims to withdraw funds from the contract more than once. They achieve this by calling the same function over and over, even before the previous calls are complete. This creates a loop where the attacker can repeatedly drain funds from the contract.</p><p>This attack can be straightforward to understand and prevent, and it stresses the importance of ensuring that a function’s execution is completed before allowing further calls to it.</p><p>For clarity, let’s look at the example below:</p><pre>// SPDX-License-Identifier: MIT<br><br>// Vulnerable contract<br>pragma solidity ^0.8.0;<br><br>contract VulnerableReentrancy {<br>    mapping(address =&gt; uint256) private balances;<br><br>    function deposit() public payable {<br>        balances[msg.sender] += msg.value;<br>    }<br><br>    function withdraw(uint256 amount) public {<br>        require(balances[msg.sender] &gt;= amount, &quot;Insufficient balance&quot;);<br>        <br>        // Vulnerable point: External call before updating the balance<br>        (bool success, ) = msg.sender.call{value: amount}(&quot;&quot;);<br>        require(success, &quot;Transfer failed&quot;);<br>        <br>        balances[msg.sender] -= amount;<br>    }<br>}</pre><p>The vulnerable contract contains a function called <strong>withdraw</strong>, which is exposed to a single function reentrancy attack. The contract has a <strong>balances</strong> mapping that tracks the balances of different addresses. When an address calls the <strong>withdraw</strong> function and specifies an amount to withdraw, the contract transfers the specified amount to the caller’s address before updating their balance. This order of execution allows an attacker to repeatedly call the <strong>withdraw</strong> function before the balance is correctly updated, potentially draining more funds from the contract than they have.</p><ul><li><strong>Cross-Chain Reentrancy:</strong></li></ul><p>Cross-chain reentrancy is a type of reentrancy attack that occurs when a contract on one blockchain calls a contract on another blockchain, and the contract on the second blockchain calls back to the contract on the first blockchain. This can be exploited by the attacker to drain the funds from the contract on the first blockchain.</p><p>Cross-chain reentrancy attacks are a serious threat to the security of cross-chain applications. Developers of cross-chain applications should carefully consider the risks of cross-chain reentrancy attacks and take steps to mitigate these risks.</p><p>Here is an example of a contract vulnerable to cross-chain reentrancy:</p><pre>// SPDX-License-Identifier: MIT<br><br>pragma solidity ^0.8.0;<br><br>contract VulnerableContract {<br>    mapping(address =&gt; uint256) public balances;<br><br>    function deposit() external payable {<br>        balances[msg.sender] += msg.value;<br>    }<br><br>    function withdraw(uint256 amount) external {<br>        require(balances[msg.sender] &gt;= amount, &quot;Insufficient balance&quot;);<br>        <br>        // Vulnerable point: external contract call before updating balance<br>        (bool success, ) = msg.sender.call{value: amount}(&quot;&quot;);<br>        require(success, &quot;Transfer failed&quot;);<br><br>        balances[msg.sender] -= amount;<br>    }<br>}</pre><p>The <strong>withdraw</strong> function in the contract above allows for an external contract call (<strong>msg.sender.call</strong>) before updating the user’s balance, creating a vulnerable point for reentrancy.</p><p>If another contract on a different blockchain interacts with this contract and repeatedly calls the <strong>withdraw</strong> function before the <strong>balances[msg.sender] -= amount</strong> line is executed, it can lead to cross-chain reentrancy attacks and potentially drain the contract’s funds.</p><ul><li><strong>Cross-function Reentrancy:</strong></li></ul><p>Cross-function reentrancy occurs when a function within a contract keeps calling another function within the same contract before the first function completes. This creates a loop where functions interact with each other in an unsafe manner. Sometimes this vulnerability arises when multiple functions within a contract share and update the same data without proper guards.</p><p>Look at this simple example below:</p><pre>// SPDX-License-Identifier: MIT<br><br>pragma solidity ^0.8.0;<br><br>contract VulnerableContract {<br>    mapping(address =&gt; uint) balances;<br><br>    function deposit() public payable {<br>        balances[msg.sender] += msg.value;<br>    }<br><br>    function withdraw(uint amount) public {<br>        require(balances[msg.sender] &gt;= amount, &quot;Insufficient balance&quot;);<br>        balances[msg.sender] -= amount;<br>        (bool success, ) = msg.sender.call{value: amount}(&quot;&quot;);<br>        require(success, &quot;Transfer failed&quot;);<br>    }<br><br>    function withdrawAll() public {<br>        uint balance = balances[msg.sender];<br>        balances[msg.sender] = 0;<br>        (bool success, ) = msg.sender.call{value: balance}(&quot;&quot;);<br>        require(success, &quot;Transfer failed&quot;);<br>    }<br>}</pre><p>The contract lacks proper synchronization of state changes and external calls, making it liable to cross-function reentrancy attacks. The vulnerability lies in the fact that the state variable <strong>balances</strong> is updated after the call operation in both <strong>withdraw</strong> and <strong>withdrawAll</strong>. This allows an attacker to reenter the contract by calling one function repeatedly before the call in the previous invocation completes.</p><ul><li><strong>Cross-Contract Reentrancy:</strong></li></ul><p>Cross-contract reentrancy occurs when the state of one contract is used in another contract, yet this state isn’t entirely updated before being invoked. For a clearer understanding, look at the example below:</p><pre>// SPDX-License-Identifier: MIT<br><br>pragma solidity ^0.8.0;<br><br>contract VulnerableContract {<br>    mapping(address =&gt; uint256) public balances;<br><br>    function deposit() external payable {<br>        balances[msg.sender] += msg.value;<br>    }<br><br>    function withdraw(uint256 _amount) external {<br>        require(balances[msg.sender] &gt;= _amount, &quot;Insufficient balance&quot;);<br>        balances[msg.sender] -= _amount;<br>        (bool success, ) = msg.sender.call{value: _amount}(&quot;&quot;);<br>        require(success, &quot;Transfer failed&quot;);<br>    }<br>}</pre><p>The contract has a <strong>withdraw</strong> function that allows users to retrieve funds from their balance. However, the function lacks a guard against reentrancy attacks, enabling malicious external contracts to repeatedly invoke the function before previous calls complete.</p><h3>Mitigation Techniques</h3><p>Knowing how to protect your smart contract from reentrancy attacks is crucial. Below are some anti-reentrancy techniques and best practices you need to implement to safeguard your contracts:</p><ul><li><strong>Checks, Effects, and Interactions (CEI):</strong></li></ul><p>CEI is a basic technique used to minimize the damage of reentrancy attacks. How this technique works is that it checks and tries to update all states before calling for external contracts. To learn more about CEI you can look at the<strong> </strong><a href="https://docs.soliditylang.org/en/latest/security-considerations.html#use-the-checks-effects-interactions-pattern"><strong>solidity docs.</strong></a></p><ul><li><strong>Keep Your Code Simple:</strong></li></ul><p>Writing clean and simple code can significantly reduce the chances of your contracts or functions having bugs and prevent unexpected errors. Although your contract codes may be large and bogus, going through them, simplifying them, and reviewing them can help identify any flaws in the code.</p><ul><li><strong>Reentrancy Guard:</strong></li></ul><p>A reentrancy guard prevents the execution of multiple functions at the same time. By implementing a reentrancy guard, you prevent attackers from calling your contract or function multiple times. You can achieve this by using a reentrant function modifier. A suggested method is to utilize the <a href="https://docs.openzeppelin.com/contracts/4.x/api/security#ReentrancyGuard-nonReentrant--">nonReentrant()</a> modifier available in the OpenZeppelin library.</p><ul><li><strong>Pull Payment Strategy:</strong></li></ul><p>This involves setting up an intermediary whereby the paying contract doesn’t directly interact with the receiver account. Instead, the receiver account is responsible for withdrawing its payments. This is a good method to secure end-to-end transactions. To implement this strategy in your contract, it’s recommended to utilize the <a href="https://docs.openzeppelin.com/contracts/4.x/api/security#PullPayment"><strong>PullPayment contract</strong></a> from the Openzepplin library.</p><ul><li><strong>Pausable or Emergency Stop Pattern:</strong></li></ul><p>This pattern allows you to quickly pause any withdrawals as soon as you detect any suspicious activity in your contract. Only an authorized account can initiate this pausable feature. For better implementation, use the <a href="https://docs.openzeppelin.com/contracts/4.x/api/security#Pausable"><strong>pausable contract from Openzeppelin.</strong></a></p><ul><li><strong>Smart Contract Code Analysis Tools:</strong></li></ul><p>Code analysis tools are essential for preventing reentrancy vulnerabilities in smart contracts. These tools scan the codebase for potential vulnerabilities and provide recommendations for remediation. Some examples of code analysis tools for reentrancy vulnerabilities are Slither and Mythril.</p><ul><li><strong>Smart Contract Audit:</strong></li></ul><p>A smart contract audit is a security review of a smart contract’s code. This helps identify and fix any potential vulnerabilities that could be exploited by attackers. By conducting a smart contract audit before the contract is deployed to the mainnet, developers can reduce the risk of their contract being hacked.</p><h3>Conclusion</h3><p>Reentrancy vulnerabilities in smart contracts have led to significant losses in the past. Reentrancy attacks involve reentering a contract before its execution finishes, enabling malicious manipulation. The attack types discussed included read-only, single-function, cross-chain, cross-function, and cross-contract reentrancy. Developers can guard against reentrancy by using techniques such as CEI, applying simplicity in code, reentrancy guards, pull payment strategy, pausable pattern, utilizing analysis tools, and conducting smart contract audits.</p><p>These measures collectively strengthen smart contract security by reducing reentrancy vulnerabilities and potential losses.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=b576c305cd25" width="1" height="1" alt=""><hr><p><a href="https://medium.com/rektify-ai/mastering-reentrancy-security-b576c305cd25">Mastering Reentrancy Security</a> was originally published in <a href="https://medium.com/rektify-ai">Rektify AI</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[How to Mitigate Access Control Vulnerability]]></title>
            <link>https://medium.com/rektify-ai/how-to-mitigate-access-control-vulnerability-6df74c82af98?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/6df74c82af98</guid>
            <category><![CDATA[smart-contract-auditing]]></category>
            <category><![CDATA[web3]]></category>
            <category><![CDATA[solidity-security]]></category>
            <category><![CDATA[solidity]]></category>
            <category><![CDATA[smart-contract-security]]></category>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Tue, 31 Oct 2023 16:26:44 GMT</pubDate>
            <atom:updated>2023-10-31T16:26:44.169Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*9JBhIXd3v5tedc7b" /></figure><h3>Introduction</h3><p>In August 2021, Poly Network, a decentralized finance platform, was hacked for $611 million. The attacker exploited an access control vulnerability between two important Poly smart contracts to gain control of funds. You may be asking what access control is in a smart contract, especially in Solidity.</p><p>Access control in Solidity smart contracts means controlling who can do certain things with the contract based on their permission. This is important for smart contracts. It decides who can make new tokens, vote on ideas, make withdrawals, stop transfers, and more.</p><p>So, it’s crucial to understand how to set it up properly, or attackers will take advantage of your system.</p><h3>What is an Access Control Vulnerability?</h3><p>An Access control vulnerability is a type of security flaw that allows users without permission to interact with and alter data or functions in a smart contract. This vulnerability can occur when there is a loophole in access restrictions and role assignment in a Solidity smart contract.</p><p>A lot of decentralized projects have lost tons of money due to this simple security issue. But this security risk can be prevented. In the next section below, we will go over some mitigation strategies and examples.</p><h3>Mitigation Strategies and Examples</h3><ul><li><strong>Use the Require statement effectively:</strong></li></ul><pre>// This contract is vulnerable to an access control vulnerability<br><br>contract AccessControlVulnerable {<br>    mapping(address =&gt; uint256) private balances;<br>    <br>    function deposit() public payable {<br>        balances[msg.sender] += msg.value;<br>    }<br>    <br>    function withdraw(uint256 amount) public {<br>        // Missing require statement to check balance<br>        uint256 balance = balances[msg.sender];<br>        // No check for sufficient balance before withdrawal<br>        balances[msg.sender] -= amount;<br>        payable(msg.sender).transfer(amount);<br>    }<br>    <br>    function getBalance() public view returns (uint256) {<br>        return balances[msg.sender];<br>    }<br>}</pre><p>Looking at the contract above, you see that the <strong>withdraw</strong> function has a flaw, an access control vulnerability because it doesn’t include a<strong>require</strong> statement to check if the sender has sufficient balance before allowing the withdrawal.</p><p>This means that anyone can withdraw any amount, even if they don’t have enough balance in their account.</p><p>How do we fix this vulnerability? By including a<strong>require</strong> statement to check if the sender has sufficient balance before allowing the withdrawal.</p><p>Solution</p><pre>// This contract has improved access control<br><br>contract AccessControlImproved {<br>    mapping(address =&gt; uint256) private balances;<br>    <br>    function deposit() public payable {<br>        balances[msg.sender] += msg.value;<br>    }<br>    <br>    function withdraw(uint256 amount) public {<br>        require(amount &lt;= balances[msg.sender], &quot;Insufficient balance&quot;);<br>        <br>        balances[msg.sender] -= amount;<br>        payable(msg.sender).transfer(amount);<br>    }<br>    <br>    function getBalance() public view returns (uint256) {<br>        return balances[msg.sender];<br>    }<br>}</pre><ul><li><strong>Utilize Access Modifiers:</strong></li></ul><pre>contract AccessControlVulnerability {<br>    address public owner;<br>    uint256 public secretNumber;<br><br>    constructor(uint256 _initialNumber) {<br>        owner = msg.sender;<br>        secretNumber = _initialNumber;<br>    }<br><br>    function setSecretNumber(uint256 _newNumber) public {<br>        // No access modifier, so anyone can change the secretNumber<br>        secretNumber = _newNumber;<br>    }<br><br>    function getSecretNumber() public view returns (uint256) {<br>        return secretNumber;<br>    }<br>}</pre><p>Observe the example above: the<strong>setSecretNumber</strong> function doesn’t have an access modifier like,<strong>onlyOwner</strong> which means anyone can call it to change the <strong>secretNumber</strong>. This is a vulnerability because the contract’s intention was likely to allow only the owner to modify the secret number, but due to the absence of access control, anyone can change it.</p><p>Here is a solution:</p><pre>contract SecureAccessControl {<br>    address public owner;<br>    uint256 public secretNumber;<br><br>    constructor(uint256 _initialNumber) {<br>        owner = msg.sender;<br>        secretNumber = _initialNumber;<br>    }<br><br>    modifier onlyOwner() {<br>        require(msg.sender == owner, &quot;Only the owner can call this function&quot;);<br>        _;<br>    }<br><br>    function setSecretNumber(uint256 _newNumber) public onlyOwner {<br>        secretNumber = _newNumber;<br>    }<br><br>    function getSecretNumber() public view returns (uint256) {<br>        return secretNumber;<br>    }<br>}</pre><p>Now we’ve updated the contract, the <strong>onlyOwner</strong> modifier has been added. This modifier checks if the caller of a function is the contract owner before allowing the function to proceed. By adding this modifier to the <strong>setSecretNumber</strong> function, we ensure that only the owner of the contract can change the secret number.</p><ul><li><strong>Use OpenZepplin Access Control Interface:</strong></li></ul><p>The contract below is a <strong>VotingSystem</strong> contract, and it lacks proper access control for the vote function. This means that any address can call the vote function multiple times, evading any limitations on the number of votes a single user should be allowed to cast. This stands as a flaw in the voting system, as it doesn’t prevent unauthorized or over-voting.</p><pre>// vulnerable contract <br><br>contract VotingSystem {<br>    mapping(address =&gt; bool) private hasVoted;<br>    uint256 public totalVotes;<br><br>    constructor() {<br>        totalVotes = 0;<br>    }<br><br>    function vote() public {<br>        // No access control check; anyone can vote multiple times<br>        require(!hasVoted[msg.sender], &quot;You have already voted&quot;);<br>        hasVoted[msg.sender] = true;<br>        totalVotes++;<br>    }<br><br>    function getVoteStatus(address voter) public view returns (bool) {<br>        return hasVoted[voter];<br>    }<br>}</pre><p>The vulnerability in the <strong>VotingSystem</strong> contract can be mitigated by using an access control interface from OpenZepplin</p><pre>//secured contract<br>import &quot;@openzeppelin/contracts/access/Ownable.sol&quot;;<br><br>contract SecureVotingSystem is Ownable {<br>    mapping(address =&gt; bool) private hasVoted;<br>    uint256 public totalVotes;<br><br>    constructor() {<br>        totalVotes = 0;<br>    }<br><br>    function vote() public onlyOwner {<br>        require(!hasVoted[msg.sender], &quot;You have already voted&quot;);<br>        hasVoted[msg.sender] = true;<br>        totalVotes++;<br>    }<br><br>    function getVoteStatus(address voter) public view returns (bool) {<br>        return hasVoted[voter];<br>    }<br>}</pre><p>You can see that we’ve imported the <strong>Ownable</strong> contract from OpenZeppelin, which provides a simple access control system. By using the <strong>onlyOwner</strong> modifier, we ensure that only the contract’s owner (deployer) can call the vote function. This prevents unauthorized users from voting multiple times and implements proper access control over the voting process.</p><ul><li><strong>Implement a Well-Designed Role-Based Access Control System:</strong></li></ul><p>Role-based access control is a system where different roles are assigned to users or entities and access permissions are granted based on these roles. Implementing a well-designed role-based access control system can greatly enhance the security of a smart contract by preventing unauthorized access, and minimizing the impact of access control vulnerabilities.</p><p>For a clearer understanding, let’s look at the example below:</p><p><strong>Vulnerable contract:</strong></p><pre>pragma solidity ^0.8.0;<br>// Vulnerable Contract - LendingData.sol<br><br>contract LendingData {<br>    address public owner;<br><br>    constructor() {<br>        owner = msg.sender;<br>    }<br><br>    // Vulnerable function allowing the owner to transfer ownership<br>    function transferOwnership(address newOwner) public {<br>        require(msg.sender == owner, &quot;Only the owner can transfer ownership&quot;);<br>        owner = newOwner;<br>    }<br><br>    // Other functions...<br>}</pre><p><strong>Solution Contract:</strong></p><pre>pragma solidity ^0.8.0;<br>// Solution Contract - LendingData.sol<br><br>contract LendingDataSolution {<br>    address public owner;<br>    mapping(address =&gt; bool) public managers; // Additional role<br><br>    constructor() {<br>        owner = msg.sender;<br>        managers[msg.sender] = true; // Assign the creator as manager<br>    }<br><br>    modifier onlyOwner() {<br>        require(msg.sender == owner, &quot;Only the owner can call this function&quot;);<br>        _;<br>    }<br><br>    modifier onlyManager() {<br>        require(managers[msg.sender], &quot;Only managers can call this function&quot;);<br>        _;<br>    }<br><br>    // Functions with proper access control<br>    function transferOwnership(address newOwner) public onlyOwner {<br>        owner = newOwner;<br>    }<br><br>    function addManager(address newManager) public onlyOwner {<br>        managers[newManager] = true;<br>    }<br><br>    // Other functions...<br>}</pre><p>From the two contracts above, you will notice that In the vulnerable contract, the <strong>LendingData</strong> contract allows only the owner to transfer ownership and perform other functions. This is an example of improper role-based access control because it gives too much authority to the owner, which might lead to security issues if the owner’s account is compromised.</p><p>The solution contract, LendingDataSolution, implements a more full-bodied access control mechanism. It introduces the concept of managers as an additional role.</p><p>The owner can still perform critical actions, but the ability to add managers allows the owner to delegate specific responsibilities without giving away full control. The <strong>onlyOwner</strong> and <strong>onlyManager</strong> modifiers ensure that only the appropriate roles can call specific functions, reducing potential security risks.</p><p>This solution highlights the essence of applying proper access control policies and avoiding a single point of authority.</p><ul><li><strong>Whitelisting</strong>:</li></ul><p>When it comes to mitigating access control-related vulnerabilities, whitelisting is another essential technique. Whitelisting is used to specify a list of addresses or entities that are allowed to perform certain actions or access specific resources in a smart contract. By doing this, only those addresses that have been pre-approved have access, thereby reducing the attack surface and potential vulnerabilities.</p><p>For instance, let’s consider an NFT marketplace that allows users to interact with a smart contract to create and manage digital collectables (NFTs). Here’s a vulnerable contract where anyone can mint NFTs without proper access control:</p><p>In this vulnerable contract, the <strong>mintNFT</strong> function doesn’t have any access control system. Anyone can call this function and mint new NFTs, which could lead to unauthorized or malicious minting in this situation.</p><pre>// Vulnerable Contract - Collectibles.sol<br>pragma solidity ^0.8.0;<br><br>import &quot;@openzeppelin/contracts/token/ERC721/ERC721.sol&quot;;<br><br>contract Collectibles is ERC721 {<br>    uint256 public tokenIdCounter;<br>    <br>    constructor() ERC721(&quot;Collectibles&quot;, &quot;COLL&quot;) {}<br><br>    function mintNFT(address to) public {<br>        tokenIdCounter++;<br>        _mint(to, tokenIdCounter);<br>    }<br>}</pre><p>Now let’s use whitelisting to stop unauthorized minting and maintain control over who can mint NFTs:</p><pre>// Solution Contract - Collectibles.sol<br>pragma solidity ^0.8.0;<br><br>import &quot;@openzeppelin/contracts/token/ERC721/ERC721.sol&quot;;<br>import &quot;@openzeppelin/contracts/access/Ownable.sol&quot;;<br><br>contract CollectiblesSolution is ERC721, Ownable {<br>    uint256 public tokenIdCounter;<br>    mapping(address =&gt; bool) public whitelistedMinters;<br><br>    constructor() ERC721(&quot;Collectibles&quot;, &quot;COLL&quot;) {}<br><br>    function mintNFT(address to) public onlyWhitelistedMinter {<br>        tokenIdCounter++;<br>        _mint(to, tokenIdCounter);<br>    }<br><br>    function addToWhitelist(address minter) public onlyOwner {<br>        whitelistedMinters[minter] = true;<br>    }<br><br>    function removeFromWhitelist(address minter) public onlyOwner {<br>        whitelistedMinters[minter] = false;<br>    }<br><br>    modifier onlyWhitelistedMinter() {<br>        require(whitelistedMinters[msg.sender], &quot;Only whitelisted minters can call this function&quot;);<br>        _;<br>    }<br>}</pre><p>So, in the solution contract, we’ve used whitelisting by maintaining a mapping of addresses that are authorized to mint NFTs. The <strong>mintNFT</strong> function now has the <strong>onlyWhitelistedMinter</strong> modifier, which makes sure that only addresses on the whitelist can call this function. Additionally, the contract owner can manage the whitelist using the <strong>addToWhitelist</strong> and <strong>removeFromWhitelist</strong> functions.</p><h3>Conclusion</h3><p>To wrap everything up, access control vulnerabilities are a very popular attack vector used by hackers to exploit smart contracts, and it is important we manage access and permissions in smart contracts effectively. Using mitigation techniques like Role-Based Access Control Systems, access modifiers, OpenZeppelin access control interfaces, require statements, and whitelisting can go a long way toward minimizing the risk of being hacked.</p><p><strong>function</strong> <strong>getSecretNumber</strong>() <strong>public</strong> view returns (uint256) {<br> <strong>return</strong> secretNumber;<br> }<br>}</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=6df74c82af98" width="1" height="1" alt=""><hr><p><a href="https://medium.com/rektify-ai/how-to-mitigate-access-control-vulnerability-6df74c82af98">How to Mitigate Access Control Vulnerability</a> was originally published in <a href="https://medium.com/rektify-ai">Rektify AI</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[How Chainlink VRF Works]]></title>
            <link>https://medium.com/@natachigram/how-chainlink-vrf-works-46f14645813c?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/46f14645813c</guid>
            <category><![CDATA[solidity]]></category>
            <category><![CDATA[smart-contracts]]></category>
            <category><![CDATA[smart-contract-security]]></category>
            <category><![CDATA[chainlink-vrf-v2]]></category>
            <category><![CDATA[blockchain-development]]></category>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Sun, 24 Sep 2023 18:14:08 GMT</pubDate>
            <atom:updated>2023-09-24T18:37:57.031Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*81OvKHEoVNQVShjfTisnxA.jpeg" /></figure><h3>Introduction</h3><p>Chainlink VRF (Verified Random Function) was developed to provide a source of randomness that is resistant to manipulation. It is a provably fair and verifiable random number generator (RNG) that enables smart contracts to access random values without compromising security or usability.</p><p>The importance of using Chainlink VRF is to prevent bad randomness. Because random numbers generated from Chainlink VRF cannot be manipulated by nodes or attackers, unlike generating random numbers from on-chain values like block-hash and block-timestamp.</p><h3>How Does Chainlink VRF Work?</h3><p>Chainlink VRF is a verifiable random function (VRF) that provides smart contracts with access to tamper-proof randomness. It works by using a combination of on-chain and off-chain components to generate and verify random numbers.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*bZY4_WvekoZFj_UW" /></figure><p>The process begins with a consumer contract requesting randomness from the VRF coordinator. The VRF coordinator then triggers an event that is picked up by the Chainlink VRF off-chain service.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*qlnFfBZWhpRDLyj4" /></figure><p>The off-chain service generates a random number using a combination of block data and its own private key. The private key is committed to on-chain by publishing the corresponding public key. This ensures that the randomness cannot be manipulated by the off-chain service.</p><p>The off-chain service then sends the random number and a cryptographic proof of its generation to the VRF coordinator. The VRF coordinator verifies the proof and, if valid, sends the random number to the consumer contract.</p><p>This process is self-auditing, meaning that it does not require external verification. The VRF coordinator verifies the random number proof and the consumer contract can verify that the random number was generated by the VRF coordinator.</p><h3>Conclusion</h3><p>Chainlink VRF is a powerful tool that is especially useful for applications that require a high degree of randomness, such as gaming, gambling, and lotteries. Chainlink VRF is also becoming popular in the web3 space, and it is used to create blockchain applications that are resistant to front-running, bad randomness and other forms of manipulation.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=46f14645813c" width="1" height="1" alt="">]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[The Vyper Compiler Saga: Unraveling the Reentrancy Bug that Shook DeFi]]></title>
            <link>https://medium.com/rektify-ai/the-vyper-compiler-saga-unraveling-the-reentrancy-bug-that-shook-defi-86ade6c54265?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/86ade6c54265</guid>
            <category><![CDATA[blockchain-security]]></category>
            <category><![CDATA[smart-contracts]]></category>
            <category><![CDATA[curve-finance]]></category>
            <category><![CDATA[vyper]]></category>
            <category><![CDATA[smart-contract-security]]></category>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Fri, 04 Aug 2023 19:03:05 GMT</pubDate>
            <atom:updated>2023-08-04T19:03:05.934Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*sXcOAEusJJn7AtLUnuh0yg.jpeg" /></figure><h3>Introduction</h3><p>On July 30, 2023, there was a problem in the DeFi space because of a bug in the Vyper compiler versions. These particular Vyper versions (0.2.15, 0.2.16, and 0.3.0) had an issue with reentrancy locks, which made them not work correctly. The team behind Vyper is still looking into this problem to find a solution. This incident has made people in the DeFi community worried and has shown how important it is to have strong security measures on decentralized finance platforms.</p><p>In this article, we will explain what a malfunctioning reentrancy lock means and talk about the hack in more detail. We will also discuss what happened after the hack and its consequences.</p><h3>What are Vyper Compiler, Reentrancy, and Malfunctioning Reentrancy Lock?</h3><p>The Vyper Compiler is a Python-based compiler for the Vyper programming language. It converts Vyper code to bytecode that can be executed by the Ethereum virtual machine.</p><p>Reentrancy vulnerability occurs when a smart contract allows external contracts to make repeated calls back into the same contract before it is fully processed. This could lead to a serious security risk.</p><p>In this current situation, a malfunctioning reentrancy lock can be referred to as a technique designed on Vyper to prevent reentrancy attacks, but due to some malfunctioning, it fails to provide the intended protection.</p><h3>Deep Dive into Vyper Compiler Bug and The Aftermath</h3><p>The attackers started with flash loans and took advantage of the reentrancy lock bug found in Vyper compiler versions 0.2.15, 0.2.16, and 0.3.0. <a href="https://twitter.com/vyperlang/status/1685692973051498497?s=20">Vyper</a> and <a href="https://twitter.com/CurveFinance/status/1685693202722848768?s=20">Curve Finance</a> both tweeted to confirm that these compiler versions were vulnerable to malfunctioning reentrancy locks.</p><figure><a href="https://twitter.com/vyperlang/status/1685692973051498497?s=20"><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*FyzC6Q4cKqECl-mv" /></a></figure><figure><a href="https://twitter.com/CurveFinance/status/1685693202722848768?s=20"><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*xmtpg9uHHahPrGH9" /></a></figure><p>The attackers used this flaw primarily to target the factory pools on Curve Finance. The attackers got away, stealing over $26 million from Curve Finance.</p><p>The attackers targeted multiple factory pools on Curve Finance. These pools included AlchemixFi, JPEGd, MetronomeDAO, Debridge Finance, and Ellipsisfi.</p><p>AlchemixFi loses 7,258.70 ETH, which is about $13.6 million. JPEGd lost 6,102.75 ETH, which is about $11.4 million. MetronomeDAO lost 866.55 ETH, which is also about $1.6 million. Debridge Finance lost 13.13 ETH, which is about $24 thousand, and Ellipsisfi lost 283.02 WBNB, which is about $68 thousand.</p><figure><a href="https://twitter.com/PeckShieldAlert/status/1685696196839649280/photo/1"><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*J7qmYtSRQRIDO98O" /></a></figure><p>Assets Stolen from the Curve pools due to this security flaw have crossed $41 million. This is according to Blocksec (A security firm). Blocksec has also stated that the reentrancy attack is linked to the use of ‘use_eth’ and potentially puts the WETH related pools at risk.</p><figure><a href="https://twitter.com/BlockSecTeam/status/1685742026749300736?s=20"><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*ZvYKLw1JibDg4RtI" /></a></figure><p>All the affected groups have been liquidated by security experts. This is a way to mitigate the impact.</p><p>During the recent hack, a white hat hacker managed to take back about 2,879 ETH, worth around $5.4 million, from an attacker. Then, the white hat hacker returned the funds to Curve Finance.</p><figure><a href="https://twitter.com/PeckShieldAlert/status/1685804409610203136?s=20"><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*ZhsHg2kPvDhYat00" /></a></figure><p>Still on the hack, Blocksec also discloses that the <a href="https://www.binance.com/en/feed/post/884604">BNB Smart Chain experienced copycat attacks</a> as a result of the Vyper vulnerability. Approximately $73,000 was stolen through three different exploits.</p><h3>Conclusion</h3><p>The Vyper Compiler’s malfunctioning reentrancy bug in versions 0.2.15, 0.2.16, and 0.3.0 led to a $26 million exploit on Curve Finance and other projects. This incident highlights the critical need for robust security measures and cross-platform vigilance in the DeFi space. Prompt response and white hat hacker involvement aided in mitigating the impact. Moving forward, prioritizing security best practices and conducting thorough audits are essential for the growth and trustworthiness of decentralized finance.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=86ade6c54265" width="1" height="1" alt=""><hr><p><a href="https://medium.com/rektify-ai/the-vyper-compiler-saga-unraveling-the-reentrancy-bug-that-shook-defi-86ade6c54265">The Vyper Compiler Saga: Unraveling the Reentrancy Bug that Shook DeFi</a> was originally published in <a href="https://medium.com/rektify-ai">Rektify AI</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Attack Vectors in Solidity: Signature Verification Exploit]]></title>
            <link>https://coinsbench.com/attack-vectors-in-solidity-11-signature-verification-exploit-d961cc551863?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/d961cc551863</guid>
            <category><![CDATA[smart-contract-security]]></category>
            <category><![CDATA[blockchain]]></category>
            <category><![CDATA[web3-security]]></category>
            <category><![CDATA[smart-contracts]]></category>
            <category><![CDATA[web3]]></category>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Thu, 13 Jul 2023 16:36:18 GMT</pubDate>
            <atom:updated>2023-07-21T22:53:25.497Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*MITCCGy9VWEjPzOxe8M6cA.jpeg" /></figure><h3>Introduction</h3><p>A signature verification exploit is a critical vulnerability that can affect smart contracts. This exploit arises when there is a flaw in the signature verification process, allowing attackers to falsify signatures and perform unauthorized actions. This article will explore the concept of the solidity signature verification exploit as an attack vector, give a practical example, and go over mitigation techniques to guard against this vulnerability.</p><h3>Vulnerability</h3><p>When a smart contract fails to correctly verify the validity of signatures, it might fall victim to the Signature Verification attack. An attacker can take advantage of this flaw to fake signatures and trick the contract into accepting unauthorized transactions. Severe implications might result from this vulnerability, including unauthorized financial transfers, access to restricted features, or contract state modification.</p><h3>Exploit Example</h3><p>Let’s take a more straightforward case where a contract uses signature verification to approve a fund transfer. The contract contains a function transfer that requires a valid signature from the sender to execute the transfer. However, due to a flaw in the signature verification process, the contract is vulnerable to forgery.</p><pre>contract MyContract {<br>    function transfer(uint256 amount, bytes memory signature) public {<br>        address sender = msg.sender;<br>        require(verifySignature(sender, amount, signature), &quot;Invalid signature&quot;);<br><br>        // Perform the transfer<br>        // ...<br>    }<br><br>    function verifySignature(address signer, uint256 amount, bytes memory signature) internal returns (bool) {<br>        // Incorrect signature verification implementation<br>        // ...<br>    }<br>}</pre><p>In the above code, the transfer function attempts to verify the provided signature using the verifySignature function. However, the implementation of verifySignature is flawed, allowing an attacker to bypass the signature check and execute unauthorized transfers.</p><h3>Impact and Consequences</h3><p>A successful Signature Verification exploit may have far-reaching effects. It may result in financial losses, unauthorized access to confidential functions, contract state manipulation, or the compromise of user data. The impact of this attack might have serious consequences for users and the integrity of the system, depending on the contract’s nature and features.</p><h3>Mitigation Strategies</h3><p>To avoid the dangers associated with the Signature Verification attack, developers should use robust signature verification techniques. Here are some strategies to consider:</p><ul><li><strong>Use Standard Libraries:</strong> Rather than reinventing the wheel, developers may use well-established cryptographic libraries that provide reliable signature verification functions. OpenZeppelin’s ECDSA library, for example, provides safe and validated techniques for signature verification.</li><li><strong>Implement Proper Signature Verification:</strong> Developers should carefully develop the signature verification procedure, ensuring that it adheres to the best cryptographic practices. The process should include checking the authenticity of the provided signature against the expected signer and data.</li></ul><pre>contract MyContract {<br>    function transfer(uint256 amount, bytes memory signature) public {<br>        address sender = msg.sender;<br>        require(verifySignature(sender, amount, signature), &quot;Invalid signature&quot;);<br><br>        // Perform the transfer<br>        // ...<br>    }<br><br>    function verifySignature(address signer, uint256 amount, bytes memory signature) internal pure returns (bool) {<br>        bytes32 messageHash = keccak256(abi.encodePacked(signer, amount));<br>        bytes32 ethSignedMessageHash = ECDSA.toEthSignedMessageHash(messageHash);<br>        address recoveredSigner = ECDSA.recover(ethSignedMessageHash, signature);<br><br>        return recoveredSigner == signer;<br>    }<br>}</pre><p>The improved verifySignature function uses the ECDSA library to properly recover the signer from the provided signature and compare it to the expected signer.</p><ul><li><strong>Security Audits:</strong> Regular security audits performed by credible auditors or auditing firms can assist in identifying flaws in the contract’s signature verification procedure. Auditors can offer significant insights and recommendations for strengthening the contract’s security posture.</li><li>Consider incorporating external verification services that specialize in signature validation. Through separate validation processes, these services can offer an extra layer of security and assure the legitimacy of signatures.</li></ul><h3>Conclusion</h3><p>The Signature Verification attack poses a severe danger to Solidity-based smart contracts. It gives attackers the ability to fake signatures and carry out unauthorized operations within the contract. To mitigate this issue, developers should build robust signature verification techniques, use known libraries or external verification services, and perform frequent security audits. By using these mitigation techniques, developers may improve the security and trustworthiness of their smart contracts, protecting both user assets and the integrity of the blockchain ecosystem.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=d961cc551863" width="1" height="1" alt=""><hr><p><a href="https://coinsbench.com/attack-vectors-in-solidity-11-signature-verification-exploit-d961cc551863">Attack Vectors in Solidity: Signature Verification Exploit</a> was originally published in <a href="https://coinsbench.com">CoinsBench</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Attack Vectors in Solidity #4: Unencrypted Private Data On-Chain]]></title>
            <link>https://medium.com/@natachigram/attack-vectors-in-solidity-4-unencrypted-private-data-on-chain-cf4f3ff1cf71?source=rss-11a4cede12e7------2</link>
            <guid isPermaLink="false">https://medium.com/p/cf4f3ff1cf71</guid>
            <dc:creator><![CDATA[Natachi Nnamaka]]></dc:creator>
            <pubDate>Fri, 27 Jan 2023 20:51:22 GMT</pubDate>
            <atom:updated>2023-01-27T20:51:22.578Z</atom:updated>
            <content:encoded><![CDATA[<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*mTH025Xo45KnY3UhQcbsgA.jpeg" /></figure><h3>Unencrypted Private Data On-Chain as an Attack Vector</h3><h3>Introduction</h3><p>Blockchains are increasingly being used to store and manage sensitive data, including personal information, financial records, and intellectual property. While blockchains are designed to be secure and decentralized, storing unencrypted private data on the chain can potentially make it vulnerable to being accessed or modified by unauthorized parties. In this article, we will explore the risks of storing unencrypted private data on a blockchain, and some potential solutions for protecting this data.</p><h3>Risks of Storing Unencrypted Private Data on a Blockchain</h3><p>One of the main risks of storing unencrypted private data on a blockchain is the possibility of unauthorized access. Since blockchains are decentralized networks, anyone with access to the chain can potentially view or modify the data stored on it. This includes not only the intended recipients of the data, but also any malicious actors who might be able to gain unauthorized access to the chain.</p><p>For example, if an attacker is able to gain access to a blockchain containing unencrypted private data, they could potentially view or modify the data. This could lead to the data being exposed to the public or its integrity being compromised. Additionally, if the data is being used to authenticate or authorize access to sensitive systems or resources, an attacker could potentially use the compromised data to gain unauthorized access to these systems or resources.</p><p>Another risk of storing unencrypted private data on a blockchain is the possibility of data loss or corruption. Since blockchains are distributed networks, they are subject to various types of technical failures and errors that could lead to data loss or corruption. For example, if a node on the network fails or is taken offline, it could potentially lead to data being lost or becoming unavailable. Similarly, if there is an error in the software or hardware used to store or manage the data on the blockchain, it could potentially lead to data loss or corruption.</p><h3>Solutions for Protecting Unencrypted Private Data on a Blockchain</h3><p>There are several measures that can be taken to protect unencrypted private data on a blockchain and mitigate the risks described above. Some potential solutions include:</p><ul><li>Encrypting the data: One of the most effective ways to protect unencrypted private data on a blockchain is to encrypt it before it is stored on the chain. Encrypting the data makes it much more difficult for unauthorized parties to view or modify the data, and can help to protect against various types of attacks. There are many different encryption algorithms and techniques that can be used to encrypt data, and it is important to carefully consider which one is most appropriate for a given situation.</li><li>Using secure protocols: Another way to protect unencrypted private data on a blockchain is to use secure protocols to access the data. This might involve using secure socket layers (SSL) or other protocols to establish secure connections between the parties accessing the data. Using secure protocols can help to prevent unauthorized parties from intercepting or modifying the data as it is transmitted over the network.</li><li>Implementing other security measures: In addition to encryption and secure protocols, there are many other security measures that can be implemented to protect unencrypted private data on a blockchain. This might include implementing access controls to limit who can view or modify the data, implementing authentication and authorization protocols to verify the identity of users accessing the data, or using monitoring and detection tools to detect and prevent unauthorized access to the data.</li></ul><h3>Conclusion</h3><p>In conclusion, unencrypted private data on a blockchain can be an attack vector and it is important to take steps to protect this data. Encrypting the data before it is stored on the chain, using secure protocols to access the data, and implementing other security measures can all help to protect against unauthorized access or modification of the data. By carefully considering the security implications of storing sensitive data on a blockchain, and taking appropriate measures to protect it, organizations can help to ensure the integrity and confidentiality of their data.</p><p><em>Thank you for reading my article. If you enjoyed this article, please consider following me and leaving a comment. I would love to hear your thoughts and feedback. Let me know if you have any questions or suggestions for future articles. Thank you for your support!</em></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=cf4f3ff1cf71" width="1" height="1" alt="">]]></content:encoded>
        </item>
    </channel>
</rss>