У цій статті редакція “Що біткоїться” переклала й адаптувала публічне дослідження серії вразливостей, пов’язаних із ресурсним виснаженням. Його провели студенти за підтримки Лабораторії Децентралізованих Систем при Іллінойському університеті, а розпочали ще в жовтні 2018. Вразливості цього типу вплинули на мережі більше ніж 26 криптовалют, що працюють на базі протоколу Proof-of-Stake (PoS). Але все по черзі. 

Альткоїни схожі на Біткоїн у тому, що також використовують модель UTXO (невитрачені монети, що залишаються після транзакції) та правило “найдовшого ланцюга”. Основна відмінність полягає у тому, що замість доказу виконаної роботи використовується принцип доказу права на власність коїнів. Потенційні переваги алгоритму консенсусу PoS полягають не тільки у зниженні негативного впливу на довкілля, але й підвищенні рівня захисту від атак 51%. Багато криптовалют, які наразі існують, є форками або копіями Біткоїна із вбудованою функцією PoS. 

UTXO scheme

Уразливості, які ми знайшли, ми називаємо “фейковими ставками”. Чому вони виникають? PoSv3 (третя версія протоколу Proof-of-Stake) не надто точно перевіряє мережеві дані перед тим, як використати такі ресурси, як диск та оперативна пам’ять. Наслідком цього є те, що майже будь-який зловмисник може вивести з ладу ноду жертви, заповнивши її диск чи оперативну пам’ять неправдивими даними.  

Перед тим, як перейти до деталей цих вразливостей, поговоримо про основні принципи роботи алгоритму Proof-of-Stake

Майнінг

Як і в алгоритмі Proof-of-Work, майнінг в PoS полягає у порівнянні хешу заголовка блоку із цільовим завданням. Відмінність полягає у тому, що в останньому випадку шанс ноди видобути наступний блок пропорційний тому, скількома коїнами нода вже володіє. Саме тому в ланцюзі PoS хеш залежить не тільки від заголовка блоку, але і від кількості монет. Ці монети входять до спеціальної coinstake-транзакції, що проводиться самою ж зацікавленою стороною. Ця транзакція має довести, що UTXO належить цьому конкретному користувачу. Отже, для перевірки PoS має значення дві речі: транзакції coinstake та набір UTXO, що визначається тими ж coinstake-транзакціями.

Mining scheme

Роль Proof-of-Work у захисті перевірки блоків

Безсумнівно PoW грає не останню роль у консенсусі Біткоїна. Алгоритму Proof-of-Stake відводиться менш цінна, але важлива роль. Вона полягає у тому, що протокол дозволяє отримати доступ до обмежених ресурсів ноди, таких як диск, пропускна здатність, пам’ять або ж процесор. У криптовалютній мережі не можна довіряти будь-кому, тому для запобігання атакам на виснаження ресурсів ноди Біткоїна спочатку мають перевірити PoW на наявність інших отриманих блоків. Однак виявляється, що перевірка Proof-of-Stake є набагато складнішою за перевірку Proof-of-Work. 

Щоб зрозуміти, як використання Proof-of-Stake призводить до подібного роду вразливостей, поговоримо трохи про те, де та як зберігаються блоки перед самою перевіркою. Вузол не просто повинен відстежувати найдовший ланцюг, але й усе дерево форків, адже кожен ланцюжок у будь-який момент може виявитися найдовшим. Це може статися при невдалому оновленні, подвійному витрачанні або тимчасовому поділі мережі. 

Forks scheme

Перевіряти блоки, що не належать основному ланцюгу — складно. Для початку вам знадобиться набір UTXO на час попереднього блоку. Біткоїн зберігає UTXO для поточного блоку найдовшого ланцюга, але не для всіх інших минулих блоків, з яких міг би початися форк. Існує два підходи для перевірки блоків у форку:

  1. Повернути поточний вигляд (набір UTXO) до точки на початку “вилки”.
  2. Зберігати копії UTXO-наборів для всіх попередніх блоків.

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

Перед тим, як зберегти блок на диск, база коду Біткоїна проводить деяку попередню перевірку на основі PoW (але ігноруючи транзакції). Ця перевірка залежить лише від попереднього та поточного заголовка блоку, тому вона проводиться дуже швидко. І перевірка такого роду є дуже ефективною, адже створити PoW, який її проходить — дуже дорого. І хоча можна спробувати створити недійсний блок на диску, організовувати атаку на вичерпання ресурсів надзвичайно дорого.

