Polygon Warrior Polygon Security Dialysis: як забезпечити крос-чейн безпеку та стабільність?

Автор: Ченду Ляньань
Оригінал: “Дослідження безпеки кросчейн-мостів (3)” | Безпечний діаліз Polygon Warrior, як запобігти відкриттю «скриньки Пандори»?

Ласкаво просимо до серії статей на тему “Дослідження безпеки кросчейн-мостів”, підготовленої Chengdu Chain Security, у попередній статті (Cross-Chain Bridge Security Research (2) | Що приносить нам перше децентралізоване пограбування мосту Nomad?), ми детально проводимо професійний технічний аналіз протоколу мосту Nomad.

Сьогодні дослідницька група Chengdu Chain Security Research Team проведе безпечний діаліз Polygon, багатокутного воїна, тому продовжуйте читати.

Хто такий 1_Polygon?

Polygon — це рішення для масштабування рівня 2 від Ethereum із баченням створення блокчейн-інтернету Ethereum. Polygon надає загальну структуру, яка дозволяє розробникам використовувати безпеку Ethereum для створення індивідуальних, орієнтованих на програми ланцюжків і забезпечувати сумісну мережу, яка поєднує в собі безліч різних схем масштабування, таких як: zk-rollup, PoS тощо. Серед них Polygon PoS наразі є найбільш зрілим і відомим рішенням для масштабування на Polygon. Він використовує сайдчейн для обробки транзакцій для досягнення мети підвищення швидкості транзакцій та економії споживання газу, а структура мережі в основному включає такі три рівні:

Рівень Ethereum:

Низка контрактів в основній мережі Ethereum, в основному, включаючи: контракти стейкінгу, контрольної точки та винагороди, відповідають за функції управління стейкінгом, пов’язані зі ставками PoS, зокрема: забезпечення функції стейкінгу нативного токена MATIC, щоб кожен, хто стейкінгує токен, міг приєднатися до системи як валідатор, перевірка конвертації мережі Polygon для отримання винагороди за стейкінг, покарання валідаторів за подвійні підписи, простої валідаторів та інші незаконні дії, а також збереження контрольних точок.

Шар Хеймдалля:

Рівень валідатора proof-of-stake, який складається з набору вузлів PoS Heimdall, відповідає за надсилання контрольних точок мережі Polygon до основної мережі Ethereum під час прослуховування набору контрактів стейкінгу, розгорнутих на Ethereum. Основний процес полягає в наступному: спочатку виберіть підмножину активних валідаторів у пулі валідаторів як продюсерів блоків, які відповідатимуть за створення блоків на рівні Bor та їх трансляцію, потім перевірте кореневий хеш Merkle та додайте підписи на основі контрольних точок, надісланих Bor, і, нарешті, ініціатор буде відповідати за збір усіх підписів валідаторів для зазначеної контрольної точки, і якщо кількість підписів досягне більше 2/3, контрольна точка буде надіслана на Ethereum.

Шар бору:

Рівень блок-продюсера, який складається з групи виробників блоків, які регулярно вибираються комітетом валідаторів на рівні Хеймдалля, є підмножиною валідаторів, відповідальних за агрегування транзакцій на сайдчейні Polygon і генерацію блоків. Цей шар періодично публікує контрольні точки для шару Хеймдалля, де контрольна точка являє собою знімок ланцюга Бора, як показано на зображенні нижче.

2_Polygon Сумісність

2.1 Контрольна точка

Механізм контрольних точок - це механізм синхронізації даних шару Bor з Ethereum, де синхронізовані дані - це контрольна точка, тобто знімок даних блоку шару Бора, що містяться в інтервалі контрольних точок, вихідний код наступний:

Proposer: Proposer, який також вибирається валідаторами, продюсерами блоків та ініціаторами є підмножиною валідаторів, і їхні обов’язки визначаються їхньою часткою в загальному пулі

RootHash: це хеш Меркла, згенерований з блоку Bor між StartBlock і EndBlock

Нижче наведено псевдокод для блоку Bor з номерами від 1 до n для генерації значення RootHash:

Таким чином, це значення є кореневим хеш-значенням дерева Меркеля, яке складається з номера блоку в заголовку блоку Bor, позначки часу блоку, кореневого хеш-значення дерева транзакцій tx хешу та хеш-значення keccak256, обчисленого з кореневого хешу дерева квитанцій.

AccountRootHash: хеш Меркла з інформацією про обліковий запис, пов’язаний із валідатором, який потрібно надіслати до кожної контрольної точки в Ethereum, і хеш-значення інформації про окремий обліковий запис обчислюється наступним чином:

