Смарт-контракти з функцією BlackList

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

Небезпеки смарт-контрактів з функцією BlackList:

Смарт-контракти, що включають функцію Чорного списку, несуть у собі певні ризики та проблеми як для проєкту, так і для його користувачів. Ось деякі з небезпек, пов'язаних із функціями "чорного списку":

1. Централізований контроль: Функції Чорного списку часто надають централізований контроль власнику контракту або адміністраторам.


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


3. Відсутність прозорості: Наявність функції чорного списку, особливо якщо вона не документована, може призвести до відсутності прозорості. Користувачі можуть не знати про критерії складання чорного списку або про процедуру виключення з нього.


4. Ризики для безпеки: Якщо BlackList реалізовано ненадійно, існує ризик виникнення вразливостей, які можуть дозволити неавторизованим особам маніпулювати чорним списком, що може призвести до несанкціонованого заморожування або переказу коштів.


5. Недовіра користувачів: Існування функції чорного списку може підірвати довіру користувачів, оскільки їхні активи можуть бути внесено до чорного списку без чітких правил.


6. Конфіскація токенів: Зловмисники можуть використовувати чорний список для конфіскації токенів або активів з певних адрес без належних підстав. Це може призвести до суттєвих фінансових втрат.

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

Під час перевірки смарт-контракту можна зробити певні кроки, щоб визначити наявність загрози, пов'язаної з функціями чорного списку:

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


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


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


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


• Аудити безпеки: перевірте, чи проходив смарт-контракт аудит безпеки безпеки, що проводиться авторитетними сторонніми компаніями.


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


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

 

Хороші новини: наш Сканер безпеки знаходить усі поширені (в тому числі приховані) функції Чорних списків (BlackList) у 99,9% випадків. Використовуйте нашу преміум підписку і захистіть свої кошти від загроз.

 

Далі ми розглянемо кілька найпоширеніших прикладів функції BlackList, які успішно виявляє наша Платформа.

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

Приклад 1: Базовий функціонал Чорного списку