Аналогічна попередня перевірка в PoS полягає в тому, щоб перевірити, чи перевищує coinstake-транзакція цільову складність (вона ж difficulty target) при хешуванні з ядром попереднього блоку. Оскільки повною мірою перевірити транзакцію coinstake досить складно, більшість реалізацій на основі ланцюга PoS натомість забезпечують лише приблизну перевірку. Виявляється, ці наближення часто недостатні і їх можна експлуатувати.

Difficulty target

Уразливість №1: “Я не можу повірити, що це не ставка”

Коли цю проблему досліджували вперше, виявилось, що п’ять криптовалют — Qtum, Particl, Navcoin, HTMLcoin та Emercoin — виявили досить тривіальну форму цієї вразливості: вони взагалі не перевіряють жодної транзакції, перш ніж прийняти блок до оперативної пам’яті або диску. У цих криптовалют є дещо спільне — усі вони перейняли функцію Біткоїна “спочатку — заголовки”, в якій розповсюдження блоків розділено на два повідомлення: це сам блок та заголовок. Ноди формують запит на новий блок тільки тоді, коли заголовок проходить перевірку Proof-of-Work і знаходяться на найдовшому ланцюгу. Оскільки coinstake-транзакція присутня тільки у блоці, але не в заголовку, нода не може перевірити транзакцію самостійно. Натомість вона безпосередньо зберігає заголовок до структури даних в пам'яті (mapBlockIndex). 

Як результат, будь-який мережевий зловмисник, навіть не маючи жодної частки володіння, може заповнити оперативну пам’ять жертви. 

Другий варіант цієї атаки може бути здійснений проти одних і тих же кодових баз, хоча він працює дещо по-іншому і спрямований на інший ресурс — диск жертви, а не оперативну пам’ять. Можливо, атака, що націлена на диск, навіть є більш шкідливою для жертви: якщо оперативна пам'ять заповнена, а вузол виходить з ладу, її можна просто перезапустити. Однак якщо заповнений диск — без ручного втручання не обійтися.

Зазвичай попередні перевірки проводяться при отриманні блоку, а не при отриманні заголовка. Оскільки блок містить транзакцію coinstake, то в ідеалі програмне забезпечення ноди має перевірити її перед подачею блоку на диск. А проте, якщо блок знаходиться у форку, ноді не буде так легко прийняти набір UTXO, який був витрачений при транзакції coinstake. 

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

Task Manager kind of situation

Вразливість №2 та атака “Витрачена ставка”

Простеживши походження цих кодових баз, дослідники помітили, що вразливість №1 спочатку була введена під час об'єднання функції "головний заголовок" Bitcoin у базу даних коду PoSv3. Атака не працює на більш ранніх версіях (наприклад, Peercoin), оскільки перед зберіганням блоків на диску є дві додаткові попередні перевірки:

  • Перевірка №1. Чи існує витрачений вихід у головному ланцюжку?
  • Перевірка №2.  Чи відповідає хеш ядра PoS цільовій складності?

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

  • Проблема А: Перша перевірка гарантує те, що монета існує, але НЕ те, що вона НЕ є витраченою. Це миттєво призводить до другої проблеми.
  • Проблема В: Навіть якщо ми перевіряємо блок у форку головного ланцюга, транзакція coinstake перевіряється проти бази даних TxDB безпосередньо для самого головного ланцюга.

Виходячи з проблеми А, дослідники знайшли спосіб обдурити програму, використовуючи тоншу атаку, яка була названа атакою “Витрачена частка”. Для того, щоб обійти Перевірку №2, нам потрібен дійсний блок, що вже пройшов межу цільової складності. Це, у свою чергу, вимагатиме великої ставки. Однак, як виявилося — можна зловживати неповною перевіркою для отримання довільної кількості дійсних ставок, використовуючи технологію, яка називається “ампліфікацією ставок”.

Transaction, output, address

Ампліфікація ставок

Щоб здійснити атаку з невеликою кількістю ставок, зловмисник повинен підвищити кількість дійсних ставок. Дійсні ставки відносяться до усіх запропонованих ставок, навіть до тих, які вже були використані. Якщо зловмисник почне з UTXO у кількості k, зловмисник може створити кілька транзакцій, витрачаючи монети назад до зловмисника, як показано на малюнку нижче. 

Нехай n — відмінне від k число, яке показує достатню для PoS кількість виходів транзакцій. Ми маємо дозволити проводити ставки тільки UTXO(n+1), але через Перевірку №2, про яку ми вели мову вище, можна робити ставки на весь UTXO від 1 до n+1, тим самим збільшуючи кількість видимих ставок на n*k. Це збільшує шанси знайти блок PoS, оскільки зловмисник може продовжувати працювати за таким алгоритмом, щоб збільшити кількість своїх дійсних ставок. Це показано зліва на ілюстрації нижче.

Ампліфікація ставок

