Краткое руководство по атакам с короткими адресами в криптовалюте

Вы когда-нибудь слышали об атаке с использованием коротких адресов? Это серьёзная уязвимость в смарт-контрактах Ethereum, которая позволяет злоумышленникам использовать различия в обработке адресов разной длины. 

Чтобы предоставить более подробную информацию, в этой статье мы рассмотрим механизмы атак с использованием коротких адресов, их влияние и основные стратегии предотвращения. Развенчивая заблуждения и предлагая советы по противодействию этим атакам, мы стремимся предоставить исчерпывающую информацию как для рядовых пользователей, так и для экспертов.

Читайте также: Какая криптовалюта самая безопасная?

Основные выводы

• Атаки с использованием коротких адресов используют уязвимости смарт-контрактов в криптовалютных кошельках, отправляя средства на короткий, похожий адрес, заставляя пользователей совершать ошибки.

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

• Стратегии снижения риска включают использование инструментов проверки адреса и обеспечение актуальности программного обеспечения кошелька.

Что такое атака с коротким адресом?

Ethereum, как децентрализованная платформа, позволяет выполнять смарт-контракты с помощью языка программирования Solidity. Аналогично, Solidity устанавливает строгие ограничения по длине адресов, требуя, чтобы адреса имели ровно 20 байт (40 шестнадцатеричных символов).

Это обеспечивает согласованность и безопасность при обработке адресов в транзакциях смарт-контрактов. Однако атака с коротким адресом — это уязвимость, при которой злоумышленники используют алгоритмы кодирования адресов, игнорируя конечные символы закодированной строки. 

Создавая закодированную строку, которая соответствует префиксу законного адреса, злоумышленники обманом заставляют пользователей отправлять средства или проводить операции, используя контролируемый злоумышленником адрес. 

Хотя адреса Ethereum обычно состоят из 20 байт, если злоумышленник использует адрес короче 20 байт, Solidity автоматически дополняет оставшиеся байты справа нулями, чтобы сохранить правильную длину адреса. 

Например, если функция ожидает два аргумента, например, адрес и сумму токена, контракт может непреднамеренно интерпретировать часть второго аргумента (сумму токена) как часть первого (адреса) из-за этого автоматического дополнения. Такая неверная интерпретация позволяет злоумышленнику отправить большее количество токенов, чем предполагалось изначально.

По сути, этот тип атак часто использует человеческий фактор, поскольку пользователи могут не проверять каждый символ в адресе кошелька из-за его сложности. Поэтому злоумышленники пользуются этим, создавая адреса, которые выглядят почти как настоящие, но укорочены или немного изменены.

Пример атаки с коротким адресом

Рассмотрим приведенный ниже код Solidity, который используется для перевода токенов со счета отправителя на другой счет:

функция передачи(адрес _to, uint256 _value) public {

    требуется(_to.length == 20);

    _to.transfer(_value);

}

Эта функция контракта предназначена для перевода указанной суммы на указанный адрес. Чтобы убедиться, что предоставленный адрес представляет собой корректное 20-байтовое значение, контракт проверяет длину адреса с помощью свойства length. 

Однако использование свойства «length» не является надёжным методом проверки адреса, поскольку оно возвращает количество байтов, а не битов. Это создаёт уязвимость для атаки с коротким адресом, когда злоумышленник может предоставить адрес короче 20 байт, но при этом он будет выглядеть корректным, поскольку его длина равна или превышает 20 байт.

Чтобы показать, как может осуществляться атака с использованием короткого адреса, рассмотрим следующий код Solidity:

функция передачи(адрес _to, uint256 _value) public {

    требуется(_to.length == 20);

    _to.transfer(_value);

}

функция testAttack() public {

    адрес shortAddress = 0x01;

    значение uint256 = 100;

    передача(shortAddress, значение);

}

В этом случае функция передачи идентична той, что использовалась в предыдущем примере. Однако в контракте также присутствует функция testAttack, которая вызывает функцию передачи, используя короткий адрес и значение 100. 

