XRP Ledger виправив критичну вразливість у сфері безпеки, що сягає 2015 року, яка могла дозволити зловмисникам створити приблизно 18 трильйонів XRP за допомогою однієї спеціально розробленої транзакції, причому понад 80% довірених валідаторів встановили екстрене оновлення 25 вересня.
Підсумок
- Розробники XRPL виправили критичну помилку платежів, яка могла створити витратні XRP понад їхню пропозицію.
- Дослідник Кейден Ляо продемонстрував, що приблизно 18 трильйонів XRP можна було створити за допомогою однієї спеціально створеної транзакції.
- Команда з безпеки не знайшла доказів того, що вразливість переповнення була використана в публічних мережах.
- Понад 80% валідаторів за замовчуванням оновилися до xrpld 3.4.1 25 вересня, підтвердили розробники.
- Окреме виправлення валідації Batch активовано 9 жовтня після того, як валідатори відклали його початкове заплановане розгортання.
XRP Ledger Foundation та RippleX підтвердили вразливість у розкритті від 9 жовтня, пояснивши, що помилка в платіжному механізмі мережі могла створити витратні XRP понад заплановану пропозицію в 100 мільярдів. Розробники відтворили проблему під час тестування та випустили версію 3.4.1 для її вирішення. Їхнє розслідування не виявило доказів того, що вразливість була використана в публічній мережі. Дослідник з безпеки Кейден Ляо та Veria AI отримали максимальну винагороду в розмірі 250 000 доларів США за програмою bug bounty після повідомлення про вразливість і демонстрації її потенційного впливу.
XRP Ledger виправляє помилку, яка могла створити трильйони XRP
Вразливість вплинула на платіжний механізм XRP Ledger, який обробляє перекази та транзакції, пов’язані з вбудованою децентралізованою біржею мережі.
Згідно з офіційним розкриттям, проблема виникла через цілочисельне переповнення в програмному забезпеченні, написаному в 2015 році. Цілочисельне переповнення виникає, коли обчислення дає число, більше, ніж комп’ютерна система може представити за допомогою виділеної кількості бітів.
У цьому випадку платіжний механізм додавав суми XRP, пов’язані з кількома пропозиціями в книзі замовлень мережі. Програмне забезпечення використовувало 64-бітне ціле число для обчислення загальної суми, яку покупець заборгував при завершенні платежу, що включав кілька пропозицій.
Розробники виявили, що зловмисник міг створити сотні спеціально оцінених пропозицій і організувати так, щоб один платіж спожив їх. Коли обчислена сума перевищувала максимальне значення цілого числа, число могло обернутися до набагато меншої суми. Система все одно зараховувала окремим продавцям повні суми XRP, зазначені в їхніх пропозиціях, навіть якщо покупець сплачував лише зменшену суму, отриману внаслідок переповнення. Різниця створювала XRP, яких раніше не існувало.
Згідно з XRPL Foundation, отримана криптовалюта могла бути переказана на інші рахунки, продана або відправлена на біржі. У звіті описано потенційний результат: «Зловмисник міг створити витратні XRP далеко за межами загальної пропозиції».
За словами розробників, вразливість не могла бути активована через звичайну торгівлю. Зловмиснику потрібно було створити кілька сотень рахунків, розмістити пропозиції за незвичайними цінами та подати ретельно побудовану транзакцію для їх спільної обробки. Існуючі перевірки безпеки не спрацювали, оскільки перевірка пропозиції системи використовувала той самий тип арифметики, що спричинив початкову помилку.
Тим часом окрему перевірку балансу рахунку можна було обійти, розподіливши новостворені XRP між кількома гаманцями.
Дослідник виявив потенційну експлуатацію 18 трильйонів XRP
Вразливість привернула увагу розробників після того, як дослідник з безпеки Кейден Ляо та Veria AI протестували програмне забезпечення XRP Ledger з відкритим вихідним кодом.
Veria Labs опублікувала свої висновки 10 жовтня, описавши, як її автоматизована система тестування безпеки виявила проблему 21 вересня. Наступного дня дослідники розробили робочий концепт-доказ у локальній тестовій мережі.
За словами компанії, демонстрація показала, що приблизно 18 трильйонів XRP можна було створити за допомогою однієї спеціально розробленої транзакції. Ця сума була еквівалентна приблизно 184 разам від запланованої загальної пропозиції XRP, згідно з розрахунками дослідників. Ця цифра описує результати контрольованого тестування безпеки, а не фактичне збільшення обігової пропозиції криптовалюти. Ляо подав вразливість через офіційну програму винагород за помилки XRPL 22 вересня.
Інженери RippleX відтворили проблему на окремому сервері та підтвердили, що новостворені XRP можна було витратити в наступному платежі.
Початковий звіт класифікував вразливість як серйозну, але розробники підвищили її рівень до критичного після підтвердження потенційних наслідків. Veria Labs заявила, що вразливість могла поставити під загрозу всю ринкову вартість XRP, якби зловмисники успішно її використали. Оцінка компанії базувалася на ринковій капіталізації XRP приблизно 94 мільярди доларів на той час.
Однак цифра в 94 мільярди доларів є оцінкою дослідника потенційного фінансового ризику, а не підтвердженими збитками. Команда безпеки не знайшла доказів несанкціонованого створення XRP у публічних мережах. 8 жовтня Veria AI отримала максимальну винагороду в розмірі 250 000 доларів за виявлення та відповідальне розкриття проблеми.
RippleX випускає екстрене виправлення без звичайного процесу затвердження
Після підтвердження вразливості інженери RippleX розробили виправлення між 22 і 23 вересня. Патч було включено до xrpld версії 3.4.1, випущеної 25 вересня.
Згідно з офіційним розкриттям, розробники додали перевірки, які запобігають прийняттю платіжним двигуном розрахунків, що перевищують дозволений цілочисельний діапазон. Оновлене програмне забезпечення відхиляє уражені розрахунки та повертає звичайну помилку платежу замість створення додаткових XRP. Інженери посилили перевірку пропозиції мережі, замінивши існуючу арифметику ширшим лічильником, призначеним для виявлення подібних помилок. Додаткові розрахунки балансу були перевірені як запобіжний захід.
Однак рішення розгорнути виправлення створило незвичайну ситуацію для управління XRP Ledger. Зазвичай зміни в обробці транзакцій повинні проходити через систему поправок мережі. Поправка вимагає підтримки понад 80% довірених валідаторів протягом двох послідовних тижнів перед активацією.
Щодо вразливості переповнення платежів розробники вирішили застосувати виправлення негайно, коли валідатори оновили своє програмне забезпечення. Фонд XRPL пояснив, що звичайний процес виявив би вразливість, залишаючи її використовуваною протягом періоду затвердження.
Оскільки програмне забезпечення XRP Ledger є відкритим кодом, публікація патча може розкрити місцезнаходження та природу вразливості.
Розробники дійшли висновку, що очікування звичайного процесу внесення поправок могло створити додаткові ризики для безпеки. Екстрений підхід мав окреме занепокоєння: валідатори, які працюють на різних версіях програмного забезпечення, могли не погоджуватися щодо того, як обробляти шкідливу транзакцію.
У крайньому випадку розбіжність могла тимчасово перешкодити мережі підтверджувати нові реєстри. Фонд заявив, що рішення було прийнято після консультацій з RippleX, операторами валідаторів та іншими учасниками XRPL. До 25 вересня понад 80% валідаторів у стандартному списку унікальних вузлів оновилися до версії 3.4.1.
Публічний вихідний код було згодом випущено після негайної реакції на загрозу безпеці. Записи випуску Фонду XRPL описують версію 3.4.1 як екстрене оновлення, що вирішує чутливі до безпеки проблеми протоколу.
XRP Ledger вирішує другу вразливість безпеки перед активацією Batch
Розкриття від 9 жовтня охоплювало ще одну вразливість, пов'язану з функцією пакетних транзакцій XRP Ledger. Batch дозволяє розробникам об'єднувати до восьми транзакцій в одну операцію. Функція підтримує різні режими виконання, включаючи схеми, в яких кожна транзакція повинна бути успішною, щоб повна операція була прийнята.
Під час тестування безпеки дослідники виявили помилку валідації, пов'язану з тим, як окремі транзакції пакувалися всередині Batch. Протокол вимагав, щоб кожна транзакція використовувала спеціальне поле під назвою RawTransaction.
Однак програмне забезпечення могло приймати альтернативні назви полів за певних умов. Дослідники виявили, що різні версії серверів можуть по-різному обробляти ті неправильно відформатовані транзакції.
За даними XRPL Foundation, resultant розбіжність могла перервати валідацію мережі, якби функція стала активною до виправлення проблеми. Проблему спочатку було виявлено під час Sherlock Attackathon, а згодом її дослідив учасник XRPL Foundation Денис Енджелл. Інженер RippleX Маюкха Вадарі визначив, що вразливість створювала потенційний ризик консенсусу між версіями серверів.
Розробники відреагували, представивши поправку fixBatchV1_2. Поправка вимагає, щоб кожна транзакція Batch використовувала затверджений формат полів, і відхиляє неправильно упаковані транзакції. Валідатори тимчасово відкликали підтримку попереднього графіка активації BatchV1_1, поки розробники завершували виправлення.
Як fixBatchV1_2, так і BatchV1_1 активувалися в головній мережі XRP Ledger 9 жовтня. Активація XRP Ledger Batch отримала підтримку 30 валідаторів, п'ять виступили проти оновлення, згідно з даними XRPScan, включеними до перевіреного звіту мережі.
Раніше дослідження перевірки безпеки Batch детально описувало екстрений випуск 25 вересня та запобіжні заходи, необхідні до активації функції. Початкова версія раніше стикалася з проблемами безпеки, зокрема з питаннями авторизації транзакцій, виявленими під час перевірок розробниками.
Окремий аудит безпеки XRP Ledger у серпні задокументував 96 дійсних уразливостей, виявлених під час змагання Sherlock, що охоплювало запропоновані функції протоколу.
Щодо останньої вразливості Batch, XRPL Foundation підтвердила, що постраждалі поправки не були активними в головній мережі на момент виявлення проблеми. Кошти користувачів не були втрачені, приватні ключі не були скомпрометовані, і жодного збою консенсусу не сталося через цю конкретну ваду. Активація 9 жовтня означає, що сервери, які працюють на старіших версіях програмного забезпечення, тепер заблоковані поправкою і повинні оновитися до версії 3.4.1 або новішої, щоб залишатися синхронізованими.
XRPL Foundation заявила, що запроваджує додаткову вимогу верифікації для майбутніх випусків програмного забезпечення: раніше повідомлені проблеми безпеки повинні бути повторно протестовані на кандидатах у випуски, перш ніж їх буде класифіковано як виправлені.
За словами фонду, ця процедура застосовуватиметься до висновків аудитів, програм винагород за помилки, безпечного тестування за допомогою ШІ та інших оцінок уразливостей.
