Опис детектора Proxy

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

Проксі-смарт-контракти завоювали популярність у блокчейн-просторі завдяки своїй модернізованості та гнучкості. Однак такі контракти приховують у собі й велику небезпеку, особливо в разі використання зловмисниками. Шахраї часто використовують обманні схеми в проксі-смарт-контрактах для обману користувачів. Щоб визначити наявність таких загроз, необхідно розуміти можливі ризики і бути технічно підкованими.

Давайте детально розглянемо опис потенційних небезпек, поширених схем обману та способів виявлення таких загроз у проксі-смарт-контрактах.

Небезпеки проксі-смарт-контрактів:

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


2. Неперевірені зовнішні виклики:
   Програмісти-шахраї можуть використовувати зовнішні виклики до недовірених контрактів без належної перевірки. Це може призвести до вразливостей, зокрема до атак типу reentrancy, коли шкідливі контракти неодноразово звертаються до проксі-контракту, що може призвести до виснаження його коштів.


3. Відсутність прозорості:
   Вихідний код керуючого контракту, як правило, не верифікований.


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


5. Схеми Понці:
   Шахраї будують схеми Понці на основі проксі-контрактів, заманюючи користувачів обіцянками високих доходів. Для підтримки ілюзії правдоподібності такі схеми можуть мати оновлювані компоненти.


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

Як самостійно визначити наявність подібних загроз у смарт-контрактах?

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

Тому варто розуміти, що робота з Proxy смарт-контрактом це гра в рулетку в самому прямому сенсі слова (казино завжди виграє).

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

Якщо Ви хочете самостійно визначати наявність функцій Proxy у смарт-контрактах, то наступні поради будуть у цьому корисні.

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


• Переконайтеся, що смарт-контракт пройшов зовнішній аудит безпеки, проведений авторитетними компаніями. Звіт про аудит може дати уявлення про потенційні вразливості.


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


• Зверніться до спільноти проєкту та дізнайтеся відгуки інших користувачів, які мають досвід роботи з контрактом. Шахраї часто уникають публічного обговорення.


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


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


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


• Будьте в курсі останніх подій у нашій спільноті (Телеграм-канал) та найкращих практик з виявлення шахрайства (наш Блог і YouTube-канал).

 

Сканер безпеки Lotus Market знаходить усі поширені (та зокрема приховані) функції зовнішнього керування (Proxy). Використовуйте нашу преміум підписку і захистіть свої кошти від загроз.

 

 

Далі ми наведемо приклади поширених "червоних прапорців" і підозрілих патернів, на які слід звернути увагу під час вивченні смарт-контрактів для виявлення потенційно шкідливої функціональності. Важливо розуміти ці ознаки, щоб захистити себе та інших від потенційного шахрайства. Розглянемо деякі варіанти шаблонів коду та поради, які допоможуть вам виявити підозрілу функціональність у смарт-контракті:

 

Основне правило - якщо в коді контракту є виклик функцій Call, CallCode або DelegateCall, значить контракт звертається до зовнішнього коду і передає йому управління своїми даними.

Розглянемо основні приклади використання Proxy контрактів.

1. Неініціалізовані змінні зберігання.

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

    contract Implementation {
        address public owner;

        constructor() {
            owner = msg.sender;
        }
    }

У цьому прикладі, якщо змінна owner у контракті Proxy неініціалізована, виклик функції owner() на контракті proxy поверне змінну owner контракту реалізації, що може виявитися не тим, чого очікує користувач.

2. Неперевірені зовнішні виклики.

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

    contract Proxy {
        function execute(address target, bytes memory data) external {
            target.delegatecall(data);
        }
    }

Якщо користувач надсилає як цільову адресу довільний контракт і шкідливі дані, це може призвести до виконання несанкціонованих дій від імені користувача.

3. Неправомірний контроль доступу.

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

    contract Proxy {
        address public owner;
        address public implementation;
                                        
        function upgrade(address newImplementation) external {
            require(msg.sender == owner, "Only the owner can upgrade.");
            implementation = newImplementation;
        }
    }

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

4. Ризики, пов'язані з версіонуванням і управлінням.

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

    contract Proxy {
        address public owner;
        address public implementation;
        address public pendingImplementation;
            
        function upgrade(address newImplementation) external {
            require(msg.sender == owner, "Only the owner can upgrade.");
            pendingImplementation = newImplementation;
        }
        function claimUpgrade() external {
            require(msg.sender == owner, "Only the owner can claim the upgrade.");
            implementation = pendingImplementation;
        }
    }

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

На що звертати увагу під час вивчення Proxy-контрактів і які загрози вони становлять вони становлять?

1. Несанкціонований переказ коштів:
   Одним із найпоширеніших способів розкрадання грошей шахраями є переказ коштів власником контракту на себе або на іншу адресу без відповідного дозволу.


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


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


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


5. Документація, що вводить в оману, або коментарі, які не відповідають поведінці коду:
   Шахраї можуть надавати документацію або коментарі у своєму коді, які вводять в оману або неточні документацію або коментарі у своєму коді, щоб ввести користувачів в оману щодо справжньої функціональності контракту. Завжди проводьте перехресну перевірку документації з реальною поведінкою коду.


6. Відсутність перевірок безпеки:
   Остерігайтеся контрактів, у яких відсутні належні перевірки безпеки, механізми контролю доступу або не реалізовано засобів захисту від таких поширених вразливостей захисту від таких поширених вразливостей, як реентерабельність. Під час розгляду смарт-контракту завжди ретельно вивчайте код, шукайте добре документовані та прозорі проєкти, перевіряйте зовнішні аудити безпеки та вивчайте відгуки спільноти. Крім того, будьте обережними під час взаємодії з контрактами, у яких присутні будь-які з перерахованих ознак, оскільки вони можуть бути спрямовані на розкрадання коштів або здійснення інших шкідливих дій.


7. Складні умовні вирази:
   Шахраї можуть використовувати складні умовні вирази або логіку, за якою важко встежити. якою важко встежити, що ускладнює розуміння істинної функціональності контракту. Шукайте надмірно заплутаний код: надмірно складну або незрозумілу логіку, а також умови, що не мають відношення до мети контракту.


8. Неясні схеми управління та володіння (Ownership):
   Шахраї часто використовують проксі-контракти з неясними механізмами управління або прихованою структурою володіння, що ускладнює користувачам визначення того, хто контролює контракт.


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


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


11. Відсутність публічної верифікації або аудиту:
    Якщо контракт не пропонує публічної перевірки вихідного коду або не пройшов аудит безпеки третьою стороною, слід підходити до нього з особливою обережністю.


12. Незвичайне або приховане зберігання даних:
    Шахраї можуть використовувати нетрадиційні або приховані схеми зберігання даних для маскування шкідливої функціональності. Звертайте увагу, що дані можуть зберігатися в несподіваних місцях у межах контракту.


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

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

У світі Blockchain, що швидко розвивається, необхідно зберігати пильність та інформованість, щоб захистити себе і свої активи від можливих шахрайських схем і вразливостей, пов'язаних із проксі-контрактами та функціями DelegateCall.

 

Сподіваємося, що ця інформація допомогла Вам краще розібратися зі схемами керованих (Proxy) смарт-контрактів.

 

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

Однак, ми все вже зробили за Вас! Підключайте преміум підписку та відкрийте для себе доступ до ексклюзивних фільтрів за функціями смарт-контрактів та свіжу аналітику. Підвищіть шанси на успішні інвестиції в прибуткові токени.

З повагою, команда Lotus Market.

All posts