Address poisoning в TON: атака на буфер обмена

Address poisoning в TON: атака на буфер обмена

Address poisoning — самая «тихая» из массовых атак на пользователей крипто-кошельков, и в 2025 году она пришла в TON всерьёз. Не нужно ни фишингового сайта, ни социальной инженерии, ни компрометации seed-фразы: атакующий просто делает входящий перевод на 0 TON с адреса, который в истории выглядит как один из твоих регулярных контрагентов. Через неделю-две, когда ты копируешь «привычный» адрес из последних операций, ты копируешь подделку. Подпись уходит, средства уходят, разбор полётов — после факта. Этот разбор — что именно делает TON особенно удобной поверхностью для подобной атаки и какой минимум привычек её закрывает.

TL;DR

• Атакующий генерирует адрес с теми же первыми и последними 4-6 символами, что у твоего постоянного контрагента, и отправляет тебе 0 TON.
• Цель — не украсть здесь и сейчас, а посадить «отравленный» адрес в твою историю операций, чтобы при следующем копипасте ты взял его.
• TON-адреса в user-friendly формате (UQ… / 0Q…, base64url, ~48 символов) визуально шумные — сверка по краям проваливается.
• Защита — никогда не копировать адрес из истории, держать контрагентов в адресной книге или через TON DNS, сверять адрес полностью, особенно на экране Ledger.
• На уровне команд — multi-sig с allow-list, тестовый перевод, подтверждение по второму каналу.

Как работает address poisoning — механика атаки

Схема состоит из трёх компонентов, ни один из которых не требует доступа к твоему кошельку.

Первый компонент — vanity-адрес. Атакующий с помощью brute-force или GPU-инструмента генерирует TON-адрес, у которого совпадают, скажем, первые 4 и последние 4 символа с адресом, которым ты регулярно пользуешься. Алгоритм перебирает приватные ключи и вычисляет соответствующий адрес кошелька, пока не находит совпадение по нужным символам. На современном железе пара 4+4 находится за минуты, 6+6 — за часы.

Второй компонент — dust transaction. С полученного адреса атакующий отправляет тебе перевод на 0 TON или 0.000001 TON. Иногда — с пустым комментарием, иногда с подсказкой вроде «refund», «test», «cashback». Транзакция стоит атакующему долю цента в газе.

Третий компонент — психология копипаста. В какой-то момент ты переводишь средства тому же контрагенту, что и раньше. Открываешь Tonkeeper, заходишь в историю, видишь свежий перевод с «привычными краями» — UQAB…6F2C — и копируешь оттуда. Сравниваешь первые и последние символы с тем, что помнишь, всё совпадает, нажимаешь «Отправить». Сумма уходит атакующему.

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

Почему TON-адреса особенно уязвимы

TON-адрес во внутреннем виде — это workchain:hash (обычно 0: плюс 64 hex-символа). В пользовательском интерфейсе кошельки показывают user-friendly формат: 48 символов base64url с префиксом UQ (non-bounceable) или EQ/kQ (bounceable mainnet/testnet). Внутри этих 48 символов закодированы workchain, hash и контрольная сумма, разделённые особенностями base64url-алфавита.

Что это означает для глаза:

• Смешение регистров и цифр. base64url использует A-Z, a-z, 0-9, -, _. Глаз цепляется за заглавные буквы и цифры, остальные символы воспринимаются как шум.
• Префикс UQ/0Q одинаков у всех нон-баунсебл адресов, и проверка первых двух символов не даёт никакой информации. Реальная разделяющая часть начинается с третьего символа.
• Контрольная сумма размазана по концу, но проверить её на глаз невозможно — приходится либо доверять кошельку (он откажет невалидный адрес), либо сверять полную строку.
• Длина 48 символов ровно в той зоне, где краткие краевые проверки уже не работают, а полная сверка психологически слишком утомительна, чтобы делать её каждый раз.