Ампліфікація ставок та атака “Витрачених ставок” (Decentralized Systems Lab)

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

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

Єдиною витратою, яку зазнає зловмисник, були б комісії за транзакції.

Повне розкриття вразливості

Вперше вразливість №1 була досліджена у контексті криптовалют Particl та Qtum. Щоб визначити ступінь цієї вразливості, дослідники зібрали список відомих криптовалют з сайту coinmarketcap.com (9 серпня 2018 року), відсортований за ринковою межею та відфільтрований типом консенсусу PoS. 

Розглядалися лише криптовалюти, кодова база яких була форкнута (взята за основу) від Біткоїна, тобто на C++. Загалом автори дослідили 26 криптовалют і виявили, що лише п’ять з них (Qtum, Navcoin, HTMLcoin, Emercoin та Particl) постраждали, але “сфабрикована” атака, схоже, не спрацювала на решту. Для підтвердження вразливості дослідники реалізували атаки в кожній з п’яти постраждалих кодових баз. Для цього використовувалися наявні тестові набори в програмному забезпеченні Bitcoin, зокрема, режим regtest, який дозволяє моделювати часові позначки та легко створювати блоки, і тестову ноду на основі Python, яку можна розширити за допомогою поведінки зловмисника. Дослідники також використовували контейнери Docker для упаковки цих тестів, їх залежностей та конкретного хешу.

Потім вони заглибилися, щоб зрозуміти, чому криптовалюти, які не постраждали, не були чутливими до першої атаки, і зрозуміли, що Вразливість №2 є настільки ж серйозною (і вимагає мінімальної кількості ставок), але набагато більш поширеною. Плануючи узгоджене відповідальне розкриття інформації, дослідники зробили висновок, що розкривати криптовалюти з низькою економічною активністю та неактивними командами розробників може бути контрпродуктивним (ризик, наприклад, полягає в тому, що якщо вразливість просочиться, вона може вплинути на інших, перш ніж команди матимуть час зреагувати). Врешті-решт, дослідники вирішили зосередити свою увагу на спілкуванні з п'ятнадцятьма командами розробників, що працюють з криптовалютами, які, швидше за все, можуть піддатися нападу (серед 200 кращих криптовалют) та можуть зреагувати (деяка діяльність протягом 2018 року).

Надійсність блокчейну

Одним з ускладнювальних факторів було те, що більшість із цих кодових баз не надходила в режимі регресивного тестування, тому не можна легко продемонструвати атаку або надати набір для відтворення для кожної з них. Через це дослідники лише провели демонстрацію на кодовій базі C++ проєкту stratisX. Виходячи з подібності в базах даних, вони повідомили всі п'ятнадцять команд розробників, на які мали б повпливати наші атаки. П’ять команд визнали вразливість системи, три на момент публікації досі розслідують, три спростували її (вказали зміни на впровадження, що мали пом'якшувальний ефект), і чотири команди не відповіли. Набір відтворюваності Github для обох вразливих ситуацій можна знайти тут, а короткий документ про Вразливість №1 можна знайти тут. У Decentralized Systems Lab також зарезервували CVE (англ. Common Vulnerabilities and Exposures — база даних загальновідомих вразливостей інформаційної безпеки), які мають бути оприлюднені незабаром.

Пом'якшення наслідків від вразливості 

Дослідники побачили низку пом'якшення, здійснених командами у відповідь на дослідження. Деякі криптовалюти впроваджували програми, які виявляють напади та відключаються від мережевих порушників. Проблема з такою евристикою полягає в тому, що важко відрізнити фактичну атаку від чесного вузла, який проходить через законну реорганізацію — є ризик помилково заборонити чесні вузли. Це той напрямок досліджень, який варто продовжити.

Деякі інші криптовалюти додали часткове підтвердження до фіксованої довжини ланцюга. Якщо одноранговий учасник отримує блок, який відщеплюється від основного ланцюга, минаючи цю довжину, то блок просто відкидається. Цей підхід також застосовується, наприклад, у кодовій базі коду ABC BCH (Bitcoin Cash), де використовується алгоритм прокатної контрольної точки 10-го блоку. Недолік цього підходу полягає в тому, що він вводить можливість "розколу ланцюга". Розкол ланцюга відбувається, коли чесні вузли опиняються на розбіжних гілках блокчейну. Це може статися, наприклад, якщо погане підключення до мережі призводить до того, що вузли не синхронізуються один з одним досить довго, щоб створити конфліктні контрольні точки. Навіть якщо вузли відновлять зв'язок, вони не зможуть досягти загального виду ланцюга. 

