Identifying Admin Key Exploits
with SAULO RICCI and MUDABBIR KALEEM
Intro
In this report, we perform the first systematic review of Admin Key exploits in Ethereum. For context, Admin Keys have become the primary access management tool for smart contracts, enabling developers to arbitrarily make changes to their already-deployed smart contracts. While incredibly convenient for experimentation and maintenance, Admin Keys introduce a centralization factor that, if exploited, can be incredibly destructive not only to the exploited application itself but also to the entire DeFi ecosystem. In order to understand whether these risks have historically materialized, we developed an Intrusion Detection System (IDS) that checks onchain for the attributes of an Admin Key exploit. Then, we applied the IDS to the entire archival history of the Ethereum blockchain.
A Note on DeFi Protocol Development
Beyond its potential impact on finance, the advent of DeFi has required a complete re-evaluation of how smart contracts are developed. A new paradigm has emerged that is at odds with the Silicon Valley ethos of moving fast and breaking things. In a lot of ways, smart contracts are like rockets. Once deployed, their flaws and vulnerabilities cannot be fixed. Like rockets, there is very little their creators can do in case of catastrophic failures other than watch their creations implode.
While the laws governing blockchains are more flexible than the laws of physics, the principle still stands: smart contracts are immutable post-launch because they need to be. That is the main goal of using a blockchain in the first place for these types of applications. The clauses of the contract are solidified on the blockchain and participants can have assurances that they will not change. Otherwise, it’s not a level playing field and it would be impossible to manage risk and build trust in the system.
Needless to say, this fundamental structure does not go well with experimentation. Builders with a Web2 approach to product development have to re-learn core principles when making the leap to Web3. No more moving fast when breaking things entail multi-million dollar losses. Naturally, this was not a lesson learned overnight by the industry. It took massive exploits over the course of many years before the requirement for a rocket scientist mindset was established. Similarly, it also took several years and many failed experiments before tooling to enable safe experimentation was developed.
The Birth of Application Admins
Chief amongst the exploits that triggered a reevaluation of how applications are developed was The DAO Hack of 2016. Envisioned as a decentralized venture capital fund, The DAO was at the edge of experimentation in Ethereum and attracted millions of dollars worth of ETH in deposits. While the DAO was successful at acquiring users, its codebase was riddled with issues. Upon launch, a reentrancy vulnerability enabled an attacker to steal nearly all user funds. The DAO’s seemingly innocuous nine hundred lines of experiential code effectively lead to the halt and subsequent hard fork of the entire Ethereum network.
In the aftermath of The DAO Hack, security became a major discussion point within the Ethereum community. Developers began converging on the notion that better security tools, such as access management, were critical to the success of Ethereum. In response to this, nearly a year after the hack, the auditing and security firm OpenZeppelin launched Defender, the first complete access management tool for smart contracts. The main goal of this tool was to enable smart contracts to have special permissions for their owners, or admins, so that they could halt or update an application in the event of a security breach.
Access control is by no means a new area in the field of security, it is perhaps the oldest, but prior to the launch of Defender, no such solutions had been systematized in the field of smart contracts. In this new paradigm, applications are implemented as two contracts; the application itself and an intermediary called a proxy which controls all interactions between users and the application. Simply put, the role of the proxy is to send users to the most up-to-date version of the application and store some user-level data in that process. While there is diversity in how projects are structured, both the proxy and the application contracts can be controlled by a special key called an admin key. Whoever possesses this key can make changes to the application via an update.
Fundamentally, this new approach de-emphasizes the need for perfection from the get-go and has simplified smart contract development. In order to better understand this dynamic, let us look at an example where the developers of an application want to expand functionality or fix critical bugs. This approach enables them to do so even if their application is live by simply telling the proxy contract to “update”. This would make user requests to be executed against the updated application code, as determined by the proxy. Because the proxy structure was in place at the contract’s launch, users of the application would not face downtime or otherwise notice the change.
Additionally, this structure eases the development and operational requirements of new types of applications, such as reserve-backed stablecoins such as USDT and USDC. These applications often require special functionality, such as the ability for the admin to mint or burn tokens to reflect increases and decreases in deposits. The admin is also able to “alter” key parameters, such as interest rates, in case the application offers yield to users holding its token. Critical operational functions are also enabled, such as the ability for the admin to whitelist/blacklist specific addresses, usually for compliance purposes, or even completely halt the application itself.
Admin Centralization and Risk
The immense increase in utility and convenience introduced by admin-level functionality did not come without a cost. As with most things in this industry, there are unavoidable trade-offs at play. Namely, the advent of admins introduces a centralization factor that has become a single point of failure for many DeFi applications. If the admin has the power to mint tokens or make any arbitrary change to an application’s codebase, what would happen in the event of a compromise? Due to the high connectivity between DeFi protocols, an admin key exploit at a major project could cause catastrophic damage – arguably of the same proportion of TheDAO.
Several projects are well aware of this risk and have taken preemptive measures to build security perimeters around their admins. We have identified three popular approaches to protecting applications’ admins, which have seen varying degrees of adoption:
Multi-Sigs, which require multiple entities to come together and produce a valid m-of-n signature in order to invoke admin functionality.
Time-locked Actions, which prevent the admin from being able to operate and/or limit the issuance of tokens for a predetermined period of time.
DAO Governance, whereby admin operations require community voting, most frequently by delegates of a Decentralized Autonomous Organization (DAO).
While mature applications tend to use at least one of the approaches above, many do not. Upon examining all major DeFi projects with an admin, we have found that several of them do not have any protections visible on-chain.
Notably, projects like USDC, OKB, and BNB do not have any on-chain security measures around their admins. That does not mean they are not protected using off-chain techniques, but those are much harder to audit. Many projects have steered away from on-chain Multi-Sigs given that they have been exploited on Ethereum in the past. An emerging trend in the industry is the use of Multi-Party Computation (MPC), which enables Multi-Sigs to be implemented outside of the blockchain and are effectively invisible on-chain. While that could be how USDC, OKB, and BNB protect their admins, we were unable to find disclosures by these projects on whether this is the case.
The Anatomy of an Admin Key Exploit
A reality the industry must face under this new paradigm is that every project with an admin can pose a threat not only to its users but to DeFi as a whole. This is especially true for reserve-backed stablecoins which as we have shown often have centralized admins with the ability to mint tokens. At first glance, it may seem like if the admins of these projects were to be compromised, the damage would be compartmentalized. After all, their value is predicated on fiat currency deposits held and controlled by their issuer. However, this only mitigates the risk for the issuer. All decentralized markets that have a trading pair with that currency could be entirely drained merely a few blocks after the admin is compromised and tokens are minted off thin air.
To better understand this, let us delve into what an admin key exploit looks like. It begins with the legitimate admin of an application being compromised and having their keys extracted. For some projects, this is as easy as compromising a single individual within that organization. For others, it might involve breaching an entire access management system which can be a substantially more complex feat. As mentioned previously, some projects assign admin control to a DAO whereby admin actions have to be approved via a governance process. Although this also complicates the exploit, there are several precedents where a governance process was compromised, many of which via technologies such as Flash Loans.
While simply stealing an Admin Key would be enough to wreak havoc, more sophisticated hackers think a step ahead and change the admin altogether. The reason behind this is simple: if both the admin and the hacker have the key, the admins could nullify the hacker’s actions and prevent monetization. As such, in order to avoid a race condition, it is in the hacker’s best interest to change the ownership of the application to a new address only controlled by the hacker. At this point, there is nothing the application’s legitimate owners can do other than to disclose to the community that there has been a breach.
Once the ownership of the application is transferred to a new address, the hacker can either manipulate the proxy contract or the application itself to monetize the hack. If the application already has the functionality to mint new tokens, as is the case with stablecoins, the hacker can mint any arbitrarily large amount of tokens. If not, the hacker can use the proxy contract to add that functionality, or even make direct changes to that token’s ownership ledger depending on how the application is structured. Either way, they can easily mint billions of units of tokens off thin air using the newly acquired admin power.
The final step is monetization. Decentralized Exchanges are often leveraged due to the fact that market making is automated in such venues, but it is also possible to target centralized exchanges. The hacker can swap the newly minted tokens across all Liquidity Pools that have a pair with that token. Since any large quantity of tokens can be printed, the hacker can simply swap as many tokens as needed until the liquidity in those markets is fully depleted. Crucially, all of this can happen within minutes after the legitimate admin is compromised and ownership is changed to the hacker.
Identifying Admin Key Exploits in the Wild
Now that we have delineated what the archetypical Admin Key exploit looks like, the natural next question is: how frequently do these exploits occur?
In order to find out, we designed an Intrusion Detection System (IDS) that monitors the key characteristics of an admin key exploit. For clarity, an IDS is a cybersecurity tool that detects activity indicative of an intrusion or an exploit. In this context, the IDS was designed to identify when three events happened consecutively: governance activity, such as admin key changes and/or proxy implementation updates, followed by token minting events, much like the diagram shown in the previous section. In order to decrease the incidence of false positives, we constricted the time interval to 3 hours since it is in the hacker’s best interest to act quickly once the admin is breached.
We then applied this IDS to all smart contracts in the Ethereum network between January 2020 and April 2022. During this time window, the IDS identified and flagged 3,446 instances where that sequence took place. Upon examination, it became clear that not all of these events were, in fact, exploits. We quickly identified false positives where that pattern was part of how certain applications operate. For example, the DEX aggregator 1-Inch issues so-called Liquidity Provider (LP) tokens with mint and burn functionality that were flagged by the IDS. As such, in order to narrow our results, we excluded all token types except for ERC20s with active markets. This resulted in a total of 123 instances where the IDS issued an alert.
In order to quantify these mints in dollar terms, we calculated the nominal value of each of 123 minting events. The nominal value represents the number of tokens minted multiplied by the price of the token at the time of the event. For example, if a project’s token is trading at $10 and a mint takes place where 1,000 tokens are issued, its nominal mint value is $10,000 USD. Although this metric is the only way to price the dollar value of a mint ex-ante, it is important to note that it does not account for liquidity issues that emerge when supply is debased. Going back to our example, if $10,000 USD worth of tokens is minted, but there is no liquidity in that market, it is unlikely the minted tokens are actually worth their nominal value.
While nominal mint value can be an unrealistic metric for thinly traded tokens, it can still provide insight into the magnitude of a token mint in dollar terms. The table below is a compilation of the top 10 mints by nominal mint value from the set of 123 refined IDS alerts. It is important to note that, although the IDS picked up these events, not all of them were in fact exploits. At times, a project might issue new tokens immediately after changing admins, and that might be an operational coincidence. However, we were unable to find public disclosures that justified the often drastic changes in supply in the projects listed below.
We were able to confirm that at least one project, the PAID Network, was indeed the target of an admin key exploit which led to the minting of $174.2M USD. We also noticed that both VITE and MBX saw the mint shortly after their contracts were launched, which may have been part of their bootstrapping phase. Combined, the nominal mint value of these events totals $483.3M USD. We expect this list to change as more admins get hacked which speaks for the importance of clearer disclosures from token issuers, as well as the continuous monitoring of these on-chain events. The latter is the only way investors and projects alike can minimize losses by preventing exposure to supply minted after a hack.
Since it would be impractical to perform a deep dive on all 123 events flagged by the IDS, we would like to highlight two case studies that clearly demonstrate how the real-time monitoring of admin keys can be useful in preventing financial loss. We will first take a closer look at the PAID Network (PAID) exploit and how the hacker was able to walk away with over $3M USD in stolen funds. Then, we will look into Basis Cash (BAC), a stablecoin project created by Terra’s Do Kwon that imploded soon after its launch.
Case Study 1: PAID Network (PAID)
The PAID Network is a project that aims to become a “blockchain incubator” and provide its users a venue to create simple business agreements. PAID was initially funded via a private seed round of 2M USD from venture capital investors. In order to offer tokens to a broader set of investors, the project subsequently performed an IDO (Initial DEX Offering), which is a type of token sale offered through a decentralized exchange, in January of 2021. The sale was successful and PAID sold over 3M tokens in that fashion.
Like most ERC20 tokens created after 2020, PAID used a proxy to update its application. After the IDO, on January 26th 2021, the admin of the proxy was invoked and the application was updated to add the functionality to mint and burn PAID tokens. According to the project, this functionality was added specifically to mint new tokens and assign them to all roughly 300 IDO participants. Once investors received their freshly-minted PAID tokens, the proxy was updated once again to remove the mint and burn functionality for security purposes.
Only five weeks after PAID’s IDO, on March 5 2021, disaster struck. A hacker was able to breach the PAID team, and extract their admin key. In order to outright prevent the team from being able to respond to the breach, the hacker re-assigned the ownership of the proxy contract which effectively locked the team out. Once the hacker had full control of the proxy, the update function was used to re-introduce mint and burn functionality. Since PAID had a token cap, the hacker had to burn millions of tokens and then mint an equivalent amount to new address only they controlled, leading to a huge fluctuation in token supply. After making several mistakes and failed attempts, the hacker’s address received 59.47M PAID tokens.
Around two minutes after the millions of new tokens were minted, the hacker approved them to be sold on Uniswap. The minted tokens had a nominal value of 174.2M USD, making the hack among the largest in the history of DeFi. Nevertheless, there was not enough liquidity to capitalize on the mint entirely. The hacker was only able to sell around 3M of the 59.47M tokens minted before the liquidity of PAID markets in Uniswap was depleted. By March 6, the hacker had netted around 3,000 WETH worth over 4.6M USD at the time.
By the time the hack was publicly disclosed, it was too late. The hacker’s relentless selling of PAID tokens created chaos and the price of the token dropped 90% across markets over the following days. Since the hacker hijacked the proxy, the PAID team had only one option to recover from the hack: broadcast an entirely new contract and socially coordinate a migration with token holders. In order to recover, the original ledger had to be created using account balances from the block that preceded the hack. Arguably, had the project employed stronger safeguards around their keys, it is likely that they would have prevented the severe disruption and financial loss caused by the hack.
Case Study 2: Basis Cash (BAC)
Basis was a prominent algorithmic stablecoin project that attempted to achieve price stability via so-called Seigniorage Shares. Although Basis received substantial amounts of interest and around $133M in investments in 2018, the project ultimately shut down in 2018 citing regulatory concerns. Nearly two years later, in November of 2020, a group of pseudonyms launched a spin-off of the Basis stablecoin called Basis Cash. Amongst the creators was Rick Sanchez, a pseudonym now believed to belong to Do Kwon, the infamous founder of LUNA.
Basis Cash relied on a complex system consisting of three ERC20 tokens: Basis Cash (BAC), Basis Shares (BAS), and Basis Bond (BAB). On November 29th, 2020, several markets were established on Uniswap to enable users to trade each of these assets using several different stablecoins, including USDC, DAI, SUSD, and USDT. The founders of Basis Cash also created two “official” liquidity pools that were actively managed for the BAC-DAI and BAS-DAI pairs.
Although Basis Cash was designed to retain parity with the US Dollar, it reached upwards of $300 USD per token only two days after the launch. Markets saw considerable volume and the BAC-DAI liquidity pool was the 4th largest market on Uniswap by Total Value Locked (TVL) in early December. Due to the intrinsic design of BAC’s stabilization mechanism, the smart contract automatically issued more units of BAC and increased circulating supply by many multiples.
Four days after the enormous BAC token mint, the project’s admin key was invoked and the admin changed. This was highly unusual given that Basis Cash was designed to operate purely algorithmically. The entire contract was reinitialized and the new admin erased all tokens that had been minted using the burn function, thereby bringing supply back to previous levels. The mint function was also used and the project’s treasury awarded 1001 units of BAC. While the new admin was likely still part of the Basis Cash organization, the unusual nature of this “reset” should have served as a loud warning that the project was not working as intended. The severity of the reset also revealed a casual and arbitrary approach to the project’s governance that would have likely made investors concerned had they been aware of the admin’s actions.
The same exact event happened two days later, whereby the entire application was reinitialized, large quantities of BAC was burnt, and the treasury was awarded freshly minted BAC tokens. This time, too, it appeared that the admin change was a “reset” – a desperate attempt to peg BAC to the US dollar. While the price of BAC did go down after the second alert, it was too late by then. The complete lack of stability irreparably damaged the project, which ultimately failed. No other attempts were made to reset the application after the two admin changes.
In this case, the change of the admin key and the resulting reset were clear signs that the project was facing severe issues where the only solution was a complete reset. It is important to note that we have not found a direct connection between the treasury address that received the mints and any liquidity provider selling tokens on Uniswap. Nevertheless, had investors and market participants been aware of the drastic moves the admins were making behind the scenes, they would arguably have not provisioned liquidity to the project and potentially prevented multi-million dollar losses.
Avoiding a DeFi Black Swan
It is remarkable that our analysis of historical admin key exploits did not find exploits at major projects, but the attack vector remains. There are clear steps industry participants can take to diminish, or outright eliminate, the single points of failure introduced by admin keys. While functions such as minting are a fundamental part of how assets like stablecoins operate, the current level of disclosures we see is clearly insufficient. It can be argued that any token issuer with centralized admin has an ethical responsibility to disclose any action that potentially debases token holders, even if that action is part of the project’s long-term plan.
It is crucial for all network participants to be aware of when an admin key exploit might be happening. As we covered in this report, the interconnectivity of DeFi makes it so that contagion across markets could be unavoidable if an admin gets compromised. Awareness of all admin actions is the bare minimum in order to avoid a black swan scenario. We have integrated the IDS described in this report into Coin Metrics FARUM, our risk management tool. As we have done with previous network exploits, we will responsibly disclose any IDS alert of concern to the community.
There is also a lot that both on-chain and off-chain service providers can do to mitigate their risk exposure. Cryptoasset exchanges, for example, could increase their confirmation requirements for assets that have seen an admin key change followed by a mint. For context, confirmation requirements relate to the time that must be waited, in blocks, before a service provider considers a transaction final. If an exchange increases confirmation requirements the moment it sees a suspicious mint, it can effectively prevent the hacker from monetizing the exploit immediately. Though the mechanics of this preventative strategy are more complicated for DEXs, a reevaluation of confirmation requirements in the era of admin keys is warranted.