Сравни с Ethereum, где адрес — 42 hex-символа с префиксом 0x. EVM тоже уязвим к address poisoning, но в TON цена ошибки выше: кошельки часто отображают только начало и конец адреса в интерфейсе истории, и пользователь видит ровно те символы, которые атакующий специально подобрал.

Workflow атаки шаг за шагом

Чтобы было нагляднее, разберём типичный сценарий — без выдуманных имён и сумм, чисто по шагам.

1. День -7. Ты переводишь $500 в USDT-jetton своему партнёру по адресу, начинающемуся с UQAB12 и заканчивающемуся 6F2C. Перевод проходит, всё нормально, история кошелька запоминает этот адрес.
2. День -6. Атакующий наблюдает за публичной активностью адреса твоего партнёра (например, через tonscan). Он видит входящий перевод от тебя и понимает, что ты — регулярный отправитель.
3. День -5. Атакующий запускает vanity-генератор и подбирает адрес UQAB…6F2C с теми же 4 символами на краях. Это занимает у него от нескольких минут до нескольких часов.
4. День -4. С этого адреса атакующий отправляет тебе 0 TON. В Tonkeeper в твоей истории появляется новая запись: «Получено 0 TON от UQAB…6F2C».
5. День 0. Тебе снова нужно перевести USDT партнёру. Ты открываешь кошелёк, заходишь в историю, видишь последнюю транзакцию с «привычными краями» и копируешь адрес — но это адрес атакующего.
6. День 0 + 1 минута. Ты вставляешь адрес в поле получателя, видишь те же UQAB…6F2C, мысленно подтверждаешь, нажимаешь «Подписать», подтверждаешь сумму на Ledger (если он есть), отправляешь. $500 уходит атакующему.
7. День 0 + 5 минут. Партнёр пишет: «не пришло». Ты заходишь в кошелёк, смотришь транзакцию — и видишь, что середина адреса совершенно другая. Возврата нет.

Атакующий за неделю работы получил $500 при затратах в десятые доли цента. Если он рассылает dust по тысяче регулярных адресов, ROI рассчитывается сам.

Vanity-генерация: как атакующий получает lookalike-адрес

Vanity-генератор — это утилита, которая перебирает приватные ключи и проверяет, удовлетворяет ли полученный адрес заданному шаблону. На TON для wallet v3/v4 это считается по фиксированной схеме: ключ → publicKey → hash контракта кошелька → user-friendly строка.

Сложность поиска экспоненциально зависит от количества требуемых символов:

• 4 символа на крае — порядка нескольких минут на современном CPU.
• 6 символов — часы на CPU или минуты на GPU.
• 4 спереди и 4 сзади одновременно — те же порядки, что и 6 подряд, потому что эффективное «совпадение» составляет 8 символов с обеих сторон.
• 6+6 — десятки часов на массиве GPU, экономически оправдано только для крупных целей.

Инструменты широко доступны как opensource на GitHub под названиями вроде ton-vanity, ton-address-grinder. Их легитимное применение — генерация запоминающихся адресов для проектов (например, кошелька, начинающегося с UQDEAD…). Те же инструменты с минимальными модификациями используются для address poisoning — задача та же, меняется только шаблон.

Стоимость атаки минимальна: GPU-час на облачной платформе обойдётся в $0.5-2. Газ за dust-транзакцию в TON — доли цента. Один атакующий с одной GPU за сутки готовит пул из сотен lookalike-адресов и запускает массовую рассылку.

Защита: never copy from tx history

Минимальный набор привычек, которые закрывают эту атаку почти полностью.

Никогда не копируй адрес из истории операций. Это правило номер один. История кошелька — это не справочник контактов. Атакующий контролирует, что попадает в твою историю (он может прислать тебе любой dust), и не контролирует, что попадает в твою адресную книгу (туда добавляешь только ты).

Веди адресную книгу с человеческими именами. В Tonkeeper встроена функция Address Book — добавляй каждого регулярного контрагента один раз с понятным именем («партнёр-USDT», «зарплата-холодный»). При следующем переводе выбирай его из списка, а не из истории.