contract TokenWithBlackListAndFee {
    address public owner;
    mapping(address => bool) public BlackList;
    uint256 public BlackListFee;

    constructor(uint256 _fee) {
        owner = msg.sender;
        BlackListFee = _fee;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    function addToBlackListWithFee(address _account) public payable onlyOwner {
        require(msg.value >= BlackListFee, "Insufficient fee");
        BlackList[_account] = true;
    }

    function removeFromBlackList(address _account) public onlyOwner {
        BlackList[_account] = false;
    }
}

Поради щодо виявлення:Шукайте функції (наприклад, addToBlacklist і removeFromBlacklist), що мають модифікатори доступу (onlyOwner). Наявність подібних модифікаторів означає, що тільки власник (Owner) може змінювати чорний список.

Приклад 2: Чорний список із механізмом стягнення плати (Blacklist with Fee)

contract TokenWithBlackListAndFee {
    address public owner;
    mapping(address => bool) public BlackList;
    uint256 public BlackListFee;

    constructor(uint256 _fee) {
        owner = msg.sender;
        BlackListFee = _fee;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    function addToBlackListWithFee(address _account) public payable onlyOwner {
        require(msg.value >= BlackListFee, "Insufficient fee");
        BlackList[_account] = true;
    }

    function removeFromBlackList(address _account) public onlyOwner {
        BlackList[_account] = false;
    }
}

Поради щодо виявлення:Визначте функції (наприклад, addToBlacklistWithFee), які вимагають стягнення плати (msg.value) для внесення до чорного списку. Це є дуже небезпечним сигналом.

Приклад 3: Чорний список з умовами, що залежать від часу

contract TokenWithTimeLock {
    address public owner;
    mapping(address => bool) public BlackList;
    uint256 public BlackListTimeLock;

    constructor(uint256 _timeLock) {
        owner = msg.sender;
        BlackListTimeLock = _timeLock;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    function addToBlackListTimed(address _account) public onlyOwner {
        require(block.timestamp >= BlackListTimeLock, "Time lock not yet expired");
        BlackList[_account] = true;
    }

    function removeFromBlackList(address _account) public onlyOwner {
        BlackList[_account] = false;
    }
}

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

Приклад 4: Чорний список із реєстрацією подій (Events)

contract TokenWithBlackListAndEvents {
    address public owner;
    mapping(address => bool) public BlackList;

    event AddressAddedToBlackList(address indexed account);
    event AddressRemovedFromBlackList(address indexed account);

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    function addToBlackList(address _account) public onlyOwner {
        BlackList[_account] = true;
        emit AddressAddedToBlackList(_account);
    }

    function removeFromBlackList(address _account) public onlyOwner {
        BlackList[_account] = false;
        emit AddressRemovedFromBlackList(_account);
    }
}

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

Приклад 5: Чорний список із функцією білого списку (Whitelist)

contract TokenWithBlackListAndWhitelist {
    address public owner;
    mapping(address => bool) public BlackList;
    mapping(address => bool) public whitelist;

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the lists");
        _;
    }

    function addToBlackList(address _account) public onlyOwner {
        BlackList[_account] = true;
    }

    function removeFromBlackList(address _account) public onlyOwner {
        BlackList[_account] = false;
    }

    function addToWhitelist(address _account) public onlyOwner {
        whitelist[_account] = true;
    }

    function removeFromWhitelist(address _account) public onlyOwner {
        whitelist[_account] = false;
    }
}

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

Приклад 6: Чорний список із контролем управління (Governance Control)

interface Governance {
    function canBlackList(address _caller) external view returns (bool);
}

contract TokenWithGovernanceControl {
    address public owner;
    address public governanceContract;
    mapping(address => bool) public BlackList;

    constructor(address _governanceContract) {
        owner = msg.sender;
        governanceContract = _governanceContract;
    }

    modifier onlyOwnerOrGovernance() {
        require(msg.sender == owner || Governance(governanceContract).canBlackList(msg.sender), "Not authorized");
        _;
    }

    function addToBlackListGoverned(address _account) public onlyOwnerOrGovernance {
        BlackList[_account] = true;
    }

    function removeFromBlackList(address _account) public onlyOwnerOrGovernance {
        BlackList[_account] = false;
    }
}

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

Приклад 7: Чорний список з аварійною паузою (Emergency Stop)

contract TokenWithEmergencyStop {
    address public owner;
    bool public emergencyStop;
    mapping(address => bool) public BlackList;

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    modifier whenNotPaused() {
        require(!emergencyStop, "Contract is paused");
        _;
    }

    function addToBlackList(address _account) public onlyOwner whenNotPaused {
        BlackList[_account] = true;
    }

    function removeFromBlackList(address _account) public onlyOwner whenNotPaused {
        BlackList[_account] = false;
    }

    function toggleEmergencyStop() public onlyOwner {
        emergencyStop = !emergencyStop;
    }
}

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

Приклад 8: Чорний список із динамічними умовами

contract TokenWithDynamicBlackList {
    address public owner;
    mapping(address => bool) public BlackList;

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    function conditionallyBlackList(address _account, uint256 _threshold) public onlyOwner {
        require(getBalance(_account) < _threshold, "Account balance exceeds threshold");
        BlackList[_account] = true;
    }

    function removeFromBlackList(address _account) public onlyOwner {
        BlackList[_account] = false;
    }
}

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

Приклад 9: Чорний список із видаленням за часом (Time-Locked Removal)

contract TokenWithTimeLockedRemoval {
    address public owner;
    mapping(address => bool) public BlackList;
    mapping(address => uint256) public removalTimeLock;

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    function addToBlackList(address _account) public onlyOwner {
        BlackList[_account] = true;
        removalTimeLock[_account] = block.timestamp + 7 days;
    }

    function removeFromBlackList(address _account) public onlyOwner {
        require(block.timestamp >= removalTimeLock[_account], "Time lock not expired");
        BlackList[_account] = false;
        removalTimeLock[_account] = 0;
    }
}

Поради щодо виявлення:Виявляйте контракти, в яких видалення з чорного списку обмежене за часом. Часто в таких випадках використовуються розрахунки часу, засновані на block.timestamp.

Приклад 10: Чорний список із лімітами по газу (Gas Limit Protection)

contract TokenWithGasLimitProtection {
    address public owner;
    mapping(address => bool) public BlackList;

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    modifier limitGas() {
        require(gasleft() >= 100000, "Insufficient gas");
        _;
    }

    function addToBlackListGasLimited(address _account) public onlyOwner limitGas {
        BlackList[_account] = true;
    }

    function removeFromBlackList(address _account) public onlyOwner {
        BlackList[_account] = false;
    }
}

Поради щодо виявлення:Визначте контракти, у яких певні функції, наприклад, складання чорного списку, залежать від лімітів газу.

Приклад 11: Чорний список із зовнішньою інтеграцією з Оракулом (Oracle)

interface Oracle {
    function isBlackListed(address _account) external view returns (bool);
}

contract TokenWithOracleIntegration {
    address public owner;
    Oracle public oracle;

    constructor(address _oracleAddress) {
        owner = msg.sender;
        oracle = Oracle(_oracleAddress);
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    function addToBlackListByOracle(address _account) public onlyOwner {
        require(oracle.isBlackListed(_account), "Oracle did not confirm BlackListing");
    }
}

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

Приклад 12: Чорний список із взаємодією із зовнішнім контрактом

interface ExternalContract {
    function addToBlackList(address _account) external;
    function removeFromBlackList(address _account) external;
}

contract TokenWithExternalInteraction {
    address public owner;
    ExternalContract public externalContract;

    constructor(address _externalContract) {
        owner = msg.sender;
        externalContract = ExternalContract(_externalContract);
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    function addToBlackListExternal(address _account) public onlyOwner {
        externalContract.addToBlackList(_account);
    }

    function removeFromBlackListExternal(address _account) public onlyOwner {
        externalContract.removeFromBlackList(_account);
    }
}            

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

Приклад 13: Чорний список із динамічним порогом (Dynamic Threshold)

contract TokenWithDynamicThreshold {
    address public owner;
    mapping(address => bool) public BlackList;
    uint256 public dynamicThreshold;

    constructor(uint256 _initialThreshold) {
        owner = msg.sender;
        dynamicThreshold = _initialThreshold;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can modify the BlackList");
        _;
    }

    function addToBlackListDynamicThreshold(address _account) public onlyOwner {
        require(getBalance(_account) > dynamicThreshold, "Account balance is below threshold");
        BlackList[_account] = true;
    }

    function removeFromBlackList(address _account) public onlyOwner {
        BlackList[_account] = false;
    }

    function updateDynamicThreshold(uint256 _newThreshold) public onlyOwner {
        dynamicThreshold = _newThreshold;
    }
}

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

Загальні поради щодо виявлення функцій Чорного списку (BlackList)

1. Шукайте функції, що змінюють список адрес (mapping):
   Вивчіть код смарт-контракту, щоб виявити ті функції, які змінюють список адрес, наприклад, додають або видаляють адреси.


2. Перевірте наявність доступу тільки для власника (Owner):
   Функції чорного списку часто мають обмеження доступу, що дозволяють виконувати їх тільки власнику контракту або адміністраторам. Шукайте використання модифікатора onlyOwner або аналогічних механізмів контролю доступу.


3. Перевірте функцію-конструктор constructor():
   Функція-конструктор задає початковий стан контракту. Перевірте, чи не ініціалізуються в конструкторі будь-які адресні зв'язки або списки, що вказує на наявність чорного списку.


4. Вивчіть логіку модифікаторів:
   Проаналізуйте логіку модифікаторів типу onlyOwner, щоб зрозуміти, за яких яких умов можуть виконуватися функції, пов'язані з чорним списком.


5. Пошук ключових термінів:
   Знайдіть у коді смарт-контракту такі ключові слова, як "blacklist", "addBlacklist", "removeBlacklist" або аналогічні терміни (у найпростіших простих випадках ці функції мають подібні назви, у складніших варіантах назви можуть не відображати суть функції, щоб замаскувати її).


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


7. Перевірте зовнішні виклики (call) або події (event):
   Шукайте зовнішні виклики або події, які можуть бути ініційовані під час додавання адреси до чорного списку або її видалення. Це може дати уявлення про те, як контракт взаємодіє із зовнішніми компонентами на основі дій, пов'язаних із чорним списком.


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


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


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


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


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


13. Залежні від часу умови:
    Перевірте наявність залежних від часу умов, пов'язаних із внесенням до чорного списку. Наприклад, у контрактах можуть бути реалізовані тимчасові блокування на видалення або інші механізми, чутливі до часу.


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


15. Вивчіть відгуки спільноти:
    Перевірте форуми спільноти, соціальні мережі або офіційні канали зв'язку на предмет обговорення наявності та використання функції чорного списку. Користувачі можуть висловити цінні міркування та побоювання.
















 
16.  
17.  
18.  
19.  
20.  
21.  
22.  
23.  
24.  
25.  
26.  
27.  
28.  
29.  

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

За можливості обирайте контракти, що відповідають усталеним стандартам (наприклад, ERC-20). Ці стандарти часто піддаються ретельній перевірці та мають репутацію надійних.

 

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

 

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

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

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

All posts