Перейти к содержанию
Financial Context Wiki

Отравление адреса

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

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

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

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

Контрольная сумма ERC-55 помогает выявить некоторые случайные опечатки, однако другой адрес злоумышленника может быть синтаксически допустимым и иметь правильную контрольную сумму. Обычный 20-байтовый адрес EVM также не указывает сам по себе предполагаемую сеть, актив, роль получателя, примечание к депозиту или вызов контракта. Безопасное платежное поручение связывает все эти параметры с полным адресом назначения.

Отравление адреса
0 / 5
0 проверено; 5 осталось

Завершение этой проверки не доказывает безопасность актива, транзакции или системы.

Как это работает

Злоумышленник наблюдает публичный шаблон платежей и ищет vanity-адрес, совпадающий по символам, которые кошелек оставляет при сокращенном отображении. Совпадение выбранных шестнадцатеричных символов не клонирует учетную запись: скрытые байты остаются иными, а новым ключом управляет злоумышленник. Небольшой перевод может поместить такой реальный адрес в историю. При этом ERC-20 требует обрабатывать переводы нулевой стоимости как обычные и создавать событие Transfer, поэтому запись с нулевой стоимостью сама по себе не доказывает подделку, компрометацию, авторизацию или экономический убыток.

Вредоносный токен-контракт также может создать собственный лог Transfer(victim, lookalike, 0). Это реальные данные квитанции, относящиеся к испустившему их контракту, однако событие исходит не от канонического контракта актива и не доказывает, что жертва подписала внешнюю транзакцию. Тем не менее индексатор, который классифицирует активность по темам событий без достаточного контекста контракта и вызова, может показать обманчивую строку исходящего перевода.

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

Имена и тестовые платежи — вспомогательные меры, а не доказательства личности. Разрешайте имя ENS для нужной сети и записи непосредственно при подписании; если отображается обратное имя, выполните прямое разрешение обратно в тот же адрес. Малый тест помогает только тогда, когда получатель независимо подтверждает его, а основной платеж повторно использует то же закрепленное назначение. Повторное копирование из истории лишает тест этой защиты.

Используйте следующий порядок:

  1. Зафиксируйте сеть, актив и точный токен-контракт, тип получателя, формат адреса, сумму, примечание, тег, calldata, версию или срок действия из аутентифицированного независимого источника.
  2. Один раз разрешите имя или QR-код, проверьте формат и контрольную сумму и свяжите все байты назначения с нужной сетью; обратное имя подтвердите прямым разрешением, не считая метку удостоверением личности.
  3. Сверьте назначение с контролируемым списком разрешений, адресной книгой или подписанным счетом, но никогда не с историей транзакций; новый или существенно измененный получатель требует независимого либо двойного одобрения.
  4. Точно декодируйте неподписанную транзакцию: отличите нативное поле to от токен-контракта или моста и проверьте в calldata получателя, токен, исходную сумму, разрешение, крайний срок и семантику назначения.
  5. Когда уместно, отправьте небольшой тест на закрепленное назначение и получите независимое подтверждение получателя; для основного платежа не копируйте адрес из истории повторно.
  6. Подпишите основной перевод только из проверенной записи, сравните полные назначение и сумму на доверенном дисплее, затем проверьте квитанцию, контракт-эмитент, логи и изменения балансов в правильной сети.
  7. При подозрении на отравление или ошибочную отправку остановите последующие платежи, сохраните хеши и доказательства и без промедления свяжитесь с сервисом получателя, эмитентом или правоохранительными органами, когда это уместно; заморозка, возврат и восстановление условны и никогда не гарантированы.