Используй TON DNS / .ton-домены. Если у твоего контрагента есть .ton-домен, привязанный к адресу (например, partner.ton), используй его. Tonkeeper и MyTonWallet резолвят домен в полный адрес автоматически, и подмена partner.ton на визуально похожий домен требует от атакующего отдельной фишинг-операции — это совсем другой класс сложности.

Сверяй полный адрес, а не края. Если приходится копировать из новой переписки, сверяй адрес целиком хотя бы один раз — символ за символом. Это утомительно, но это единственный 100% надёжный способ.

Используй Ledger для крупных сумм. На экране устройства адрес получателя показывается перед подписью. Это твоя последняя контрольная точка. Если на экране Ledger ты видишь чужой адрес, не подтверждай.

iАдресная книга — это две минуты раз и навсегдаДобавление трёх регулярных контрагентов в Tonkeeper занимает 2 минуты. После этого address poisoning против тебя становится экономически бессмысленной атакой — атакующий не знает, что у тебя в адресной книге, и его dust остаётся в истории как нечитаемый шум.

Что делать если уже отправили на lookalike-адрес

Худшая часть address poisoning — практически нулевая обратимость. Если транзакция подтверждена в мейннете, средства у атакующего. Тем не менее минимальный план действий:

1. Зафиксируй транзакцию. Скопируй её хэш с tonscan, сохрани ссылку. Это понадобится для всех дальнейших шагов.
2. Проверь адрес атакующего на tonscan. Иногда атакующие используют один и тот же адрес для нескольких жертв. Если ты видишь много мелких входящих от разных адресов и одно крупное от тебя — это публичный поведенческий паттерн, который можно сообщить в экосистему.
3. Сообщи в Tonkeeper / MyTonWallet через support. Они маркируют известных атакующих как «scam» на уровне кошелька — твоё сообщение поможет следующим потенциальным жертвам.
4. Сообщи на tonscan через форму abuse. Помеченный адрес отображается с warning-баннером во всех интеграциях.
5. Если сумма крупная — обратись в TON Foundation через официальные каналы, иногда крупные инциденты получают координацию с биржами для блокировки вывода.
6. Документируй паттерн для команды/сообщества. Любая публикация о свежей атаке снижает её эффективность для остальных.

Подробнее общий алгоритм первой помощи описан в гайде что делать если украли TON.

Профилактика для команд

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

Минимальный продакшен-сетап:

• Multi-sig 2-из-3 минимум для исходящих транзакций. Один подписант не может ошибиться в одиночку.
• Allow-list получателей на уровне мультисига или внешнего реестра. Адрес добавляется в реестр после out-of-band проверки и подписи двух операторов.
• Источник адреса — не транзакция. Адрес получателя берётся из CRM, корпоративного реестра, подписанного контракта — но никогда из последней транзакции кошелька.
• Тестовый перевод. Для сумм выше определённого порога — сначала 0.1 TON, подтверждение получения по отдельному каналу (звонок, рабочий мессенджер, не комментарий к транзакции), потом основная сумма.
• Ротация операторов. Один человек не должен иметь право на крупные исходящие переводы без второго.
• Аудит истории раз в месяц. Сравнение исходящих с реестром получателей — простая SQL-выгрузка на скриптовом уровне.

Заключение

Address poisoning — это не атака на блокчейн и не атака на кошелёк. Это атака на привычку пользователя, и единственное лекарство — изменить привычку. Адресная книга с именами, TON DNS, сверка полной строки, мультисиг для серьёзных сумм. Всё это бесплатно, не требует ни специального ПО, ни технической квалификации, и закрывает поверхность атаки практически полностью. Цена внимательности — 30 секунд при настройке кошелька и 5 секунд при каждом переводе. Цена невнимательности — баланс кошелька целиком.

Источники

• SlowMist — Address Poisoning research
• tonscan — explorer для TON-адресов
• TON Documentation — user-friendly address format
• Tonkeeper — Address Book feature
• TON DNS — официальная документация