Поскольку функция передачи проверяет адрес по свойству «length», она ошибочно предполагает, что предоставленный адрес является допустимым 20-байтовым адресом, и продолжает операцию передачи. Однако, поскольку фактически адрес короче 20 байт, передача завершится неудачей, и значение не будет передано.

Как работает атака с коротким адресом?

Стандарт ERC20 предписывает, что функция «transfer» требует два параметра: адрес получателя и значение «uint256», представляющее количество токенов для передачи. При атаке с коротким адресом злоумышленник предоставляет входные данные, длина которых короче, чем ожидается в контракте.

Это приводит к тому, что принимающий контракт неверно интерпретирует данные, поскольку поля могут быть смещены. Поскольку некоторые сторонние приложения, кодирующие данные транзакций, могут неправильно обрабатывать заполнение или выполнять корректную проверку длины, контракт может обрабатывать неправильно отформатированные транзакции, что приводит к непредвиденному поведению.

Вот упрощенное описание процесса:

Манипуляция адресом

Злоумышленник предоставляет сокращённую версию адреса легитимного кошелька. В некоторых случаях злоумышленник может использовать инструмент или вредоносное ПО для автоматического заполнения или отображения неверного адреса во время транзакции.

Например, злоумышленник отправляет транзакцию в функцию перевода с коротким адресом 0x123456 и суммой 1000.

Набивка

Клиент Ethereum добавляет нули к короткому адресу, чтобы расширить его до необходимых 20 байт. Это дополнение нарушает соответствие последующих параметров транзакции, что приводит к неверной интерпретации данных транзакции смарт-контрактом.

Например, клиент Ethereum дополняет значение 0x123456 до 0x1234560000000000000000000000000000000000 . Это смещает предполагаемый параметр суммы в 1000, что приводит к неправильной интерпретации данных контрактом.

Человеческая ошибка

Пользователь, инициирующий транзакцию, не замечает, что адрес кошелька неполный или неверный. Это часто происходит из-за того, что адреса длинные, и пользователи полагают, что копирование и вставка всегда обеспечат точность.

Перевод денежных средств

Пользователь отправляет криптовалюту на сокращённый или неверный адрес. Поскольку транзакции в блокчейне необратимы, средства теряются или отправляются на адрес злоумышленника.

Один из самых известных случаев атаки с использованием сокращенного адреса произошел в середине 2022 года, когда известный криптоинфлюенсер публично раскрыл запланированный перевод 250 ETH (стоимостью около 500 000 долларов на тот момент). Злоумышленники, отслеживая транзакции инфлюенсера, подставили в поле транзакции сокращенную версию адреса кошелька получателя.

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

Этот инцидент подчеркнул важность проверки адресов кошельков, особенно при работе с крупными суммами денег или проведении публичных транзакций.

Однако следует отметить, что начиная с версии Solidity 0.5.0 , компилятор ввел проверки во время выполнения, чтобы гарантировать, что размер данных вызова соответствует ожидаемой длине для аргументов статического размера или, по крайней мере, минимальному размеру, требуемому для аргументов динамического размера. Эти проверки помогают защититься от методов манипулирования, таких как атаки с использованием коротких адресов, когда злоумышленники могут попытаться использовать несоответствия в длине данных.

Кроме того, он обеспечивает согласованность данных при исполнении контракта.

«Блокчейн — очень интересная технология, которая в ближайшие годы найдет широкое применение в жизни общества». — Кеннет К. Гриффин

Влияние атак с короткими адресами

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

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

Большинство атак с использованием коротких адресов было зафиксировано на платформах децентрализованных финансов (DeFi) и сервисах кошельков, в которых отсутствуют строгие меры проверки. Эти платформы особенно уязвимы из-за характера транзакций между физическими лицами и отсутствия посредников, которые могли бы проверить точность адресов кошельков.

Согласно данным Chainanalysis , в первом квартале 2022 года хакеры украли 1.3 миллиарда долларов у бирж, платформ и частных компаний, при этом значительная часть потерь непропорционально сильно затронула сектор DeFi.

