Всем привет. Я решил подготовить краткую выжимку о взломе PolyNetwork. Моя публикация не претендует на полноту или уникальность, в сети есть и более глубокие разборы вплоть до воссоздания математической модели экономической системы проекта. Надеюсь некоторых заинтересует данная тематика, уж поверьте, здесь точно есть где развернуться. Так же я хочу найти единомышленников для совместного аудита контрактов и прорешивание CTF заданий, в подписи в моем профиле вы найдёте требования и мои контакты. У читателя должны быть стойкие знания в технологиях и токеномике (defi) в целом.
По мере использования блокчейна Ethereum пропускная способность блоков достигает определенных ограничений. Появляются проблемы в виде повышение стоимости операций в самой сети. Решить проблему масштабируемости, а именно снизить стоимость транзакций/вычислений и повысить скорость обработки транзакций не просто, нужно при этом избежать централизации и некоторых других проблем, так же назревает потребность в взаимодействие между блокчейнами, блокчейн в силу своей изолированности накладывает ограничения на передачу информации и обмена различных активов. Появляются все новые решения такие как L2, state channels, plasma, side/cross-chains, rollups. Есть несколько классификаций и нет единого стандарта как должна работать та или иная технология, соответственно, из-за сырости таких решений, низкой квалификации разработчиков, пренебрежения всестороннего аудита появляются уязвимости, которые приводят к большим финансовым проблемам.
Poly Network - позволяет проводить транзакции между блокчейнами. https://poly.network/PolyNetwork-whitepaper.pdf
Чтобы проводить кросс-чейн транзакции актив замораживается в хранилище в одном блокчейне и появляется в другом. Хранилище блокирует актив до того момента пока не получит сообщение от другого хранилища на другом блокчейне. Между хранилищами происходит общение, которого должно быть подписано bookkeeper-ми. Взлом произошел из-за не разграничения прав доступа к контракту-владельца и проблем владения между контрактами, данная уязвимость подходит под классификацию Access Control. Хакер мог подделывать сообщения из заблокированного хранилища в другую цепочку.
Инфраструктура контрактов: https://github.com/polynetwork/eth-contracts/tree/d16252b2b857eecf8e558bd3e1f3bb14cff30e9b/contracts
Нам нужно найти функцию verifyHeaderAndExecuteTx() в контракте EthCrossChainManager.sol. Функция вызывается для выполнения кросс-чейн транзакций, она проверяет подлинность заголовков блока, проверяя подписи и проверяет была ли транзакция включена в блок с доказательством Меркла. EthCrossChainManager.sol - это контракт-владелец, который может запускать сообщения из другой цепочки.
Тут у нас имеется такой код: https://github.com/polynetwork/eth-...n_manager/logic/EthCrossChainManager.sol#L127
В конце контракта EthCrossChainManager.sol функция verifyHeaderAndExecuteTx() вызывает _executeCrossChainTx(), которая выполняет вызов целевого контракта.
Если изучить контракт до конца мы увидим, что нет никаких ограничений в вызове пользователем контракта EthCrossChainData.sol!
Код контракта: https://github.com/polynetwork/eth-...ross_chain_manager/data/EthCrossChainData.sol
EthCrossChainData.sol отслеживает список public keys, которые идентифицирует данные идущие из другой цепочки. Из-за того, что нет ограничений в вызове контракта и к тому же наш привилегированный контракт EthCrossChainManager.sol ВЛАДЕЕТ контрактом. EthCrossChainData.sol мы можем просто устанавливать свои открытые ключи в соответствии с нашим private keys и отправлять кросс-чейн сообщения(транзакции) с правильными данными напрямую в контракт EthCrossChainData.sol, мы можем заставить наш главный контракт вызвать EthCrossChainData.sol обойти проверку onlyOwner(владелец контракта) и в контракте EthCrossChainData.sol изменить те самые public keys.
Код функции: https://github.com/polynetwork/eth-..._chain_manager/data/EthCrossChainData.sol#L45
Нужно каким-то образом заставить EthCrossChainManager.sol вызвать нужную нам функцию при этом у нас появляется проблема из-за спецификации работы EVM.
Первые 4 байта входных данных в транзакции называются сигхешем(сигнатурой). 4 байта сообщает контракту, что мы пытаемся сделать. Например в функции transfer ERC20 сигхэш это первые 4 байта хэша "function transfer(address user, uint256 amout)". EthCrossChainManager.sol может вызывать любой контракт, но при этом только определенную функцию, которая соответствует определенной сигнатуре.
Чтобы вызвать нужную нам функцию, нужно вычислить значение для _method, которого вместе с другим значениями и хешированием имеет одинаковые 4 байта, что и сигнатура нашей функци. Нужно лишь подобрать значения для правильным сигхэша, при этом полную коллизию хэшей подбирать не нужно, т.к. достаточно будет всего 4 байта.
При помощи криптографической функции ethers.utils.id мы получаем фактическую сигнатуру:
('putCurEpochConPubKeyBytes (bytes)'). Slice (0, 10) '0x41973cd9'.
А вот поддельный сигхэш:
('f1121318093 (bytes, bytes, uint64)'). Slice (0, 10) '0x41973cd9'.
В этом кейсе нет криптографической атаки в проверке подписи/доказательства Меркла во всех цепочках или атаки по сторонним каналам. Проблема связана в не ограничение какие контракты/функции пользователь может вызывать. PolyNetwork допустили в коде выполнение любого сввоего контракта любому пользователю с помощью EthCrossChainManager.sol. Всего лишь нужно было найти контракт, который разрешает вывод средств(EthCrossChainData.sol) и от имени owner выполнить функцию putCurEpochConPubKeyBytes() распределяя себе токены.
По мере использования блокчейна Ethereum пропускная способность блоков достигает определенных ограничений. Появляются проблемы в виде повышение стоимости операций в самой сети. Решить проблему масштабируемости, а именно снизить стоимость транзакций/вычислений и повысить скорость обработки транзакций не просто, нужно при этом избежать централизации и некоторых других проблем, так же назревает потребность в взаимодействие между блокчейнами, блокчейн в силу своей изолированности накладывает ограничения на передачу информации и обмена различных активов. Появляются все новые решения такие как L2, state channels, plasma, side/cross-chains, rollups. Есть несколько классификаций и нет единого стандарта как должна работать та или иная технология, соответственно, из-за сырости таких решений, низкой квалификации разработчиков, пренебрежения всестороннего аудита появляются уязвимости, которые приводят к большим финансовым проблемам.
Poly Network - позволяет проводить транзакции между блокчейнами. https://poly.network/PolyNetwork-whitepaper.pdf
Чтобы проводить кросс-чейн транзакции актив замораживается в хранилище в одном блокчейне и появляется в другом. Хранилище блокирует актив до того момента пока не получит сообщение от другого хранилища на другом блокчейне. Между хранилищами происходит общение, которого должно быть подписано bookkeeper-ми. Взлом произошел из-за не разграничения прав доступа к контракту-владельца и проблем владения между контрактами, данная уязвимость подходит под классификацию Access Control. Хакер мог подделывать сообщения из заблокированного хранилища в другую цепочку.
Инфраструктура контрактов: https://github.com/polynetwork/eth-contracts/tree/d16252b2b857eecf8e558bd3e1f3bb14cff30e9b/contracts
Нам нужно найти функцию verifyHeaderAndExecuteTx() в контракте EthCrossChainManager.sol. Функция вызывается для выполнения кросс-чейн транзакций, она проверяет подлинность заголовков блока, проверяя подписи и проверяет была ли транзакция включена в блок с доказательством Меркла. EthCrossChainManager.sol - это контракт-владелец, который может запускать сообщения из другой цепочки.
Тут у нас имеется такой код: https://github.com/polynetwork/eth-...n_manager/logic/EthCrossChainManager.sol#L127
В конце контракта EthCrossChainManager.sol функция verifyHeaderAndExecuteTx() вызывает _executeCrossChainTx(), которая выполняет вызов целевого контракта.
Если изучить контракт до конца мы увидим, что нет никаких ограничений в вызове пользователем контракта EthCrossChainData.sol!
Код контракта: https://github.com/polynetwork/eth-...ross_chain_manager/data/EthCrossChainData.sol
EthCrossChainData.sol отслеживает список public keys, которые идентифицирует данные идущие из другой цепочки. Из-за того, что нет ограничений в вызове контракта и к тому же наш привилегированный контракт EthCrossChainManager.sol ВЛАДЕЕТ контрактом. EthCrossChainData.sol мы можем просто устанавливать свои открытые ключи в соответствии с нашим private keys и отправлять кросс-чейн сообщения(транзакции) с правильными данными напрямую в контракт EthCrossChainData.sol, мы можем заставить наш главный контракт вызвать EthCrossChainData.sol обойти проверку onlyOwner(владелец контракта) и в контракте EthCrossChainData.sol изменить те самые public keys.
Код функции: https://github.com/polynetwork/eth-..._chain_manager/data/EthCrossChainData.sol#L45
Нужно каким-то образом заставить EthCrossChainManager.sol вызвать нужную нам функцию при этом у нас появляется проблема из-за спецификации работы EVM.
Первые 4 байта входных данных в транзакции называются сигхешем(сигнатурой). 4 байта сообщает контракту, что мы пытаемся сделать. Например в функции transfer ERC20 сигхэш это первые 4 байта хэша "function transfer(address user, uint256 amout)". EthCrossChainManager.sol может вызывать любой контракт, но при этом только определенную функцию, которая соответствует определенной сигнатуре.
Чтобы вызвать нужную нам функцию, нужно вычислить значение для _method, которого вместе с другим значениями и хешированием имеет одинаковые 4 байта, что и сигнатура нашей функци. Нужно лишь подобрать значения для правильным сигхэша, при этом полную коллизию хэшей подбирать не нужно, т.к. достаточно будет всего 4 байта.
При помощи криптографической функции ethers.utils.id мы получаем фактическую сигнатуру:
('putCurEpochConPubKeyBytes (bytes)'). Slice (0, 10) '0x41973cd9'.
А вот поддельный сигхэш:
('f1121318093 (bytes, bytes, uint64)'). Slice (0, 10) '0x41973cd9'.
В этом кейсе нет криптографической атаки в проверке подписи/доказательства Меркла во всех цепочках или атаки по сторонним каналам. Проблема связана в не ограничение какие контракты/функции пользователь может вызывать. PolyNetwork допустили в коде выполнение любого сввоего контракта любому пользователю с помощью EthCrossChainManager.sol. Всего лишь нужно было найти контракт, который разрешает вывод средств(EthCrossChainData.sol) и от имени owner выполнить функцию putCurEpochConPubKeyBytes() распределяя себе токены.