Ризик розколу ланцюга також вводить нові вектори нападу для злочинців-майнерів. Зловмисник може спробувати “намайнити” довгий ланцюг таємно, а потім опублікувати його в підмножині вузлів, щоб викликати розрив ланцюга. Вузли в IBD (початкове завантаження блоку) або вузли, які щойно перезапустилися після тривалого періоду офлайн, є особливо вразливими до цієї атаки. Такі махінації можуть поєднуватися з видом атак, коли шахраї вводять вести чесні вузли в ланцюг, керований зловмисником.

Користувачам наступних постраждалих криптовалют слід оновити свої вузли до найновішого виправленого програмного забезпечення та усвідомлювати, що в непропатчених вузлах ця вразливість може бути використана, що призведе до можливої ​​аварії. Деякі криптовалюти, такі як Qtum, планують перейти до повної перевірки блоків, що не входять до основного ланцюга, у своїх майбутніх релізах.

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

Назва
Тікер
Капіталізація
Вразливість #1: Без ставки
 
Вразливість#2: витрачена ставка
 
 
 
 
Використовується
Статус
Використовується
Статус
Qtum
QTUM
952,265,768
Налагоджений
 
Emercoin
EMC
110,386,208
Налагоджений
 
Particl
PART
47,065,433
Налагоджений
 
NavCoin
NAV
39,029,633
Налагоджений
 
HTMLCOIN
HTML
25,447,981
Налагоджений
 
StratisX**
STRAT
302,105,983
 
 
Переміщено до іншого програмного забезпечення вузлів
PIVX*
PIVX
153,755,781
 
Налагоджено
ReddCoin
RDD
147,438,673
 
Не повідомлено (немає активності)
Neblio
NEBL
66,347,971
 
Працює над виправленням
Peercoin
PPC
40,556,844
 
Спростували
CloakCoin
CLOAK
28,772,914
 
Очікують підтвердження
Experience—Points
XP
24,227,526
 
Очікують підтвердження
BitBay
BAY
24,064,909
 
Не повідомлено (немає активності)
Linda
LINDA
21,960,091
 
Спростували
Phore
PHR
19,628,809
 
Налагоджено
ColossusCoinXT
COLX
17,028,079
 
Працює над виправленням
PotCoin
POT
16,212,367
 
Не повідомлено (немає активності)
DeepOnion
ONION
14,740,554
 
Спростовано, потім налагоджено
ALQO
ALQO
14,205,565
 
Не відповіли
Bean—Cash
BITB
13,475,106
 
Не повідомлено (немає активності)
Divi
DIVX
13,349,316
 
Очікують підтвердження
NoLimitCoin
NLC2
12,941,709
 
Налагоджено
HempCoin
THC
12,779,111
 
Не повідомлено (немає активності)
LUXCoin
LUX
11,046,202
 
Налагоджено
BlackCoin
BLK
10,848,600
 
Працює над виправленням
Diamond
DMD
10,158,775
 
Працює над виправленням

by Sheetsu.com, дані Marketcap від 9 серпня 2019 року

Висновки

Попри те, що атаки “фейкових ставок” є досить простими за своєю сутністю, вони підкреслюють складний виклик: деякі ідеї, що мають сенс у Proof-of-Work, не переносяться на Proof-of-Stake. Досліджуючи наведені вище вразливості було знайдено декілька прикладів початкових версій програм для захисту з коментованим кодом. Нам це говорить про усвідомлення розробниками PoS, що принципи обміну в цьому дизайнерському просторі ще не повністю зрозумілі. Завдання полягає в тому, що з одного боку ми хочемо якнайшвидше позбутися недійсних блоків, а з іншого — ми не хочемо застрягти на розриві ланцюга або затримуватися в обробці того, що насправді є основним ланцюгом. Систематичний спосіб розв'язання цього питання залишається відкритою проблемою для подальшої роботи.

Хоча ми бачили останні приклади (наприклад, апгрейд CVE 2018–17144 в BTC), що впливають на щонайменше дві бази кодів, наскільки нам відомо, це перше скоординоване розкриття вразливості безпеки через таку велику кількість (20+) незалежних криптовалют. Враховуючи кількість повторного використання коду в криптовалютах, можна передбачити, що в майбутньому буде більше таких вразливих місць. Було виявлено, що між досліджуваними базами коду є однаковість у процесі забезпечення захисту. Наприклад, для більшості з них не було виділених контактів із питань безпеки. Впровадження практики повного розкриття інформації може принести користь загальній екосистемі.

[1] Приклади спеціальних перевірок для PoS можна знайти тут.

"Що біткоїться" — це освітньо-медійний ресурс про криптовалюти, блокчейн і нові технології з гумором. Ранкові брифи щодня на Телеграм-каналі.

Коментарі