AccountRootHash генерується з кореневого хешу дерева облікового запису Merkle так само, як і значення RootHash.

2.2 Синхронізація стану

StateSync відноситься до синхронізації даних Ethereum з ланцюжком Polygon Matic, яка в основному поділяється на такі етапи:

1. По-перше, контракт на Ethereum запустить функцію syncState() у StateSender.sol для синхронізації стану

2. Функція syncState() видасть подію події наступним чином:

3. Всі валідатори на рівні Heimdall отримають подію, а один з валідаторів упакує транзакцію в блок heimdall і додасть її до списку синхронізації стану очікування;

4. Вузол bor-шару отримає вищевказаний список для синхронізації через API, і передасть його контракту bor-шару для подальшої обробки бізнес-логіки.

2.3 Багатокутний міст

Polygon Bridge забезпечує двосторонній крос-чейн канал між Polygon та Ethereum, полегшуючи користувачам переказ токенів між двома різними ланцюговими платформами без сторонніх загроз та обмежень ринкової ліквідності. Існує два типи Polygon Bridge, PoS і Plasma, і обидва мають наступну схожість у передачі активів між Polygon та Ethereum:

1. Спочатку вам потрібно зіставити токен на Ethereum з Polygon, як показано на зображенні нижче:

2. Також використовується технологія двостороннього анкерного кріплення (Two-way Peg), тобто

a: Усі активи токенів, передані з Ethereum, спочатку будуть заблоковані на Ethereum, і стільки ж зіставлених токенів буде викарбувано на Polygon;

b: Щоб вивести активи токенів на Ethereum, вам спочатку потрібно спалити ці зіставлені токени на Polygon, а потім розблокувати активи, заблоковані на Ethereum;

На наступному малюнку показано порівняння між PoS Bridge і Plasma Bridge:

Як видно з наведеного вище малюнка, з точки зору безпеки, PoS Bridge покладається на безпеку набору зовнішніх валідаторів, тоді як Plasma покладається на безпеку основного ланцюга Ethereum. У той же час, коли користувачі здійснюють міжланцюгові перекази активів (наприклад, переказ токенів з Polygon на Ethereum), PoS вимагає лише інтервалу контрольних точок, приблизно від 20 хвилин до 3 годин, тоді як Plasma вимагає 7-денного періоду оскарження. У той же час, PoS підтримує більш стандартні токени, тоді як Plasma підтримує лише три типи, зокрема: ETH, ERC20, ERC721.

3_Cross-ланцюговий обмін повідомленнями — PoS-міст

PoS Bridge в основному складається з двох функцій: депозит означає переказ активів користувачів на Ethereum на Polygon, а зняття коштів – виведення активів з Polygon на Ethereum.

Депозит

Нижче наведено приклад того, як користувач Аліса використовує PoS Bridge для надсилання активів токенів зі свого облікового запису Ethereum на свій обліковий запис Polygon:

1. Якщо активи токенів, які ви хочете передати, є ERC20, ERC721 або ERC1155, вам потрібно авторизувати токен, який ви хочете передати, через функцію approtect. Як показано нижче, відповідна кількість токенів авторизується для контракту erc20Prefer шляхом виклику методу approtect у контракті токена на Ethereum.

Функція approtect має два параметри:

• Spender: адреса призначення, за якою користувач авторизує витрачання токенів

• amount: кількість токенів, які можна витратити

2. Після підтвердження вищезазначеної транзакції авторизації користувач блокує токен у контракті erc20Preliminary на Ethereum, викликаючи метод depositFor() контракту RootChainManager. Тут, якщо тип активу, який потрібно передати, є ETH, викликається depositEtherFor(). Подробиці такі:

Функція depositFor має три параметри:

• user: адреса користувача, який отримав токени депозиту на Polygon

• rootToken: адреса токена в основному ланцюжку Ethereum

• depositData: кількість токенів, закодованих ABI

Нижче наведено конкретний код функції depositFor у контракті RootChainManager:

Аналізуючи вихідний код, можна побачити, що функція спочатку отримує адресу предикатного контракту, що відповідає токену, а потім викликає свою функцію lockTokens() для блокування токена в контракті. Нарешті, syncState() буде викликано для синхронізації стану за допомогою _stateSender, який може бути викликаний лише відправником стану, встановленим адміністратором.

3. Функція syncState() у StateSender.sol надішле подію StateSynced, а саме:

Перший параметр є індексом порядкового номера журналу, другий параметр використовується для перевірки того, чи є абонент зареєстрованою легітимною адресою контракту, а третій параметр є даними, які потрібно синхронізувати зі станом. Транзакція додається до блоку Heimdall і додається до списку синхронізації станів очікування.

4. Потім, після того, як bor-вузол у ланцюжку Polygon Matic отримає подію StateSynced у списку синхронізації станів через API, контракт ChildChainManager у ланцюжку викличе функцію onStateReceive(), яка використовується для отримання даних синхронізації, завантажених з Ethereum, і перейде до наступного кроку відповідно до типу бізнес-логіки синхронізації стану:

data: bytes32 syncType і bytes syncData. Коли syncType є відображенням, syncData — це закодована адреса rootToken, адреса childToken і bytes32 tokenType, а коли syncType — депозит, syncData — це закодована адреса користувача. Адреса rootToken і depositData типу bytes. depositData — це кількість у REC20 та tokenId у ERC721.

5. Оскільки це депозитний бізнес, то буде викликана функція _syncDeposit(). Ця функція спочатку декодує syncData у відповідному форматі, щоб отримати відповідні rootToken, адресу користувача та depositData. Потім перевірте, чи має rootToken відповідний токен відображення на полігоні, і викличте функцію deposit() childToken, якщо вона є.

6. Тут ми беремо як приклад контракт на токен ERC20, щоб представити, як депонувати контракт на карту токена. Ця функція переводить відповідну кількість токенів на рахунок користувача.

Функція має два параметри:

• user: адреса користувача, який вносить депозит

• depositData: сума, закодована в ABI

Зняття коштів

Нижче наведено приклад того, як користувач Аліса використовує PoS Bridge для виведення коштів, внесених на її рахунок Polygon, на свій обліковий запис Ethereum:

1. Коли користувач знімає кошти, йому потрібно спалити відповідну кількість зіставлених токенів, викликавши функцію withdraw() контракту на токен відображення в ланцюжку Polygon.

Виведення містить лише один параметр: кількість токенів, які будуть спалені. Функція withdraw() у відповідному контракті токена виглядає наступним чином:

2. Перераховані вище транзакції будуть включені в контрольну точку приблизно через 20 хвилин до 3 годин, і валідатор відправить їх в Ethereum.

3. Після того, як транзакція буде додана до контрольної точки та надіслана до Ethereum, буде викликано функцію exit() контракту RootChainManager на Ethereum, яка підтвердить дійсність транзакції виведення на Polygon, перевіривши надісланий вміст контрольної точки, і запустить відповідний контракт Predicate для розблокування депонованих токенів користувача.

Доказ вводуДані, передані у функцію, включають такі дані:

• headerNumber: містить заголовок блоку контрольної точки для транзакції виведення

• blockProof: Довести, що заголовок блоку в дочірньому ланцюжку є листовим вузлом кореня Merkle, який зафіксував

• blockNumber: Номер блоку в дочірньому ланцюжку, що містить транзакцію виведення

• blockTime: позначка часу блоку транзакції виведення коштів

• txRoot: кореневе значення дерева транзакцій блоку

• receiptRoot: кореневе значення дерева квитанцій блоку

• Receipt: квитанція про транзакцію виведення коштів

• receiptProof: підтвердження Merck про отримання транзакції виведення коштів

branchMask: Шлях до квитанції, представлений 32 бітами в дереві квитанцій

• receiptLogIndex: індекс журналу, який зчитується з дерева квитанцій

Нижче наводиться основна логіка функції, яка в основному включає три частини: перша частина - перевірка дійсності квитанції про транзакцію виведення, друга частина - перевірка того, чи містить контрольна точка блок транзакції, і третя частина - виклик функції exitTokens() в предикатному контракті для відправки заблокованих токенів користувачеві.

4. Візьмемо для прикладу контракт ERC20Predicate, тобто після розшифровки одержувача, відправника та кількості токенів, відправлених з журналу, користувачеві буде відправлено задану кількість токенів.

Згідно з аналізом вихідного коду процесу крос-чейн обміну повідомленнями PoS Bridge, виклики функцій всього процесу можуть бути викликані лише роллю, вказаною валідатором, тому безпека крос-чейну гарантується лише PoS (нотаріусом).

4_Cross-ланцюговий обмін повідомленнями — Plasma Bridge

Plasma Bridge також включає дві функції: депозит і зняття коштів, як показано на наступному малюнку:

Polygon Plasma дещо відрізняється від реалізації Bitcoin Plasma MVP, представленої в першій статті нашої серії кросчейн-мостів, яка в основному використовує модель Plasma MoreVP на основі облікових записів. У порівнянні з Плазмою, алгоритм було частково покращено у частині вилучення.