Кроме того, следует отметить, что, хотя жертвой может стать кто угодно, большинство жертв обычно относятся к категории новичков или неопытных пользователей криптовалют. Сложность адресов кошельков и незнание протоколов транзакций повышают их уязвимость.

«Даже у некоторых крупных криптовалютных компаний, вероятно, нет достаточно продвинутой киберзащиты, чтобы перехитрить хакеров. Учитывая столь стремительный рост криптовалютной индустрии, понятно, почему за ней может быть сложно угнаться», — Люк Уиллмотт, соучредитель и главный операционный директор криптоплатформы AutoCoinCars.

Как обнаружить уязвимости атак с короткими адресами

Для обнаружения уязвимостей, связанных с атаками с использованием коротких адресов, требуется многоуровневый подход, включающий тщательный анализ кода, автоматизированные инструменты и улучшенные методы обеспечения безопасности. Вот несколько методов обнаружения этих уязвимостей в смарт-контрактах:

Аудит кода и формальная проверка

Один из наиболее эффективных способов обнаружения уязвимостей коротких адресов — это ручной аудит кода и формальные процедуры верификации. Аудиторы, имеющие опыт в области безопасности смарт-контрактов, могут выявить потенциальные уязвимости в обработке адресов в контракте. 

Формальная проверка использует математические модели для доказательства того, что контракт ведет себя ожидаемым образом во всех случаях, включая случаи, связанные с неверно сформированными или сокращенными адресами.

Автоматизированные средства безопасности

Существует несколько автоматизированных инструментов, предназначенных для обнаружения уязвимостей в смарт-контрактах, в том числе уязвимых для атак с использованием коротких адресов. Вот некоторые популярные инструменты:

• Миф X: Это инструмент анализа безопасности смарт-контрактов Ethereum, который помогает выявить потенциальные уязвимости, включая проблемы с короткими адресами.
• Обезопасить: Инструмент аудита, который выполняет автоматизированные проверки безопасности смарт-контрактов и выявляет проблемы, связанные с форматированием адресов.
• Плагины Remix IDE: Разработчики Ethereum могут использовать Remix IDE с плагинами безопасности, которые автоматически отмечают уязвимый код.

Эти инструменты анализируют логику контракта и выявляют любые небезопасные практики, которые могут быть использованы с помощью атак с использованием коротких адресов.

Проверка длины в коде

Разработчики смарт-контрактов должны реализовать проверку длины адреса, чтобы гарантировать, что все адреса имеют длину не менее 20 байт перед обработкой транзакций. Это можно сделать, явно проверяя длину параметра адреса и отклоняя транзакции с укороченными или неправильно отформатированными адресами.

Например, в Solidity разработчики могут использовать следующую функцию для проверки адреса:

функция isValidAddress(address _addr) public pure возвращает (bool) {

    return _addr != address(0) && _addr == address(uint160(_addr));

}

Эта простая проверка гарантирует правильность длины адреса перед обработкой транзакции, предотвращая потенциальные атаки с использованием короткого адреса.

Моделирование тестовой сети и тестирование на проникновение

Перед развертыванием смарт-контракта в основной сети Ethereum разработчикам следует провести моделирование тестовой сети и тестирование на проникновение для выявления потенциальных уязвимостей. Эти тесты имитируют реальные сценарии атак и могут выявить проблемы, которые могли быть не выявлены во время разработки. 

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

Читайте также: Статистика утечек данных в сфере криптовалют: тенденции и выводы

Как предотвратить атаки с использованием коротких адресов

Для предотвращения атак с использованием коротких адресов необходимы как технологические решения, так и осведомлённость пользователей. Несколько эффективных стратегий помогут снизить вероятность стать жертвой таких атак:

Проверка ввода

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

Эти инструменты гарантируют, что пользователи не смогут отправить средства на усеченный или неверный адрес. Примером может служить Tokenview , широко используемый инструмент проверки адресов криптокошельков, упрощающий процесс проверки адресов кошельков в разных блокчейнах.