Примеры

  • Сокращение скрывает различие. Законный 0x12ab1111111111111111111111111111111189ef и принадлежащий злоумышленнику 0x12ab9999999999999999999999999999999989ef отображаются одинаково: 0x12ab...89ef. У них совпадают 4 + 4 = 8 видимых шестнадцатеричных символов, но различаются все 32 символа в середине. Сравнение только показанных концов дает ложное совпадение, а сравнение всех байтов — нет.
  • Трудоемкость поиска vanity-адреса. Для совпадения k = 8 выбранных шестнадцатеричных символов ожидается перебор 16^8 = 4,294,967,296 кандидатов. При предполагаемой скорости 50,000,000 candidates/s ожидаемое время равно 4,294,967,296 / 50,000,000 = 85.89934592 s. Это иллюстрация пространства поиска, а не гарантированного времени или порога предупреждения кошелька.
  • Лог и состояние. Токен-контракт создает событие Transfer(victim, lookalike, 0). Баланс жертвы остается от 250,000.000000 до 250,000.000000, то есть изменение равно 0.000000, однако индексатор активности может показать строку перевода. Проверяйте контракт-эмитент и авторизацию вызова: одна строка не доказывает ни движение стоимости, ни подпись жертвы.
  • Тест должен закреплять назначение. Казначейство намерено отправить 50,000 USDC, переводит 1 USDC на проверенный адрес, получает независимое подтверждение и отправляет 49,999 USDC из той же закрепленной записи: 1 + 49,999 = 50,000 USDC. Если сотрудник заново скопирует похожий адрес из истории для второй части, тест уже не защищает платеж 49,999 USDC.

Риски

  • Отправитель копирует похожий адрес из отравленной истории транзакций.
  • Сокращенный интерфейс скрывает отличающиеся символы в середине.
  • Vanity-префикс или суффикс принимают за идентификатор получателя.
  • Перевод ERC-20 с нулевой стоимостью создает обманчивую строку истории.
  • Поддельный токен или его лог принимают за активность канонического актива.
  • Индексатор неверно классифицирует поля события или исправляет их слишком поздно.
  • Спам-токен имитирует названием, символом или значком доверенный актив.
  • Вредоносная программа в буфере обмена заменяет проверенный адрес до подписания.
  • Локальная или синхронизируемая адресная книга отравлена либо устарела.
  • Список разрешений привязывает не ту сеть, актив, роль или версию адреса.
  • Пользователь игнорирует предупреждение о неверной или отсутствующей контрольной сумме.
  • Правильную контрольную сумму ошибочно считают доказательством личности получателя.
  • Разрешение ENS меняется, использует неверный тип монеты или устаревает.
  • Обратное имя показывается без прямого подтверждения.
  • После тестового платежа адрес заново копируется из недоверенного источника.
  • Депозитный адрес биржи, сеть, примечание или тег неверны либо просрочены.
  • Назначение моста, прокси или контракта и необходимая calldata истолкованы неверно.
  • Подписант проверяет только сокращенный текст даже на аппаратном устройстве.
  • Перевод неправильному получателю становится каноническим до вмешательства.
  • Жертва полагается на добровольную заморозку эмитентом или попадает в мошенничество с возвратом.

Распространенные заблуждения

  • Отравление адреса означает взлом кошелька, ключа или блокчейна. Обычная атака эксплуатирует выбор получателя, а исправные криптография и консенсус исполняют неверное подписанное намерение.
  • Строка с нулевой стоимостью обязательно является поддельной ончейн-транзакцией. Соответствующие стандарту переводы и реальные логи могут иметь нулевую стоимость; проверяйте их источник и влияние на состояние.
  • Совпадающие концы и контрольная сумма доказывают получателя. Другой допустимый адрес может совпадать по видимым символам и иметь собственную правильную контрольную сумму.
  • Один успешный тест автоматически защищает следующий перевод. Защита теряется, если основной платеж не использует повторно закрепленное и подтвержденное назначение.
  • Кошелек, валидатор или эмитент токена всегда может отменить платеж. Возможности восстановления и сотрудничество зависят от актива, сервиса, юрисдикции, доказательств и времени.

Связанные темы

Источники

Навигация

Поиск по вики...