Оскільки передача токенів ERC20 і ERC721 здійснюється через журнал подій, схожий на Bitcoin UTXO, давайте спочатку представимо подію:

• input1: Баланс рахунку відправника до переказу

• input2: Баланс рахунку одержувача до переказу

• output1: Баланс рахунку відправника після переказу

• output2: Залишок на рахунку одержувача після переказу

По-друге, оскільки початковий MVP Плазми генерується одним оператором або невеликою кількістю блок-продюсерів, існує два сценарії атаки на Polygon:

Оператор зла:

Попередня стаття (Дослідження безпеки кросчейн-мостів (2) | Nomad cross-chain bridge) згадує, що коли транзакція користувача упакована Оператором у блок Плазми, існує недоступність даних поза мережею. Тому, коли користувач здійснює транзакцію виходу, якщо він починає виводити кошти зі старої транзакції, Оператор може оскаржити її однією зі своїх останніх транзакцій, і виклик буде успішним. У той же час, завдяки механізму контрольних точок PoS, який використовується в Плазмі, якщо Оператор вступає в змову з валідаторами, щоб чинити зло, він може навіть підробити деякі зміни станів і надіслати їх до Ethereum.

Зла користувача:

Користувачі продовжують витрачати токени на Polygon після ініціювання транзакції виходу, подібно до крос-чейн подвійних витрат.

Таким чином, алгоритм Plasma MoreVp від Polygon використовує інший алгоритм для обчислення пріоритету виходу, який полягає у виході з останньої транзакції. Оскільки цей метод використовує подію LogTransfer, подібну до UTXO, якщо законна транзакція користувача використовує правильні input1 і input2, навіть якщо деякі шкідливі транзакції упаковані перед транзакцією користувача, транзакція користувача може бути оброблена правильно, оскільки транзакція користувача походить лише від дійсного введення. Відповідний псевдокод виглядає наступним чином:

Депозит

Розглянемо приклад користувача Аліси, яка використовує Plasma Bridge для надсилання токен-активів зі свого облікового запису Ethereum на свій обліковий запис Polygon:

1. Перш за все, користувачам також потрібно авторизувати токен-активи, які їм потрібно переказати, в депозитний менеджер контракту Polygon на основному ланцюжку (Ethereum) через функцію approtect.

2. Після підтвердження авторизованої транзакції користувач викликає функцію erc20token.deposit(), щоб запустити функцію depositERC20ForUser() контракту depositManager і депонувати активи токенів користувача ERC20.

3. Коли основна мережа Ethereum підтвердить транзакцію депозиту, вона створить блок, що містить лише цю транзакцію, і надішле його контракту childChain у мережі Polygon за допомогою механізму синхронізації стану, викарбує таку саму кількість відображених монет і внесе їх на рахунок користувача на Polygon.

Зауваження: згідно з аналізом початкового коду контракту childChain, у Плазмі передбачено підтримку лише трьох типів, зокрема ETH, ERC20 та ERC721.

Вивести

Коли користувач захоче використовувати міст Плазми для виведення активів з Polygon на Ethereum, він пройде наступні кроки:

1. Користувач спалює зіставлені активи токенів у ланцюжку Polygon, викликаючи функцію withdraw() зіставленої монети на Polygon:

Ви також можете викликати реалізацію інтерфейсу withdrawStart() клієнта Плазми на Polygon.

2. Користувач може викликати функцію startExitWithBurntTokens() у контракті ERC20Predicate, яка спочатку викличе WithdrawManager.verifyInclusion(), щоб перевірити, чи містить контрольна точка транзакцію виведення та відповідну квитанцію, код наступний:

Після проходження перевірки буде викликано WithdrawManager.addExitToQueue(), щоб вставити його в чергу повідомлень у порядку пріоритетності:

Нарешті, addExitToQueue() викликає _addExitToQueue(), щоб викарбувати NFT як ваучер на відшкодування:

3. Користувач чекає 7-денного періоду челенджу

4. Після завершення періоду челенджу ви можете викликати функцію WithdrawManager.processExits() для відправки токенів користувачеві.

Функція розділена на два кроки: спочатку підтверджуємо, чи пройшла транзакція виведення в черзі повідомлень 7-денний період оскарження, і якщо період виклику минув, видаляємо транзакцію з черги:

Потім визначте, чи був видалений NFT-ваучер на повернення коштів протягом періоду челенджу, і якщо ні, NFT буде знищено, а відповідні активи повернуто користувачеві:

5_Polygon Уразливість Plasma Bridge з подвійними витратами

5 жовтня 2021 року білий капелюх Герхард Вагнер подав заявку на вразливість Polygon, яка може призвести до атаки подвійних витрат на суму 850 мільйонів доларів, за яку Білий Капелюх отримав офіційну винагороду за помилку в розмірі 2 000 000 доларів США від Polygon.

У представленні Plasma Bridge вище ми знаємо, що повний процес виведення транзакцій виглядає наступним чином:

- Користувач ініціює транзакцію виведення коштів на Polygon, яка спалює токени користувача на Polygon;

- Після інтервалу між контрольними точками (приблизно 30 хвилин) дочекайтеся включення транзакції виведення коштів у контрольну точку;

- Більше 2/3 валідаторів підписують і відправляють його в Ethereum, після чого користувач викликає startExitWithBurntTokens() в контракті ERC20PredicateBurnOnly, щоб перевірити, чи містить контрольна точка транзакції спалювання;

- Якщо верифікацію пройдено, буде викарбувано та надіслано користувачеві ваучер на повернення коштів NFT

- Користувачі чекають на 7-денний період челенджу

- Викличте WithdrawManager.processExits(), щоб знищити NFT та повернути гроші користувачеві

Примітка: Щоб запобігти повторному відтворенню транзакцій (атакам подвійних витрат), Polygon використовує NFT як доказ повернення коштів, щоб однозначно ідентифікувати транзакцію виведення коштів. Однак через дефект генерації NFT ID зловмисники можуть створювати параметри для генерації кількох NFT з різними ідентифікаторами, використовуючи одну й ту саму дійсну транзакцію Withdrawal, а потім використовувати ці NFT для транзакцій відшкодування, таким чином досягаючи «атаки подвійних витрат».

Розглянемо докладніше, як генерувати NFT:

1. З наведеного вище аналізу вихідного коду видно, що addExitToQueue() викличе _addExitToQueue() для карбування NFT:

Згідно з аналізом параметрів, exitid = priority, то ID NFT генерується зсувом ліворуч вікового пріоритету в Plasma Bridge.

2. Як видно з наведеного вище аналізу вихідного коду, age - це значення, що повертається функцією WithdrawManager.verifyInclusion(), яка спочатку перевірить дійсність транзакції виведення, а потім згенерує відповідний вік, якщо перевірка буде пройдена. У логіці валідації значення, що декодується даними контрольованого параметра, має вигляд branchMaskBytes:

Ця величина також використовується при генерації віку:

3. Простежте функцію MerklePatriciaProof.verify(), яка викликається в логіці перевірки транзакцій, і виявите, що функція викликає _getNibbleArray() для перекодування branchMaskBytes:

4. Продовжуйте відстежувати функцію декодування, яка відкидає частину значення при перекодуванні branchMaskBytes, і такий спосіб втрати значення призведе до того, що різні значення будуть перекодовані для отримання одного і того ж декодованого значення. Зокрема, якщо перший шістнадцятковий біт (половина байта) вхідного значення b у кодуванні hp дорівнює 1 або 3, другий шістнадцятковий біт аналізується. В іншому випадку перший байт просто ігнорується.

Якщо зловмисник будує параметр branchMaskBytes так, що перший шістнадцятковий біт не дорівнює 1 і 3, існує 14*16 = 224 способи отримати те саме перекодоване значення.

Конкретний процес атаки виглядає наступним чином:

- Внесіть велику кількість ETH/токенів на Polygon через Polygon Plasma

- Ініціюйте угоду на виведення коштів на Polygon і дочекайтеся 7-денного періоду челенджу

- Змініть перший байт параметра branchMaskBytes в транзакції виведення (одна і та ж дійсна транзакція може бути повторно відправлена до 223 разів) і ініціюйте транзакцію виведення кілька разів

Таким чином, ця вразливість в основному пов’язана з проблемою в дизайні алгоритму ідентифікатора NFT, який генерує ваучер на відшкодування, щоб запобігти повторному відтворенню, в результаті чого одна і та ж транзакція відшкодування може генерувати різні NFT, що призводить до атаки подвійних витрат. Виходить, що перший байт закодованої маски гілки завжди повинен бути 0x00. Виправлення полягає в тому, щоб перевірити, чи є перший байт закодованої маски гілки 0x00, і не розглядати це як неправильну маску.

Що ж, сьогоднішній обмін закінчився, у наступному випуску Chengdu Chain Security Security Research Team представить дослідження безпеки іншого крос-чейн проекту, будь ласка, з нетерпінням чекайте на нього.