Он позволяет пользователям подтверждать подлинность адресов, а также предоставляет информацию о удерживаемых токенах, истории транзакций и другие важные данные.

Обучение пользователей

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

Простые шаги, такие как копирование и вставка полного адреса в блокнот для его ручной проверки, могут предотвратить множество атак.

Механизм контрольной суммы 

Контрольная сумма — это строка цифр и букв, полученная из исходных данных, которая может использоваться для обнаружения ошибок. Убедитесь, что все адреса являются корректными адресами Ethereum с контрольной суммой. 

Реализация контрольных сумм помогает проверить их соответствие формату адреса Ethereum, тем самым минимизируя риск манипуляций с короткими адресами.

Аудит и тестирование

Регулярный аудит смарт-контрактов и комплексное тестирование могут выявить уязвимости безопасности. Поэтому использование автоматизированных инструментов аудита в сочетании с ручным анализом кода может сыграть решающую роль в предотвращении подобных атак.

Формальная проверка 

Формальная верификация подразумевает математическое доказательство корректности смарт-контрактов. Этот метод может быть использован для гарантии корректной обработки входных параметров, тем самым предотвращая атаки с использованием коротких адресов.

Примером инструмента формальной верификации является Solidity SMTChecker . Интегрированный в компилятор Solidity, он использует формальные методы для обнаружения логических ошибок.

Безопасные математические библиотеки

Использование безопасных математических библиотек, таких как SafeMath от OpenZeppelin, может усилить защиту от атак с короткими адресами. Эти библиотеки предоставляют функции, выполняющие математические операции со встроенными проверками безопасности, гарантируя срабатывание ошибок в случае переполнения или недополнения.

Другие распространенные уязвимости смарт-контрактов

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

Однако наличие смарт-контрактов также привлекает злоумышленников, стремящихся использовать потенциальные уязвимости. За кулисами скрываются те, кто ищет возможности воспользоваться уязвимостями кода.

В последние годы из-за уязвимостей в смарт-контрактах были потеряны миллиарды долларов в криптовалюте. Например, в августе 2022 года американская криптовалютная компания Nomad сообщила о краже 190 миллионов долларов в криптовалюте в результате взлома моста токенов Nomad.

Это подчёркивает острую необходимость в усилении мер безопасности. Давайте кратко рассмотрим некоторые другие уязвимости смарт-контрактов, о которых вам следует знать:

Целочисленное переполнение/отсутствие значимости

Целочисленное переполнение и потеря значимости — распространённые проблемы в смарт-контрактах Solidity, возникающие, когда арифметические операции превышают максимальное или минимальное значение, которое может храниться в типе данных. Эти проблемы затрагивают как типы данных uint, так и int, что может привести к непредвиденному поведению или потере активов. 

Например, если контракт использует 32 бита памяти для каждого целого числа, он может хранить только значения в диапазоне [0, 2 147 483 647]. Если арифметическая операция приводит к значению, превышающему 2 147 483 647, переменная автоматически возвращается к 0, что может привести к серьёзным проблемам.

Примером этого является атака Proof of Weak Hands Coin (PoWHC). PoWHC — это финансовая пирамида, построенная на Ethereum с использованием Solidity и созданная группой пользователей 4chan. В этом случае авторы смарт-контракта не учли условия переполнения и дефицита средств, что привело к несанкционированному выводу 866 эфиров из контракта.

Рекомендация

Используйте библиотеку SafeMath в Solidity для защиты от переполнения и потери значимости целочисленных значений. Эта библиотека предоставляет функции для выполнения арифметических операций, которые автоматически проверяют эти условия и генерируют исключение при обнаружении переполнения или потери значимости.

Повторная атака

Повторный вход (Reentrancy) — это уязвимость безопасности смарт-контрактов Solidity, которая позволяет злоумышленникам многократно вызывать функции внутри контракта, что потенциально приводит к краже средств или активов. Эта уязвимость возникает, когда злоумышленнику удаётся вызвать функцию контракта несколько раз до завершения первоначального выполнения, что позволяет ему манипулировать состоянием контракта и незаконно присваивать токены.

Атаки с использованием уязвимостей — распространённый метод, используемый злоумышленниками. На их долю приходится 5 из 60 взломов, связанных с уязвимостями, и в результате в первой половине 2023 года были понесены общие убытки в размере 8.5 миллионов долларов. Примечательный пример произошёл в июне 2016 года, когда подобная атака вывела средства из «DAO», что побудило разработчиков Ethereum создать форк блокчейна.

Рекомендация

Чтобы уменьшить эту уязвимость, одним из эффективных решений является использование модификатора «nonReentrant», предоставляемого реализацией ERC20 OpenZeppelin. 

Важно отметить, что, поскольку существует только один защитник «nonReentrant», функции, отмеченные этим модификатором, не могут напрямую вызывать друг друга. Однако это ограничение можно обойти, сделав эти функции приватными и предоставив внешние точки входа, отмеченные как «nonReentrant».

Для предотвращения атак повторного входа ещё одной эффективной стратегией является реализация шаблона «Проверки-Эффекты-Взаимодействия». Этот подход начинается с проверки входных данных и условий, затем обновляются переменные состояния и, наконец, осуществляется взаимодействие с внешними контрактами. 

Гарантируя, что все изменения состояния будут завершены до того, как произойдет какое-либо внешнее взаимодействие, этот шаблон эффективно предотвращает уязвимости повторного входа.

Неправильное хранение данных

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

Рекомендация

Для функций, которым требуется только чтение значений, рекомендуется использовать calldata. Calldata — это доступная только для чтения область хранения, в которой хранятся аргументы функций, переданные в контракт, что позволяет оптимизировать расходы на газ и гарантировать неизменность входных аргументов.

Эксплойты одобрения

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

Проблема этой схемы заключается в том, что она позволяет одобренному контракту переводить токены в любое время, даже если пользователь отзовёт своё одобрение или контракт будет скомпрометирован. Следовательно, злоумышленник может воспользоваться этой уязвимостью, получив контроль над одобренным контрактом и выполнив несанкционированный перевод токенов с учётной записи пользователя на свою.

Рекомендация

Чтобы снизить риск злоупотреблений, связанных с одобрением, контракты на токены ERC20 должны предусматривать механизм ограничения количества токенов, которые одобренный контракт может передать от имени пользователя. Это можно реализовать, установив максимальное ограничение или введя ограничение по времени, истекающее по истечении определённого периода.

Кроме того, разработчики могут повысить безопасность, требуя подтверждения пользователя для каждой передачи токенов или используя многофакторную аутентификацию для проверки передач токенов.

Зависимость состояний между функциями

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

Кроме того, эта проблема может возникнуть, когда обе функции вызываются одновременно, что может привести к возникновению условий гонки, которые поставят под угрозу целостность смарт-контракта.

Рекомендация

Чтобы снизить эту уязвимость, рекомендуется реализовать те же превентивные меры, которые используются для устранения подобных состояний гонки. В частности, необходимо убедиться, что все изменения состояния завершены до начала любых переводов эфира. 

При таком подходе смарт-контракт выполнит все необходимые изменения состояния, прежде чем инициировать какие-либо транзакции эфира.

«Нет возможности исправить ситуацию. Это невозможно. Нельзя отменить транзакции в блокчейне», — Элкс Финн, криптопредприниматель 

Заключение: будущее предотвращения атак с использованием коротких адресов

Атаки с использованием коротких адресов представляют серьёзную проблему, поскольку зачастую приводят к значительным потерям. По мере развития криптовалют и блокчейн-технологий пользователям и платформам крайне важно сохранять бдительность в отношении подобных атак.

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

В конечном счёте, лучшая защита от атак с использованием коротких адресов — это осмотрительность. Пользователи должны уделять время проверке каждой транзакции, а платформы должны внедрять передовые меры безопасности для защиты от постоянно меняющихся угроз. 

По мере развития криптосреды эти усилия будут иметь решающее значение для поддержания доверия и защиты цифровых активов от мошеннических атак.

Часто задаваемые вопросы (FAQ)